Essential DoD Skills I and II Finally Game-Ready!

Well, what about a not-shadow clone then? An honest-to-god clone (can you clone equipment?).

 

Sadly, no. I have a good idea based off of Kazeto's, though.

 

Is it just me or are QiGong's 3 Qi Blasting abilities fairly weak? I'm currently level 16 and just maxed out QiGong only to find out that Spirit Bomb seems to be incredibly weak. It has a huge radius radius but does even less damage than Qi Blast/Infusion, which are already a bit underwhelming. That and the cooldown is insanely high so you can hardly ever use it. The passive bonuses are great and Clear Meridians is useful, but the core abilities are a bit...disappointing.

 

It's not exactly weak, but rather situational (if you know how to use it, it can blast a large part of monster zoo, and it's useful for maraudering monsters). It could get a slight boost to be more useful, but I wouldn't say it's sub-par now.

 

Spirit Bomb only seems to be doing 3-8 damage to each enemy it hits, I can't see how that would be useful at all. Qi Blast/Infusion do quite a bit more damage as well as having a low cooldown, the only difference is the huge radius.

 

OH CRAP

Hahahaha -- Thanks for the catch, ElfBarf! There's actually supposed to be a 4th and final hit to Spirit Bomb that occurs the next turn and deals the bulk of the damage, but I accidentally left it referencing a custom template. If you go into the mod files for Essential DoD Skills I and copy the contents of manTemplateDB.xml (template id 600) into the game's core manTemplateDB.xml, you'll find that Spirit Bomb suddenly becomes worth it's huge cooldown.

This will also cause SB to deal a mild amount of damage to you along the way, but I think you'll find it's worth it. It should deal easily more than double the damage it was before.


As to the Qi Blasts being weak, they're kind of supposed to be. It is a Warrior class after all; the blasts are intended to soften bad guys up, not kill them.

 

It explains much. I actually did that myself to my DoD's files while trying to fix everything when I had time to sit around and do random things.

 

Tried that and it seems to have done the trick, it's pretty powerful now

 

First, move Template 600 to the very end of the TemplateDB.xml file if you haven't already.

Then, look very carefully at Template 89 and make sure you didn't do something to mix that up along the way. If it's borked, Ragnar's Meteor and the staff Ki Strike won't work, since both rely on it.

 

I just figured it out, I had replaced the manTemplateDB.xml file with the one from the mod as opposed to just copying the contents into the existing one. Now I have it all working, thanks

 

Warlockery's "Supercharge" skill crashes the game, immediately after playing the hero's kick animation (for some reason). Also, the Empowered Form buff just causes the hero to appear as though he's constantly walking, overriding any calls to make him stand idly still. Is that what it's supposed to do?

Also, Mana Crush fails to do most of its damage, and displays many concentric rings of the word "NO" written in white on a transparent background in place of actual effect tiles. A lot of content is similarly bugged with the two .zip files provided on the first post in this topic.

 

Strange, it didn't used to do that. I'll look into it and see if I can't figure out why.

Yep. It's a Polymorph, and none of the Polymorphed forms (diggle, demon, bat) use idle animations. It just happens to polymorph you into something that looks like the male hero.

The concentric rings of the word "NO" are intended. You should be seeing blue, X-shaped explosions that occur randomly centered on each of the tiles that say "NO" before the next "NO" circle forms. If you're not seeing them, there's definitely a problem, because I get them just fine on my machine. [/quote][/quote]

 

Windows XP, running 1.0.9 RotDG through Steam, mods unzipped into correct folder hierarchy (C:\Documents and Settings\Me\My Documents\Gaslamp Games\Dungeons of Dredmor\mods\*), applied template corrections to primary manTemplateDB.xml as provided by Essence (yes, I know how to use notepad). Running EDoD 1 and 2 alongside CK and Megacrafts, the latter two of which function normally, except the Vampiric Gauntlet's on-hit spell does not appear to function at all... in fact, most things in the spellDB.xml files don't seem to work.

 

Check skillDB. Replace all instances of the string "BU" with "Bu"; that will fix all 6 instances of accidentally capitalizing <secondaryBUff. I made the changes myself, but have yet to test whether or not they solve the problem. Supercharge's entry in spellDB looks fine.

That pattern you described occurs, but the damage it deals is so negligible that I assumed sprites/sfx/divine_inscription was an error handler tile substituted for missing graphics or broken effects - a MissingNO. if you will.

 

Well, I got the problem with Supercharged fixed. Silly me used "turns" instead of "amount" to declare the duration of a dot. Along the way, I extended the duration of Supercharge to 30, mostly just for fun.

Unfortunately, without more information, I don't really have any way to verify the problem with Mana Crush. I tried it in your circumstances -- WinXP, through Steam, running CK and Megacrafts, and it works just fine for me:



That's the last of many explosions, 10% of which leave those mana crystals on the floor. If that's not happening on your machine, I have no idea why.


[EDIT] Oh, the damage is low? ...wow, holy crap, you're right. I swear to God I more than doubled those numbers like 6 edits ago. Apparently that change got lost somewhere. New upload to fix Supercharged will also restore proper damage to Mana Crush. Thanks for the catch!

Also the divine inscriptions on the floor are a necessity -- if you don't have SOME form of graphical acknowledgement of those concentric circles, the game crashes. I just wanted to pick something visually interesting instead of another generic glint. [/EDIT]

 

I took the liberty of throwing together a somewhat more appropriate and visually impressive graphical acknowledgment for the express purpose of making this spell pretty.

http://www.brugenhagen.com/stephen/dredmor/

That directory includes the manacrush_up folder to be placed in sprites/sfx/, and the source .xcf GIMP workfile, wherein each frame of the animation is a layer. The individual .png images of the animation are indexed to 4 colors (the minimum necessary) in keeping with the standard used by the game's other sprite files, and are also named sequentially (manacrush_up0000, manacrush_up0001... manacrush_up0009) to match. This would theoretically allow them to be imported directly into a mod with no further assembly required, with the obvious exception of editing spellsDB to actually use the animation. (frames="10" and framerate="60" should be fine.)

If you like that, I can do more things of such nature. I think it would be cool to create a custom sound effect for the spells as well, which is something I can also do.

Thank you very much for fixing the various Super Saiyan goodies. I was worried that I had done something wrong and was therefore a big stupid idiot, and I am glad that was not the case.

 

digglemaggot, I REALLY like that graphic. Unfortunately, and I have no idea why because I'm not a graphics person, it's not showing up. I've added them to my mod's sprites/sfx/manacrush_up/ folder, and I've referenced them correctly ( <anim sprite="sprites/sfx/manacrush_up/manacrush_up" frames="10" sfx="choir" />, with or without framerate=
60"), but the game simply doesn't display them.

Which is odd, because it's clear that it thinks there's graphics there (the spell wouldn't work if there weren't some form of graphics attached to those concentric rings), it's just not displaying them. Which is quite disappointing. I'll keep needling it and see if I can figure out why. Once I do, I'll upload the change along with my more chaotic Ninpo thrownbuffs later this week.

 

They're probably not indexed .pngs. Run them through mtPaint, convert them to RGB, then convert them to indexed. Then, hit Save As, and make sure the transparency index is set to 1.

 

Pretty sure digglemaggot knows what he's doing.

Tried it exactly as you suggested just to be sure, to no effect.

 

Indeed, the images are indexed to a small palette - the way .png compression handles transparency is by declaring a color on the palette to be the transparent color, the "transparency index." Setting it to 1 will only solve transparency issues if the color mapped to index number 1 on the palette is the color intended to be transparent. However...

The images were made in GIMP, a program which assumes the user is worried about IE6 failing to display transparent 24bit .png files properly, and so doesn't display or allow editing of the transparency index because who seriously cares, right? Knowing this, I opened the images in mtPaint, and confirmed that each image's transparency index was set properly. However...

I noticed that all images belonging to a single animation group (.e.g. all images under sprites/sfx/divine_inscription/) have several attributes in common with one another; an important note is that they all have the same palette size, which is especially curious in the case of divine_inscription because the images use ~5 colors but their palette size is 9, meaning that most of the palette is unused, but present nonetheless.

I suspect the issue is that my images do not share a uniform palette.

I am currently struggling with mtPaint's "Our design goal was to have 5,000 buttons all conveniently accessible from a single dashboard the size of a Pop-Tart" interface philosophy. If all goes according to plan, I'll update the directory on my server, and let you know.

EDIT: All images now have the exact same palette, a feat I accomplished by first saving the palette as a .GPL file and then forcing the images to load it instead of the disorganized defaults. The directory URL I posted earlier reflects these updates.

If this doesn't work... is 64x64 pixels an acceptable canvas size for these animations? I checked the other files in sprites/sfx/ and 64x64 shouldn't be out-of-bounds since I saw one or two other images with similar or greater dimensions in either regard.