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

TNT MAP30 stairs

Recommended Posts

Reported that TNT MAP30 stairs at red key do not build right using DoomLegacy.
Using Doom95, they build to the top of the pillar.

During verification, discovered that prboom-2.5.0 and Edge1.35 do the same thing as DoomLegacy. They build those particular stairs 48 units lower than Doom95.

PrBoom 2.2.0 bug fixes reported: fixed stair building (ex. TNT - Evilution MAP30)
PrBoom bug report exists: Stairs Broken in Boom Compatibility - ID: 267175, Status: Open

The map cannot be finished, as the player cannot get to the red key.

Have not figured out what the wad and Doom95 engine are doing, but it is weird. Some steps build double height, and it is not related to anything I can identify yet.

It does NOT seem to be special detection of the wad and level, as other stairs in MAP30 build normally.
(Except: Stairs in final Boss room build short too. Cannot get to top of stairs)

Search on the subject indicates that Boom fixes broke this stair on TNT MAP30. I have yet to find out specifically how they broke it.

I have several way to fix this, some more distasteful than others.

Are there any other known wads that depend upon this same Doom95 behavior ??

Found statement by Quasar that makes me nervous: EE is *supposed* to have fixed the BOOM/MBF issues with comp_stairs (the thing got progressively more broken with every person that touched it...)

According to Google I got about 2,120 results to go through.
Well, not as bad as most searches ...

Share this post


Link to post

Have a look at PrBoom-plus - it allows the toggling of the different stair-building methods via it's compatibility options.

It's a shame that these type of problems have been created - there's nothing more frustrating than looking for a non-existent switch to try to complete a level, only to finally conclude that a source-port setting is the cause of the problem.

I understand that the original stair code is buggy, and frustrating for map makers, but, if this stair build "fix" was never created, anyone testing their newly built map would modify it until the stairs worked properly.

For a long time, I've been thinking about creating a database that remembers all of the required settings to properly play wads, but, it's a lot more than a one-man job, which makes it even more complicated.

Share this post


Link to post

It would be an insurmountable task without some form of mechanism which allows users to actively modify said database as they find exceptions to the port's default interpretations.

The only way I could see this working is if a cross port standard for a new MAPINFO was devised (a bare bones one, excluding all port specific stuff) and if /idgames allowed users to upload and associate a sidecar wad/zip/whatever with the metadata for each map.

Share this post


Link to post
kb1 said:

For a long time, I've been thinking about creating a database that remembers all of the required settings to properly play wads


Both zdoom and Risen3D already have this feature. For zdoom it is the file compatibility.txt contained in zdoom.pk3 and for Risen3D it is in the file R3D_modify, in the \bin folder. Just open it using notepad.

Interestingly, zdoom still does not have a compat setting for phobos.wad (phobos2.zip) by Roger Ritenour. Note that with zdoom that the floor of sector 203 in map 3 does not rise to the intended level.

wesleyjohnson said:

Are there any other known wads that depend upon this same Doom95 behavior ??


The only other one I am aware of is Reality3.wad

Share this post


Link to post
hawkwind said:

Interestingly, zdoom still does not have a compat setting for phobos.wad (phobos2.zip) by Roger Ritenour. Note that with zdoom that the floor of sector 203 in map 3 does not rise to the intended level.



If nobody tells the developers that's not really surprising, isn't it? Which setting does the map need?

Share this post


Link to post

Yes, in the wrong subforum. You should have posted it in Bugs, not Feature Suggestions. I check that one far less frequently.

Share this post


Link to post
wesleyjohnson said:

During verification, discovered that prboom-2.5.0 do the same thing as DoomLegacy. They build those particular stairs 48 units lower than Doom95.

The map cannot be finished, as the player cannot get to the red key.

Share this post


Link to post

I recently encountered a similar problem with my Obituary repackaging, which caused the yellow key pillar to rise too high above the surrounding platforms, unless I used a proper complevel (in prBoom+) or toggled "Use Doom's method for finding shortest texture" on in ZDoom and derivatives.

This behavior is caused by the fact that the iterator functions that search for the lowest/highest floors around a sector have a lowest/highest cap (e.g. a height of -500) and anything under it is considered "low enough", for whatever reason). Boom modifies this by placing the lower cap at SHORT_MIN (-32 K) but this of course breaks some Doom maps and, viceversa, most Boom maps will break in vanilla Doom (or in limit removing but not Boom compatible engines, e.g. MOchaDoom, Doomonstration Games yellow key gizmo doesn't work using the Boom method).

Something related with the TNT MAP30 stairs, in Mocha Doom I discovered that looking at them caused a solidsegs overflow during the BSP tree trasversal, which is asymptomatic (?) in vanilla. Interestingly, this only happens after the stairs are raised, not before (and led me to bullet-proof EVEN solidsegs, among other things).

Share this post


Link to post
Graf Zahl said:

Yes, in the wrong subforum. You should have posted it in Bugs, not Feature Suggestions. I check that one far less frequently.


I admit that at the time I was debating with myself whether to put it under bugs or not. I decided that it was more of a compatibility issue rather than a bug per-se. Oh well ...

Share this post


Link to post

The Doom port world had and has poor foresight.

The typical Doom port author also preaches cross port unity and co-operation. But in reality, they have always and continue to compete with each other for multiple reasons, some of which are self centred.

I'm deliberately avoiding listing any example(s).

Of course, it's easy to talk in hindsight, simply talk the talk or be idealistic...

Share this post


Link to post

No reason a global "database" in the form of a CSV file of wad compatibility problems couldn't be maintained, storing SHA-1 hash codes or some other identifier together with a standardized set of compatibility fixes that the map needs applied to it.

Port authors could then just SVN update to pull the latest copy into their own project.

Conflating this with MAPINFO, which handles everything from skies to monster behaviors to music to scripts and god knows what all else, would be a serious mistake though. It is not something that should have to be added to the wadfile, or manually given to the engine by using -file on a .lmp every time you want to play.

Share this post


Link to post
Quasar said:

No reason a global "database" in the form of a CSV file of wad compatibility problems couldn't be maintained, storing SHA-1 hash codes or some other identifier together with a standardized set of compatibility fixes that the map needs applied to it.

Other than the SHA-1 that sounds very much like the MAPINFO subset I suggested. Several ports already allow compat options to be set on a per map basis using this approach.

Doing this via any mechanism which requires port authors to act on changes is just doomed to fail in my opinion. It needs to be something the players can actively contribute to and maintain for themselves.

Naturally I wouldn't expect users to load it manually, that would be pointless complication. The user should be able to update their local copy of this metadata which the engine can then index using the SHA-1 to locate the correct info for a particular map.

Share this post


Link to post

Thanks. Got more discussion than expected.

Wads affected:
tnt.wad
Reality3.wad

Committed patch tied to detecting TNT, but no complevel switch yet.
Really prefer that engine cope with these before player has to get frustrated.

Only read about 200 of the google links. It got to the garbage level pretty quick. A few made it clear, it needed the old buggy behavior from before Boom fixes. I got lucky, it was well marked in the code.

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
×