Adding player classes via ZScript

[Marrub]

I want my mod to add some player classes when ZScript is available, but I've no idea how to do this.
There's a PlayerClasses global array, but it's readonly. Is there any way to do this outside of MAPINFO?
Also a problem is that my weapon base class is in DECORATE, so I'll have to figure out some way to export it to ZScript, but that's another issue entirely.

[Xaser]

The hard answer is there isn't any way to do this -- stuff traditionally done in MAPINFO's GameInfo block is still done in GameInfo, even in ZScript-land -- though it seems like an odd problem to need to solve if I'm reading it right (conditionally loading a playerclass in a ZScript-capable ZDoom?).

What's the end goal, out of curiosity? There may be another path that works.

[Marrub]

The new player classes in Lithium will be written in ZScript because I'm sick and tired of DECORATE. The majority of code will still be in C, but anything I would have written in DECORATE should now just be in ZScript. (The first two classes will stay as they are, of course.)
Originally I had planned to put them in a separate character pack, but honestly that's a bit of a pain for the end user and could get confusing (especially version-wise.) So what I want to do is add these player classes only if ZScript is available.
One solution that I thought of was that I could put the playerclasses in the MAPINFO and only define them in ZScript, but the issue with that is my base playerpawn is written in DECORATE... so I can't derive from it.
Any ideas there?

[Xaser]

The only real way to achieve what you're looking for without jumping to the latest GZDooms is to fall back to the original idea and make the character pack a separate .pk3. Apologies for the being the proverbial raincloud.

My two cents on this topic (as if anyone asked ) is that unless one is shooting for Zandronum compatibility (which Lithium isn't), it's best to just go for it and adopt ZScript all the way. Maintaining 2.8.1 compatibility really isn't worth much (lilith.pk3 aside).

Good to see the motivation is to use ZScript though! Migrating an older mod is a bit of a grind (I've done it twice now, heh), but it's hella worth it.


[EDIT] For discussion's sake, you can put a "load" directive in the GAMEINFO lump for the player pack .pk3 that will autoload base Lithium (do note that you'll need to specify a specific filename, though, so you'll want to keep versions in lockstep), meaning the player just has to -file the addon wad. That doesn't solve the base weapon inheritance problem, though, and I'm not sure there's any real way of getting around that without mad hackery.

[Marrub]

The only real way to achieve what you're looking for without jumping to the latest GZDooms is to fall back to the original idea and make the character pack a separate .pk3. Apologies for the being the proverbial raincloud.

Ah well, it can just be a simple pk3 that puts the proper MAPINFO stuff in. Thanks.

My two cents on this topic (as if anyone asked ) is that unless one is shooting for Zandronum compatibility (which Lithium isn't), it's best to just go for it and adopt ZScript all the way. Maintaining 2.8.1 compatibility really isn't worth much (lilith.pk3 aside).

There are a few reasons I prefer to maintain 2.8.1 compatibility. One is that there are bugs introduced after 2.8.1 that make it more difficult to test, so I test in 2.8.1. Another is that I hate how OpenAL sounds, so I prefer having the old FMOD system. It's really just small issues like that which pile up and make me only want to use 2.8.1, besides when I need to use newer versions. It's good to have a stable base to fall back to if something explodes.

Good to see the motivation is to use ZScript though! Migrating an older mod is a bit of a grind (I've done it twice now, heh), but it's hella worth it.

Amusingly, the mod was originally written in early ZScript VM DECORATE. And then everything exploded, and I rewrote it in 2.8.1 DECORATE. Later, after ZScript was finished, I ported it, and then threw that port away because everything exploded.
So I've been quite reluctant (and probably won't ever) port all of the code. But I'm not afraid to add new (non-core-gameplay) features using it.

[Marrub]

I have created an awful solution that works exactly as I wanted.
Since MAPINFO doesn't care if a playerclass isn't defined, I just shove all the new class names in there.
Then I duplicate the PlayerPawn base in ZScript, which overrides the DECORATE one.
So, it only exists in ZScript, and it's always added when it can be. Yay!

[Arctangent]

I ... can't help but feel that that solution is just going to end in tears later down the line when an undesirable aspect of defining an actor in both Decorate and ZScript pops up and that results in a boot-up error.

[Marrub]

The actor is pretty simple, and I test in both versions, so it shouldn't cause any issues. I haven't actually had to add anything to the actor in months.