Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
GooberMan

ID24 0.99.2 - currently in draft status

Recommended Posts

For ExMy and MAPxy, having the levelnum be determined from map slot name makes intuitive sense. For other slot names (even if they're trivial extensions, e.g. ExMyz, or MAPxyz, or even ExyzMtuv because why the hell not), having to define it explicitly is reasonable.

 

Episode numbers is IMO something we should only bother with in the ExMy scheme; with MAPxy format there's no episode number built into the map slot name. E.g. in Legacy of Rust, there's nothing in the slot names that tells you that MAP15 in is E1, while MAP14 and MAP16 are both in E2. In that wad, should "idclev15" send you to MAP15, or to MAP05 which is labelled as "E1M5"? This is ambiguous but personally I'd lean in favor of the map slot.

 

Storing the map slot name in the demo makes sense; it's less ambiguous than using episode numbers when there's no real episode number to be had.

Share this post


Link to post

With how much DecoHack is depended on, why not just take out the middleman and add DecoHack support for modding, as an alternative to DEHACKED?

Share this post


Link to post
34 minutes ago, Gez said:

Episode numbers is IMO something we should only bother with in the ExMy scheme; with MAPxy format there's no episode number built into the map slot name. E.g. in Legacy of Rust, there's nothing in the slot names that tells you that MAP15 in is E1, while MAP14 and MAP16 are both in E2. In that wad, should "idclev15" send you to MAP15, or to MAP05 which is labelled as "E1M5"? This is ambiguous but personally I'd lean in favor of the map slot.

 

Yes, this would be the point of the larger conversation. The only way to get clean episode numbers is going for Doom 1 format, but that disables the SSG. Multiple episodes in Doom 2 is quite common, but they're restricted to a linear map number format. And for an example from my own modding history, Prime Directive split things out in to GExMAPyy lump names to explicitly get it away from the normal Doom 2 map format numbers.

 

Myself, I'm basically in favor of leaving it all alone for now. But multiple episodes are a Thing(TM) that we really should deal with cleanly.

Share this post


Link to post
30 minutes ago, Obsidian Plague said:

With how much DecoHack is depended on, why not just take out the middleman and add DecoHack support for modding, as an alternative to DEHACKED?

 

DecoHack is just one way to create a valid DeHackEd patch. DEH9000 was used very successfully in Knee-Deep in Knee-Deep in ZDoom for example.

 

When considering multiple ways of generating DeHackEd patches, it starts to redefine DeHackEd from its original intention of modifying data tables stored in the DOS executable and looks more like a target for compilation. There's straight up some crazy stuff waiting to be done with DEH9000 that would be a nightmare to manage in DecoHack, programmatically generating new mobj definitions is an untapped frontier. Right now, there's no real need to kneecap possibilities like that by committing to supporting DecoHack as a first-class data format.

Share this post


Link to post
7 hours ago, Arsinikk said:

I very much disagree with this. "Bugfixed" does not equal "Boom", nor would I want it to equal "Boom". "Boom" changes so much shit in the backend that basically makes certain Vanilla things not work correctly. Stuff such as floor action behaviour being "fixed", stuff like actors falling off, and just so much other stuff that just isn't Vanilla.

 

I mean "Boom" and above. For example, MBF21 fixes most issues with Boom complevel, so users who want "bugfixed" behavior can use the latest standard.

 

My point is to reduce the number of complevels and simplify them. While vanilla compatibility is very advanced in ports like PrBoom+ and Chocolate Doom, other complevels are not. I believe KEX port developers shouldn't spend time emulating the exact behavior of BOOM.EXE and MBF.EXE, just complevel 9/11 is enough. As for various vanilla versions, that's probably a niche, there's Chocolate Doom for that.

 

On 9/6/2024 at 2:47 AM, GooberMan said:

rfomin's post is being discussed with a few other people, and I will reply to that when there is something worth saying on it.

 

That's intriguing, any news?

Share this post


Link to post
3 hours ago, rfomin said:

I mean "Boom" and above. For example, MBF21 fixes most issues with Boom complevel, so users who want "bugfixed" behavior can use the latest standard.

Tbh the main problem I have here is that MBF21 does not fix everything. It gets the closest to vanilla behaviour (compared to Boom and MBF), but is not the same thing. There are changes to the RNG table post-vanilla, and stuff like ghost monsters still doesn't function correctly. Lay on top of that, that floor movement behaviour in boom+ does not exactly replicate Vanilla behaviour... even with the OPTIONS lump.

 

Lay on top of that of forcing mappers to have to turn off a bunch of translucency effects on things... It's honestly a huge hassle, as well as not being accurate to Vanilla behaviour.

 

I don't mean to be difficult here, but there's a reason I'm bringing this up, since Vanilla is my specialty. In trying to remove this "bugfixed" complevel, you are actually further complicating things in basically saying that "bugfixed" maps are "mbf21", which just isn't the case here at all.

 

3 hours ago, rfomin said:

My point is to reduce the number of complevels and simplify them. While vanilla compatibility is very advanced in ports like PrBoom+ and Chocolate Doom, other complevels are not. I believe KEX port developers shouldn't spend time emulating the exact behavior of BOOM.EXE and MBF.EXE, just complevel 9/11 is enough. As for various vanilla versions, that's probably a niche, there's Chocolate Doom for that.

I will say that I agree with you when it comes to Boom and MBF behaviour. But that is only because that is what the community has basically decided for what Boom and MBF is respectively. Since Boom 2.02 and original MBF hasn't really been tailored to, or has basically been superseded, I don't see a reason to support it.

 

The main problem here is that "limit-removing" will always be a Vanilla complevel, and saying to use MBF21 is absolute insanity to me.

Share this post


Link to post

I have a question about SKYDEFS. When a fire sky is used as the foreground of another sky, what should the behavior be if the fire sky is not used elsewhere in that map. It looks like currently in Rum and Raisin, the fire sky will not be considered active, and therefore is not updated. This leaves the texture unmodified instead of as fire. Is this the intention of the specification or just a result of the clearly unfinished implemention of fire skies as of the most recent commit.

 

Edit: nvm I found where the foreground sky gets activated.

Share this post


Link to post

Regarding the interlevel intermission definition:

https://docs.google.com/document/d/1j3KF96cWyD-bTFhthX_lDSK5pD8RPwEaetcyC-jy6o4/edit#heading=h.hi93du5doy8s

 

Quote

The map number accessible for condition checking is dependent on whether the victory screen is currently displaying an exit animation or an enter animation. If it is an exit animation, the map number corresponds to the map being played; if it is an enter animation, the map number corresponds to the map about to be entered. The map number itself is defined through other means, including but not limited to UMAPINFO, and is outside of the scope of this document to define.

That's pretty bad, in light of the levelnum discussion above.

 

As a counterexample, ZDoom's old intermission scripts do not use map numbers (like 12), but map names (like "MAP12").

 

Looking into the spec, all the condition param values, when used, correspond to a map number. There's no other use of the param value than to indicate a map. Therefore, it could be changed from an integer to a string, and use the map slot name instead of an undefined levelnum.

Share this post


Link to post

To add to the topic of "should cosmetic features trigger Boom/MBF/etc complevels", there is more than just the MBF sky transfer which some limitremoving wads use.

 

As an example, Scythe 2 and Scythe X, known to the demo community as limitremoving wads, actually have Boom specials in several maps which normally just get ignored in non-boom engines., mostly to set different floor/ceiling brightness values.

(Though Scythe 2 MAP32 also has a switch that uses a Boom floor action which would be a non-cosmetic change)

Share this post


Link to post
9 minutes ago, Trov said:

(Though Scythe 2 MAP32 also has a switch that uses a Boom floor action which would be a non-cosmetic change)

Which brings to mind another limitation of the existing COMPLVL approach, which is its one-size-fits-all in the wad philosophy. There have been a number of community projects that result in compilations of maps which are not all on the same feature level.

 

Take the Doomworld Mega/Maximum Projects, or, say, Baron Door. They start vanilla/limit-removing, then gradually move to Boom, MBF, ZDoom, etc. as you move through the maps. Such things would need to be able to set a feature level per map, rather than for the whole file.

Share this post


Link to post
9 hours ago, Gez said:

Take the Doomworld Mega/Maximum Projects, or, say, Baron Door. They start vanilla/limit-removing, then gradually move to Boom, MBF, ZDoom, etc. as you move through the maps. Such things would need to be able to set a feature level per map, rather than for the whole file.

Correct me if I'm wrong, but isn't COMPLEVEL stuff in Boom-family ports set at engine start instead of game start? Either way, it sounds like a pain in the butt to untangle into a per-map setting.

 

Realistically, just setting the COMPLEVEL to that of the most "advanced" level in the pack should cover like 90% of use cases, with the remaining 10% being ZDoom-centric eccentricities which that family of ports has their own solutions and workarounds for (compatflags in MAPINFO etc.)

Share this post


Link to post

Is there any plans to address game controller force feedback in this specification?

 

This may sound like a rather odd question, but KexDoom port does implement controller force feedback for weapons at least, and Doom Retro does it as well. At least addressing this in the specification would be better for all source ports still lacking implementation for it, in addition to unifying it, since this topic isn't mentioned in the specs at all.

Share this post


Link to post

Okay, I just want to make sure I'm clear on this. When it comes to the complevel checks, if the PWAD does not have a GAMECONF or COMPLVL lump present, does it just refer to the corresponding lumps in the IWAD instead, forgoing the other checks?

 

The main reason I ask this is because after today's update, I went to load Eviternity up to test something and got this error:

image.png.ff891ffd76990add21f2b8ee87fce793.png

 

I was talking with my friend and I deduced that this may be authoritatively attempting to set the feature level based on the GAMECONF lump in the IWAD instead of the other features in the PWAD. Am I right on this? Or is something else causing this to happen?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×