A few ideas for source port coders

[Vegeta]

Do you think that'd be cool/useful to have flags (selectable from the level editor) that set the monster/items characteristics as:
-fast (the monster behave as with the -fast parameter but the other monsters act as normal)
-respawn
-nightmare skill
-zombie (ressurect in the Archvile way after certain seconds)
-altdeath (for pickups)

[cycloid]

i like this idea, my only thought is that the player would have no way of visually distinguishing between monsters with each flag set. = bad for gameplay. It could be done via dehacked... but that would involve adding new monsters, sprites and frames just to get the behaviour

hmmm...

if the dehacked color flags were in there too then that might work: (the color green -> red/brown/grey)... so you could replace the imps with green imps and then have the brown flag set by default and still have 3 other imps (red,green and grey) to play with. green could be zombie

did any of that make sense?


i don't know what altdeath does, never used it and isnt nightmare essentially the same as -fast + -respawn? and so wouldnt zombie be the same as -respawn?

so i'd say

- fast
- respawn
- red / grey
- brown / grey

[myk]

cycloid said:
if the dehacked color flags were in there too then that might work: (the color green -> red/brown/grey)... so you could replace the imps with green imps and then have the brown flag set by default and still have 3 other imps (red,green and grey) to play with. green could be zombie

did any of that make sense?

No, it does not make sense; you need green monsters for that to work.

AltDeath is a DM mode where weapons disappear when you pick them up, but then the weapons and most items return (respawn) after a bit.

[Graf Zahl]

myk said:

No, it does not make sense; you need green monsters for that to work.

Didn't he say just that?
Anyway, who says that translations have to be limited to the player color range. ZDoom's translation feature can remap any color you want. It isn't that hard.

[kristus]

Vegeta said:

Do you think that'd be cool/useful to have flags (selectable from the level editor) that set the monster/items characteristics as:
-fast (the monster behave as with the -fast parameter but the other monsters act as normal)
-respawn
-nightmare skill
-zombie (ressurect in the Archvile way after certain seconds)
-altdeath (for pickups)

Most ports already allow you to do all that, but not with flags. Like Zdoom got decorate, and Eternity got EDF and so on.

It's not hard to make monster with those characteristics even in dehacked mode.

and a script can do the -altdeath thing.

[cycloid]

but to make a monster have different characteristics means setting up a whole bunch of dehacked definitions, now there is some clever work you can do sharing frames but only so much. if a select few of the dehacked flags could be set, in an editor on a per-monster basis then the mapper can concentrate on being creative more than working out the (very) complex, old and hacky deh/bex system.

as the flags only make the monsters harder to beat, it actually makes them backwards compatible too. e.g. play in winmbf and you get only standard imps but play in a things+ port and you get some fast imps, some stealth imps. etc.

i think this is a valid discussion to have, alongside the (ongoing) 32bit map format discussion. It'd be relatively easy to create a new source port that added these options but we already have enough source ports IMO and i features can be added and supported cross-port then that can only be a good thing

[myk]

cycloid said:
and i features can be added and supported cross-port then that can only be a good thing

That'd just the common denominator imposing things on coders. The 32 bit map format discussion is more fundamental and sprung from the development of the engines by the coders. And why bother if there are engines that can do those things already (Eternity and ZDoom, for instance) quite fine? As a designer, just use those; did the coders waste their time because these features aren't "cross-port" stuff easily understood by a 5 year old?

Engines have generic customizable systems just for this kind of stuff, otherwise they would be a mess if coders hardcoded every specific feature designers requested on a whim out of incidental necessity:

"I'm too lazy to learn how to use this highly versatile feature; add some flags so that I can do what I just thought up very easily."

[DaniJ]

Thing flags present in a editor should be applicable to ALL (or at least the majority) of the various types of Thing. Otherwise there would be hundreds of flags that do absolutely nothing for the majority of Things (not to mention the added complication for ports if thing flags are type-specific).

For example:
What would the -fast flag do to a torch?
What would the -zombie flag do a an ammo clip?
What would the -altdeath flag do to a barrel?

The bottom line is that this sort of stuff is not common to all things therefore it makes more sense for the option to be set via a custom thing.

As mentioned, ALL of the massively enhanced ports have dedicated features for this. And we already have one "cross-port" standard in DEHACKED (at least mostly).

[Graf Zahl]

DaniJ said:

For example:
What would the -fast flag do to a torch?
What would the -zombie flag do a an ammo clip?
What would the -altdeath flag do to a barrel?

Nothing in each case.

The bottom line is that this sort of stuff is not common to all things therefore it makes more sense for the option to be set via a custom thing.

Theoretically yes, but since the entire behavior of monsters is defined by some code pointers it's not that simple. And it wouldn't work well with DEHACKED because Doom never made such a distinction. Such an approach would make sense if you wanted to create something new from scratch but here we have to work within predefined parameters that make the distinction much less obvious.

[DaniJ]

Exactly, that was the point I was making.

IMO there should be such a distinction made. The various caveats surrounding the original flags and code pointers should be minimised, not added to.

I see no problem as far as DEHACKED support goes with the original thing flags or the original code pointers (I understand that may be different in a port like ZDoom). It's just a question of organisation.

[Graf Zahl]

DaniJ said:

IMO there should be such a distinction made. The various caveats surrounding the original flags and code pointers should be minimised, not added to.

Easier said than done, especially when you have several flags that can interact but are exclusive to yet another set of flags that could be combined with something else.

ZDoom's new flags are a good example: Many are specific to projectiles (some even to projectiles with specific behavior) but there's no projectile class and you can easily change anything into a projectile if you wanted to so there's really no alternative to defining the flags in the base class even though a dedicated projectile class might be preferable. But if that was done several things that are possible right now (and are being used) could no longer be done.

I'd define it differently if I could start from scratch...

As for the code pointers, take one guess why most of the original weapon code pointers cannot be used in DECORATE. ;)

[rpeter]

How about: rent a coder? Or: do the coding yourself? If you crave for editing features not found in existing ports make a custom engine and distribute your wad with it. It has happened before (like Korax mod with DoomsDay, or Code Red with Quake2 engine).

[DaniJ]

As for the code pointers, take one guess why most of the original weapon code pointers cannot be used in DECORATE. ;)

"That" reason is THE reason I don't plan to go down that road with Thing definitions in DED ;)

Afterall, DECORATE is pretty much DED on steroids so I spent some time analyzing DECORATE and reached the conclusion that I'll change the direction Thing definitions are currently going in with DED, while I still can.

[Quasar]

Eternity does already allow monsters to respawn in any difficulty and regardless of the -respawn setting; this is called the ALWAYSRESPAWN flag.

I am now considering adding a flag that'll allow monsters to always be fast, as well as to apply the various AI enhancements added in BOOM and MBF by Lee Killough even when the player has those enhancements disabled for normal monsters (this was requested by Mordeth a long time ago and has been on the TODO list since then).

Of course, these features will be in 3.35.00 or later, not the upcoming 3.33.33 release, which is on the brink of being zipped up and shipped out.

[DaniJ]

...the upcoming 3.33.33 release, which is on the brink of being zipped up and shipped out.

Sweet. I was beginning to wonder when the next version was coming (so says a Doomsday developer /joke).

[cycloid]

reading back over, so (in a very broad sense)) -altdeath is the same for pickups as -respawn is for monsters... so any thing that can "die" can be set to respawn... might get interesting with barrels :-)

though i can't think of what -fast would do, presumably nothing as if they arent moving then they can't go, er, faster.


Eternity has been my favourite port for a few years now so glad to see these features being incorporated. i just think it's a shame that "boom" + "bex" is the base port standard and there seems to be no chance of a "next step". i posted musing about this in another thread: about slopes. ho hum.

[rpeter]

There was an initiative after Boom by TeamTNT (what was it's name? Gnome?) to create the next standard engine, but it died quietly. Source port coders wanted to compete, not cooperate.

[Quasar]

I don't know if compete is totally correct. While there is some friendly rivalry between certain source ports, they have, on the whole, done more cooperation. For example, Randy Heit was helpful when I added the zdoom particle system to Eternity :)

Also, some "de facto" standards have emerged from the work of particular authors, the best example being Doom Legacy's skin format.

[myk]

rpeter said:
Source port coders wanted to compete, not cooperate.

That is, being individuals, each wanted to follow their different visions, as opposed to mashing these into a abhorrent monstrosity (some engines kind of managed that anyway).

[rpeter]

I did't want to imply discontent with my above post, after all if there was only one omnipotent source port the actual release of the Doom source would lose it's importance.

[deathbringer]

Also, some "de facto" standards have emerged from the work of particular authors, the best example being Doom Legacy's skin format.

EDGE and Legacy share 3D floor linedef numbers too, also i saw a thing a while back that was a list of thing numbers for port creators to "claim", so that other ports with extra things wouldnt use those same thing numbers for different objects, dunno what happened to that though

[Graf Zahl]

deathbringer said:

EDGE and Legacy share 3D floor linedef numbers too,

Which is something every developer should do. When I add a mapping feature I know exists in another port I try to define the same interface. The less confusion the better. Unfortunately there are situations where this is not possible due to the different internal handling of certain things.

also i saw a thing a while back that was a list of thing numbers for port creators to "claim", so that other ports with extra things wouldnt use those same thing numbers for different objects, dunno what happened to that though

Practically nothing. Some ports in that list are long dead, others didn't add anything and yet others ignored it.

[Quasar]

deathbringer said:

EDGE and Legacy share 3D floor linedef numbers too, also i saw a thing a while back that was a list of thing numbers for port creators to "claim", so that other ports with extra things wouldnt use those same thing numbers for different objects, dunno what happened to that though

It was part of the JDS project, which would have been nice if it had gained some ground.

Eternity reserves all doomednums greater than 20000 for EDF or external utility usage. Other than that, I've been using the same numbers for objects that work the same (or reasonably the same) in Eternity as they do in zdoom :)