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 actors 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 its 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 lets 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 Things special-table in the special-table array defined in the levels 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 its 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.
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 actors 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 actors 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.
