New Events for Macros

[rkathey]

Is your feature request related to a problem? Please describe.
Add additional event macros such as those at http://lmwcs.com/rptools/wiki/Category:Event

The new events would cover things like clicking on a token or creating a new token.

Describe the solution you'd like
Create a new set of events not covered in the following
onCampaignLoad
onChangeSelection
onMouseOverEvent
onMultipleTokensMove
onTokenMove

Describe alternatives you've considered
BAU

Additional context
This is a request from @kayila

[Merudo]

Having "onMouseOver" being integrated would be good.

[JamzTheMan]

What do you mean by integrated? Like not needing a frame to hold onMouseOverEvent? (If so yes!)

[Merudo]

I mean it becoming an actual event instead of being a fake one.

[kayila]

Included in this, we'd like to see the following:

• onClick
• onTokenCreated
• onMapLoad
• onTokenDelete

Ideally this could be done as a proper event system, and the existing event macros move to that rather than haphazardly adding special macro names as one offs.

[JamzTheMan]

onCampaignStart could be useful. Would this fire when connected to a server as well or should there be a onServerJoin? I could see these used to move players to a specific map, among other things.

Question: where should these be defined? I suggested via UI (campaign properties?)

But what should that be? Should they simply accept a macro and or UDF? Should they contain it's own macro command?

In other words, as a new user, for on onCampaignStart, can I enter a few lines of macro code like gotoMap and a broadcast ("Hello!")

Or will we require them to create a lib token somewhere and call a macro and such? (Obviously I advocate for the former and not later)

I can assist with throwing together the UI components if needed (I know some have issues with h abillie forms, it depending on when this gets done, a FX component may be better)

[kayila]

So, the answer to the question of where the handlers are located is a little more complicated than just storing them in one place. I'm thinking there would be a way to store some, such as onCampaignLoad and onServerJoin on the campaign itself, no use of lib tokens. The onClick event, however, would trigger a macro on the token which was clicked on.

I think having seperate onCampaignLoad vs onServerJoin is a good idea, maybe also an onPlayerJoin/onGMJoin?

Also, these macros should probably be passed useful information, such as onClick being passed who clicked on it, onServerJoin passing the user who joined, etc.

[JamzTheMan]

OnServerJoin is probably good enough as long as who joined is passed and you can if isGm it in the macro.

I think onClick should be a global still. It's args would be maybe map, map cell and/or x,y and IF a token is clicked token (should it be tokenList? Tokens can be stacked)

I don't think I would want to change a macro on every token. Say, I just want to call a REST method using a property from the token? Why put a macro on each token?

Now, alternative, maybe it also can fire a default macro like onTokenClick IF that macro is on the token? (Does it do both? Only if there is no global macro?)

But having it global is think is better, as worse case you just out a executeLink for a specific macro on the token.

[cwisniew]

Question: where should these be defined? I suggested via UI (campaign properties?)

You really don't have much of a choice, if you add these then people will want to use them in their libraries so you have to support lib tokens, otherwise there can only be one, and you couldn't have it in both your frame work and the bag of tricks for example

[kayila]

I'm imagining a world where frameworks would subscribe to events to get their event macros called...

But yea, calling a onTokenClick macro on the clicked token(s) in addition to a global macro I think is ok

[cwisniew]

I'm imagining a world where frameworks would subscribe to events to get their event macros called...

For the campaign properties vs lib toke question, for new scripting language thats fine (and preferred), but I would rather not introduce a new way of doing things in only some cases to the current one, it has enough inconsistencies as is.

[JamzTheMan]

Forgot one, onInitiativeChange event.

Also, some (all?) Of these events should have a way to direct output.

In other words, if a player drops in a token and it fires off a macro to stay it, and there is a a dialog prompt that requires input, it may be desired to have said output direct to the gm vs player who initiated the event.

This issue is a can of worms :)

[rkathey]

onMovedOver() would be handy on a token for traps, teleports, opacity changes, sounds, etc.

The onInitiativeChange() should return the token losing init and the one gaining init.

[rkathey]

onCampaignStart could be useful. Would this fire when connected to a server as well or should there be a onServerJoin? I could see these used to move players to a specific map, among other things.

@JamzTheMan would this fire when the GM started a server. Do they technically connect to a server they start?

I think I would prefer an onServerStart and onConnectToServer. They might do the same things but I can see the GM wanting to run checks before anyone connects.

[JamzTheMan]

But the GM may or may not start the campaign? So would those fail? Couldn't you do the same thing with just a isGM clause in the onServerStart?

FWIW I think the onCampaignLoad macros fire again don't they when a server starts? The only issue is we have no control in the order in which they start, so a place that is guaranteed to be the very first macro to run may be nice?

So maybe a onCampaignStart and onServerStart could be nice for separate reasons?

[aliasmask]

Going from the list posted in Discord:

onMouseOver
onClick
onTokenCreated
onMapLoad
onTokenDelete
onCampaignStart
onServerJoin
onInitiativeChange

onMouseOver - we kind of already have this with the token type and * option.
onClick - onSelectToken fires when a token is clicked and deselected. I have some code that will tell me when a token is clicked, 2nd clicked and deselected. Maybe a doubleClick option to prevent token props from opening and doing something else with token?
onTokenCreated - I think this should only be for drop-in tokens and not for something like copyToken. Also, what about cut/paste tokens or copy/paste?
onTokenDelete - I can see a use in moving a token to another map instead of deleting it. What about cut/paste? Will it fire for that?
onServerJoin/onCampaignStart - I don't really see a difference than the onCampaignLoad. Maybe better support for setting variables which isn't supported with onCampaignLoad. I use the execLink trick to avoid lib token duplication.

onInitiativeChange would be useful for obvious reasons. I can see some use for onMapLoad as well (ie force a player to a certain part of a map when it loads).

[JamzTheMan]

FWIW one reason would be to move all the events OFF lib tokens and onto a more campaign macro global area.

I would also think, right now, all your "will it fire" Questions would be a yes. But when the events fire it would pass a set of args so you would know if it was a drop event or macro or copy/paste for instance.

OnCampignLoad is nice but what order do they fire? Today I don't really have a way to say "do this first before anything else" without complicated code.

onClick was specifically requested because you have to deselect a token to click it again. And the fact that you have to put in special code to avoid multiple fires of the event tells us we should add a new event that works correctly.

Right now we have lots of "tricks" to get MapTool to do things but we would like to lower the bar so new users can get things scripted up and running without needing to jump through hoops. IMHO at least.

[rkathey]

I’m coming around to @Jamz point of view on the event macros being stored in Campaign Properties. I can envision a tab much like property type or light/sight definition (probably the latter) where you put the event name and macro text.

[Merudo]

I think UDFs definitions should belong in lib tokens. That way you can share frameworks by sharing a single token.

[rkathey]

The counterpoint to the ‘on token’ argument is that you usually have to share the campaign properties export for frameworks as well.

[aliasmask]

I'm all for having things work better than they are. I do have to go through some code gymnastics to get things to work the way I want which probably prevents others from using these useful events. I was just going over the current state of things pointing out we have some of this functionality already. It just requires a little more effort to use.

Using an event like onSelectToken you can do your own onInitiativeChange or onMapLoad by setting some variables and comparing it to current states. But having a dedicated event would be more preferable.

[JamzTheMan]

Yea, I get that, I do rank this lower on my list of wants because we can work around a lot (some?) of it today. But that's only for the "elite" lol

Re UDF's, sure, UDF makes sense on the lib token. But we also want to get rid of lib tokens as well. They kind of suck for modularity. When you need states/bars/tables/properties/property types to also be installed for your "lib token" to work then ya, they sort of suck.

But that's neither here or there, events are more than UDF's and onCampaignStart is more than just UDF's.

[Azhrei]

Has it been discussed (in Parser 2.0?) to allow calls directly to macros on Lib tokens without defining the UDF? For example, a token named Lib2:Stuff would automatically allow calling any macro on it as Stuff.someMacro without needing defineFunction...

I know wants to kill Lib tokens in general, so maybe hobbling with what we have is better than another bandaid in the short term until Paraer 2.0 and (eventually) JavaScript (or Groovy, or whatever).

[JamzTheMan]

Yea, to be honest I think events should wait for parser 2.0 and do em right.

I'm assuming we're theory crafting here to get the wish list ironed out?

[aliasmask]

So, we're going to have lib tokens in 2.0? I was thinking things would be folder-tree type of structure. Then all the files (macros) would be udfs based on the tree and uniqueness... ie

lib 
  utils
    printForm

could be reference by printForm() given no other printForms macros exist, or lib.utils.printForm() or utils.printForm(). That would be ideal.

The macro editor could show all macros in a branch. Have a checkbox system to show/not show macros in branch and options to show sub branches and those macros.

[cwisniew]

So, we're going to have lib tokens in 2.0?

Lib:Tokens are deprecated. No new support for them in future macro rewrites

could be reference by printForm() given no other printForms macros exist, or lib.utils.printForm() or utils.printForm(). That would be ideal.

Everything will have to be fully qualified, otherwise someone adds a macro in a framework you have imported with same name and suddenly boom nothing works

[aliasmask]

Creation and importing should account for duplicates or rewrites. If I were to import a branch with new macros on it, it would rewrite the originals and add the new one. Then it would build the alias list.

But I see what you mean. If I referred to printForm() in the code, but suddenly I added a new printForm() under a new branch the code will have to identify which one I was referring to. Maybe some kind of IDE reference like an auto complete would be better. So, if I were to type in printForn() it would add the lib.utils.printForm() for me or list the other printForm() references.

When referencing a function not defined, it create a local reference based on current macro location. Later if I were to drag-drop reference to a new location in branch it changes all the relevant code to correct reference.

[rkathey]

Yea, to be honest, I think events should wait for parser 2.0 and do em right.

I'm assuming we're theory-crafting here to get the wish list ironed out?

The original point of the thread was for discussion purposes. We now have several discussion points:

1. The events themselves (which we want to tackle and which we do not)
2. New vs. Old concept for events (on token vs on campaign)
3. When to tackle - MTScript 2 vs current MTScript.

On point 3 - since we don't have a timeframe for MTScript2, some of the more useful ones could go now while the others can wait.

[bubblobill]

onChangeFacing

[Merudo]

I think a onServerLeft would pair nicely with onServerJoin, to perform some cleanup once a player leave.

[kayila]

This would likely be implemented well using the event system which #1827 is adding.

[nildik]

Hello. The onChangeInitiative Event... Runs on every client, when the initiative is changed? or just in the client that change the initiative?

[aliasmask]

I would assume for all clients, but I'm wondering if that is true with tokens unseen by clients. I would probably make a check to verify code is running only for the GM/server. But it would probably depend on what you're doing as well.

[nildik]

I just make a simple trial and it seems than only runs for the client that execute the "nextInitiative" no matter if via macro or panel.
I am trying to make a macro controled initiative panel and i think that i could "refresh" it via this event, but doesn't work

[selquest]

Hello. The onChangeInitiative Event... Runs on every client, when the initiative is changed? or just in the client that change the initiative?

Both initiative events only run on the client triggering the nextInitiative call (whether through the UI panel or macro function):

• the onInitiativeChangeAttempt event happens before the actual change is processed, so other clients don't know it's happening yet.
• the onInitiativeChange event needs to fire exactly once per change (on only the client that triggered it) or the macro authors would have to account for race conditions in every onInitiativeChange handler.

[bubblobill]

It would be nice if onChangeToken could be made less hazardous.