[Resolved] Chocolate Doom: "Vanilla will crash here"

I was testing my map on Chocolate Doom 1.2.1 when the program suddenly exited with the error below in the console:

Error: Sector with more than 22 adjoining sectors. Vanilla will crash here

This sounds like I either exceeded one of the limits of Vanilla or there is a bug somewhere in the map. Is there any way for me to find out exactly which sector number it is referring to (besides poking around at random in my editor)?

I can only assume this is due to this lesser-known vanilla limit:

fixed_t	P_FindNextHighestFloor(sector_t *sec,int currentheight)
{
	int			i;
	int			h;
	int			min;
	line_t		*check;
	sector_t	*other;
	fixed_t		height = currentheight;
	fixed_t		heightlist[20];		// 20 adjoining sectors max!
	
	for (i =0,h = 0 ;i < sec->linecount ; i++)
	{
		check = sec->lines[i];
		other = getNextSector(check,sec);
		if (!other)
			continue;
		if (other->floorheight > height)
			heightlist[h++] = other->floorheight;
	}
	
	//
	// Find lowest height in list
	//
	min = heightlist[0];
	for (i = 1;i < h;i++)
		if (heightlist[i] < min)
			min = heightlist[i];
			
	return min;
}

A static array is used to track sector floor heights for the "next highest floor" line action target. There is, as you might be able to tell from above, no rangechecking when adding sectors to this temporary list (the line heightlist[h++] = other->floorheight;).

This means that DOOM starts to corrupt memory if more than 20 sectors are adjacent to a sector that is the target of such an action. Because of some extra space on the stack, I assume it can corrupt up to 2 additional DWORDs of space before biting the function's activation record and crashing the game.

Well that's new to me.

Quasar said:

This means that DOOM starts to corrupt memory if more than 20 sectors

Yikes. No error or exit? Shame on him.

sparerib1968 said:

Is there any way for me to find out exactly which sector number it is referring to (besides poking around at random in my editor)?

prboom-plus -complevel 2 -> stdout.txt

Quasar said:

. . . P_FindNextHighestFloor . . .

I think that must be it. I had set that action on a linedef and left the sector tag at "0". (Doh! I really thought I had set the tag.)

entryway: I had wanted to try your idea, but the problem seems to be resolved. It looks like Quasar's guess is correct because the map works fine in Chocolate now. I will try to remember that in the future though.

Thank you, everyone.

Maybe the error message should be rephrased, so that map authors immediately know that it is related to a P_FindNextHighestFloor action. The way it is, it would have confused the hell out of me too.

This sounds like a great idea for a DoomBuilder 2 plugin; "Vanilla Limit Checker" - its purpose would be to extend the functionality of the existing map error checking by adding additional checks for vanilla limit breaches.

Yeah, DB2 enhancements for limits would be nice.

Erik brought this limit to light recently. Level 24 of Scythe 2 had the problem and I read he had to make some edits to a Scythe X level to avoid it.

In this case, the overflow was probably being triggered when the map went crazy due to the tag 0, though. So the tag 0 might have been the problem, and the overflow only a symptom.

Are Boom-like ports saved from this limit?

printz said:

Are Boom-like ports saved from this limit?

Here's the same function in BOOM:

//
// P_FindNextHighestFloor()
//
// Passed a sector and a floor height, returns the fixed point value
// of the smallest floor height in a surrounding sector larger than
// the floor height passed. If no such height exists the floorheight
// passed is returned.
//
// Rewritten by Lee Killough to avoid fixed array and to be faster
//
fixed_t P_FindNextHighestFloor(sector_t *sec, int currentheight)
{
  sector_t *other;
  int i;

  for (i=0 ;i < sec->linecount ; i++)
    if ((other = getNextSector(sec->lines[i],sec)) &&
         other->floorheight > currentheight)
    {
      int height = other->floorheight;
      while (++i < sec->linecount)
        if ((other = getNextSector(sec->lines[i],sec)) &&
            other->floorheight < height &&
            other->floorheight > currentheight)
          height = other->floorheight;
      return height;
    }
  return currentheight;
}

DaniJ said:

This sounds like a great idea for a DoomBuilder 2 plugin; "Vanilla Limit Checker" - its purpose would be to extend the functionality of the existing map error checking by adding additional checks for vanilla limit breaches.

I would love to have such a tool. It would be worthwhile for me to install Windows in a virtual machine just to run Doom Builder 2.

One problem with the idea is that relatively very few of the limits in DOOM are testable in a static manner -- that is, just by examining the map. Many of them can only be triggered by simulating the actual game engine. Imagine for example searching for potential intercepts overflows amongst 2S linedefs. This would require casting bullet tracers from every point on the map to every other point within range, and that still would not account for the influence of mapthings or dynamically spawned objects.

Visplanes would be a similar nightmare, and would require running the 1S rendering step of the DOOM engine for every possible coordinate point in order to build the visplanes and then count them.

Openings and solidsegs are in the exact same situation.

Even the limit on simultaneous active switches is difficult to test for, as it would also require volume sweeping with tracers to account for gun triggers.

It wouldn't be trivial, but surely something more efficient than walking around the map in Doom and waiting for it to get an error or some weird effect should be possible (granted, there's also chocorenderlimits, that is more convenient). And being a plugin, it may be developed by anyone who's skilled and interested, leaving CodeImp's hands free.

I'm guessing VPO detection would still require the use of the DB camera or the like, checking visplane values in all directions from its current location, even through doors and the like that may be raised or lowered.

Intercepts doesn't seem possible, because it depends a lot on the location of monsters corpses and dropped items, but the calculation in a more static way may be helpful to the mapper.

Some other vanilla checking is easier to implement, though, such as the tutti frutti and medusa phenomena.

Perhpas enhancing chocorenderlimits would be somewhat more effective, however, at least for the more dynamic or relative limits, as it's already directly based on (Chocolate) Doom. Thus, less needs to be added to it to catch bugs and potential issues. Otherwise, you'd have to somehow add Doom's idiosyncrasies to DB2.