ZDoom

So, I'm working on a script that teleports the player to a new location and changes their player class when activated. I'm currently using MorphActor to go through with the transformation, however, MorphActor does not allow the player to switch weapons beyond that point, and the new actor they transform into is supposed to have an all new weapon set, beyond just one weapon, like in Hexen. Is there any way to go about doing this cleanly?

The cleanest way to do this is to not use different player classes at all, but rather just be selective about what weapons a player can get as a "class" and using ACS or ZScript to change the player's properties ( like speed, max health, etc. ) appropriately.

Ehhhhh... That's what I'd read, but I'd figured that in the ten years since the last time it was asked, someone would've had a better solution... guess that was too much to expect...

It really would be nice to have a morph option that doesn't presuppose any time limit and does nothing with the player's inventory. Has someone posted a feature suggestion along those lines before?

Well, it may be possible to copy a lot of what P_MorphPlayer does in ZScript and not run into any real problems due to being able to create an implementation that doesn't have to be generic but rather is tooled for the needs of the project. This is just spitballing, though, I'm not sure if there's anything outright necessary in the morph code that can't be done in ZScript that would prevent replicating it.

The main thing I can think of that can't be done in ZS is changing playersprites for both main and crouch sprites. The problem I described could be worked around, but the workaround is a hack with constraints and side effects.

Beyond that, it would just look a lot cleaner for certain implementations to define all this by different playerclasses instead of functions that change properties.

That wouldn't really be much of an issue if a good chunk of the morph code can be used in ZScript, due to the fact that it just creates a new PlayerPawn entirely and transfers the player and some of the first PlayerPawn's properties over to it.

I get the feeling that a lot of limitation of morphs stem from the fact that the old PlayerPawn still sticks around, just put into an "out of game" state, and it's brought back to normal once the morph runs out. Though I'm not sure how giving the player a new PlayerPawn will interact with entering a new level - possibly you'd end up in the old one again.

Problem is, my project is for Zandronum, so ZScript isn't an option

I'm not entirely sure why you were expecting a better solution, then. Zandronum is pretty antithetical to elegant solutions due to how far behind it is.

Actually, I had one pop up I'd thought about. Since the player is still collection weapons/items (most of them, anyways) while transformed, maybe have an ACS script run that checks the player's input, and when they try change weapons, have the script run some inventory checks and force said weapon into their hands.

You can't catch the player's weapon selection inputs in ACS. Heck, I'm not even sure if you can really do that in ZScript, since they're just a special wrapper for the "use [weaponname]" console command.