This switch currently crashes chocolate Doom.

[Kyka]

All the tags are correct. The switch opens a series of doors.  of the doors are monster closets, the 10th is the door for progression, and the 11th is an off map teleport. The switch has action 112: S1 door open fast (stay). The sector and linedef tags are correct and the switch works fine on GZDoom. The only thing I can think of is that there is too many linedefs associated with the switch itself (44), which may be triggering the crash. (All of the smaller door sectors are one sector.) Here is an image:

 

Would appreciate any thoughts.

 

 

 

 

[Vermil]

Too many moving sectors?

 

https://doomwiki.org/wiki/Moving_platforms_limit

[Quasar]

What is the error message you get?

[Kyka]

It is an intermittent error, it doesn't happen everytime. But when it does happen, there is no error message, the game freezes upon hitting the switch, and then drops back to Windows.

[Kyka]

That error specifies floors. I am guessing that this moving limit also applies to ceilings? (ie opening doors.)

 

To answer your implied question though there are 5 sectors associated with that linedef. 4 of those sectors are single doors with 4 linedefs, the fifth has 8 doors with 32 linedefs associated with it. 

[IcarusOfDaggers]

BE AWARE, the following is based on my limited experience with doom and there are bound to be some things wrong on the technical side. if you spot it, please feel free to correct me.

 

This is just what i experienced and how I fixed it (and my presumption about why it happens)

 

It is indeed related to too many actions, but the exact cause (for me) is unknown. 

However, when a program crashes and closes without error message, you can assume it's an unknow  one at the time of the programs development or an overload of available resources.

Best way to mitigate this problem, is to split this action into 2 switches instead of 1 for choco doom (say, one switch reveals the other switch on top of opening some of those area).

 

The game engine will usually be able to sort out these kinds of issues by queueing the operations. But for some reason, it does NOT like to do that when there are too many actions of a similar type, most likely due to something (more likely a demon) suddenly hogging the resources needed to trigger the actions.

[Doomkid]

Are you able to test in DosBox? It could potentially help in identifying what's going on here

[Uncle 80]

If the crash isn't consistent, perhaps it may be related to things' hitboxes being "stuck" in the doors? Like, when you place a thing too close to a raised platform it sometimes "jumps" up when you view it from a different angle? Does the error occur with -nomonsters? I have experienced problems with monster closets (using lowering walls) not lowering when viewed from different angles in Doom2.exe (when a thing's hitbox collides with the geometry after the things inside it "jump" up or down before activating the lowering floor) , but never resulting in a crash. I have very limited user experience with Choco, though.

 

A second theory might be the "bounding box" - if all those doors are joined into a single sector, the sectors "bounding box" may or may not cover large parts of the whole area, thus interfering with objects and/or other geometry in ways I can't explain... it might be worth trying to make all the doors into individual sectors to see if the problem persists.

Edited June 21, 2022 by Uncle 80

[Noiser]

See if there is any multi-patched wall used as mid-texture. That freezes chocolate doom without any message.
If you are not sure if a texture have more than one patch, you can see it on Slade (under the Texture lump).