This example uses quite a few different techniques. It shows how to take an existing set of frames and change them to create a new monster using new characteristics for most of the frames. Frame orders, durations and code pointers have been changed to accommodate this. In addition, new graphics have been used illustrating how to replace graphics with ones that do not necessarily match the names of the original graphics, but do replace the correct part of a graphic sequence. For more details on graphic names and how they work, look follow the "Sprite Naming Conventions" links on the home page. Finally, to complete the process, I threw together some sounds using the normal demon sounds added to some fiery sounds from Hexen. The death sound could be improved a bit I think, but this is just a quick example.

It also includes a special patch that uses thing ID swapping to allow a hack of the stealth archvile in zdoom too.

This patch has only been tested with zdoom 1.23 beta 24.

This is a pretty extensive hack of a single enemy (the archvile) and assumes a reasonable degree of familiarity and understanding of dehacked.

The example Zip contains 5 files. They are:

demres.wad - The resource wad to support the patch

dem1.wad - A simple level with an archvile in it allowing you to find one without having to go searching.

dem1.bex - The patch file needed to make the Archvile into a demon.

dem2.wad - Another level, but this one also includes the Stealth archvile. Do not use this one with dem1.bex, Zdoom will crash.

dem2.bex - A patch to make both the Archvile, and stealth archvile work.

I used some sprites from "All Hell is Breaking Loose!!!" by Joel Huenink (jh32322@ltec.net). The files are dated 1996, I tried the E-mail address to get permission but the E-mail reported an error, so I suspect that address is no longer current. If anyone knows how I can get in touch with Joel, please let me know. If you are Joel, please let me know if you have a problem with me using your graphics.

The reason I used extra graphics was just to underline the fact the demon was untouched and the archvile was replaced with graphics that match the standard naming convention, and not necessarily the exact archvile sprite names. I also added/modified a couple of pictures myself to support the effects I wanted.

This patch, and resource wad does the following:

Replaces most of the archvile frames.

Replaces most of the archvile sprites.

Replaces the archvile sounds.

Hacks the archvile to behave like a fast, tough demon with a vicious bite.

What I did:

Ripped the graphics out of Allhell.wad and renamed them by simply typing ren sarg*.* vile*.* at the dos prompt.

Created a few extra graphics for the wait to wake up fire animation, and the rise from the fire sequence.

Made some new sounds.

Threw all the above into a WAD using DeePsea.

The rest is dehacking

In the thing editor (F2) I went to the archvile thing and set its general properties as I wanted. I left it's speed as it was (quicker than the demon). Made it the same size and mass as a demon and increased its pain chance to be closer to that of the demon. The archvile attack normally generates its own sound. As I wasn't using this, I used the Archvile "act" sound as its attack, and set its act sound to be the same as the demon.

I decided to have a 4 frame animation for the "wait to wake up state". In the frame table (F3) I worked on frames 241, 242, 243 and 244. 2 of these were already the AV waiting frames. I set them to have the right sprites, and made it so they played in numeric order and then cycled back to 241 using the next frame parameter. Frames 243 and 244 had to have their code pointer changed to "wait to wake up". Frame durations were also changed to look better. These frames just look like an animated fire.

Next I set the AV first moving frame to 245 in the thing editor. Using the frame table, frames 245 - 248 were given sprites that show the demon rising from the fire. They were also given the "turn to face player" code pointer so that the demon will "rise" without actually moving around. Possibly I could have used the "null" pointer here, but these work fine. As I only drew these frames from one angle, this code doesn't affect how the monster appears to face.

The next frames (249-256) were set to follow on from each other. I checked them for appropriate duration and gave them standard walking code pointers. Frame 256 loops back to frame 249 instead of 245 so that the rising frames are only shown once. All frames were set to use the correct sub sprites.

Back to the thing editor again, the AV pain frame was set to 257. Frame 257 was given a null bex code pointer to cancel out the one it already had. (This was done after finishing with dehacked, using a text editor to add in the bex section.) Frame 258 was given the pain code pointer, duration was modified and its next frame set to 249 in the walking sequence. Again, the frames were made to look right by setting the sprite sub number.

The AV far attack was set to 0, this is a close attack only monster.

The AV close attack was set to 259.

Frames 259 and 260 already had the correct, turn to face code pointers. I checked their duration and made them look right by setting the sprite sub number.

I then fiddled around with the durations of frames 261-264 to try and get the best combination of what I wanted to do. Giving consecutive frames a duration of 0 means the frames are played at the same time, and any effects associated with the frames are applied simultaneously. Putting a slight gap between frames can make the frames seem simultaneous, but allow for a bit of flexibility with what actually happens.

Basically all 4 of frames 261-264 have the demon bite code pointer. I first set the first 3 frames to have a duration of 0 and 264 to have a duration of 8. This gave him a helluva bite and a 100% health player was killed with one bite most of the time. Too tough. I then set the first 3 frames to have a duration of 2. This worked quite well. If you were against a wall or something, you usually got all 4 bites, or sometimes just 1, and next time all 4 (although it still appeared like 1 tough bite to the casual observer). In open ground, however, the first bite pushed you far enough away that you didn't get the others. Not tough enough. I eventually went for setting 261 to 0, 262 to 1, 263 to 0 and leaving 264 as it was. This usually gives 2 separate double bites and seems to work reasonably well, but you can still be hit by all 4 bites if you are unlucky. The Frame 264 was set to return to frame 249 in the walking sequence to finish off the attack and return to the walking state.

The AV death frame was set to 265.

The death frames were all given suitable sprites and durations, and set to follow on from each other in numeric order.

The frames used for the death had no code pointers, and so these were added using bex code pointers and a text editor after the dehacking was finished.

Frame 265 was given a "turn to face" code just in case what I had planned for the second last frame needed it. Not sure if it does.

Frame 266 was also given that pointer for the same reason

Frame 267 was given the code pointer that calls the death sound

Frame 268 was given the "set dead body mode" pointer

Frame 269 was given the pain elemental attack pointer to make it spawn a lost soul as a last dying act. :-)

Frame 270 was set to "null" using bex to cancel out its existing pointer. It had its duration set to -1 to make sure it never left that frame and the next frame set to 0 for the sake of neatness.

Frames 271 to 280 - previously part of the archvile, are now unused.

After going in to Zdoom and looking at the monster, I decided it looked better with all the frames set to "Bright", so I checked that for each one, except the last two death frames.

Finally, a couple of text replacements were put in for the Zdoom obituary and the end credit title.

The only problem with this patch is the stealth Archvile. The stealth monsters cannot easily have the frames they use modified as they have no entry in the thing editor. So if you put a stealth AV on a level with this patch loaded, Zdoom will crash as it is trying to use frames with inappropriate code pointers and next frames.