bradharding / doomretro

The classic, refined DOOM source port. For Windows PC.
https://www.doomretro.com
GNU General Public License v3.0
653 stars 79 forks source link

[Feature Request] Ability to Force Vanilla Comp for Mapsets that rely Vanilla Limits/Bugs as Features #696

Open andrikpowell opened 2 years ago

andrikpowell commented 2 years ago

I've looked through all the command-line parameters and console commands and I wasn't able to find some of the settings that would make the vanilla megawad I'm currently working on to work correctly in Doom Retro.

I have maps that specifically rely on these Vanilla quirks/limits:

I was messing around with Doom Retro and I really like some of the added effects, though as it currently is, I won't be able to tell people to play the megawad (when it releases) in Doom Retro, since there's no way to toggle these Vanilla bugs/limits.

bradharding commented 2 years ago

I'll look at implementing most/all of the following (copied from ZDoom's wiki):

Crushed monsters can be resurrected (Yes/No) compat_corpsegibs (CVAR and MAPINFO) If enabled, corpses under a vertical door or crusher are changed into gibs, rather than replaced by a different actor, if they do not have a custom Crush state. This allows an arch-vile or similar monster to resurrect them. By default, actors without a custom Crush state are removed entirely and can therefore not be raised from the dead.

Friendly monsters aren't blocked (Yes/No) compat_noblockfriends (CVAR and MAPINFO) If enabled, friendly monsters are, like in MBF, not affected by lines with the "block monsters" flag, allowing them to follow the player all around a map. This option does not, however, block them at lines with the "block player" flag.

Limit Pain Elementals' Lost Souls (Yes/No) compat_limitpain (CVAR and MAPINFO) Vanilla Doom prevents a pain elemental from spawning lost souls if there are already 21 in the level. This limit has been removed in most source ports but there are maps that require it to work properly. For an example, see DoomWikiLogoIcon.pngMAP19 of Hell Revealed.

Monster movement is affected by effects (Yes/No) compat_mbfmonstermove (CVAR and MAPINFO) If enabled, monsters are affected by sector friction, wind and pusher/puller effects, as they are in MBF. By default, monsters are not subjected to friction and only affected by wind and pushers/pullers if they have the WINDTHRUST flag.

Monsters cannot cross dropoffs (Yes/No) compat_crossdropoff (CVAR and MAPINFO) The original Doom physics code prevented monsters from being thrown off of ledges that they couldn't step off of voluntarily, even when propelled by an outside force. ZDoom allows monsters to be pushed over these dropoffs by weapons and other forces. This options restores the vanilla Doom behavior.

Monsters get stuck over dropoffs (Yes/No) compat_dropoff (CVAR and MAPINFO) This option disables the logic that allows monsters to move away from positions where they hang over a tall dropoff (e.g. the edge of a lift.) Originally a monster got stuck in such a situation. Normally there shouldn't be any need to revert to the old behavior.

Monsters see invisible players (Yes/No) compat_invisibility (CVAR and MAPINFO) This option restores Doom's original behavior where monsters would always wake up when seeing a player who is using an invisibility powerup. ZDoom normally uses a more realistic routine where monsters will usually be unable to see those players.

They probably won't make the next release (which will probably be this weekend), but should hopefully be in the release after that.

andrikpowell commented 2 years ago

Thanks, that should make it so that more vanilla map packs that rely on these can be played with Doom Retro...

As for the map30 "Monsters can telefrag other monsters" option...

It's actually really weird how it's implemented in ZDoom. Basically it's not exactly a comp setting, but is instead added via ZMAPINFO like how map07special is added.

For ZDoom, you have to add allowmonstertelefrags under the map that you want to use the feature.

What's strange is that the new UMAPINFO doesn't support this tag. It's only ZMAPINFO.

I think Eternity and PrBoom+ / DSDA Doom just have a separate toggle for the comp setting.... or it just automatically gets activated when using the command-line -complevel 2 (PrBoom+) and -vanilla (Eternity).

bradharding commented 2 years ago

I've implemented ZDoom's allowmonstertelefrags here: cf7566965f74a6583c1750ce280d3d6123d9303d

andrikpowell commented 2 years ago

Sounds good! Just curious is there any way I can test it out in a dev version, or is it not completely implemented yet?

bradharding commented 2 years ago

I've just released v4.4.5 if you want to give it a go. 😀

andrikpowell commented 2 years ago

Hmm... I gave it a go and it seems crash immediately, as opposed to the last version...

I noticed that if I deleted the UMAPINFO lump, it would boot up but it still ignored the allowmonstertelefrags tag...

Does Doom Retro only specifically load allowmonstertelefrags from MAPINFO as opposed to ZMAPINFO... The documentation of the differences between those 2 lumps is quite lacking to be honest.

If it might help, I have a version of the wad you can use to test the allowmonstertelefrags tag on for map30 (and why UMAPINFO no longer works): https://drive.google.com/file/d/1hSwugcO3zZst9sUYhKF6tzcLDYSlI7qE/view?usp=sharing

and a video to show what I'm seeing in Doom Retro as opposed to DSDA Doom: https://www.youtube.com/watch?v=DegmBvsv3DI

bradharding commented 2 years ago

Thanks for this. I must've messed something up. Real life is seriously getting in the way, but I'll look into this.

andrikpowell commented 2 years ago

No worries! I'm just glad that a dev is willing to try to implement features and listen to feedback! :)

bradharding commented 2 years ago

I haven't had the chance to actually test your wad, but the crash is fixed. Please redownload.

andrikpowell commented 2 years ago

Ok cool. I tested it and it now loads the wad! So with some testing, it seems that Doom Retro only reads MAPINFO and not ZMAPINFO... which is fine, since you can just rename the lump and Doom Retro will read it...

There is a slight problem though: If your wad has a UMAPINFO, the allowmonstertelefrags tag will never be read from the MAPINFO lump, since UMAPINFO seems to supersede it. and as mentioned earlier, UMAPINFO does not have the allowmonstertelefrags tag.

So when I renamed the ZMAPINFO lump to MAPINFO, and then deleted the UMAPINFO, I was able to see that the allowmonstertelefrags tag does in fact work correctly on MAP30 in the wad.

bradharding commented 2 years ago

For now, you could use RMAPINFO that DOOM Retro will recognize over MAPINFO and UMAPINFO. At this stage, DR will look for RMAPINFO, UMAPINFO and MAPINFO (in that order), and it processes only one. I should change this so it processes all three (and perhaps ZMAPINFO as well). In your experience, what should be the order of precedence?

andrikpowell commented 2 years ago

Ah, I didn't realise that RMAPINFO was a lump. lol I should've cuz you do have it in the documentation / wiki.

I think that the order you have it in makes sense: RMAPINFO UMAPINFO MAPINFO ZMAPINFO

RMAPINFO would make sense to be parsed first since it includes specific features exclusive to Doom Retro. UMAPINFO should be next, since it's supposed to be the MAPINFO lump that is compatible with all ports. MAPINFO and ZMAPINFO are kind of interchangeable.

I will say that it would be beneficial to have all of the lumps be processed, though that sounds like a bit of work, since like there's probably commands in ZMAPINFO that Doom Retro probably wouldn't understand and are exclusive to ZDoom ports (like the defaultmap compatibility settings or like how my wad's ZMAPINFO redefines the the skill screen to include a UV Plus difficulty that has the multiplayer monsters/items).

It'd say that having all the (X)MAPINFO lumps be processed would be good, since at the moment I could create a RMAPINFO to have the allowmonstertelefrags tag... but then since I've all defined episodes in the UMAPINFO, that would currently be ignored, right?

(I say this because looking at the wiki, RMAPINFO uses an old style Hexen kind of MAPINFO format... and I'm not sure if that supports episode declarations or added text screens like UMAPINFO does)

bradharding commented 2 years ago

Currently DR parses RMAPINFO, UMAPINFO and MAPINFO in the same way, so you can have UMAPINFO stuff in RMAPINFO.

andrikpowell commented 2 years ago

Oh weird... Yeah that's actually really cool. I literally just copied the text from my UMAPINFO into a RMAPINFO lump and then added the allowmonstertelefrags tag to MAP30 and it worked while also giving me the episode select.

andrikpowell commented 2 years ago

If you can mix and match the commands from the other MAPINFO lumps... I don't see the issue with having RMAPINFO override the other MAPINFO lumps. But it may be beneficial to state in the wiki that you can mix and match MAPINFO data in the RMAPINFO so that mappers know.

I guess you do run into the problem of when there is no RMAPINFO in the wad... maybe then you can pull mixed info from UMAPINFO, ZMAPINFO and MAPINFO

andrikpowell commented 2 years ago

So I looked at some of your more recent releases and was excited to see the added MAPINFO commands compat_corpsegibs and compat_limitpain. And so I gave them a shot in my wad.

It's really cool you added these options.

compat_limitpain worked as expected. Cool 👍

However compat_coprsegibs doesn't quite work as it's supposed to. At first glance, when it's added to the MAPINFO, it does in fact allow Archviles to create ghost corpses of enemies. In addition, like in Vanilla they can only be killed by rocket launcher splash damage.

However I noticed that it's possible for monsters when they are resurrected as ghosts to get stuck to one another when resurrected in the same place, which doesn't happen in Vanilla since they are supposed to be noclipping when resurrected after being crushed. Additionally, I noticed the ghosts block the player if "infiniteheight on" is set in the config file.

I'll also mention that the ghosts should not be counted as kills, since when they are initially crushed, they should be counted as already dead.

If you'd like to see what I mean about stuck imps, you can download this file and look at MAP08, and after triggering the crusher, you can IDDQD and IDCLIP to the crusher and see the stuck imps.

I'll also mention that there's a bit of weird thing when Doom Retro reads both UMAPINFO and RMAPINFO, in that if they both specify episodes, it'll show up as duplicated episodes in the episode screen. I simply solved this by removing the episode declaration in the RMAPINFO lump.

Also in that same wad I linked from earlier, on MAP33 (The Descent III), the config option r_graduallighting on breaks the way the map looks because of how it's built. Is there anyway to get around this? (It has to do with a long elevator ride down, and the entire ceiling being a flat bleed, so eventually the further the elevator goes down, the darker some parts of the ceiling become)

Also another minor thing... I know that the cyberdemon and mastermind wake/death sounds should be heard throughout the level, but it also seems like their other sounds like walking are also full volume, which is kind weird, especially in maps that have Cyberdemons/masterminds in out-of-bound monsters closets far away from the player. In Vanilla, the wake/death sounds of the cyberdemon/mastermind are full volume, but their other sounds are not full volume. See MAP33 for example.

andrikpowell commented 2 years ago

Also I wanted to mention that the file I sent is an WIP update to the wad I just released today: https://www.doomworld.com/forum/topic/128171-100-line-massacre-new-vanilla-megawad-complevel-2-dehacked/

And if you can get some of those things sorted out, I'd have no problem in posting an update saying that the wad is now completely compatible with Doom Retro.

bradharding commented 2 years ago

Sorry @andrikpowell, I did mean to let you know I implemented (or at least attempted to) those options. Wow, there are several issues to address. Leave it with me. I'll see what I can do.😀

andrikpowell commented 2 years ago

Hey Brad,

I just came across another small bug.

So in the 100 Line Massacre wad (and in many other wads), I've replaced the SS Nazi with the Commander Keen in DehackEd, with the original Commander Keen thing becoming a new enemy that doesn't drop a clip.

I bring this up, because a have new imps (that replace the Commander Keen in DehackEd) on MAP10, and have them set to affect the Kill percentage.

However, when I run the map with "-nomonsters" for some reason only in Doom Retro do those new imps still spawn even though they affect the Kill percentage and are seen as monsters.

andrikpowell commented 2 years ago

Hey Brad (again),

Hopefully I don't seem too annoying. I thought I'd test out the latest build you had (mostly because I was curious about your changes with bobbing powerups when they are on a floor that meets the ceiling).

Basically I found a few new issues that cropped up from some of the latest build's changes:

  1. In MAP33 (100lnm.wad), There is a megasphere that is on top of a door sector. Eventually it gets to the point where that floor meets really close to the ceiling. Eventually that floor lowers down again, but it seems that megasphere gets stuck under the floor and is now unattainable.

  2. In MAP34 (100lnm.wad), there are a lot of sectors in this map that have the floor set above the ceiling, and eventually they lower to below the ceiling onto the adjacent lowest floor. On these sectors there are also powerups that come down on them. On the latest build of Doom Retro, these powerups seem to disappear / not come down with the floor (my guess is that they get stuck on the original height when the floor is above the ceiling).

  3. In MAP10 (100lnm.wad), the game crashes when the player telefrags a new dehacked enemy (originally commander keen). Previously, Doom Retro did not crash (maybe has something to do with the changes you made to blood?)

Slightly off topic, but is there a better way of communication to give you this bug information rather than on this post?

I'd rather not keep posting via this thread since it's easier for the stuff I say to get lost... also much of the more recent issues I've been posting seem a bit removed from this post's original focus.

bradharding commented 2 years ago

Hi again! Thanks for the reports. I haven't got 'round to fixing compat_coprsegibs just yet, but I promise I'll try to before next release. I have checked out MAP33 in 100lnm.wad and did notice and fix the megasphere issue already. (I also encountered and fixed another bug (missing blood splats on moving sectors) due to that map.)

I'll look into the issues you've already brought up here, but I guess the best way moving forward if you encounter other issues, is to please raise a new issue for each. 😄

andrikpowell commented 2 years ago

Brad,

Thanks for the response. I've added quite a few separate issue threads that I hope will make your life easier in remembering the different issues. Also once you address them, we can easily check them off.

The one thing I wanted to ask is how you wanted to deal with the r_graduallighting issue (#717). I'm about to release the final version of my wad (100 Line Massacre) and so I'd like to have the RMAPINFO as close to done as possible. So I'd like to see what your thoughts are on that issue, before I finalise it and send it to /idgames. (I think that most of the other issues are more on the Doom Retro end, and not on my wad's end)

bradharding commented 2 years ago

Thanks for taking the time to create those separate issues, I really appreciate it @andrikpowell. I think for issue #717 I'll implement nograduallighting in RMAPINFO. That'll override the CVAR and display a warning in the console. What do you think? I'll look at doing this over the next couple of days so it will definitely be in the next release.

andrikpowell commented 2 years ago

Hey Brad,

I think that'll work great! I'll add nograduallighting to MAP33 in the RMAPINFO lump.

Just a small thing, I forgot about another small Vanilla issue with MAP31 regarding Vanilla's light change algorithm. I've detailed it more in issue #721. Do you think the best plan of action for that is to add compat_light for MAP31 in RMAPINFO?

bradharding commented 2 years ago

Just a small thing, I forgot about another small Vanilla issue with MAP31 regarding Vanilla's light change algorithm. I've detailed it more in issue https://github.com/bradharding/doomretro/issues/721. Do you think the best plan of action for that is to add compat_light for MAP31 in RMAPINFO?

Yes I do. I'll implement that as well. :smile:

andrikpowell commented 2 years ago

I just wanted to mention that I recently tested out both nograduallighting and comp_light in the latest build and they work great!

andrikpowell commented 2 years ago

I meant to mention this earlier when you closed the ticket #720 , but I did test it out myself and it does work correctly now. Good work!

Also I meant to mention that the final version of 100 Line Massacre how now been released on /idgames.

Once the issues I've opened have been completely closed, I'll write a post in the forum that says it's completely compatible with Doom Retro! Thanks again.

bradharding commented 2 years ago

Glad #720 is fixed for you! :smile: