[Added] Tic randomizing in actor states

[Tormentor667]

What about an additional feature that lets you randomize tics in frames of actors? For example something like

Code: Select all • Expand view

Spawn:
    TROO AB random(1,10) A_Look
    loop

...that randomizes the duration of the TROO AB animation between 1 and 10.

[FDARI]

It is more plausible as an action function. A_SetStateTicks(int ticks, int flags = 0)
- You could pass random(1,10) as ticks
- Flags could contain such options as "ADD", "SUBTRACT"... well, you get it. Default behaviour is to set (replace). -1 means unlimited time.

Setting the duration randomly in the first place probably demands some reengineering, while modifying the remaining duration of the current state seems possible.

Such a function should probably affect the state owner, and not necessarily the caller. (When called from a weapon, affect the current weapon state, not the player state; when called from custominventory pickup/use, make no difference.)

Code: Select all • Expand view

Spawn:
    TROO A 0 A_Look
    TROO A 0 A_SetStateTicks(random(1,10))
    TROO B 0 A_Look
    TROO B 0 A_SetStateTicks(random(1,10))
    loop

A little less nice in decorate, but probably more easy to achieve.

Note: Add and subtract need not be different operations. You can pass negative values to subtract using "add".
Note: Add and subtract should not be able to change to or from -1. -1 represents an infinite duration, and cannot be reduced or increased significantly by finite operations.
Note: More advanced solutions than simply passing the desired duration (including -1 if infinity is desired) may be completely unnecessary. The feature is simpler if just sticking to the one parameter.

[Ryan Cordell]

Hell, if you want an example of tic modification, I think you needn't look further than A_BeakAttackPL1.

[Gez]

Or A_IceSetTics.

[Tormentor667]

Even though I understand this, I see problems (or redundant work) when I want to have an actor like this:

Code: Select all • Expand view

TROO ABCDEFG random(1,19)

because instead of one simple line I need to write 14 of them

[FDARI]

For such a narrow requirement, redundant work is expected. The alternative (which you propose) is to expand every state duration from a constant to an expression, and evaluate it whenever the state is changed. A_SetStateTicks would be a generalised approach using existing mechanisms. The cost of implementing it is therefore a lot lower.

Also; you will only need multiple lines when you want to call additional code pointers. If you want every state on a line to have the same (initially random) duration, you need one extra line to set a user_variable or something like that.

(EDIT: I am aware, as is later pointed out, that calling additional code pointers requires lines to be broken into many lines. I would not want to solve this in a bad way to make his decorate a little less clunky. Such streamlining I'd put on hold until I know what Doomscript has to offer. I am proposing/offering to write something equally/more functional that will in some cases lead to bulky decorate, with the advantage that the underlying mechanisms will not need to be rewritten.)

[XutaWoo]

He meant as in the example in the original post. He'd have to break each of those into different lines and insert a 0-tic state with A_Look inbetween each of them.

[cypherphage]

Such a feature would be boss, especially if it worked from custominventory so that you could do

Code: Select all • Expand view

TROO ABCDEFG 1 A_Give..."DoStuffCustomInvnetory"
...
Actor DoStuffCustomInvnetory...
TNT1 A 0 A_SetStateTicks(random(0,18),SUBTRACT)
TNT1 A 0 //Do More Stuff


Even without that, this would make all kinds of timing functions much easier to do.

[FDARI]

Making it usable from CustomInventory would be a bit of a tradeoff:
- Unusable in weapon states (or rather; will affect player and not weapon)
- Can interfere with states whose duration should not be altered (only if used inappropriately)

I think it has been brought up before, and that it is considered "invasive". Functions that affect the duration of the calling state already exist, so it may be more "acceptable".

A flag parameter could perhaps give us both... That might be worth exploring.

A_SetStateTicks(int duration, int flags)

Default behaviour: Set remaining duration of owning state to duration. -1 is unlimited.

possible flags:
SSTF_ADD (add positive/negative duration, does not cross between -1 and 0; -1 is unaffected, and 0 is the lowest resultant value)
SSTF_MUL (multiply remaining duration)
SSTF_DIV (divide remaining duration)

more important flags:
SSTF_CALLERSTATE (affect caller instead of state-owner; relevant when custominventory or weapon states need to influence something else)

Of course, we could do "bool" (A_SetStateTicks(int duration, bool usecaller)) but I like to have the flag specification from the get-go in anticipation of expansions.

[cypherphage]

Making it usable from CustomInventory would be a bit of a tradeoff:
... Can interfere with states whose duration should not be altered (only if used inappropriately)

The only issue I can think of there is somebody trying to extend a custominvnetory frame...but oh well, that is what the wiki is for.

[FDARI]

I think the potentially inappropriate use would be "A_RadiusGive" or any of the other handouts, using custominventory to modify the state durations of another actor, but even that would only mess things up significantly if it interacts with timed elements that are not equally adjusted. (ACS script or related actor with time sensitive design.)

Most features can be used in game-disrupting/breaking/crashing ways, so this is probably a minor issue.

[randi]

Added in r3847.

[Xtyfe]

How did I miss this? This is awesome

[Xaser]

Awwww hell yes!

[Nash]

Does this also mean expressions are already allowed in state durations?