ZDoom

Nanami wrote:GameArena is an all right coder, but like Carnevil he has a lot of ideas that require changing the way Doom works, which I do NOT want to see in ZDoom.

Graf seems to be okay with just submitting things to Randy occasionally, and I think that's the best method.

I'll let Randy decide. I'm not interested either in radically altering the way Doom works but I do have some ideas for improvements for mappers. Much of this would require extensive generalization throughout the code.
(The one thing I'd like to see most is to be able to place Heretic/Hexen stuff directly in a Doom map without the need for scripts and SpawnSpot.)

Some of the more elabotate stuff in my actor definition code can't be easily ported to ZDoom because it interferes with ZDoom's strict C++-class-based model. In an environment where an actor is just a collection of data it normally meant if I found some hard coded reference that it was sufficient to replace it with a new flag. In ZDoom it's not that easy in many cases. For example, I can't get pickup items to work because it would require some (unfortunately not so minor) adjustments elsewhere which I am not willing to do.

GameArena is an all right coder, but like Carnevil he has a lot of ideas that require changing the way Doom works, which I do NOT want to see in ZDoom.

Graf seems to be okay with just submitting things to Randy occasionally, and I think that's the best method.

Lexus Alyus wrote:Oh, by the way LADooM would be based on the final Zdoom 2.1.0 when it's done and the most stable version of Jdoom at the time... then I'll add loads of my own stuff... but that's just a dream as I can't program... yet [/size]

Good luck combining those sources. It would certainly be interesting but these source ports are so far apart that it'll be a LOT of work...

Mmmmm... this is all interesting stuff and it's just arose that maybe Zdoom should be more than just Randy? I'ts all obveously up to Randy, but Graf Zhal and GameArena seem to know a lot of useful things to help Randy along the way, plus if there are more heads working on this then:

1) Things will progress faster,
2) Randy will have a little less to worry about
3) Maybe those two could become moderators?
4) Zdoom will really start tro take off .

At this stage I'm beginning to wish that I could program, then i'd probably be more of an help rather than and inderhance .

Altogether though, this is really exciting stuff... plus, it would be really nice when this is final so people wiull be playing the later Zdoom on DC rather than 1.22...

Disclaimer: Graf and Arena are just the first two that have done something to Zdoom... as far as I know. Maybe there could be more (or less)... but in the end it is up to Randy as this is His project... On a side note I think I'm gonna learn to program... know any good tutorial sites? That would be most apreciared... I'd love to work on LADooM ... r would RBJDooM sound better? Oh, by the way LADooM would be based on the final Zdoom 2.1.0 when it's done and the most stable version of Jdoom at the time... then I'll add loads of my own stuff... but that's just a dream as I can't program... yet

Killo Zapit wrote:I guess I might as well ask this now as this thing is getting started. I don't really care that much, but I have always wondered if something like this ever got off the ground if it would allow defining translations on the new actors, just so people wouldn't need to make whole new sprites for some new kind of imp or something. Just something to think about later I guess. Probably not worth it actually.

It's more an issue of altering how the translations are stored internally. The current implementation of translations doesn't support the addition of arbitrary translations to the internal table. So for the time being you have to stick with ACS to do this. I don't know if it's worth the effort to reprogram this stuff for a very minor convenience issue because with very little additional work during editing you can already achieve the desired effect.

I'm..... excited

Just get it out the door, worry about improvements/features later

I guess I might as well ask this now as this thing is getting started. I don't really care that much, but I have always wondered if something like this ever got off the ground if it would allow defining translations on the new actors, just so people wouldn't need to make whole new sprites for some new kind of imp or something. Just something to think about later I guess. Probably not worth it actually.

I'm almost done. A little testing and I can send it to Randy. I hope he releases a new beta rather quickly so that you guys can mess around with it...

Cool beans!!! Keep up the good work.

As it is this format currently cannot handle pickups which was part of the original implementation. Pickups are handled in a completely different way in ZDoom which requires the code to determine whether an actor is a pickup at a point much earlier than I had done. The main problem is that the amount of work required to make the (rather limited) pickup support I had work with ZDoom is a little high compared to the benefits. With Decorate pickups and ACS you can achieve significantly more than with what I ever had. I somehow doubt there is much need to create new kinds of medikits, armors, keys and standard Doom powerups because that's all my original stuff could do.

This does neither affect the regular pickups (otherwise it'd be pointless) nor normal DECORATE pickups. The old DECORATE stuff hasn't been changed a bit (with the single exception that 'Actor' is now a keyword and can no longer be used as an actor's class name )

Ah O.K. Also could you elaborate on the lose of pick-up support. I was a little unsure of what you meant? Does it effect normal Doom pick-ups? Or just those that were defined in DECORATE? Wether it be normal, or DECORATE will it be able to be added back in? That last question I'm especially concerned about, cuz I'm not sure if I want to give up new pick-up items in order to get new monsters.

Look further above. Theoreticall it is possible but weapon handling requires some extensive rewrite of the current weapon code. This requires adding one tiny 'if' at one place and the rest is completely standalone.

BTW, I'm currently writing the docs for this. Currently I'm at 15270 bytes and it isn't even finished...

Is there any way that this could be expanded to create player weapons. Ones that not only can use monster code pointers to shoot their projectiles, but can shoot newly defined projectiles. Or even any projectile for that matter like the ovum's, and the chicken morpher and such.

Sounds awesome. No pickup support doesn't bother me because if I need something, I can still just do a fake pickup the way you would right now, right?

Ok, here's a short summary of what I'm doing:

1. Almost all flags are accessible. I disabled a few which require special coding or don't make sense (internal flags, pickups)
2. All code pointers accessible through Dehacked are accessible. I also added a small selection from Heretic and Hexen (but not much. Most are simply too hard coded for any generic use.) All code pointers are accessible in all games. Only the required sprites have to be provided.
3. The most important thing: Generic attack functions! (That was the major reason I started messing around with this stuff.) You can specify any projectile you like for use in a monster's attack! (but limited to one type per monster!) This alone makes most of Hexen's/Heretic's usable code pointers obsolete. These functions can shoot all original projectiles (including those with special properties, like the chicken morpher etc, of course you have to provide the sprites for them) and anything that's newly defined.
4. Of course I'll write some documentation before this is released. It would be a shame if it wasn't used to its potential because nobody knows how to use it, right?

And the one bad thing:
5. Unfortunately I had to remove pickup support. ZDoom handles pickups in a completely different way than PrBoom. With PrBoom I just could give an object some additional properties which were interpreted by the pickup code. ZDoom uses C++ subclasses for this.
Fortunately with ZDoom's scripting abilities this isn't such a bad thing because you can do so much more with ACS than ever was possible with what I had.