[Not Needed] GetThingSpecial/GetThingArg

[solarsnowfall]

// tid = 0 for activator
int GetThingSpecial(int tid)

As above, add a GetThingArg(int tid, int index).

A great many of the features suggested in this dusty old thread have made their way into ZDoom over the years. There was even a feature suggestion made about this very feature in 2012 but it never seemed to get any further discussion.

So I'm curious to know what the development team thinks about this today. Would it be non-trivial to add?

Here's my example usage. Say you've got an add-on mod which assigns specials to monsters for the purpose of collecting kill statistics. To do so you might assign a script execution special to all your monsters in some programmatic way. This would be fine and dandy for any monsters which did not already have a special assigned, but potentially game breaking if it blindly overwrites the monster's pre-existing special. If you're able to detect whether or not a given monster already has a special assigned you could handle it differently or ignore it and avoid breaking a map.

[NeuralStunner]

Additionally, if you intend to replace an actor via script (it could happen), you'd want to make sure the special gets transferred properly.

Needless to say, seconded.

[Ed the Bat]

I've wanted this for years. I genuinely thought that if it was possible to do, it would've been done a long time ago by now.

[NeuralStunner]

I don't see why it wouldn't be, when [wiki=DECORATE_expressions#Variables]there's already decorate expressions for it[/wiki].

[Ed the Bat]

There's a lot of things Decorate can do that ACS can't. Which is why a gross Decorate hack is the only way to approximate certain things in ACS, such as changing actor flags.

[Nash]

I know workarounds are frowned upon but if the example in the OP is the only use case; would KILL scripts help (the exact purpose why the feature was added in the first place is to prevent overwriting existing monsters' scripts)?

[solarsnowfall]

In that very specific example, yes. I wasn't aware of this new script type when I wrote that. Be that as it may, that doesn't necessarily mean there isn't any value in being able to poll an actor's special/arguments.

[yqco]

It's already possible:

Code: Select all

function int GetActorArg(int tid, int arg)
{
    return GetUserArray(tid, "Args", arg);
}

function int GetActorSpecial(int tid)
{
    return GetUserVariable(tid, "Special");
}

[Ed the Bat]

I tried this, and it would only ever return zero.

EDIT: Just tried it again, and it works. Perhaps I was just making mistakes all that time...

[solarsnowfall]

Ah snap! I had poured over the ACS list but for whatever reason it hadn't occurred to me that those functions would have changed (or will be changing) since the last time I played with them.

Man, it really has been a while.

[NeuralStunner]

I usually watch the feature suggestions forum and didn't spot this either. Good to know, though.

[ZzZombo]

It's already possible:

Code: Select all

function int GetActorArg(int tid, int arg)
{
    return GetUserArray(tid, "Args", arg);
}

function int GetActorSpecial(int tid)
{
    return GetUserVariable(tid, "Special");
} 

Ugh? I mean, "user" variables were introduced exactly to make them never conflict with built-in features, so this just has to be a bug.

[yqco]

It's intentional. User variables are prefixed with "user_" to prevent name collisions.

[ZzZombo]

That's dumb. First, we already have S\GetActorProperty(). Then, even if it misses something, a separate GetNativeVaiable() is in order instead of tackling everything into functions never intended to do that.

[Graf Zahl]

However dumb it is, it's too late to remove it and rename it to something more correct.