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

"Sector with more than 22 adjoining sectors crashes Chocolate."

Recommended Posts

In a map I am working on for TNT Forever, there is a large pool of lava. In the lava is a switch that raises the floor by 1 unit and changes it from lava to water. The switch has action 20: Floor raise to next higher floor (changes texture). Now here is a picture of the pool of lava in question.

 

e5YXYLU.png

 

Now when I hit the switch, CHocolate Doom crashes with this error:

 

dvZkcdq.png

 

Now the interesting thing here is that there is exactly 20 sectors adjoining this particular sector, which is obviously less than 22. (There were many more than 22 sectors originally, but I merged many sectors and altered the geometry to meet this limitation.) I should also add that there are no other problems with this area, or this map. No visiplane or seg overflows etc, though the level does break the savegame buffer. The map has been thoroughly tested, by a number of people, and there is nothing else really wrong with it that is known.

 

So would anyone have any ideas why this switch is crashing chocolate? A number of the sectors are segmented: (all of the rectangles with the red circle floor textures are one sector, for example.) So could the engine be counting segments perhaps? Is it counting sectors that share a vertex and are touching on one corner, but not along an entire linedef? Any other thoughts? (The sector itself is a single 'piece' and has no dummy sectors or anything else like that.)

 

An interesting problem. Appreciate any replies.

Share this post


Link to post

Yes, this is a vanilla limitation. The function to find the next highest (lowest?) neighboring sector was very, very stupidly done, instead of just iterating over the neighbors, it stored the height info in a local array to check that later. That array had 20 entries, you could add two more due to other variables on the stack before it crashed.

 

That function is actually a genuine facepalm thing, one has to wonder how anybody could come up with something this idiotic.

 

Share this post


Link to post

So could that mean that if I reduced the sector count further, to say 18, it may work?

 

Thanks for the reply.

Share this post


Link to post

There is exactly 20 now, so I will reduce it by one further and see what happens there.

Share this post


Link to post

Reading that function again, it's not the number of sectors that matters but the number of linedefs. And that's a lot more than 17.

 

Share this post


Link to post

Aaaaah. I see. Well we are never gonna get that under 22 linedefs.

 

Thanks for the help. Much appreciated.

Share this post


Link to post
1 hour ago, Graf Zahl said:

Yes, this is a vanilla limitation. The function to find the next highest (lowest?) neighboring sector was very, very stupidly done, instead of just iterating over the neighbors, it stored the height info in a local array to check that later. That array had 20 entries, you could add two more due to other variables on the stack before it crashed.

Does it mean you can perform arbitrary code execution in vanilla Doom with the right sector setup? 

 

EDIT: I see that linedef type 20 is part of the commonly misnamed "plat" specials, which are essentially permanent floor movements, but classified like the lifts. I always found them particularly messed up (just see what crazy shit will happen if you block their full ascent); I didn't know they also have this quirk.

 

Are there no alternative linedef types which raise floor and change texture/type? Maybe one from the real "moving floors" category.

Edited by printz

Share this post


Link to post
10 minutes ago, printz said:

Does it mean you can perform arbitrary code execution in vanilla Doom with the right sector setup? 

 

 

You are inevitably limited by not being able to put fractional heights in the map data which severely limits the places your code may jump to. Of course, if you manage to get some meaningful code into such a place, yes it is theoretically possible. This is a typical array-on-stack overflow, after all that will eventually overwrite the return address (with its 23rd element if I am not mistaken)

 

 

Share this post


Link to post

Very interesting limit that I never knew about. The reason it crashes is oddly similar to the All-Ghosts effect (only so many objects on a table before it overwrites other data). My question is why some tables are so limited, or why there are tables at all. Why not, at the very least, change the table dynamically? For each object, add 1 spot to the table.

Probably optimization.

Share this post


Link to post
28 minutes ago, ViolentBeetle said:

What if you split the lava pool in a few sectors?

 

This is definitely worth looking at, as long as the increase in linedefs doesn't put the area over any visiplane limits or other limits. Thanks for the suggestion.

 

Just now, forgettablepyromaniac said:

Very interesting limit that I never knew about. The reason it crashes is oddly similar to the All-Ghosts effect (only so many objects on a table before it overwrites other data). My question is why some tables are so limited, or why there are tables at all. Why not, at the very least, change the table dynamically? For each object, add 1 spot to the table.

Probably optimization.

 

Not gonna even attempt to answer these questions. But it was definitely a limit that I also never knew about. At least until a few weeks ago when suddenly Chocolate Doom went away, and left me with the mysterious windowed message I posted above.

 

Share this post


Link to post
1 hour ago, Graf Zahl said:

Reading that function again, it's not the number of sectors that matters but the number of linedefs. And that's a lot more than 17.

 

 

Does this apply to all "move floor" lines, or only the category listed by @printz? I've never encountered this bug in Vanilla/Chocolate Doom, and I like to use changing floors a lot; however, I mostly use line type 9 ("donut") and set all my target heights through using donut sector dummies outside the playfield. (This method also has the benefit of allowing non-instant movement in both directions, as well as texture/sector special changes)

Share this post


Link to post
Just now, Uncle 80 said:

 

 I mostly use line type 9 ("donut") and set all my target heights through using donut sector dummies outside the playfield. (This method also has the benefit of allowing non-instant movement in both directions, as well as texture/sector special changes)

 

Wait... you can use dummy sectors on donuts? I always assumed that donuts would just raise/lower to the floor height of the sector surrounding the outer sector of the donut. Does the donut take on the properties of the sector in front of the first sidedef of the triggering linedef? And can you get the inner and outer sectors of donut floors to move to different heights? That is super cool! How do you use donuts differently from, well, how they have always been used? Really interesting idea. Cheers

 

Share this post


Link to post
4 minutes ago, Kyka said:

 

Wait... you can use dummy sectors on donuts? I always assumed that donuts would just raise/lower to the floor height of the sector surrounding the outer sector of the donut. Does the donut take on the properties of the sector in front of the first sidedef of the triggering linedef? And can you get the inner and outer sectors of donut floors to move to different heights? That is super cool! How do you use donuts differently from, well, how they have always been used? Really interesting idea. Cheers

 

You can abuse line type 9 just like all the others; the only catch you need to take into consideration is that its trigger type is numerical (gets target info from lowest numbered linedef) so you either need to make as many donut sector dummies as you need before starting your actual map, or - the easier way - making the actual map first, then creating a new map from scratch with just the donut dummies, then pasting your original map into that and join the sectors.

 

In addition to the benefits I listed above, there's also the "added feature" that the "donut area" does not have to be tagged (like the steps beyond the first in a stair raiser) so with this approach you can make real elaborate setups, like having a section being "flooded" then raising e.g a bridge from the water again later.

 

At the moment, I'm working on a map where a switch triggers 12(!) dummies off-screen, you can only imagine the havoc I'm making in the playfield, hahaha! I can probably whip up a small example map during the weekend if there's interest.

 

I've always used the "Unofficial Doom Specs v666" by Hank Leukart when trying to figure out what I can and can't do with vanilla's trigger types, and his explanation of how the donut trigger works is very accurate; it just doesn't say you can use dummies, but they weren't well known in '94 i guess... :)

Share this post


Link to post
Just now, Uncle 80 said:

You can abuse line type 9 just like all the others; the only catch you need to take into consideration is that its trigger type is numerical (gets target info from lowest numbered linedef) so you either need to make as many donut sector dummies as you need before starting your actual map, or - the easier way - making the actual map first, then creating a new map from scratch with just the donut dummies, then pasting your original map into that and join the sectors.

 

In addition to the benefits I listed above, there's also the "added feature" that the "donut area" does not have to be tagged (like the steps beyond the first in a stair raiser) so with this approach you can make real elaborate setups, like having a section being "flooded" then raising e.g a bridge from the water again later.

 

At the moment, I'm working on a map where a switch triggers 12(!) dummies off-screen, you can only imagine the havoc I'm making in the playfield, hahaha! I can probably whip up a small example map during the weekend if there's interest.

 

I've always used the "Unofficial Doom Specs v666" by Hank Leukart when trying to figure out what I can and can't do with vanilla's trigger types, and his explanation of how the donut trigger works is very accurate; it just doesn't say you can use dummies, but they weren't well known in '94 i guess... :)

 

Thanks so much for the explanation. It would never have occured to me to use donuts in interesting ways. Nice creativity. Don't go to any trouble, but I would love to see an example map, sooooo, if one were to magically appear in this thread or something... :)

Share this post


Link to post
3 hours ago, Graf Zahl said:

That function is actually a genuine facepalm thing, one has to wonder how anybody could come up with something this idiotic.

Working under deadlines? Crunch time? Y'know, the yoozhe?

 

If you're under tight deadlines and all that and you don't have much time, I can see why you'd go for a quick but flawed solution in the interest of moving on.

Share this post


Link to post

@Kyka: Here's a really quick example map showcasing a simple setup - raising a pool of water while lowering a barrier, then later raising a bridge from the water (using your problematic line type 20, by the way). A setup like this actually uses two different dummy setups for the same sector - check the middle sector of the lava that becomes the bridge once you press the switch on the ledge above ;) heh, no - second swich uses the trigger model :P Anyway, this simple setup uses "only" 4 donut control sectors. :D

 

kykdonut.zip

 

The only "drawbacks" using this method is that unlike the other floor-changers, the raising part of the donut doesn't change texture until it arrives at its target height, meaning it's going to look strange if there's "solid ground" instead of lava in the central pit - the "ground" will raise and become liquid after unlike the other raisers which change their texture when the movement starts. But the sector special for the raising part will change, in this example stopping the lava from doing more damage after it changes to water. Also, the "donut hole" doesn't change neither texture or sector type unfortunately. But still, lots of fun can be had with this!

Edited by Uncle 80

Share this post


Link to post

@Uncle 80 Thanks so much. Appreciated.  Gonna go have a look at this map. I now have to work this somewhere into TNT Forever if at this map. I'll credit you if I do. :)

Share this post


Link to post
8 minutes ago, LucasRafael132 said:

I think there's a vanilla-limit removing source port called "Sparkling Doom".

 

 

Both mine and Kyka's projects are designed for vanilla doom 1.9, so source ports are not considered a solution to the problem discussed in this thread.

Share this post


Link to post
6 hours ago, Graf Zahl said:

Yes, this is a vanilla limitation. The function to find the next highest (lowest?) neighboring sector was very, very stupidly done, instead of just iterating over the neighbors, it stored the height info in a local array to check that later. That array had 20 entries, you could add two more due to other variables on the stack before it crashed.

 

That function is actually a genuine facepalm thing, one has to wonder how anybody could come up with something this idiotic.

 

Take a shot every time id uses a table to hold data, regardless of whether or not it's needed at all.

 

Seriously, I feel like they made a lot of really weird coding decisions and I don't know why.

Share this post


Link to post

PROBLEM SOLVED

---------------------

 

Thanks to @ViolentBeetle for the solution. And @Graf Zahl for pointing out that this limit refers to sidedefs, not sectors.

 

Now @ViolentBeetle suggested that I split that huge lava sector into some smaller sectors. I didn't expect it to work, too many moving parts or something, but I tried it and it worked just fine. I split that sector into 9 segments, as seen in this pic:

 

ZzAWH3J.png

 

Each of these new sectors has up to, but not more than, 20 linedefs, (both surrounding or internal,) associated with it. I then created a dummy sector, with 8 of the sectors attached to it, which was one unit higher than the lava sectors, and had water as a floor texture:

 

WB9xe8c.png

 

The 9th sector used the switch itself as its reference sector, and so did not need to be attached to the dummy sector:

 

w8QVokd.png

 

(Seeing as Action 20: Raise floor to next higher floor, (changes texture,) uses the front sidedef of the switch as a reference sector for what the switch will do, the one-unit-wide blue border around the above silver switch served as both the reference sector for the switch linedef itself, as well as the next-higher-floor from the lava sector around it.)

 

*Super interesting side note. A couple of the sectors have exactly 20 sidedefs associated with the main body of the sector, (internal plus bordering linedefs,) plus the three linedefs in the dummy sector, which makes 23, which is obviously above 22. I don't know why this is the case, but I do know that Chocolate Doom doesn't crash with the map as it is now when activating the switch.

 

*Another moderately interesting thing is that all of the lava sectors had the Effect 4 (damage 10-20% health and light blinks - 0.5 seconds) applied to them, from when the original single lava sector had that effect. Now all but one of the sectors blinks up and down from their own light level (208) to the light level of surrounding sectors (mostly 192) but this one sector for some reason is blinking from 208 down to zero. I don't know why this happens to this one sector only... aaaaaand even as I am typing this, I worked it out. (*goes and checks) That is the only sector that does not have a surrounding sector with a lower light level, but instead has two adjacent sectors with higher light levels, so I think it blinks to zero instead of blinking to an adjacent lower light source sector. I thought it might have been related to the issue at hand, but it really isn't at all. Good stuff. Go me. asdfsdfasadfsadfsfdasdafasdffsda.

 

Anywhoo, thanks for all the help and replies. Appreciated.

Share this post


Link to post

And thanks for sharing your results! Workarounds like these are great for future reference when vanilla gets destroyed by an elaborate floor move setup. ;)

Share this post


Link to post

I had the same problem with Zone 400 MAP23 and needed to do some major design changes to fix it. Glad I did not scrap the map, it is one of the best in Zone 400.

Share this post


Link to post
1 hour ago, Uncle 80 said:

And thanks for sharing your results! Workarounds like these are great for future reference when vanilla gets destroyed by an elaborate floor move setup. ;)

 

Had a good look at that little donut map you uploaded here. I am kind of blown away by the possibilities. You can almost treat the raising floor and the lowering floor as two completely different entities. Boom functionality in vanilla. This is legit pretty big in terms of expanding vanilla capabilities. Awesome. I assume you gutted this little segment from a larger map, I guess this from there being unused dummy sectors there. At first I thought it was way more complicated. It still is complicated, but just less than I first thought. Thanks so much for uploading this little map. I have a folder called "example wads." And in it I keep stuff like this, little tricks, hints, cool ideas etc etc. And this map will wind up in there. Good luck with your project too. I am interested to see it when it is getting towards done.

Share this post


Link to post

@Kyka Actually, I made it from scratch in 20 minutes after our little exchange yesterday, but I took the approach of making all dummies before the rest of the map, so there are a few extra that ended up unused, yes :) This exploit of line action 9 is indeed useful/powerful, and when I'm discussing mapping techniques with myself, I often playfully refer to action 9 as Vanilla Scripting, heh. I considered uploading one of my maps from my project, but the stuff I've done there is a tiny bit more complicated and I decided against revealing them too soon ;)

Share this post


Link to post

Just to be clear, does this mean Chocolate Doom needs to have that error message altered slightly to say linedefs rather than sectors? (Assuming the latest version of Chocolate Doom was used). Just asking so I can pass it on to fraggle if need be.

Share this post


Link to post

I don't know whether it is the very latest version, but I only downloaded it a few months back, when I started getting involved with tnt forever once again. So if not the very latest version, it would have to be not too far off.

 

*checks

 

I don't actually know how to check what version it is, but the actual .zip file I downloaded is named "chocolate-doom-3.0.1-win32" so version 3.0.1?

 

Hope that helps.

 

[edit] It also says 3.0.1 on the error message that I posted a screen of in the OP.

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
×