Custom Labels in DECORATE

[DoomRater]

I can understand the need for jump offsets, but it is getting very frustrating to remember to change every offset when I add a frame in and then suddenly wonder why my code doesn't work anymore. If we had custom labels to go to this would not be nearly as much of a problem. As it is I feel like I'm working with Assembly Code!

[Graf Zahl]

Next version. Randy has already coded it.

[DoomRater]

Like a savior who already knows our needs....

[Macil]

Like a savior who already knows our needs....

Does the next version of zdoom have.... well... you mean like a savior who knows our needs before we know we need?... well... come on... I know there's something zdoom will have...

How will it work? Anything like in BASIC and bat files with

Code: Select all

:imalabel

and

Code: Select all

Goto :imalabel

?

[TheDarkArchon]

The colon would be after the name to fit the existing trend E.G

Code: Select all

imalabel:
     PISG A 2
     Goto death 
death:
    TROO L 4
    Goto see
see:
    POSS A 4
    Goto burn
burn:
   BURN A 7
   Goto impse
impse:
   IMPS AB 4
   Goto impse

[Phobus]

Ooohhh. That'd be great for stuff like reloading states and stuff, though you'd need to have proper activators and the like to get between them all.

[Macil]

The colon would be after the name to fit the existing trend E.G

Code: Select all

imalabel:
     PISG A 2
     Goto death 
death:
    TROO L 4
    Goto see
see:
    POSS A 4
    Goto burn
burn:
   BURN A 7
   Goto impse
impse:
   IMPS AB 4
   Goto impse

Eh, its been a LLLLLOOOONNNGGG time since I've looked at Decorate. I remember now discussing somewhere else about that.

[MartinHowe]

PLEASE PLEASE PLEASE let there be a "just ran out of enemies to fight" state or "just about to enter the chase state but not there yet" state built-in to the next version. You have no idea how difficult this is to intercept and it can't be done "properly" so it doesn't always work. A "TID of whoever is attacking me" property that can be gotten from ACS is also needed! (Unless Randy intends to implement the filter scripting hacks that I did, or something like it )

[Graf Zahl]

"just about to enter the chase state but not there yet"

That's the see state. If you need something to do before the loop don't loop all the states.

[MartinHowe]

"just about to enter the chase state but not there yet"

That's the see state. If you need something to do before the loop don't loop all the states.

At DECORATE level the SEE state is the CHASE state; just two different names for the same thing. Unless the changes inside 2010 are more extensive than I thought

The problem with "don't loop all the states" is that in some case, it is the engine itself that is "looping all the states" - sort-of. The SEE/CHASE state is entered automatically during the game by the engine itself under some circumstances and there is no option to tell it "when entering SEE/CHASE, actually enter SEE/CHASE+1" under some circumstances and SEE/CHASE under other circumstances.

After all, this isn't a "dreamer's wish-list" comment, I have wrestled with this problem for ages; look at the zdoomfx hack - I did a lot of work to find out where unexposed engine behaviour exists in this matter.

In particular it is not currently possible to determine when a monster is entering the SEE (CHASE) state (or one of them) because it has found somebody to attack, or when it is reentering (under engine control, not DECORATE control) it because it has no enemies remaining. Wherever you start in those states, even if you call a script, there is no function inside ACS to tell me whether the actor is under attack or just looking for trouble, nor any way to jump to a different state from within ACS. Even this depends on being able to use state jumps to labels, which isn't available until 2010+.

Getting a friendly monster to reenter the SPAWN/IDLE state when it runs out of enemies or a normal monster to return to the SEE/CHASE state and wander is not currently possible, as far as I can tell - why do you think I put the STANDIDLE and WANDER flags in my 96x hack

Of course, I might have missed something obvious (sod's law at work), so if anybody knows a guaranteed-reliable way to intercept "run out of enemies" and jump to an arbitrary state by name (or name+offset), including when the engine puts the monster in that state other than under control of DECORATE, then please tell me what it is!!

[MartinHowe]

No comments after a few days. Well, OK, now that I've had time to think about it a bit more, here's a suggestion for both type and TID based attack filtering and no-enemies interception, without going the whole hog and adding filterscripts and suchlike:

(1)
Define a new DECORATE-level state "Bored".
If declared in DECORATE for a particular actor, this state would be entered by the actor whenever it has just run out of enemies (but not when it has never had any in the first place, that's what A_Look() is for). If not so declared, the actor would do whatever it would currently (.96) does.

(2)
Define a new DECORATE-level state "Angry".
If declared in DECORATE for a particular actor, this state would be entered by the actor whenever it is about to switch to a target because of just being hit by THAT target (or a projectile that it fired). If not so declared, the actor would do whatever it would currently (.96) does.

(3)
Define a new DECORATE-level state "Vindictive".
If declared in DECORATE for a particular actor, this state would be entered by the actor whenever it is about to switch to a target because of that target being a friend of the enemy (and not because the target is an enemy itself). If not so declared, the actor would do whatever it would currently (.96) does.

(4)
Define a new DECORATE-level state "Targeting"".
If declared in DECORATE for a particular actor, this state would be entered by the actor whenever it is about to switch to a target because of having just found it for the first time after being idle (or after just having defeated its previous enemy). This would leave the SEE state for what it actually is: CHASING an actor once the decision to attack it has actually been taken - the "Targeting" state would allow the decision to attack a target from scratch to be intercepted and, if necessary, overridden). If not so declared, the actor would do whatever it would currently (.96) does

(5)
Allow state jumps to states by label (already in 2.0.10)

(6)
Add an ACS function SetActorState(statelabel). The state would take effect when the script exited.

(7)
Add the following ACS functions: GetCurrentTargetTID(void), GetProspectiveTargetTID(void),GetCurrentTargetType(void), GetProspectiveTargetType(void),GetCurrentTargetSpawnID(void), GetProspectiveTargetSpawnID(void). These would return the TID, DoomEdNum and T_XXXX of the current and prospective targets. Outside the Angry or Vindictive states, the "prospective" functions would return -1.

(8)
Add a function to ACS: RevertCurrentTarget(statelabel). This would cause the actor to reenter the SEE state (or the specified state if statelabel is not "") with the current target, effectively ignoring a particular attack. Thinking about it, this could potentially be an action function as well. ****This is needed to avoid having to give every actor on the map a TID.

(9)
Add a function to ACS: SetTargetByTID(int TID, int statelabel), SetTargetBySpawnID(int SpawnID, int statelabel), SetTargetByType(int DoomEdNum, int statelabel). These would cause the actor to reenter the SEE state (or the specified state if statelabel is not "") with the first-matching actor as a target and would return TRUE if successful or FALSE if not. Note this is NOT Thing_Hate(), it would set the AActor->target field NOT the TIDToHate field.


**** Finally, there is still the problem of writing "truly generic" ACS action functions, that is, functions that can affect any actor, WITHOUT having to give every actor on the map a TID. I don't know how difficult this would be but how about the following: since TIDs are positive, how about modifying all ACS functions that expect a TID to accept a negative number whose absolute value would be the *AActor value for that actor; effectively a handle to an actor, and exposing the AActor->this, AActor->target and "AActor->prospectivetarget" fields with GetActorProperty?