Vanilla door issue - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Doom Editing > Vanilla door issue

Author

All times are GMT. The time now is 08:40.

NaturalTvventy
Forum Regular

Posts: 764
Registered: 06-09

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.

Last edited by NaturalTvventy on 09-03-12 at 21:10

09-03-12 18:05 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9136
Registered: 07-07

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

09-03-12 18:29 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Pottus
Forum Regular

Posts: 767
Registered: 07-09

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

Last edited by Pottus on 09-03-12 at 20:16

09-03-12 19:22 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Memfis
Forum Spammer

Posts: 3130
Registered: 04-07

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

09-03-12 19:32 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

hex11
Senior Member

Posts: 1982
Registered: 09-09

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.

09-03-12 19:46 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

NaturalTvventy
Forum Regular

Posts: 764
Registered: 06-09

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

Check your PMs.

09-03-12 20:22 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

TimeOfDeath
Forum Regular

Posts: 2003
Registered: 06-06

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

09-03-12 21:04 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

NaturalTvventy
Forum Regular

Posts: 764
Registered: 06-09

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.

09-03-12 21:07 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

cannonball
Senior Member

Posts: 1386
Registered: 07-11

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.

09-03-12 21:10 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Grazza
Inventor of "Y Y" to quit

Posts: 11783
Registered: 07-02

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.

09-03-12 21:18 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

marineController
Newbie

Posts: 9
Registered: 08-12

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.

09-03-12 21:48 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

hex11
Senior Member

Posts: 1982
Registered: 09-09

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

09-03-12 21:57 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9136
Registered: 07-07

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.

09-03-12 22:21 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 08:40.

Doomworld Forums > Classic Doom > Doom Editing > Vanilla door issue

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 >