[Added] Custom player/hexen classes in decorate

[dennisj1]

Any chance of an update to ZDoom 2.1.1, instead of 99x?

[Necromage]

I am gonna bump this since its my thread.

I see in another thread, Grubber, (here) that you updated it 2.1.1 but you only posted the diff for it. Could you possibly compile it and release 2.1.1x since others, including me, cannot compile zdoom.

I was also wondering if any other goodies have been added (such as the much fabbled but sought after morpheplayer() function).

[Bouncy]

is there any way to make it so that if you have a hidden class it *DOESN'T* show up in the player settings menu? because all classes, whether selectable in the menu or not, show up in there.

And if you want to make hidden classes, well, Kinda hard when it's very open in the middle of the classes menu. same with vehicles.

[Necromage]

I went through all my earlier posts and here is the composite of everything that I noticed as bugs and things that should be changed and/or added:

First: PlayerPawn should work like other bass classes like customInventory and Weapon so that all you have to really do is add states. In other words: with its current implimentation if you inherit from PlayerPawn instead of something like DoomPlayer then the actor wont even be able to move.

Second: If you have all the classes except one are hidden then it will still ask you to select your class even though your only choice is that class and random, which, can only select that class.

Third: the following flags should be supported for class: float, invisible (it actually needs some work as it does work just not well), rockettrail would be nice, and notarget are the flags that I know that don't work that would be nice if they did.

Fourth: If you set up a actor class to have more health then 100 and his health drops below 100 and then picks up a health pack. His health will still not go above 100. I realize this is because the health is set by the item rather then the player so I am not sure how to go about and fix this. However, since you can set the player's starting health it might not be a bad idea to be able to set its maxhealth as well.

Lastly: some functionality to yet be implimented. For the morph player function I would like it to look like this: int MorphPlayer(int PlayerNumber, int PlayerClass, bool KeepInventory). The return value is the player class the player was before being morphed. After that I think the only other things that should be added is a way to set up weapons that only one class can pick up it up (maybe other items as well and not just weapons), a way to set the difficulty messages for each class (like being able to set the text for "I am too young to die"), and a way to set the item's flags so that they appear only when that class is present in the game.

I am sure others can come up with more but thats all I have right now.

[madnessJack]

I would rather see maxhealth and initialhealth etc defined in a class definition rather than a health item.

[Graf Zahl]

Initial health is a player property. For max health it is problematic because different items have different maximums. Something can be done about the default items that max out at (100 + stamina). Adjusting these to use a player property instead is certainly doable and I was already thinking about it because it helps me to get rid of some Dehacked support code - which is always a good thing.

[madnessJack]

Is it worth sticking to dehacked compatibility? Surley if someone wan't to play with an old level they can just use an old version (1.22), and from what I gather, it would make your life easier.

[Enjay]

Is it worth sticking to dehacked compatibility?

I'd say yes because a lot of mods in the archive use it. So, it's not just the occasional mod that you might DL and want to play, it's a significant number. People would complain if that number of mods suddenly became unsupported. Also, there are still a few minor, but useful, things DEHACKED can do that are not possible by other means. Although the list gets shorter all the time.

However, it should just be a static thing now. There is no need to add features to DEHACKED (as there was in the past) seeing as how almost everything can be done by better means.

[madnessJack]

Maybe then a way in the future to convert the lump into a less dying form like DECORATE or even the holy DoomScript form.

EDIT: IE take the dehacked lump and parse a decorate lump or doomscript thing out of it - so that it has the same effect.

[Graf Zahl]

Is it worth sticking to dehacked compatibility? Surley if someone wan't to play with an old level they can just use an old version (1.22), and from what I gather, it would make your life easier.

Half the community would massacre you if you did...

[madnessJack]

I have to say I pretty willing to sacrifice myself for the amount of times I see 'this has to be here for dehacked compatibility' or 'this could be done more efficiantly if...'

[Graf Zahl]

Dehacked support is more important than your opinion.

[Ryan Cordell]

Dehacked support is more important than your opinion.

Much more important. Quite a lot of people would be dissapointed if Dehacked wouldn't even work where it was used the most.

[madnessJack]

Granted.

Most of my own levels used Dehacked I'm just saying that they're not going to any more. I appreciate the compatibility and stuff, I just wandered if there is a possible compromise. -so the dehacked stuff can be redone by zdoom in another way.

[Ryan Cordell]

We can only wait and see.