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

Line 18/20 Floor Raise to Next Higher Floor Is Trolling Me

Question

Either I have always misunderstood this line special or something weird is happening. How does it determine the height to raise to? I had a joined sector and a dummy sector, like I always do, but it was overshooting that dummy sector height. Then I added several more adjacent sectors. It's still raising to the highest adjacent sector.

 

Upon further investigation, it seems to be having a love affair with one particular sector, so I deleted that sector. All those test sectors are still there at different heights. It had been raising to the highest. When I delete that highest sector, it now works as it's supposed to, raising to the next higher, i.e. lowest that's greater. There were adjacent sectors of 16, 32, 48, and 64. Tagged floor was 0. It had been raising to 64. 64-height sector was deleted; now it raises to 16, as expected. I recreate the 64-height sector. Now it raises to that again. I added a 128-height sector. It never raises to that. It either goes to 64, or if I delete it, to 16 as expected.

 

This sector that it was obsessed with is the largest and has the longest/most shared lines. Does that matter? What is happening?

Share this post


Link to post

11 answers to this question

Recommended Posts

  • 0

I never had such a problem. They always went up to the next higher sector. Ignoring lower sectors and those on the same level. Is it possible that your adjacency bugged out? Lots of things might bug out with sectors. Try using "make sector" all over it and on its adjacent ones, then re-joining them.

 

And, naturally, seeing the map might give someone an insight on what went wrong as well.

 

Update: I tested some hypotheses on what could've gone wrong, but it never did go wrong. However, as I was drawing more sectors around dummy sector it randomly decided to stop being joined with the actual sector. This might've happened to you as well. Check if they are actually joined.

Edited by ViolentBeetle

Share this post


Link to post
  • 0

Alright, so I got it to work but with no real explanation. I tried many things. I copied the section into a brand new map and reset tags. I tried a different nodebuilder. I kept adding sectors that would be lower than what it was going to. I could get it to change but never go to the correct height or even really be consistent. Since it all seemed to be based on one particular sector, I just messed with that sector's geometry. It had a curved line in it, so I deleted a few vertices. Then suddenly it worked, even if I deleted all the extra sectors I had created and reverted back to just the original dummy sector.

 

Also of note, the failure only happened in Crispy, Chocorender, and PrBoom+ -cl2. -cl9, Retro, and GZDoom worked as expected regardless.

 

I've attached the map in one of the many failing states. Sector 9 should go up to 16 height because of the dummy sector and/or because of sector 10. It's going up to 32 instead. I simply deleted a few of the curved lines in sector 0 and then it worked.

Line_20.zip

Share this post


Link to post
  • 0

I removed the sectors and drew identical ones and the problem go away. I am stumped.

 

I tried re-creating any combination of sector deletion and creation, sector numbering, line arrangement but couldn't break it again. My guess would be something in the node builder bugged out and stuck in this condition.

 

So, just use Shift-J to remove sectors then re-draw them and it should be fine.

Edited by ViolentBeetle

Share this post


Link to post
  • 0

You are encountering a stack overflow bug that was present in Doom, but Boom can avoid (if configured to do so).

 

When finding the next highest adjacent floor, there is a "height list" of adjacent sectors and their heights, but it can only hold 20 entries. More than that will overflow the array and, if you go too far, likely crash the game.

 

If you run PrBoom with verbose/debug output enabled, you will see warnings about this appear and it should tell you which line(s) are encountering this situation.

Share this post


Link to post
  • 0
1 hour ago, JadingTsunami said:

When finding the next highest adjacent floor, there is a "height list" of adjacent sectors and their heights, but it can only hold 20 entries. More than that will overflow the array and, if you go too far, likely crash the game.

 

Okay, that makes some sense, but the whole map has only 11 sectors. And the "fix" seemed to be decreasing number of vertices, not sectors.

Share this post


Link to post
  • 0

Here you are:

 


M_LoadDefaults: Load system defaults.
 default file: C:\DOOM2/glboom-plus.cfg
 found C:\DOOM2/prboom-plus.wad

PrBoom-Plus v2.5.1.5 (http://prboom-plus.sourceforge.net/)
I_SetProcessPriority: priority for the process is 1
 found C:\DOOM2/doom2.wad
IWAD found: C:\DOOM2/doom2.wad
PrBoom-Plus (built May 18 2017 19:47:34), playing: DOOM 2: Hell on Earth
PrBoom-Plus is released under the GNU General Public license v2.0.
You are welcome to redistribute it under certain conditions.
It comes with ABSOLUTELY NO WARRANTY. See the file COPYING for details.
V_Init: allocate screens.
V_InitMode: using OpenGL video mode
I_InitScreenResolution: Using resolution 3840x2160
 found C:\DOOM2/prboom-plus.wad
 found C:\DOOM2/line_20.wad

 	

	[...]	

 

P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
 Sector 9, line 38, heightlist index 20: successfully emulated.
P_FindNextHighestFloor: Overflow of heightlist[20] array is detected.
 Sector 9, line 46, heightlist index 21: successfully emulated.

Share this post


Link to post
  • 3

As grazza's log indicates, the issue isn't adjacent sectors directly, it's the amount of 2s lines that lead into other sectors. The code loops through all the lines in the sectors, checks if they're 2s, and if so, stores the height of the sector its joined to in an array, the heightlist mentioned in the log. This means the amount of sectors its joined to isn't important, but the amount of lines joining to other sectors (whether they're the same or different sectors) is.

 

Basically you can only have 20 2s lines in a sector that's going to move. Technically speaking you can have 22, since the check was implemented wrongly, and ports will handle this gracefully, emulating the overflow.

Share this post


Link to post
  • 0
9 minutes ago, SaladBadger said:

Basically you can only have 20 2s lines in a sector that's going to move. Technically speaking you can have 22, since the check was implemented wrongly, and ports will handle this gracefully, emulating the overflow.

 

I see. Thanks a lot. That explains why deleting a few vertices worked. But why am I only a couple over the threshold when the sector in question seems to have well over 40 two-sided lines?

Share this post


Link to post
  • 0

If it goes above 22, it simply stops checking for other adjacent sectors. It's entirely possible that the first 22 lines checked contained the "correct" answer when it had only 40 lines in it.

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
×