ZDoom

by **BouncyTEM** » Thu Jul 13, 2006 11:46 am

woot!
yay!

Great.

by **Graf Zahl** » Thu Jul 13, 2006 4:33 am

And now the code is in. It took a little longer because while checking out the menus I discovered some bugs in there that had to be fixed. I hope now it's working as expected.

by **Cutmanmike** » Thu Jul 13, 2006 3:03 am

Graf Zahl wrote:I merged all of Grubber's code with the most recent SVN version. So defining new players to modify the basic properties, redefine the starting inventory or to add new death states should work now.

One thing, however, does not work properly yet: redefining the player's attack states. The reason for this is that the code which uses them is incredibly dirty and needs serious cleaning up before there can even be a thought of making this customizable. Currently the code jumps wildly between the MissileState and MissileState+1 without decent control and worse, different implementations for different players. So keep that in mind when defining new players for now.

I'll take care of this issue as soon as I find the time but I want to commit the code to the SVN repository now.

Awesome. Can't wait for this now

by **Graf Zahl** » Thu Jul 13, 2006 2:28 am

I merged all of Grubber's code with the most recent SVN version. So defining new players to modify the basic properties, redefine the starting inventory or to add new death states should work now.

One thing, however, does not work properly yet: redefining the player's attack states. The reason for this is that the code which uses them is incredibly dirty and needs serious cleaning up before there can even be a thought of making this customizable. Currently the code jumps wildly between the MissileState and MissileState+1 without decent control and worse, different implementations for different players. So keep that in mind when defining new players for now.

I'll take care of this issue as soon as I find the time but I want to commit the code to the SVN repository now.

by **Ryan Cordell** » Wed Jul 12, 2006 5:53 am

We can only wait and see.

by **madnessJack** » Wed Jul 12, 2006 5:45 am

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.

by **Ryan Cordell** » Wed Jul 12, 2006 5:43 am

Graf Zahl wrote: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.

by **Graf Zahl** » Wed Jul 12, 2006 5:39 am

Dehacked support is more important than your opinion.

by **madnessJack** » Wed Jul 12, 2006 5:22 am

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...'

by **Graf Zahl** » Wed Jul 12, 2006 5:11 am

madnessJack wrote: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...

by **madnessJack** » Wed Jul 12, 2006 4:56 am

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.

by **Enjay** » Wed Jul 12, 2006 4:50 am

madnessJack wrote: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.

by **madnessJack** » Wed Jul 12, 2006 4:43 am

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.

by **Graf Zahl** » Wed Jul 12, 2006 4:02 am

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.

by **madnessJack** » Wed Jul 12, 2006 2:48 am

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

ZDoom

Custom player/hexen classes in decorate

Post a reply

Expand view Topic review: Custom player/hexen classes in decorate