Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004204Zandronum[All Projects] Bugpublic2024-03-08 04:512024-04-08 20:27
Assigned To 
PlatformOSOS Version
Product Version3.1 
Target Version3.2Fixed in Version3.2 
Summary0004204: Non-standard player classes can cause "eaten" skins and crashes
DescriptionWhen loading files with multiple non-standard (non-DoomPlayer inheriting) player classes alongside skin files which have skins for player classes which are not in the load order, it is possible for valid skins to be improperly removed from the list. This extends to the "Base" skin designated for each player class, which causes a known crash when opening the Player Setup menu with that class selected. Some players have also reported crashes as soon as the game starts up in this scenario.

I've attached a few example files to illustrate this problem as well as a potential patch to fix it. The patch adds an extra validation step before removing any skin. It would probably be better to tackle the logic leading up to the improper removal instead, but I wasn't too familiar with that area of the code to go that route.
Steps To ReproduceFirst, load freedoom1.wad and NewPlayerClasses.pk3. The latter file implements a FreeDoomMarine1 (FreeDoomPlayer1) and FreeDoomMarine2 (FreeDoomPlayer2) player class, neither of which inherit from DoomPlayer. Neither of these classes should have any skins at this point.

Next, load freedoom1.wad, NewPlayerClasses.pk3, FreeDoomMarine2Skins.pk3, and FreeDoomMarine3Skins.pk3. FreeDoomMarine2Skins.pk3 attempts to define two skins for FreeDoomMarine2 while FreeDoomMarine3Skins.pk3 does the same for the non-existent FreeDoomMarine3. In-game, you'll notice that FreeDoomMarine2 only has one extra skin defined, rather than the two, so one was eaten.

Finally, load freedoom1.wad, NewPlayerClasses.pk3, and FreeDoomMarine3Skins.pk3. Attempting to open the Player Setup menu with FreeDoomMarine2 selected will now crash the game, because the FreeDoomMarine3Skins.pk3 file has eaten the "Base" skin for FreeDoomMarine2.
Additional InformationThis issue has historically impacted class mods in MM8BDM which want to remove the default Megaman class (which doesn't inherit from DoomPlayer). Because all skin packs there typically use a "class" of Megaman, people with skins in their skins folder would always experience these crashes.
Attached Files? file icon NewPlayerClasses.pk3 [^] (999 bytes) 2024-03-08 04:51
? file icon FreeDoomMarine2Skins.pk3 [^] (139,633 bytes) 2024-03-08 04:51
? file icon FreeDoomMarine3Skins.pk3 [^] (139,635 bytes) 2024-03-08 04:51
patch file icon skin_removal.patch [^] (2,300 bytes) 2024-03-08 04:52 [Show Content]
? file icon FreeDoomMarine2+3Skins.pk3 [^] (139,645 bytes) 2024-03-08 17:22
? file icon FreeDoomMarine3+2Skins.pk3 [^] (139,645 bytes) 2024-03-08 17:23
patch file icon skin_removal_BOF.patch [^] (594 bytes) 2024-03-24 01:05 [Show Content]

- Relationships

-  Notes
User avatar (0023316)
Trillster (reporter)
2024-03-08 17:22

Disregard the previous patch, after some further testing, I've realized that it doesn't solve this issue in all scenarios. I've attached two more testing files to showcase this.

FreeDoomMarine2+3Skins.pk3 combines the two prior testing files, putting 2's skins first then 3's. FreeDoomMarine2's second skin will still be eaten with the patch in play.

FreeDoomMarine3+2Skins.pk3 does the same, except it puts 3's skins first then 2's. The issue doesn't occur with this file, patch or no patch.

This makes me believe the crux of the issue is that whenever all loaded player classes don't inherit from a standard player class (ie. DoomPlayer) and the last skin of a SKININFO file is set to be removed, after that skin is removed, the parsing to finish out the file will end up removing one extra skin than intended.
User avatar (0023478)
BarrelsOFun (reporter)
2024-03-24 01:04
edited on: 2024-03-24 01:05

The issue was caused by the basetype of the last skin being reinitialized from the removal continuing the loop, which leaves it at an uninitialized value.
the initializer after the fact sets it to the default basetype of whichever game it is, and when that isn't there in the next check, then the skin gets removed.
This patch adds a check at if (remove) to finish parsing the individual skin by checking for '}' and will continue if hit, otherwise breaking when out of strings. When S_SKIN it should just break, since S_SKIN generally only holds one skin unless it's converted into a SKININFO

User avatar (0023512)
Trillster (reporter)
2024-03-30 20:53

Can confirm that the most recently uploaded patch corrects the issues.
User avatar (0023531)
Ru5tK1ng (updater)
2024-04-07 20:39

Change was merged in:' [^]'
User avatar (0023558)
Ru5tK1ng (updater)
2024-04-08 20:27

Tested the skin files with the latest 3.2 beta there was no crash and the skin count for the 2nd class was 2.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2024-03-08 04:51 Trillster New Issue
2024-03-08 04:51 Trillster File Added: NewPlayerClasses.pk3
2024-03-08 04:51 Trillster File Added: FreeDoomMarine2Skins.pk3
2024-03-08 04:51 Trillster File Added: FreeDoomMarine3Skins.pk3
2024-03-08 04:52 Trillster File Added: skin_removal.patch
2024-03-08 17:08 Kaminsky Status new => needs review
2024-03-08 17:22 Trillster Note Added: 0023316
2024-03-08 17:22 Trillster File Added: FreeDoomMarine2+3Skins.pk3
2024-03-08 17:23 Trillster File Added: FreeDoomMarine3+2Skins.pk3
2024-03-24 01:04 BarrelsOFun Note Added: 0023478
2024-03-24 01:05 BarrelsOFun File Added: skin_removal_BOF.patch
2024-03-24 01:05 BarrelsOFun Note Edited: 0023478 View Revisions
2024-03-30 20:53 Trillster Note Added: 0023512
2024-04-07 20:39 Ru5tK1ng Note Added: 0023531
2024-04-07 20:39 Ru5tK1ng Status needs review => needs testing
2024-04-07 20:39 Ru5tK1ng Target Version => 3.2
2024-04-08 20:27 Ru5tK1ng Note Added: 0023558
2024-04-08 20:27 Ru5tK1ng Status needs testing => resolved
2024-04-08 20:27 Ru5tK1ng Resolution open => fixed
2024-04-08 20:27 Ru5tK1ng Fixed in Version => 3.2

Questions or other issues? Contact Us.


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker