Currently I know this is possible in multiplayer when you die and respawn but I have a special reason to be able to use this in single player as well.
To be specific I'm wondering if it would be possible for, maybe a script, to be able to change the player's class between levels in a game, so that when the player starts the next level, they'll start as the new class.
Dimension LXXII has different characters, and through scripting, character-specific weapons, inventory, magic, and also have 3 different campaigns that introduce different styles of gameplay. I also want to add a "mixed" campaign that tells the full story all at once and would involve use of all of the characters one at a time, rotating between each one per level, Sonic Adventure 2 style.
This would also allow for the introduction of "restricted" classes that can be accessed in-game which would be used for, for example, an evolving player-monster that can change types, or maybe classes that have different special fields that can later on change what they specialize in.
Mid-game (Not *IN*-game) class changing?
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
Mid-game (Not *IN*-game) class changing?
Last edited by Kate on Mon Oct 01, 2007 10:55 am, edited 1 time in total.
The different between this and those feature requests was that they wanted to change the player class in the level, which is an open no-no because certain actor properties that require to be changed like height/crouch height/jump height, speed and such are hard-coded to the actor, so that would require changing all of the actor's current properties dynamically (especially it's radius and height, which could also especially result in getting stuck in walls and ceilings without proper checks for such cases).
This would only take effect after the level has changed since in this case one could just simply spawn a different actor as the level is being loaded. One could also probably make an exception to prevent it in things like hubs where it would result in weirdness when the player returns to the level since all of the state data gets saved and reloaded.
This would only take effect after the level has changed since in this case one could just simply spawn a different actor as the level is being loaded. One could also probably make an exception to prevent it in things like hubs where it would result in weirdness when the player returns to the level since all of the state data gets saved and reloaded.
This to me sounds doable right now. None of the issues with dynamically changing the class appear to be an issue; all the properties would just be reset to their default values (e.g. the player gets max health and the starting weapon(s)) as if the player had started a new game. If finer control is needed, it can be accomplished with scripting.
...As I think about it, it would make more sense to supply as an additional argument to ChangeLevel, since the SetClass call alone would effectly be a NOP until next map change, so it would make more sense to have the actual function to change the map also be able to change the class as well. In this case, if the class parameter is used, then CHANGELEVEL_RESETINVENTORY is automatically implied since the behavior would otherwise require it to operate properly.
Or have it print a small warning or something if a new class is specified but the inventory reset flag isn't, which wouldn't confuse people as much and would explain to them why their inventory was reset when they weren't expecting it.
Or have it print a small warning or something if a new class is specified but the inventory reset flag isn't, which wouldn't confuse people as much and would explain to them why their inventory was reset when they weren't expecting it.