Severed bunny head
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > TNT MAP30 stairs
 
Author
All times are GMT. The time now is 04:52. Post New Thread    Post A Reply
wesleyjohnson
Member


Posts: 486
Registered: 04-09


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 ...

Last edited by wesleyjohnson on 08-31-11 at 21:56

Old Post 08-31-11 21:50 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Junior Member


Posts: 167
Registered: 11-06


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.

Old Post 08-31-11 22:46 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 1740
Registered: 08-03


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.

Old Post 08-31-11 22:58 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
hawkwind
Forum Regular


Posts: 789
Registered: 04-04



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

Old Post 09-01-11 00:16 #
hawkwind is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7130
Registered: 01-03



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?

Old Post 09-01-11 00:47 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
hawkwind
Forum Regular


Posts: 789
Registered: 04-04



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


I actually did, some time ago ...

http://forum.zdoom.org/viewtopic.php?f=15&t=28623

Old Post 09-01-11 05:37 #
hawkwind is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7130
Registered: 01-03


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

Old Post 09-01-11 07:13 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
entryway
Forum Staple


Posts: 2587
Registered: 01-04



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.

http://prboom-plus.sf.net/okay.gif

Last edited by entryway on 09-01-11 at 10:16

Old Post 09-01-11 08:43 #
entryway is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 8664
Registered: 07-06


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).

Old Post 09-01-11 09:29 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
hawkwind
Forum Regular


Posts: 789
Registered: 04-04



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 ...

Old Post 09-01-11 10:41 #
hawkwind is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Vermil
Senior Member


Posts: 1224
Registered: 03-04


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...

Old Post 09-01-11 14:41 #
Vermil is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 4615
Registered: 08-00


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.

Old Post 09-01-11 17:59 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DaniJ
Senior Member


Posts: 1740
Registered: 08-03



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.

Last edited by DaniJ on 09-01-11 at 20:48

Old Post 09-01-11 20:32 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Junior Member


Posts: 167
Registered: 11-06


Make a new thread to discuss this further: http://www.doomworld.com/vb/source-...-database-ideas

Old Post 09-01-11 22:05 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Member


Posts: 486
Registered: 04-09


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.

Old Post 09-02-11 20:45 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 04:52. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > TNT MAP30 stairs

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Forums Directory