Maps that need compatibility settings.

[drfrag]

The problem causing the crash is that the sector is null, in MapLoader::LoadSideDefs2:

Code:

      if ((unsigned)LittleShort(msd->sector)>=Level->sectors.Size())
      {
         Printf (PRINT_HIGH, "Sidedef %d has a bad sector\n", i);
         sd->sector = sec = nullptr;
      }

So does it make sense using sector 0? Or a fake null sector?

Last edited by drfrag on Thu May 28, 2020 4:39 pm, edited 1 time in total.

PRBoom+ and others (but not Crispy) use sector 0 and that mostly fixes the crash but still crashes at times and crashes earlier.
With:

Code:

sd->sector = sec = &Level->sectors[0];

Crashes here:

Code:

sd->SetTextureXOffset(LittleShort(msd->textureoffset));

Code:

>   lzdoom.exe!MapLoader::LoadSideDefs2(MapData * map, TMap<FString,FMissingCount,THashTraits<FString>,TValueTraits<FMissingCount> > & missingtex) Line 2172   C++
    lzdoom.exe!MapLoader::LoadLevel(MapData * map, const char * lumpname, int position) Line 3012   C++
    lzdoom.exe!P_SetupLevel(FLevelLocals * Level, int position, bool newGame) Line 465   C++
    lzdoom.exe!FLevelLocals::DoLoadLevel(const FString & nextmapname, int position, bool autosave, bool newGame) Line 1165   C++
    [Inline Frame] lzdoom.exe!G_DoLoadLevel(const FString & newGame, int) Line 1039   C++
    lzdoom.exe!G_InitNew(const char * mapname, bool bTitleLevel) Line 552   C++
    lzdoom.exe!G_DoNewGame() Line 422   C++
    lzdoom.exe!G_Ticker() Line 1127   C++
    lzdoom.exe!TryRunTics() Line 1993   C++
    lzdoom.exe!D_DoomLoop() Line 1381   C++
    lzdoom.exe!D_DoomMain_Internal() Line 3660   C++
    lzdoom.exe!GameMain() Line 3673   C++
    lzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 963   C++
    lzdoom.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, wchar_t * cmdline, int nCmdShow) Line 1242   C++


IMO it's not worth adding a compatibility entry for this, it's a random 1994 quality map. I mean the bad reviews discourage dowloading it and it always crashed in ZDoom.

I'm not really sure the quality of the map matters in these decisions...

IMO there should be a minimum, Graf said at some time there were already too many compatibility entries. I don't think supporting every random map out there is a good solution.
Anyway it's fixed and i've done a PR.
https://github.com/coelckers/gzdoom/pull/1092

No, it isn't, still crashes from time to time. The texture names change and are random junk.

Code:

e1m1 - Hangar

Linedef 72 has a bad sidedef
Linedef 74 has a bad sidedef
Sidedef 92 has a bad sector
Unknown middle texture 'ÿ#+ÿ' on second side of linedef 72
Unknown top texture 'ÿOc{ÿ' on second side of linedef 72
Unknown bottom texture '‡Ÿ·ÿ7/ÿ' on second side of linedef 72
Sidedef 95 has a bad sector
Unknown middle texture 'ÿ#+ÿ' on second side of linedef 74
Unknown top texture 'ÿOc{ÿ' on second side of linedef 74
Unknown bottom texture '‡Ÿ·ÿ7/ÿ' on second side of linedef 74


Fixed for real this time, it seems. The logic to deal with NO_INDEX is not in, i've used a dummy sidedef.
https://github.com/coelckers/gzdoom/pull/1093

Not sure if this is the right place for this, but I can't get Sunlust's (https://www.doomworld.com/idgames/level ... ds/sunlust) map30 to work properly at all.

1 of 2 things happen in Boom (strict) compatibility mode or default compatibility mode. Either the monster spawning starts too early, or it fails to spawn the revenants in the first arena.

Edit: apparently this was mentioned and the monster spawning too early just happens in Boom (strict) (it shouldn't though?). But the revenants failing to spawn happens in both modes + boom.

Regarding REKKR E1M3:

To open the door to the freezer room, you're supposed to press the middle button, then the left button, then the right button, in that order. The middle button completely lowers a lift in a hidden room; the left button raises that lift a step; and the right button opens a slit that, if the player pressed the buttons in the correct order, allows a scarecrow-looking thing to shoot a wall that opens up the freezer room.

In GZDoom, the problem isn't that the scarecrow isn't firing (it is), but that it shoots its arrows a bit too low, so they don't pass through the slit. Because of this, the player must press the left button again (to raise the scarecrow's lift more) immediately after entering the correct button combination; this gives the scarecrow a chance to shoot through the slit (due it its extra height), thus opening the freezer room.

Played through obtic.wad recently, MAP01 needs compat_shorttex, checksum:

Code:

41C12F740CD7635E4595D3661237992F

I don't have the time to test this, nor the desire to set up Obituary on my system right now - so I've put it in a pull request so it doesn't get lost: https://github.com/coelckers/gzdoom/pull/1381

What is it needed for? I also have no desire looking for some random change occurring in that map.

Sorry, forgot to mention it's for the yellow key. Without the compat flag, the platform it's on raises up too high when you cross linedef 496 (W1 Floor Raise by Shortest Lower Texture).

Last edited by Warden on Mon May 24, 2021 5:18 pm, edited 2 times in total.

Perdition's Gate (http://visionsofdoom.us/wads/perdgate.zip) Map 07 (https://doomwiki.org/wiki/MAP07:_UAC_Nukage_Areas,_Nukage_Monitor/Flow_Control_Facility_(Perdition%27s_Gate))

The yellow door can only be opened once (Action 34: D1 Door (Yellow) - Open Stay). Reentering the previous area again triggers a linedef that closes the door (Action 107: WR Door Close Stay (fast)) and the yellow key does not work anymore (btw: Why?).

Return to Phobos (return01.wad) has an ancient bug in map E1M2 where the switch to raise the exit bridge doesn't work in versions of Doom past patch 1.2. Here's a level_compatibility.zs fix:

Code:

        case 'E0D747B9EE58A0CB74B9AD54423AC15C': // return01.wad e1m2
        {
            // fix broken switch to raise the exit bridge
            SetLineSpecial(1248, Floor_RaiseByValue, 39, 8, 512);
            break;
        }


Yeah, that one. Ran into it in 1995 with no idea why the map was broken.