esselfortium

Okay, I've replicated the GZDoom bruiser fire attack bug you described. We're looking into another ZScript patch to solve it. Thanks for the report!

Hmmm. That attack had to be recreated from scratch for the GZDoom patch, so I'm not surprised to hear it's behaving differently, but that's not good. Hopefully there's a way it can be improved. The attack all spawning simultaneously on the bruiser itself is not what I've seen happen, though, so I wonder if that's a compat setting thing.

Hey Woolie! I also doubted it would see the light of day, for a long time. Somehow after resurrecting it from the dead in 2020 everything miraculously went pretty smoothly, and now here we are in the parallel universe where it actually exists. I posted a KDiKDiZD trick encyclopedia a few days ago that gives a brief explanation of pretty much every technical trick done here. If there's anything you're interested in hearing more about, I can try to explain in more detail.

I generally try to circle strafe around the outer perimeter and use the pillars to block their floor attack. Glad you enjoyed overall, thanks for playing!

Okay. The working solution is in KDiKDiZD, which adds 38 fullbrights as duplicates without replacing their original colors.

This is awful. Rest in peace Ghastly.

It is possible, but you need to do some palette optimization to allow for a small set of duplicate reds that can be made fullbright. This change also necessitates remapping any existing sprites and other graphics to use your new palette, which probably conflicts with your intended uses here as a mod. So scratch that whole idea, actually...

I didn't rename them anywhere in the deh9000 script, so I guess "Chaingun Sargeant" is just a default coming from somewhere. That's also what shows up in WhackEd4 if a new deh patch is created. Just calling it the Chaingunner or KDiZD Chaingunner is fine. Okay, then I guess their behavior is comparable to the ZDoom version. I didn't remember all the specifics. :) Thanks!

Some other fun clips from KDiKDiZD's development: And relinking the rocket zombie clip to have these all in one place:

Skullfly state is automatically set when they’re spawned by A_PainAttack. As for when they reach the lost soul limit, I just tuned the timing until it seemed reasonable and I don’t know the underlying details.

KDiZD used scaling in-engine to increase their size by something like 1.2x, and upscaling the actual sprites by that amount for a comparable size here would have lead to a lot of awkward resizing artifacts unless all of the sprites were then painted over by hand to adjust all the details for the new size.

But why?

Thanks for playing, I'm glad you liked it! Vader was kind enough to grant permission to use the Soul Reaper sprites in this. I also used some marble STAR textures that I originally made myself for TSoZD. I avoided using any other TSoZD resources (unless I overlooked something). A remake of Z1M10 might be added in a future update, but no promises. The timeline just didn't work out to get it into this release, as I promised myself early in the year that I would definitely get it done this year. At one point I had rocket zombies implemented, but they were so prone to killing themselves and each other that I decided suicide bombers would be a more fun inclusion as a "panic monster", since they run around and give the player more indication of their presence. Removing the rocket zombie also meant being able to repurpose A_CyberAttack for the Hell Warrior's shield, as explained in the trick encyclopedia post above. There was a particularly funny moment I somehow managed to capture on video (albeit without sound) in which I enter a room with three rocket zombies, and somehow all three of them kill each other after being woken up by a shot.

I wouldn't think so, since /newstuff was reviewing things that were uploaded to the idgames archive. (At least, unless someone actively requested to have their wads removed from idgames...)

Camera textures: Type 1: Created using screenshots and Photoshop, disassembling the scene into multiple layers and then arranging those layers in Doom Builder as thin self-referencing sectors that can be moved using floor/ceiling actions. Type 2: Created using videos and Photoshop, reducing the video to a small set of frames that a script can step through ingame by instant-lowering a series of very thin sectors in sequence. In some cases, type 1 and 2 are combined for different parts of the scene, so a rising bridge will be a type-2 frame by frame animation while the nukage surrounding the bridge will be a separate layer in front using a looping animated texture. The camtexture near the original Military Base exit in Z1M9 uses type 1 for the lowering barrier and type 2 for the raising bridge. Half-cylinder projections instead of 90-degree lines are used for two reasons: This allows for more pixel detail to be fit into a smaller window shape. Using angled lines allows for much smaller gaps between each layer of the display, within the limitation of Doom's 1-mapunit grid size, so that multiple animation frames and masking layers can appear to all be a single layer. Scripting: These use a modified version of Linguica and Nine Inch Heels' Mikoportal-based scripting setup. My first modification is using an Explosion Generator (a dehacked object that calls A_Explode every tic) to blow up the barrels that slightly push the voodoo doll, rather than relying on a crusher, which is unreliable on barrels (crushers can randomly turn them into gibs and not explode). My second modification is using a dedicated thing type created in dehacked to temporarily block the voodoo doll until a script has been activated. Originally lost souls were used, but this broke in nomonsters for obvious reasons. For the final script action when the Bruisers are defeated at the end of Z1M8, a door is opened via A_KeenDie which allows an Explosion Generator to destroy the dehacked object blocking the voodoo doll's path. This was for some reason more finicky than the other Mikoveyor setups, which is why the voodoo setup for it is rotated 90 degrees in the final map (as otherwise the script would fail due to the doll not keeping its momentum). Sliding doors: The sliding doors in Z1M4 and Z1M5 use Mikoveyor scripts and a sequence of instant-lowering sectors. The sliding door seen from a camtexture in Z1M2's computer maze was an actual polyobject sliding door, spawned in the map using an ExtraData lump and recorded as video, then reconstituted as a series of thin instant-lowering self-referencing sectors using the "type 2" camtexture method described above. PLAYPAL and COLORMAP modifications: Dark reds incorporated from BTSX palette, so that red doesn't turn brown in dim areas. This is done by increasing the contrast on the low end of the red and desaturated-red ramps, so it doesn't use up any additional space in the palette. 38 fullbright colors squeezed in by eliminating duplicate and near-duplicate colors from the palette, to allow for bright lights in non-fullbright sectors, without sacrificing any standard color ranges. "Baronheist 451" Green, brown, desaturated red, and gray ranges rearranged heavily in order to use Dehacked's multiplayer sprite remapping flags (which normally turn greens into one of three other colors) on Barons/Hell Knights, Demons/Nightmare Demons, and the xdeath sprites for Imps/Dark Imp. The first step was to turn the 32-color brown and desat red ramps into two non-contiguous 16-color ramps each, putting the odd-numbered colors into one ramp and the even-numbered colors into another. Because the color remapping flags only utilize the bottom 16 colors out of these 32-color ranges, I needed to do this so that the affected monsters' sprites could retain their entire dynamic range, in a quantized form. The second step was to swap the ranges' placements around so that the usual green ramp is now desat red, desat red ramp is now the green ramp, etc. This was necessary so that Barons' desat red skin could be remapped without affecting their green hands. The third step was to rearrange these rearranged ramps a second time to put them out-of-order (but keeping them all in the same order as each other, for remapping to work), so that the brown color used for lines in the automap would still be in the same place Doom expects it to be. The fourth step was to remap the actual sprites in Slade, quantizing skin tones into the remappable desat-red ramp. For the Doomguy sprites, I needed to first quantize the desat reds in those sprites (i.e. blood) into the non-remappable desat red range, then move the greens into the remappable desat red range. The fifth step, done a while later, was to swap some of the darker grays from elsewhere into the palette into the remappable gray range, so that Nightmare Demons could be higher-contrast and better-looking. Lastly, the dehacked patch applies the color remap flags as needed, including on the dead marine decoration sprites so that they look as expected ingame. Dehacked: Hell Warrior shield This works by spawning a non-moving shootable "projectile" via A_CyberAttack, which lasts (nearly) the same duration as the Hell Warrior's shield-holding state. (The "nearly" is in order to allow time for its other projectile attacks to pass through it.) The player's rocket is moved to the BFG projectile slot so that A_CyberAttack can become an additional monster-only projectile type, rather than replacing one of the other monster projectile types. The projectile's radius is set to 32 so that it is wider than the Hell Warrior itself, so that it can intercept shots before they reach the Hell Warrior. Its speed is set to the lowest possible decimal value (exactly 1 rather than the usual 1*FRACUNIT) to work around an oddity in Doom's projectile spawning code where newly-spawned projectiles are moved once without updating their blockmap links. This is ordinarily not a problem in Doom because projectiles are not supposed to be in the blockmap, but a projectile can't become shootable without being in the blockmap. This could originally cause infinite-loop crashes where blockmap links would become invalid, but has been more or less fixed by reducing the total distance it's moved to only 0.000007629394531 of a mapunit, making it effectively impossible to leave its original block. Resurrecting monsters This was accomplished via invisible dehacked entities that move fast, look for a monster to resurrect via A_VileChase, and immediately stop existing after they find one. Suicide Bombers Making these less unfair in vanilla meant solving two basic problems: Their xdeath needs to skip over their A_Explode state, so that they don't explode a second time while dying. Their radius needs to be widened a bit so that the player cannot be as close to the center of the explosion, as it's not possible to customize A_Explode's parameters. Mauler Demons These use the lost soul behavior for their charging attack, similar to how they work in ZDoom. To keep them from falling asleep after charging, I inserted A_FaceTarget into their Spawn state (which the skullfly behavior is hardcoded to return to), which does nothing if they don't have a target yet but effectively gives them full surround vision if they do have a target. This means that as long as there is a line of sight between them and the player, they will wake up again and return to their See state as soon as their skullfly attack ends. Bruiser Demons For their fire attack, the lost soul is replaced with an object that calls A_PainAttack to spawn another of itself in front of itself, and then stops existing. This results in the "homing fire" effect seen ingame. A long invisible state is added at the end of the fire object's animation in order to finetune the effects of the lost soul limit, so that they will stop after enough have spawned rather than continuing to follow the player indefinitely. The original lost soul is moved to a different dehacked slot, and extra A_Chase frames of half their original duration are added to replicate the "attack twice as often" behavior that's hardcoded to their original slot. Walkable lamps Z1M1 has a floor lamp that can be walked on. It's just a non-solid decoration in dehacked combined with a self-referencing sector in the map. Seismic Bomb explosion Z1M1's timed seismic bomb explosion works by activating a voodoo script that first opens a small window allowing an Explosion Generator to kill the "bomb explosion" object, whose death state consists of three countdown beeps followed by the explosion itself. This is timed to sync up with the voodoo script's instant-lowering of the wall to reveal its exploded remains. Instakill forcefields Rather than using the old method of telefragging a voodoo doll, KDiKDiZD's instakill forcefields rely on Explosion Generators placed through small invisible windows on each side of the field. This allows them to affect monsters and co-op players that pass through, and can be turned on or off at will by opening or closing the window. Teleporting berserk pack The teleporting berserk in Z1M5 was done by making a shootable duplicate of the berserk pack, and using an Explosion Generator to push it across a teleport line. Because its death state is the same as its spawn state, it doesn't matter that it can be killed. Center guns while firing By using the misc1/misc2 fields to set weapon offsets to 1,32 while firing, vanilla can mimic ZDoom's behavior where weapon sprites are automatically centered while firing. Quiet imp The imp that hides and walks away from you in The Party uses the old trick where a negative speed is set and the sprites' frames are swapped. Replacing the final state Dehacked.exe had a bug where modifying the final state in the table would cause an overflow, breaking other things. I've worked around it by leaving that final state unmodified, and instead working it and its predetermined nextstate into a sequence of other states. Texture effects: Translucent floors and reflective floors These are my vanilla version of an old Boom trick, wherein midtextures with the translucent line flag would be aligned under the floor to "bleed over" the flats and create the appearance of translucent flats. Because vanilla doesn't have translucent lines, I instead recolored the midtextures to more closely match the color range of the flats (and sometimes vice versa, recoloring both the textures and the flats), and applied a dithered transparency mask to the textures so that the midtextures can be seen through in the transparent spaces between pixels. For Z1M8's reflective marble floor, the textures were also mirrored, and upside-down recolored torches were created in dehacked to complete the effect. Because this effect breaks if there is any visible change in sector properties on the affected floor, I also applied baked-in gradient lighting to the walls and used some fullbright red ceiling flats to add contrast. Midtexture slopes: Simple ceiling slopes with solid black inside them and shadowcasting baked into the textures below them, the usual approach. (For instance, the arches in the Z1M3 mines.) Slopes using palette-fullbright solid colors inside them, as another way to create an illusion of solidity. (For instance, the slopes beside the nukage bridge in the first room of Z1M5.) Slopes using 256-brightness sectors inside them with noise-patterned textures/flats inside, with baked-in lighting to appear more solid. (For instance, the arched corridors in Z1M5 and Z1M7, the "broccoli" room near Z1M7's forcefield switch, or the sloped ramp in Z1M1's opening outdoor scene.) Slopes using 256-brightness sectors inside them with LITE5-style shading inside them, to create sloped lights. (For instance, the lit gates here and there in Z1M4 or the sloped green lights in Z1M5's small outdoor nukage courtyard.) Baked-in lighting: Rather than using individual sectors for small gradients, I often made pre-baked textures and/or flats with gradiented shadowcasting already applied to them. Areas with colored lighting were done simply by recoloring the affected textures/flats in Photoshop. Rotating objects: Z1M4's ceiling fans and hologram screen use the old method of making an animated texture with all frames transparent except for one, applied to an asterisk shaped arrangement of lines with a different animation start offset on each line. Z1M3 and Z1M5's spinning nukage mixers use a modified form of the above method that also creates the appearance of solid geometry by applying animations also to the outer sides and changing the animation starts on the backsides to be one step out of sync from the front sides. Extra keys: In maps that use more than the standard R/Y/B key arrangement, key doors were simulated using thin sectors that instant-lower when the key is picked up. That should be... most of it :-)

Don't use Fandom, it's a mess. The Doom Wiki that's actually maintained by the community was moved to doomwiki.org over a decade ago, and the old version only still exists because Fandom actually won't allow us to have it removed because they want to keep getting ad revenue from it.

Hmm, I don't really have an article-worthy answer for that one. I probably converted it 15 years ago using different tools or simply with less knowledge of what vanilla could handle, and I never noticed it afterwards. I guess I could convert the SSG sounds again.

Thank you! It's been submitted to Spotify so it should show up there in a few days.

Playing the sound from the weapon itself (via the A_LoadShotgun2 codepointer) instead of from the projectile prevented some noticeable sound dropouts I was getting with it in vanilla.

I don't know why I'm credited as a secondary mapper on Z1M1, I only did a few revisions for the 1.1 update (since I was around already for TSoZD) and wasn't involved in its original creation at all. In any case, KDiKDiZD was based on the original 1.0 release of KDiZD. I can add Vader's credit to Z1M7.

My latest soundtrack just came out today, for the visual novel Please Be Happy. Soundtrack on Bandcamp: https://esselfortium.bandcamp.com/album/please-be-happy-ost Please Be Happy on Steam: https://store.steampowered.com/app/844670/Please_Be_Happy/ Soundcloud:

You can run out of the window at the stairs nearby it, if you start from the top of the stairs.

As for KDiKDiZD, I don’t think there’s enough space left to add smooth weapons to it via dehacked, at least not without using MBF21 extensions (and thus restricting it to MBF21-supporting ports). The vanilla deh states table is already packed pretty full.

Thanks for playing, glad you enjoyed! I think the non-damaging parts you ran into are due to the use of self-referencing sectors in that area. I'm not sure whether I can do much about it.

"Kenran Butou Sai: The Mars Daybreak"