MrAlaux / Nugget-Doom

Nugget Doom is a fork of Woof! with additional features.
GNU General Public License v2.0
66 stars 3 forks source link

Reimplement `over_under` with code from DSDA #79

Closed MrAlaux closed 11 months ago

MrAlaux commented 12 months ago

This seems to fix #48.

MrAlaux commented 12 months ago

Sorry for mentioning you again, @kitchen-ace, but I'd be glad if all future discussion on this branch could take place in here now.

Also, if you don't mind, keep an eye out for new commits and try to stay up to date. No pressure, though.

kitchen-ace commented 12 months ago

No worries. I'll give this branch a try tonight or tomorrow. Thanks for your work on this!

kitchen-ace commented 12 months ago

So this is much better but I still got a few problems in The Parasite of Good Will. Mostly just pairs of cacos that got stuck, but something about the geometry of that one corner still causes a traffic jam, which makes me reluctant to call this 'good enough'.

If you want I can provide a save file right before the big fight in that wad, you still probably have to let the fight play out normally to test it.

nugg0000

nugg0001

Didn't have any problems in that Sunder map though, and UDUVUDU and other maps that didn't work with the mainline things-over-things still work fine here.

MrAlaux commented 12 months ago

If you want I can provide a save file right before the big fight in that wad, you still probably have to let the fight play out normally to test it.

Yes, please. Is it for RC1?

kitchen-ace commented 12 months ago

I made it for RC1 since that's probably the version you have if you downloaded it. I don't see a link to RC1 in the thread anymore so I'll upload it too, for posterity. The caco problem is version-independent.

Save has IDDQD and FULLCLIP enabled. Map is super dark so crank up the level brightness or use IDBEHOLDL.

If you walk more or less straight from where you start you hit a fleshy staircase, going up there and then looking to the right is where the caco cluster forms (once they've had time to rise out of that valley).

nuggsav7.dsg.zip

tpogw_rc1.zip

MrAlaux commented 12 months ago

Just tried it for the first time.

From what I could see, there were indeed many immobile cacos in that spot, but only two of them were fully stuck in each other; the rest of them were simply not moving because their attempted vertical move was blocked since there were other cacos above them.

This is behavior that I noticed but didn't think too much about, since my main goal was to stop them from clipping into each other. I'll see if I can make it so that they fall back to a horizontal move if the vertical one is blocked, but I'm guessing that that won't fix the clipping issue.

MrAlaux commented 12 months ago

I made the change described above, and while they're not getting stuck in that one spot anymore, now they're getting stuck here: imagen

I could already tell that lifts were going to be problematic. I'll have to see if I can apply a little noclip to things clipped into each other due to lifts ("little noclip" being something called tmunstuck in the code -- it should only let things get out of whatever's clipping into them, not let them go through walls and the like).

kitchen-ace commented 12 months ago

I'll have to see if I can apply a little noclip to things clipped into each other due to lifts ("little noclip" being something called tmunstuck in the code -- it should only let things get out of whatever's clipping into them, not let them go through walls and the like).

One thing to be mindful of here is that some maps intentionally place monsters stuck in each other, or in geometry. It's not common (and maybe things-over-things can just be disabled manually for those maps) but it does happen.

MrAlaux commented 12 months ago

Right. Optimally, the conditions would be very specific (clipped into something else specifically due to lift movement), but it's still something that could be done deliberately by maps. To be fair, over/under is, at its core, a feature bound to break some behavior anyways.

Perhaps I really should extend the setting so as to give the choice of only allowing the player to move over/under other things, which is probably the most-desired effect.

MrAlaux commented 12 months ago

Alright @kitchen-ace, I'm not entirely sure if you wanted over/under for just the player or for all things, but the former is now possible with the latest commit. Feel free to use that instead if it's what you prefer; it should prevent the issues with clipping flyers which I haven't been able to figure out yet.

Note: over_under == 2 is for all things (i.e. the behavior of previous commits of this branch), while over_under == 1 is for player only. An old CFG with over/under enabled will give you player-only over/under with these latest builds. Make sure you're using the one you want.

kitchen-ace commented 12 months ago

Thanks!

I don't have any objection to monsters moving over other monsters, but what I really care about is for the player to be able to run under flying things, or over monsters beneath a ledge, with minimal problems otherwise.

In any case there's no hurry for any of it. I appreciate you implementing it for player only though.

MrAlaux commented 11 months ago

@kitchen-ace, here comes another one.

From what I tested:

I'd be thankful if you could not only update to the latest commit, but also switch back to Over/Under for All Things, so as to further test it.

There might be issues if stacked things being raised by a lift clip into the ceiling, but I'm hoping that that won't be a common occurrence. I'll look into it later.

If you run into any other issues, feel free to go right back to Player Only. Hopefully that one does work properly.

MrAlaux commented 11 months ago

Excuse me, do you happen to remember any other maps with malfunctioning pop-ups? Particularly monster pop-ups, i.e. not stuff like YouDoVoodoo's breakable walls. I've encountered a handful myself over time, but they've been few-and-far-between enough to forget them.

While we're on it, anything to report on the last implementation?

kitchen-ace commented 11 months ago

Sorry for not making any reports for a bit. I haven't found too many problems with the current implementation, but occasionally a cacodemon or other flyer will get stuck in/on someone/something for no discernible reason. However I have come up with two relatively reproduceable cases in UDINO E4M2. Saves provided. I've renamed (symlinked) the nugget-doom binary to nugget2 for this branch, just in case it matters.

First is a room with a bunch of enemies that teleport in. Walk to the plasma rifle until things start teleporting in, turn around and bfg your way out, hang a right and go over the platforms over the blood, and then just wait a bunch for the teleports to finish. Sometimes there will be a caco that's stuck on another monster, often on a window ledge as well. nuggsav5.dsg.zip nugg0002

Second is the secret exit, walk up the red columns, kill the cyberdemon and everything to the left (South), then go back to the other side. There's a group of imps that are supposed to teleport in but usually at least one gets stuck below the floor. He's a little hard to find, you might need to use IDDT; if you kill everything visible and don't have max kills then anything left is probably stuck in that spot. nuggsav6.dsg.zip nugg0003

There was one other spot that was interesting in E4M3, because after awhile the stuck caco started to vibrate up and down violently, couldn't really get a screenshot of that happening though and I didn't save in time to be able to capture it by video. This is probably some of the try-to-get-unstuck code. This was also prior to the latest updates. (This screenshot sucks, there's a caco and a baron stuck in the same spot, but it probably doesn't help anyhow.) n01

I also (slightly) don't like being able to walk over decorations unconditionally because of maps that can use them to intentionally block the player. It's not really a big deal though.

MrAlaux commented 11 months ago

First is a room with a bunch of enemies that teleport in. Walk to the plasma rifle until things start teleporting in, turn around and bfg your way out, hang a right and go over the platforms over the blood, and then just wait a bunch for the teleports to finish. Sometimes there will be a caco that's stuck on another monster, often on a window ledge as well.

I made a similar setup, with monsters on a ledge and steps below it, and I got some monsters stuck indeed. I think the problem has to do with the thing below moving up the stairs and clipping into the thing above.

There was one other spot that was interesting in E4M3

Without a save nor other easy means to reproduce it, I don't think I can do much.

This is probably some of the try-to-get-unstuck code.

FWIW, there's no such code -- at least not the way I ideated it a while back.

This was also prior to the latest updates.

The changes made after the so-called "Grand Rework" shouldn't make a difference in that case. The issues you're describing sound like some that I had while working on said rework, but you didn't have access to those builds. No clue.

I'll look into the imp getting stuck in the floor later.

MrAlaux commented 11 months ago

First is a room with a bunch of enemies that teleport in. Walk to the plasma rifle until things start teleporting in, turn around and bfg your way out, hang a right and go over the platforms over the blood, and then just wait a bunch for the teleports to finish. Sometimes there will be a caco that's stuck on another monster, often on a window ledge as well.

I made a similar setup, with monsters on a ledge and steps below it, and I got some monsters stuck indeed. I think the problem has to do with the thing below moving up the stairs and clipping into the thing above.

Alright, that should be fixed by the latest commit. I've yet to look into the floor-stuck imp.

MrAlaux commented 11 months ago

I've absolutely no idea of what's wrong with that imp getting stuck in the floor in E4M2, and I'm not going to investigate any further because, whatever it is that causes it, it happens regardless of the Over/Under setting... and even in Woof. I think it's safe to say that it's not Over/Under's fault.

That leaves us with the stuck monsters from E4M3. I guess I'll try playing through the map myself to see if I can catch them (EDIT: first playthrough done, no stuck monsters).

By the way, about the binary renaming/symlinking thing (assuming that binary refers to the .exe): you do know that what matters in this case is not the .exe itself, but rather libnugget-doom.dll, right? As far as I get it, the .exe is just some sort of launcher for the .dll, which is what actually contains the engine. Just want to make sure that you're not accidentally updating the wrong files. You can update the .exe(s) if you want, but I believe that updating the .dll is what actually makes the difference.

kitchen-ace commented 11 months ago

I've absolutely no idea of what's wrong with that imp getting stuck in the floor in E4M2, and I'm not going to investigate any further because, whatever it is that causes it, it happens regardless of the Over/Under setting... and even in Woof. I think it's safe to say that it's not Over/Under's fault.

Weird, I have never encountered that bug before with that Imp but now I'm able to recreate it. Some obscure mapping problem. Anyhow you're right, not over/under's fault, sorry for the red herring!

(edit: I figured it out, a weird subsector from a nodebuilding error. The reason I assumed it was an over/under thing is because I often saw multiple imps on top of each other, which is from over/under, but aren't the cause of the problem itself.)

E4M3 just seemed like a weird one-off, I only mentioned it because of the vibrating monster thing. Don't expect you'll be able to reproduce it without playing through many times, so I wouldn't use it as a test case.

By the way, about the binary renaming/symlinking thing

Sorry, I'm using Linux, I should have been clearer. I still have mainline nugget as nugget-doom and so I've set up this branch to run when I use nugget2 as a command. It affects the cfg file (nugget2 looks for nugget2.cfg) so to be safe I thought I'd mention it in case it did something funny with the save files. Pretty sure it doesn't matter though.

MrAlaux commented 11 months ago

Alright, I'm thinking of merging this soon. Although it's evidently not perfect, it seems to be (much) less bug-prone than the implementation of the feature in master. What do you think?

kitchen-ace commented 11 months ago

Yeah, I think it's good to go. Could maybe be refined at some point but you're probably tired of tinkering with it for now ;) and it's a definite improvement.

MrAlaux commented 11 months ago

Alright, I'll give this a few finishing touches and merge it once and for all. If you come across any issues, even if rare, please don't hesitate to report them.

Many, many thanks for helping me with testing!