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
0001608Zandronum[All Projects] Bugpublic2013-12-08 21:022022-10-14 03:54
ReporterTerminusEst13 
Assigned ToDusk 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version1.2 
Target VersionFixed in Version 
Summary0001608: Swapping player classes on Unloading/Intermission screen does not reset inventory.
DescriptionWhen changing class via Player Setup, you're supposed to lose all your inventory and start afresh with new stuff, right?
When done between maps on the Unloading screen, it...doesn't. So you spawn as the new class with the old inventory intact.

This is especially a pain in the ass for class-based mods (like Samsara) because it spawns you as the class with all the visual enhancements (new hud, sprites, sounds) and stats (damagefactors/resistances/etc), but the weapons and items from the previous class are still in your arsenal. So you can play as Parias with his massive explosive resistance and speed while using Duke Nukem's explosive-heavy arsenal.
Steps To Reproduce1: Load class mod online (Like Samsara :D :D)
2: Go play a level with one class, pick up weapons and stuff
3: On intermission screen, go to Player Setup and change to another class before the next level loads.
4: If you're (un)lucky, you'll spawn in the next level with your new class using the old class' weapons.
Additional Informationverified by Dusk, screenshot is his
Attached Filespng file icon Screenshot_Doom_20131208_214634.png [^] (77,682 bytes) 2013-12-08 21:02

- Relationships
duplicate of 0001313resolvedKaminsky PlayerClass desync/incorrect weapon when changing maps in co-op 

-  Notes
User avatar (0007689)
Dusk (developer)
2013-12-08 21:38

It seems there was a workaround to preventing this from happening. p_mobj.cpp:4746:

// [BB] The (p->userinfo.PlayerClass != p->CurrentPlayerClass) check allows the player to change its class when respawning.
// We have to make sure though that the class is not changed when traveling from one map to the next, because a travelling
// player gets its inventory from the last map (which of course belongs to the previous class) after being spawned completely.


It seems the player class isn't supposed to change over map changes but it does. I don't really know how to handle this. What exactly are these PST_* constants? First thing that comes to my mind would be something like


if( p->playerstate == PST_LIVE )
{ p->p->userinfo.PlayerClass = p->CurrentPlayerClass;
    p->cls = PlayerClasses[p->CurrentPlayerClass].Type;
}
User avatar (0007700)
Torr Samaho (administrator)
2013-12-15 20:32

For the sake of completeness, here are some comments on what the PST_* constants are meant to do:

[21:11:30] <Torr_Samaho> PST_LIVE and PST_DEAD are the common ones and should be more or less self explanatory.
[21:12:12] <Torr_Samaho> The other four describe intermediate states that will be taken care of when the player is spawned.
[21:13:06] <Torr_Samaho> For instance the state PST_ENTER means that the player just entered the game and will trigger enter scripts when spawned.
[21:14:12] <Torr_Samaho> PST_REBORN is similar. The player is meant to respawn and will get his inventory depending on the game mode.
[21:14:48] <Torr_Samaho> PST_REBORNNOINVENTORY and PST_ENTERNOINVENTORY are variants of the PST_REBORN and PST_ENTER.
[21:15:07] <Torr_Samaho> Script handling is the same, but the player will get no inventory when spawned.
[21:15:24] <Torr_Samaho> In all cases the state changes to PST_LIVE when the spawning is completed.

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
2013-12-08 21:02 TerminusEst13 New Issue
2013-12-08 21:02 TerminusEst13 File Added: Screenshot_Doom_20131208_214634.png
2013-12-08 21:02 Dusk Assigned To => Dusk
2013-12-08 21:02 Dusk Status new => assigned
2013-12-08 21:03 Dusk Reproducibility sometimes => always
2013-12-08 21:38 Dusk Note Added: 0007689
2013-12-15 20:32 Torr Samaho Note Added: 0007700
2019-06-04 21:54 Dusk Status assigned => new
2022-10-14 03:54 WaTaKiD Relationship added duplicate of 0001313
2022-10-14 03:54 WaTaKiD Status new => closed
2022-10-14 03:54 WaTaKiD Resolution open => duplicate






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker