Special Behaviors

Moderator: GZDoom Developers

User avatar
Sphagne
Posts: 513
Joined: Wed Jul 16, 2003 3:36 am

Special Behaviors

Post by Sphagne »

There was a suggestion about changing the map formats, and I thought if we are about to change the map formats why not make some new additions, like having a special for each of the actor’s “States”, and also each special could have a second mode of execution, i.e. “Target Mode”.

Here is a list of possible specials:

Spawn special, See special, Melee special, Missile special, Pain special, Death special and Use special.

Note: each special can have a check box beside it that would force it to be activated in “Target Mode”, in which the activator of the special would be the target of the actor, not the actor itself.

1-Spawn Special: It is executed immediately after the level is loaded, and the activator is the actor, OK, I know we can give the actor a “TID” and execute an enter script, but it would be a little bit cleaner if we could directly define a spawn special for each actor. There is no target mode for this special.

2-See Special: It is executed right after the actor acquires a target and before it jumps to “See” state. In the target mode, the activator would be the target. This is a very useful way to force the actor act in a special way as it spots the enemy.

3-Melee Special: It is executed right before jumping into the “Melee” attack state. In the target mode, the activator would be the target. Useful for special melee attacks.

4-Missile Special: It is executed right before jumping into the “Missile” attack state. In the target mode, the activator would be the target. Complicated attacks like Archvile.

5-Pain Special: It is executed right before jumping into the “Pain” state. In the target mode, the activator would be the pain inflictor. For instance, we can check the actor’s life and when too low, it would call for help.

6-Death Special: It is the current available special. In the target mode, the activator would be the killer. The normal mode is used in current levels, but “Target Mode” would have new possibilities. It is also used for pickups.

7-Use Special: It is executed right before jumping into the “Use” state. In the target mode, the activator would be the user. If we define this special for any actor, it would automatically become a “usable” actor, i.e. if we stand in front of it and press the “Use” key then it’s use special would be executed.

-----------------------------------

I think that it would not be so hard to implement, and here is a suggestion about changing the format of Things definition in the levels:

If we want to change the “Things Definition” format entirely into a TAG based format like PNGs then there is no problem here and we can have several different “TAGs” that would define different specials for each actor state, and include any of them when used.

But if we want to keep the current structure for the things definition, then we have to change the content a bit, so let’s look at the data structure of things in the ZDoom/Hexen format:

2: TID
2: X
2: Y
2: Z
2: Angle
2: Type
...

And the rest is one special definition in 6 bytes. Can the rest of it be changed into this?

2: Special-table index
4: reserved

If the “special-table index” value is “0” then the Thing has no specials attached to it, but if is greater than “0” then it would be the index of the Thing’s special-table in the special-table array defined in the level’s “SPECIALS” lump.

The other four bytes could be reserved for future enhancements.

We could have an additional “SPECIALS” lump in each level, which can be an array of special-tables that can have a structure like this:

2: Reserved...
2: Target mode bit-array
6: Spawn special
6: See special
6: Melee special
6: Missile special
6: Pain special
6: Death special (Default) (also used for pickup)
6: Use special
18: Reserved, for later special additions

64 bytes total for each special table.

-----------------------------------

If a level has a SPECIALS lump, then ZDoom and editors would know that it has an extended special table for it’s things, and look at the Things data structure in the new way.

The “Target Mode” bit-array has a corresponding bit for each defined special of the table, so first bit is for the first special and the second bit is for the next special, and so on...

Therefore, each special has an additional definition bit, which would suggest that the special should be called in target mode.

That means the activator of the special is not the actor itself, but the target actor, which has different meaning for each special.

If we can have these different specials for the different states of our actors, then we can specialize the behavior of each individual actor that we place in our levels, and program their state specials to our liking.

Surely, the level designer is responsible to use these specials wisely and do not overdo their usage so that the levels would not become too complicated and slow.

-----------------------------------

If we have come this far then we can have some more fun, I know it is a bit far fetched, but may be interesting. :wink:

We can have several misc. states for our actors that could be called from within their “DECORATE” definitions and before their call; their defined Special could be executed as well, like:

In the chase or pain state we can check the actor’s health and if it goes lower than a quarter, then we can jump to a “MISC1” state, and do some desperate animation for the actor.

Or we can check the actor’s distance from its target and if it goes beyond a value, we can call its “MISC2” state and so on...

Any these misc. states can have a special of its own that would be executed before jumping to that state (if the special is defined, I mean).

Thus, we can program the “MISC1” special to call for some help for the desperate actor, or we can program its “MISC2” special to jump to another place nearer to the target, for instance, and so on...

In addition, if these misc. states could be called via ACS then we can have additional animation sets for our actors that could be used by ACS, like talking animation for our actors, or rotating valves and so on...

The ACS function can be something like this:

Thing_JumpToState( StateNo, Jump_Offset );

StateNo can be like these:

STATE_SPAWN
STATE_SEE
...
STATE_MISC1
STATE_MISC2
...

Jump offset is used when we do not want to jump into the beginning of the state definitions but a little after that.

Well I had asked these before, but it is more refined than before, and I think that these features can become useful tools for the future level (and actor) designers, so please think about the possibilities.
User avatar
Risen
Posts: 5263
Joined: Thu Jan 08, 2004 1:02 pm
Location: N44°30' W073°05'

Post by Risen »

Haven't you requested all this stuff before?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48543
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Several times. Obviously nobody cares. Randy apparently doesn't and I don't have the time to think about stuff only one person needs. This all is highly specialized stuff that has little use at most for the vast majority of projects.

I repeat myself again: If you need all that stuff then find a programmer who can do it for you. You can then submit it here.

Anyway, since some of this requires a new map format and so far all discussions about that have died quicker than they came I don't see it happening unless someone else takes the time to draft such a format and post it here for discussion.
User avatar
Sphagne
Posts: 513
Joined: Wed Jul 16, 2003 3:36 am

Post by Sphagne »

You think these are stuff that only one person needs? You think these are useless features for other persons? Cool, just Cool!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48543
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

I don't think that these are important enough compared to other stuff that is being done.
I repeat myself again: If you need all that stuff then find a programmer who can do it for you. You can then submit it here.
And here's your solution. Maybe you have more success if you ask someone to do it for you instead of constantly requesting some highly special features. Most of what you need is simply beyond Doom's scope, useful or not.
User avatar
Sphagne
Posts: 513
Joined: Wed Jul 16, 2003 3:36 am

Post by Sphagne »

Thanks god Randy does not share your view of things, or we would not have ZDoom at all.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48543
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Get real, man!

When I look at your feature suggestions they can be mostly categorized as highly specialized with limited use but excessive implementation requirements. And this one is the same. It requires a new map format! Problem: Currently there is no new map format! But instead of working towards it you again flood the forum with new feature requests before the necessary work hasn't even started! And please don't argue that you have to do it now to get it into the new format because any new format should be flexible enough to add stuff like this later. So before suggesting anything that requires a new map format you should concentrate in pushing to get that map format first. The way you do it you will get nothing at all.

But the more important question is: How often do you need this stuff? Once per map, 10 times per project or maybe 20? I doubt it makes sense to use it with more monsters at the same time unless you intend to do something that is so completely different that it really goes beyond the scope of the engine. If you need a fully scriptable engine you have to use one that is designed for it. But let's assume you have 20 or 25 monsters that require to call a script or special action to perform in a certain situation. For that you can easily use DECORATE directly to handle it, even if it is somewhat more to type.

The only thing here that sounds useful is the Thing_JumptoState. But again you make the mistake and bury it among a lot of other stuff that will put most readers off before they reach that part.
User avatar
Sphagne
Posts: 513
Joined: Wed Jul 16, 2003 3:36 am

Post by Sphagne »

Let's bet, with high stakes, if this feature is implemented, and also your intermission suggestion, that this would be used a lot more often that the intermission feature, (in the long time I mean).

All the features that Randy has implemented in ZDoom are used by a portion of the people that use ZDoom.

For instance ACS, this was only used by a very few percent of map designers, to an acceptable level of usage, but recently there are more and more people using this feature.

Your DECORATE features were not be used much, but now they are being more and more popular.

Terrain lump, New Fonts, Fake water teleportations, Transfer lights, and lots and lots of ZDoom features are used only by some select map designers, but they are available to be used.

If Randy wanted to be like you, ZDoom would be a Windows port of original Doom, with no additional new features.

And these new features would not be used a lot at first, but they would be more, in near future, and a lot more than the intermission screens, or lots of those other feature suggestions, in this forum.

Have you really read the first post in this thread? Can you understand the extend of its usablity? I can post lots and lots of scenarios, that could only be made after implementing these features, general scenarios that can help any one.

And I am sure that these are not *that* hard to implement, yiou can look at my implementation suggestion for an example.

I think that you can not look at my suggestions with a fair and unprejudiced look.

Thing_JumptoState is a good suggestion, but it can be more useful if combined with the other suggestions, like additional misc, states and the rest.

So please let other people declair their opinions in feature suggestion forums and do not think it is your domain of power to rule, and I am sure Randy can think and decide about these matters without your help.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48543
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Sphagne wrote:Let's bet, with high stakes, if this feature is implemented, and also your intermission suggestion, that this would be used a lot more often that the intermission feature, (in the long time I mean).
The intermission stuff is necessary to fix bugs that can't be fixed with all the special cases coded in there. Within 2 hours I was able to crash the intermission screen 6 times due to various minor oversights.
All the features that Randy has implemented in ZDoom are used by a portion of the people that use ZDoom.
And that's exactly the point where a port author has to decide what's important. Anyway, it is not that your suggestions can't be done by a mapper right now. The only problem with state specific actions is that right now it is not that flexible. But it can be done! Has anybody used it so far? At least I haven't noticed.
For instance ACS, this was only used by a very few percent of map designers, to an acceptable level of usage, but recently there are more and more people using this feature.
Strange. I know only a handful of ZDoom specifc maps that don't use ACS. It is probably the most used feature of ZDoom - and the one that draws most mappers here.
Your DECORATE features were not be used much, but now they are being more and more popular.
So tell me why the first major thing that was done after 2.0.63a was released (the first version with stable DECORATE support) was a huge monster pack that squeezed everything out of the format that was possible? It seems to me that custom monsters are the most used new feature ever. All the latest big ZDoom projects used this to some degree.
Terrain lump, New Fonts, Fake water teleportations, Transfer lights, and lots and lots of ZDoom features are used only by some select map designers, but they are available to be used.
One word: Documentation! Before the Wiki was started nobody knew how to use it. Hence nobody used it.
If Randy wanted to be like you, ZDoom would be a Windows port of original Doom, with no additional new features.
:laff:

Why should I bother with something dull like that? But unlike some people I am not interested in reinventing the entire game. Enhancement yes but why turn it into something that is no longer Doom?
And these new features would not be used a lot at first, but they would be more, in near future, and a lot more than the intermission screens, or lots of those other feature suggestions, in this forum.
I doubt that very much. Doom is an action game first and foremost where you run around and kill monsters. Only in the rarest of circumstances you need more control over a monster in such a game, namely for some few boss enemies. And for those class specific coding is normally more than enough because with carefully placed ACS_Execute's and tid selection you can do a lot more than you think!
Have you really read the first post in this thread? Can you understand the extend of its usablity? I can post lots and lots of scenarios, that could only be made after implementing these features, general scenarios that can help any one.
The state specific actions can already be done in a limited fashion that would be sufficient for 90% of all projects.

Thing_JumpToState might be useful but don't be surprised if it can't really be used for monsters because they tend to jump elsewhere in their generic code pointers. In the end it comes down to the old question again: How much does the AI system have to be changed to make something work?
And I am sure that these are not *that* hard to implement, yiou can look at my implementation suggestion for an example.
I never said that. But first the new map format has to be done. I'd say let's talk again in a year or two when that may be done.

I think that you can not look at my suggestions with a fair and unprejudiced look.
Guess why! This is not the first time you posted an overlong piece of text that is hard to follow and contains highly specialized feature requests.
So please let other people declair their opinions in feature suggestion forums and do not think it is your domain of power to rule, and I am sure Randy can think and decide about these matters without your help.
What other people? So far nobody showed the slightest hint of interest.
User avatar
wildweasel
Moderator Team Lead
Posts: 21590
Joined: Tue Jul 15, 2003 7:33 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Win10 22H2, Win11 22H2, macOS 11.7
Graphics Processor: nVidia with Vulkan support

Post by wildweasel »

Graf Zahl wrote:Why should I bother with something dull like that? But unlike some people I am not interested in reinventing the entire game. Enhancement yes but why turn it into something that is no longer Doom?
Pardon my intrusion on this war o' quote boxes, but I must ask the one question that has stuck in my mind.

At what point does Doom become something that is no longer Doom? It will always have the fast-paced action, the hordes of cannon-fodder monsters, the weapons, and the abstract level designs. And so long as at least one of those remains, Doom shall remain Doom. And to be quite honest with you, I am utterly sick of seeing somebody innocently request a feature, only to have it denied because "it's not Doom."

So tell me - how far must one go to turn Doom into not-Doom?
User avatar
Belial
Posts: 1616
Joined: Wed Feb 09, 2005 3:09 pm

Post by Belial »

Heh, for me using mouselook is enough to make Doom not-Doomish at all.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48543
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

wildweasel wrote:
Graf Zahl wrote:Why should I bother with something dull like that? But unlike some people I am not interested in reinventing the entire game. Enhancement yes but why turn it into something that is no longer Doom?
Pardon my intrusion on this war o' quote boxes, but I must ask the one question that has stuck in my mind.

At what point does Doom become something that is no longer Doom? It will always have the fast-paced action, the hordes of cannon-fodder monsters, the weapons, and the abstract level designs. And so long as at least one of those remains, Doom shall remain Doom.

So tell me - how far must one go to turn Doom into not-Doom?
At the point where the change necessitates a fundamental rewrite of how the game works.
And to be quite honest with you, I am utterly sick of seeing somebody innocently request a feature, only to have it denied because "it's not Doom."
More often it will be denied because it requires too much work. That's not the case here (it will most likely be forgotten because I don't expect that the new level format required for this will ever go beyond the planning stage - but this is something where I'd like to be proven wrong.)
User avatar
wildweasel
Moderator Team Lead
Posts: 21590
Joined: Tue Jul 15, 2003 7:33 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Win10 22H2, Win11 22H2, macOS 11.7
Graphics Processor: nVidia with Vulkan support

Post by wildweasel »

Thank you, your answers have proven most informative.
User avatar
Sphagne
Posts: 513
Joined: Wed Jul 16, 2003 3:36 am

Post by Sphagne »

Nobody decides to argue with you openly and make you an enemy, look at me for an example.

As for your step by step answers to my statements, please stand aside and read them with a neutral eye, (if you can do so) and see if they are logical (and not one sided).

Can you understand me at all?

Thanx wildweasel, for your covert help in my cause. :smile:
User avatar
David Ferstat
Posts: 1113
Joined: Wed Jul 16, 2003 8:53 am
Location: Perth, Western Australia

Post by David Ferstat »

The problem that I foresee with the majority of your suggestions, Sphagne, is that they're going to require an awful lot of work to implement, and (agreeing with Graf Zahl) I have trouble seeing how they're really going to be useful enough to justify this labour.

Now, don't get me wrong. I'm not a programmer, although I've done some programming in C. I don't know how difficult and laborious this work will be. But I've got an idea, and it doesn't look pretty.

You have to remember that, for every suggestion that Randy sees, he has to perform a cost/benefit analysis. He has to decide firstly, how much work is involved in implementing it, and secondly, what the expected benefits will be.

Now, while we don't hear from Randy anywhere near as often as we'd like (we like to tell ourselves that he's busy coding the next version) we do have Graf Zahl, who, like Randy, is a programmer, is familiar with the Zdoom code (which gives him a good idea how difficult a feature may be to implement) and is also familiar with just how Zdoom gets used.

If Graf Zahl says that something will be difficult to implement then I'm inclined to agree with him. For myself, I also fail to see how some of these suggestions will be useful to more than a coule of people.

Now, as we should all here know by now, Zdoom development has run up against some brick walls. We can't add any new line types, as the current map format has run out of space to store them. Actors are fast running out (if they haven't run out already) of data that can be stored with each one.

Until Randy finishes his current project, which is converting Zdoom from fixed point to floating point numbers, and adding the vector math class (things I barely comprehend) and then, hopefully, implements a new map format, then all your feature requests are, at best premature. Right now, there is no capacity to implement them.

Unfortunately, every time you request them we have to go to the trouble of telling you, and every other person who reads the thread, just why these seemingly excellent suggestions are not going to be enacted.

Return to “Closed Feature Suggestions [GZDoom]”