"How do I ZScript?"

[Gez]

If I'm not mistaken, "action" is there to mark the function as an action special, so that it can be called from states.

I've solved the issue by putting "invoker." in front of the user var.

[Matt]

That seems so weird that you'd need invoker for that o_O It's just an actor, not an inventory item or weapon!

[AFADoomer]

If I'm not mistaken, "action" is there to mark the function as an action special, so that it can be called from states.

I've solved the issue by putting "invoker." in front of the user var.

What Vaecrius said... I'm pretty sure that's only required for weapons.

I know for 100% certain that for a function within a normal actor, you don't need the action declaration.

[Nash]

Nash: I have some vague recollection of trying that last night and it didn't compile. Are event handlers fully supported in 3.0.1?

Try it and see what happens? :D That code was lifted directly from my project, which works.

[Matt]

It doesn't work for me.

Does it have to be defined in Mapinfo as well?

EDIT: right, that.

Code: Select all

gameinfo{
 eventhandlers="MyHandler"
}

[Gutawer]

Probably better to use

Code: Select all

AddEventHandlers="MyHandler"

in most cases, it prevents the game from overwriting all other handlers with your one, heavily increasing mod compatibility with other mods that use their own EventHandlers.

[Gez]

Alright, got rid of action and invoker. and it indeed works.



New question now: I want to make a waterproof firemace. The normal projectiles are destroyed when they hit water, so that's annoying. For the first three MaceFX, just giving them the CANBOUNCEWATER flag is enough; but MaceFX4 is more annoying because its A_DeathBallImpact kills it when it hits water. So I've got to override that. But it's not virtual so it's not overridable. I guess there's no other choice than to make a clone of the function (without the annoying bit) with a different name and replaces the state that call it.

[Graf Zahl]

If I'm not mistaken, "action" is there to mark the function as an action special, so that it can be called from states.

This is not correct. The terminology may be a bit confusing because this was the original intent but isn't correct anymore.
What 'action' does is to mark the function as usable from non-actor states, like weapons, overlays and custom inventories, so that it can pass the invoker pointer. In any other context 'action' should not be used at all!

[Caligari87]

Since we're on the subject, I think I'm having some kind of scope issues and/or misunderstandings. I've got a weapon, and it seems I can't get or manipulate certain variables in Tick(). Like, GetPlayerInput doesn't seem to return anything, I can't use variables like angle/pitch, etc. It seems those things only work in either anonymous or action functions?

[Gutawer]

Is there any way to achieve the same effect as the different modes of ACS' Thing_Hate with ZScript? I know you can set the target pointer directly, but that isn't really helpful in this case since I'd like the actor being modified to switch target to the player in the case that the player starts attacking them, like with Thing_Hate type 1 or 2. So, is there any way to set this sort of logic through ZScript?

[Xaser]

If I'm not mistaken, "action" is there to mark the function as an action special, so that it can be called from states.

This is not correct. The terminology may be a bit confusing because this was the original intent but isn't correct anymore.
What 'action' does is to mark the function as usable from non-actor states, like weapons, overlays and custom inventories, so that it can pass the invoker pointer. In any other context 'action' should not be used at all!

Yeah, I was under the same impression as Gez here. The keyword "action" no longer maps 1:1 with the DECORATE notion of "action function", which is never going to not confuse anyone. :/

I'm not really sure what to suggest here, aside from providing a synonym keyword for "action" (suggestions welcome, I guess) so the docs can simply state "'action functions' are just called 'functions' now" and use some new keyword to describe the "usable from non-actor states" concept.

[Gez]

"proxy"? The function belongs to a weapon, but it's actually the player who uses it, so the weapon is kind of a proxy? Or "indirect" perhaps.

[Major Cooke]

Since we're on the subject, I think I'm having some kind of scope issues and/or misunderstandings. I've got a weapon, and it seems I can't get or manipulate certain variables in Tick(). Like, GetPlayerInput doesn't seem to return anything, I can't use variables like angle/pitch, etc. It seems those things only work in either anonymous or action functions?

Yup. You can't use direct assignment without it being inside of a function, anonymous or otherwise.

Is there any way to achieve the same effect as the different modes of ACS' Thing_Hate with ZScript? I know you can set the target pointer directly, but that isn't really helpful in this case since I'd like the actor being modified to switch target to the player in the case that the player starts attacking them, like with Thing_Hate type 1 or 2. So, is there any way to set this sort of logic through ZScript?

Few options.

1. Use an iterator and perform sight checking.
+ Gives you total control.
- You'll have to set this one up yourself though, check for things like if it's a monster and if it's alive.
- Can lag if done too much and/or too often.

2. Use the now-fixed RoughMonsterSearch.
- I have no words of wisdom on this one.

3. If it's only when damaged, override the DamageMobj function, check if it's a player kicking them in the pants and retaliate.
- Careful though, you'll need to turn off the FRIENDLY flag AND SET THE DESIGNATEDTEAM variable to a team the player's not on.

[Graf Zahl]

If I'm not mistaken, "action" is there to mark the function as an action special, so that it can be called from states.

This is not correct. The terminology may be a bit confusing because this was the original intent but isn't correct anymore.
What 'action' does is to mark the function as usable from non-actor states, like weapons, overlays and custom inventories, so that it can pass the invoker pointer. In any other context 'action' should not be used at all!

Yeah, I was under the same impression as Gez here. The keyword "action" no longer maps 1:1 with the DECORATE notion of "action function", which is never going to not confuse anyone. :/

I'm not really sure what to suggest here, aside from providing a synonym keyword for "action" (suggestions welcome, I guess) so the docs can simply state "'action functions' are just called 'functions' now" and use some new keyword to describe the "usable from non-actor states" concept.

Give me a better keyword and we're in business. BTW, the 'action' keyword was required for any action function until I realized that I only needed to make a minimal change to the code to lift the restriction

[Mikk-]

Is there a way to access zscript variables via ACS?