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

Vanilla door issue

Recommended Posts

Greetings,

I'm having tons of issues with NEIS in cdoom that I really don't understand the cause of, and thus am just dinking around trying to fix. They include:

Floors that don't lower all the way as they are supposed to.

Floors that don't lower until monsters are activated.

Floors that raise too high when triggered.

Everything works fine in source ports. I know this is rather vague, but any idea what might be causing these issues?

If there's any vanilla engine experts out there willing to take a look at the stuff certainly let me know, I could use the help.

Thanks!

NT

EDIT:

Above issues fixed. The last error is a door that is supposed to open/wait/close, but only opens.

Share this post


Link to post
NaturalTvventy said:

I'm having tons of issues with NEIS in cdoom

If this is your pet name for Chocolate Doom, I suggest looking for another. "Choco" is five letters too, and would do the job just fine.

NaturalTvventy said:

Floors that don't lower until monsters are activated.

Are the monsters "stuck" in the ceiling? That would prevent the floors from lowering, as odd as it sounds. (IIRC, if there are monsters vertically stuck, it prevents non-crusher movements, even if said movements would free the monsters.)

Share this post


Link to post

I'm willing to bet they are testing with Visplane explorer and not doing any testing with Chocolate Doom it's self I didn't find any of the problems you describing I'm sure they are there but there are lots of tutti fruity's which to me suggests no actual vanilla testing.

Edit: I could probably give you hand NaturalTvventy this is the kind of stuff I have a lot of experience with (Epic 2 coop fix, Sunder coop fix, Strain fix, HR2 coop fix for SNS) I can eat those Maps for breakfast and shit them out for dinner ;P

Share this post


Link to post

I guess I could look at the maps and help. (I remember helping you with doors not opening before :-)

Share this post


Link to post

I remember having some discrepancies between chocolate-doom and prboom (complevel 2) with raising floors. Couldn't figure out why so ended up changing the linedef tag type from relative to absolute height change. I can't remember exactly which tags though, it's been months since I worked on that map, and actually converted it from Doom to Heretic and back to Doom again, so a lot of stuff changed...

It's a safe bet that the chocolate-doom behavior is the correct one though (if any doubt, try with doom.exe). Just recently I played a map where chocolate-doom crashes "correctly" (as doom.exe would) with "Sector with more than 22 adjoining sectors. Vanilla will crash here" error message, but prboom (complevel 2) doesn't even log any error message to console. The map in question is Blind Alley W, and the crash happens after the red key door, past the fountain and immediately after entering the big room with crescent shape in SE corner. It's very easy to get there from the start by using IDKFA (red door is in start room). Anyway, that just shows you can't trust most ports much for true vanilla behavior.

Share this post


Link to post
TimeOfDeath said:

Dunno, but I had problems with moving floors if the floor height was below -512 units.


Eureka!

Thanks ToD.

Now all that's left is a door that is set to open/close, but only opens when the switch is hit.

Share this post


Link to post

I've had problems with this myself, probably one thing to do is to check that where monsters are placed, the height of the room is not less than the monsters themselves. I've had a problem with lowering pillars in two wads I've made recently.
ok as all was sorted anyway, you can disregard this post.

Share this post


Link to post

For more detail on the "-512" problem, see my post here.

hex11 said:

I remember having some discrepancies between chocolate-doom and prboom (complevel 2) with raising floors.

Unless you were doing something very unusual indeed, it's more likely you were failing to apply the complevel correctly. If you experience this type of stuff again, record a demo and submit a bug report and it will be investigated. Remember that every single DSDA and Compet-n demo has been tested with Prboom+, so any discrepancies in the way floor motion (or other such critical things) is handled would lead to many desyncs. But these aren't to be found.

Share this post


Link to post

I have seen this in the past, for reference:
The floor problem can affect line types 9, 19, 36, 45, 53, 70, 71, 83, 87, 98 and 102: destination floor heights must be greater than or equal to -500.
Also a similar problem can affect line type 40: destination ceiling heights must be greater than or equal to zero.
These are the "maximum" values the functions concerned check for when they search for the destination heights.

Share this post


Link to post

It's actually just the regular prboom (v2.5.0), not prboom+, and I start it like this (from shell prompt):
prboom -file some.wad -complevel 2 -warp 1

Share this post


Link to post
hex11 said:

It's a safe bet that the chocolate-doom behavior is the correct one though (if any doubt, try with doom.exe). Just recently I played a map where chocolate-doom crashes "correctly" (as doom.exe would) with "Sector with more than 22 adjoining sectors. Vanilla will crash here" error message, but prboom (complevel 2) doesn't even log any error message to console.

Replicating crashes isn't needed for demo compatibility, which is all PrBoom+ wants as far as emulating vanilla bugs.

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
×