Knee-Deep in KDiZD: Released! It's KDiZD for doom2.exe - 1.7.1 is now on /idgames

Loving it so far, enjoying looking at all the effects and pondering how it was done with Vanilla compatibility. One minor complaint is it took longer than I would have liked to pick up a shotgun in the first map.

3 hours ago, taufan99 said:

In Vanilla Doom II, secret exits can only be placed in MAP15, in addition to a super secret exit in MAP31. KDiZD only has a single secret level, so yeah...

KDiZD actually has a super-secret level, Z1M10, but it's reached through a script from the Z1M7 normal exit if you fulfill certain requirements (if you don't meet them, you get sent to Z1M8), instead of relying on a secret exit as usual. For KDiKDiZD, it probably would have to be added as a regular super secret level reached from a secret exit in MAP31: Z1M9...

On mardi 22 novembre 2022 at 9:36 PM, esselfortium said:

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.

22 hours ago, NightFright said:

The final fight against those Super Barons was surprisingly tough. Tbh I am not sure how this is supposed to be done without kicking the bucket. Basically, stop moving and you can admire the floor textures from close range. If that was the idea, then well done. For my taste it was still kinda hard, especially when playing on ITYTD (which I always do in my first playthroughs). But well, with a lot of persevereance it's managable.

If someone is having trouble in that fight I would suggest that they focus on avoiding the deadly ground-based homing attacks at the expense of doing basically anything else well. That means don't worry about aiming rockets even half-decently, about trying to pick up items well, about avoiding other sources of damage, about even face-rocketing. Usually a "mistake" people make when fights are hard for them is indiscriminately trying to do everything well, but they do that in a way that makes them worse at the fight's bottlenecks. (This is why generic heuristics for playing like "try to conserve ammo" are usually harmful in harder wads.) It's paradoxical, but hard encounters require "worse" play (or less tongue-in-cheek: require greater cognizance of what you don't have to do well).

Holy shit! I remember seeing posts promoting this way back around KDIZD was new and doubted it would see the light of day even then, and then I find it came out 15 years later on Something Awful. I cannot understand how you managed to complete it. Almost every room has some sort of eldritch sorcery that should not exist, but it does. The maps look so similar on the surface to the originals, but play like good Doom levels instead of design-by-committee sprawls of rooms and corridors with awkward, intrusive detailing. And I never expected to see a vanilla mapset make framerates drop on my 1733 MHz Athlon rig (I used doom2-plus under PC-DOS 7). The DECORATE monsters have been redone in Dehacked and are somehow improved in the process. There are 38 colors set aside for fullbright, yet the color variety is not that severely effected. How is this even possible?! 🤯

Because the basis for a lot of these maps is older, parts of it almost feel like a missing link stylistically between Espi's maps and Back to Saturn X. While I'm not usually a big fan of "painting the fourth wall" in wads, here the self-conscious, set-like elements like the intro dressing room that sets up each map's scripting, the cardboard cutouts of some of the fanciest constructions from the original KDIZD, and the power adapter switch with giant American electrical outlets go hand-in hand with the wad's reliance on illusions and trickery to fake things that are technically impossible in vanilla. Do you ever plan on writing some articles on how you accomplished some of these tricks, because this has totally blown my mind and I want to know how it works.

E: I'm also impressed at how good the midis sounded with the AWE64 soft synth (can't use my Sound Canvas in protected mode DOS apps because Creative drivers are the worst). The DOS synth is pretty crappy and a lot of midis sound underwhelming on it.

On 11/11/2022 at 8:37 PM, Edward850 said:

KDiKDiKDiZD is a wolf3d mapset from 2037.

Don't give me ideas. 😜

14 minutes ago, Woolie Wool said:

Holy shit! I remember seeing posts promoting this way back around KDIZD was new and doubted it would see the light of day even then, and then I find it came out 15 years later on Something Awful. I cannot understand how you managed to complete it. Almost every room has some sort of eldritch sorcery that should not exist, but it does. The maps look so similar on the surface to the originals, but play like good Doom levels instead of design-by-committee sprawls of rooms and corridors with awkward, intrusive detailing. And I never expected to see a vanilla mapset make framerates drop on my 1733 MHz Athlon rig (I used doom2-plus under PC-DOS 7). The DECORATE monsters have been redone in Dehacked and are somehow improved in the process. There are 38 colors set aside for fullbright, yet the color variety is not that severely effected. How is this even possible?! 🤯

 

Because the basis for a lot of these maps is older, parts of it almost feel like a missing link stylistically between Espi's maps and Back to Saturn X. While I'm not usually a big fan of "painting the fourth wall" in wads, here the self-conscious, set-like elements like the intro dressing room that sets up each map's scripting, the cardboard cutouts of some of the fanciest constructions from the original KDIZD, and the power adapter switch with giant American electrical outlets go hand-in hand with the wad's reliance on illusions and trickery to fake things that are technically impossible in vanilla. Do you ever plan on writing some articles on how you accomplished some of these tricks, because this has totally blown my mind and I want to know how it works.

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.

10 hours ago, baja blast rd. said:

 

If someone is having trouble in that fight I would suggest that they focus on avoiding the deadly ground-based homing attacks at the expense of doing basically anything else well. That means don't worry about aiming rockets even half-decently, about trying to pick up items well, about avoiding other sources of damage, about even face-rocketing. Usually a "mistake" people make when fights are hard for them is indiscriminately trying to do everything well, but they do that in a way that makes them worse at the fight's bottlenecks. (This is why generic heuristics for playing like "try to conserve ammo" are usually harmful in harder wads.) It's paradoxical, but hard encounters require "worse" play (or less tongue-in-cheek: require greater cognizance of what you don't have to do well).

I beat the final battle quite easily by herding the bruiser demons towards the middle of the arena and continuously circle-strafing. I actually didn't even realize that the explosions were even homing until I had killed most of them and slowed down to mop up. The red marble room that fills with barons, hell knights, and chaingunners was a lot harder in my opinion. Only the rocket launcher can do enough damage to give you space, but you don't have enough space to use the rocket launcher without risking Good at Dooming yourself.

There seems to be something wrong with how the bruiser behave in GZDoom. I used gzdoom-4-8-2-Windows-64bit to get some screenshots for the wiki and noticed that the bruiser hurt themselves when firing their lost soul attack. As a result, they eventually kill themselves if one circlestrafes around the perimeter for long enough. The lost souls also do not follow the player nearly as long as they do on Eternity. They're still homing but stop respawning after a short distance. And, again, it seems most of the lost souls spawn all at once on the bruiser itself. I'm not using any mods and compatibility is set to Doom strict.

11 minutes ago, Gregor said:

There seems to be something wrong with how the bruiser behave in GZDoom. I used gzdoom-4-8-2-Windows-64bit to get some screenshots for the wiki and noticed that the bruiser hurt themselves when firing their lost soul attack. As a result, they eventually kill themselves if one circlestrafes around the perimeter for long enough. The lost souls also do not follow the player nearly as long as they do on Eternity. They're still homing but stop respawning after a short distance. And, again, it seems most of the lost souls spawn all at once on the bruiser itself. I'm not using any mods and compatibility is set to Doom strict.

 

  Reveal hidden contents

 

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.

42 minutes ago, esselfortium said:

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.

It seems that more lost souls are spawned than intended and a lot of them at same time rather than one after another. A lot of time, while all three bruisers are still alive this also seemingly results in the lost soul limit being hit as one or two of the bruisers are able to spawn anything when they fire their ground attack.

I tried again on default compat setting, and surprisingly, nothing changed. They still hit themselves, AND they still whiff their attack if firing right after another despite no Lost Soul limit...

They also often fire their melee attack right after their lost soul attack, probably because their pain state was triggered by the lost souls.

So yeah, this fight seems to be somewhat broken on GZDoom. At least for me.

EDIT: I downloaded the newest version of GZDoom just to be sure and also switched to OpenGL as the API (but of course still using Software Renderer) instead of OpenGL ES. Same results as before.

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!

Public Build 6: Downloab

Fix list:

Z1M8: Fix Bruiser fire attack self-damage bug in GZDoom

Z1M9: Fix stuck demon in GZDoom

Updated credits for better clarity and more thoroughness

Updated statusbar CELL display to RIFL

Flare rifle no longer leaves plasma decals in GZDoom

Huge thanks once again to Mikolah for the GZDoom-related fixes in this build!

Ok, i tried out the new build with GZDoom-4-9-0, and while the bruiser self-hit is obviously resolved, there are still some discrepancies with how the fight goes in Eternity and DSDA. For starters, the bruisers, like before, still definitely fail their ground attack more often than in Eternity/DSDA, like they are canceling each other out. This also does happen in Eternity/DSDA, especially when all three are still around as they no doubt hit the LS limit in the map, but it's still a somewhat rare occurrence, while here it seems to be almost every other attempt that fails for one or two of them. This doesn't seem to have anything to do with the normal LS limit, as the amount of spawned lost souls doesn't seem to be tied to the LS limit at all. If i use complv 9 in DSDA, the whole room gets flooded with them until my framerate starts tanking - like you would expect. On GZDoom, switching to Boom compatibility doesn't change anything about the amount of spawned fireballs.

The other thing that still persists is that the lost souls don't seem to home in on you as much as you would expect. They also don't follow you for as long, so maybe one is a consequence of the other. But the result for sure makes the attack less threatening; which might be a good thing for some people.

33 minutes ago, Gregor said:

Ok, i tried out the new build with GZDoom-4-9-0, and while the bruiser self-hit is obviously resolved, there are still some discrepancies with how the fight goes in Eternity and DSDA. For starters, the bruisers, like before, still definitely fail their ground attack more often than in Eternity/DSDA, like they are canceling each other out. This also does happen in Eternity/DSDA, especially when all three are still around as they no doubt hit the LS limit in the map, but it's still a somewhat rare occurrence, while here it seems to be almost every other attempt that fails for one or two of them. This doesn't seem to have anything to do with the normal LS limit, as the amount of spawned lost souls doesn't seem to be tied to the LS limit at all. If i use complv 9 in DSDA, the whole room gets flooded with them until my framerate starts tanking - like you would expect. On GZDoom, switching to Boom compatibility doesn't change anything about the amount of spawned fireballs.

 

The other thing that still persists is that the lost souls don't seem to home in on you as much as you would expect. They also don't follow you for as long, so maybe one is a consequence of the other. But the result for sure makes the attack less threatening; which might be a good thing for some people.

The current implementation of that attack for GZDoom is basically completely rewritten from how it works elsewhere. But after the latest revision it's actually be possible now to make it behave much closer to how it does in vanilla. Since the fire attack now passes through the Bruiser instead of getting stuck inside it, it no longer needs custom code to handle positioning the fire objects, only to apply the limit so that they don't recurse infinitely. I'm experimenting with this change now, and it does seem to be working more like it does elsewhere.

This is an amazing map set! It's been decades since I played the original KDiZD, and I love how well everything was demade for vanilla, and I gave it a few playthroughs. I have found a bug(?) that I don't think anyone else has possibly pointed out yet(?).

In Z1M5, there's this blue armour on this ledge, with no obvious way of getting to it. Looking at it in Doom Builder shows a teleport landing Thing on this ledge, and the sector itself is all tagged up, but there doesn't seem to be any linedef actions pointing towards it? At least not any I could find.

5 minutes ago, Beed28 said:

This is an amazing map set! It's been decades since I played the original KDiZD, and I love how well everything was demade for vanilla, and I gave it a few playthroughs. I have found a bug(?) that I don't think anyone else has possibly pointed out yet(?).

 

In Z1M5, there's this blue armour on this ledge, with no obvious way of getting to it. Looking at it in Doom Builder shows a teleport landing Thing on this ledge, and the sector itself is all tagged up, but there doesn't seem to be any linedef actions pointing towards it? At least not any I could find.

You can hop down to it from a nearby lift if you time it right.

45 minutes ago, esselfortium said:

You can hop down to it from a nearby lift if you time it right.

It's a bit tight but I did manage it. I did just discover that one of the linedefs on this ledge is flagged as impassible (possibly by accident?), which I missed while looking at it in Doom Builder.

3 minutes ago, Beed28 said:

 

It's a bit tight but I did manage it. I did just discover that one of the linedefs on this ledge is flagged as impassible (possibly by accident?), which I missed while looking at it in Doom Builder.

It was really easy to overshoot and fall off after making the jump, so I flagged that line as impassible.

Does the latest public build include fixes for playing it in Doom Retro? I set up DR earlier today and had issues with the prior build, but they seem to have been fixed with build 6, so I'm curious about that.

I’m not sure what the specific issues with it in Doom Retro are, I haven’t tried it.

3 hours ago, esselfortium said:

The current implementation of that attack for GZDoom is basically completely rewritten from how it works elsewhere. But after the latest revision it's actually be possible now to make it behave much closer to how it does in vanilla. Since the fire attack now passes through the Bruiser instead of getting stuck inside it, it no longer needs custom code to handle positioning the fire objects, only to apply the limit so that they don't recurse infinitely. I'm experimenting with this change now, and it does seem to be working more like it does elsewhere.

I'm curious. Why does it need to be rewritten in the first place? Shouldn't A_PainAtttack work the same under GZDoom? I thought Mikoveyors would be the main hindrance to get this running.

Just now, Gregor said:

I'm curious. Why does it need to be rewritten in the first place? Shouldn't A_PainAtttack work the same under GZDoom? I thought Mikoveyors would be the main hindrance to get this running.

There was an issue where their fire attack was always getting stuck inside them. The initial ZScript fix was to reimplement the behavior entirely, but since the other fix was made today, the rest of the vanilla behavior can be restored aside from the part that enforces the lost soul limit, which otherwise doesn’t work on the ZScript-redefined fire things.

14 minutes ago, esselfortium said:

I’m not sure what the specific issues with it in Doom Retro are, I haven’t tried it.

The ones I encountered were the Doom episodes showing up in the Episode Select menu and some bright pixels on some of them, barrels turning into stuff, and E1M1 as the first map instead of what it should be. But all that appears to be fixed in build 6, as far as I can tell.

4 minutes ago, Dweller said:

 

The ones I encountered were the Doom episodes showing up in the Episode Select menu and some bright pixels on some of them, barrels turning into stuff, and E1M1 as the first map instead of what it should be. But all that appears to be fixed in build 6, as far as I can tell.

KDiKDiZD needs to be loaded with Doom 2, not Ultimate Doom.

Hopefully everything will work in Doom Retro now but I can’t make any guarantees. There are some setups later on that might potentially break in untested ports, like the Z1M8 bosses, so fingers crossed it’ll behave.

8 minutes ago, esselfortium said:

There was an issue where their fire attack was always getting stuck inside them. The initial ZScript fix was to reimplement the behavior entirely, but since the other fix was made today, the rest of the vanilla behavior can be restored aside from the part that enforces the lost soul limit, which otherwise doesn’t work on the ZScript-redefined fire things.

I see. So i guess decorate wasn't an option for GZDoom for this wad.

Just now, esselfortium said:

KDiKDiZD needs to be loaded with Doom 2, not Ultimate Doom.

 

Hopefully everything will work in Doom Retro now but I can’t make any guarantees. There are some setups later on that might potentially break in untested ports, like the Z1M8 bosses, so fingers crossed it’ll behave.

Oh, I must have forgotten to load it with Doom 2, then. But I'll keep an eye out for anything that breaks, though

28 minutes ago, Gregor said:

I see. So i guess decorate wasn't an option for GZDoom for this wad.

ZScript was needed to fix the mikoveyor setups for GZDoom. I'm not sure whether DECORATE would have been able to handle those in a straightforward way, or at all. And then it was simpler (and more flexible) to also use ZScript for the other fixes, instead of mixing old and new approaches.

Btw, is it possible to implement the kind of hardcoded state change as you do for S_VILE_HEAL1 in the source code without DEH9000?

1 minute ago, Gregor said:

Btw, is it possible to implement the kind of hardcoded state change as you do for S_VILE_HEAL1 in the source code without DEH9000?

Sure. You would need to find that state by its number in WhackEd and modify it directly.

Regardless of the dehacked editing method being used, you can't change which state A_VileChase is hardcoded to jump to, but you can modify the contents of that state.

2 hours ago, esselfortium said:

Sure. You would need to find that state by its number in WhackEd and modify it directly.

 

Regardless of the dehacked editing method being used, you can't change which state A_VileChase is hardcoded to jump to, but you can modify the contents of that state.

But Whacked doesn't seem to expose these kind of hard-coded states to the user. It just shows you that the state uses the VileChase code pointer but nothing more. I can only choose the action for the state.

Can this be implemented through the parameters perhaps?