[Hexen] Class change in-game causes instability, issues
I thought it would be cool to change the character class in the middle of the game by using bindings, so I don't have to type stuff everytime I want to change.
There are some bugs:
The player view angles changes. This is not so life threatening as the next one..
The monsters may ignore the visible player and start attacking some invisible thing in the spot I had changed my class. This will give damage and I will notice it when I change back to the class I was at that spot. They can also kill player by killing the invisible one. I think the current player became immobilized + view lowered when they killed the invisible one. Then the monsters came to me and attacked me until I had my health down to 0.
I'm not exactly sure what causes them sometimes attack some invisible thing, but it seems to happen more often when the monsters can't get to me or when they don't see me. Sometimes as much as I try to cause the bug, the monsters just keep targeting me.
It happens with both shadowcaster cheat and using class in the console. I've tried it in 1.8.6 and 1.9.0-beta6 and happend in both.
I attached my key bindings as a text file..
#1 Updated by jimigrey over 13 years ago
Class changing weapon bindingsAttachments:
#2 Updated by danij over 13 years ago
When a player class change occurs, the player is spawned again at the same location resulting in a new mobj. Problem is, there could be pointers to the old mobj all over the place, for sector sound origins and indeed enemy pursuit targets. Even though the old mobj is "removed", it may not actually be free'd, instead being moved to list of used mobjs ready for reuse, however, it might be a while before that happens and in the mean time, pointers to it are still valid. Thats why attacking the empty spot where you were when you changed class still causes you damage because there is copy of yourself there.
Why are we calling P_SpawnPlayer in this instance? Do we truely want a new mobj at this time? If so then obviously we have quite a bit of bookkeeping that is missing that needs adding.
Or by calling P_SpawnPlayer are we just trying to return the player to the state they would be in had they spawned at the current player position and of the target class? If so then it would be a good idea to split the default player state setup out of P_SpawnPlayer and into a new routine which can be called by both P_SpawnPlayer and P_PlayerChangeClass.
Personally, I favour doing the later as its simpler all round.
#3 Updated by danij over 13 years ago
After further investigation, doing this the proposed "easy" way would not actually be possible without first addressing a fundamental design issue:
In Hexen, each player class has mobj type specifically for that class (fighter = MT_PLAYER_FIGHTER, cleric = MT_PLAYER_CLERIC, etc...).
So that means that we need either need to change the mobj type dynamically (might be tricky? what is tied to this?) or we need to revise how we interpret the mobj types for jHexen, spawning all players as MT_PLAYER and then picking the Mobj type definition according to a mobj_t->type AND mobj_t->class.
#4 Updated by danij almost 10 years ago
I'm raising the priority of this to a more appropriate level because it is a real stability issue. Particularly in multiplayer where there is the very real possibility of crashing the server merely by playing the game in the intended manner. See my comment on 2009-03-12 at 02:08 PDT for more details.