You can now control thing counters from ACS

[printz]

You know the eight "counter" values that each thing in Eternity has? Eight numbers you can freely set and query in EDF, using codepointers such as SetCounter or CounterJump. Practically internal states you can set to whatever value you want when you create a new monster, to make that monster act in any complex way. You can now also set and get them in ACS using the SetActorProperty family of built-in ACS functions. Since it was already possible to control them from Small, it should be possible to do it now with ACS.

Since this is quite a recent update, there are two things to consider:
* Wait for DRDTeam to update their builds (http://devbuilds.drdteam.org/eternity/ http://devbuilds.drdteam.org/eternity-mac/)
* Wait for GZDoom Builder to update its ACS include files (especially zdefs.acs). But until then, you can copy the yellow lines from this link into your ACS file as a temporary measure.

[esselfortium]

Nice. I assume it's possible for actors to then call ACS scripts from their EDF frames, and thus use ACS for manipulation of their own specific counters?

[printz]

You can already manipulate counters directly from codepointers (this is their main use), but sure, you can call the StartScript codepointer from EDF frames, which can go into scripts which include the SetActorProperty ACS function on TID 0, which is the caller. You can also do crazy stuff such as "SetActivatorToTarget" to change the definition of TID 0 to one's enemy, so any subsequent calls to TID 0 affect the enemy (think of a monster that curses his enemy), but we're going on a tangent...

[Gez]

printz said:

zdefs.acs

Wouldn't it make sense to start maintaining an edefs.acs?

[Graf Zahl]

Funny. When I implemented something similar in ZDoom many years ago, Randi came along and turned into a completely different feature. Maybe I should dig out that old code again...

[Gez]

The user variables?

[Graf Zahl]

Yup, they were initially, I believe 5 generic user variables in Actor, but Randi nixed the idea and implemented real user variables for subclasses, completely forgetting in the process that these things could have been used by some generic coding for the original monsters as they always required subclassing.

The entire idea was essentially the same thing as these counters, they just never got a chance to be developed far enough due to Randi's intervention.

[printz]

Don't you have something more advanced by now? Something with keys/values or whatever?

[Graf Zahl]

ZDoom now has per-class variables but what hasn't been added is arbitrary properties that can be attached to a class retroactively.

[printz]

To do something similar to this, users had to create new inventory thing types as "tokens", and give them to monsters? I suppose having direct primitive variables is more convenient.