FEATURE: triggerables

[wolph42]

(This is a feature post, discussion about the functionality of this feature (and this featue alone) can be done here.)

Triggerables - draw an area and link a macro to it AND/OR apply core features.

ORIGINAL POST

There are several ways to deal with this. In the BoT you can create 'areas' (group of coordinates with a name) and link a macro to that area name. One way to simplify things is (similar to onTokenMove) have a designated macro name e.g. areaTrigger or onMoveOverArea. Several scenarios:
a. same as bot. There is a UI where you can link macros to area names
b. if an area is called e.g. trap15 then the corresponding macro is "areaTrigger_trap15"
c. similar to onTokenMove. There is only the macro 'areaTrigger' and when you move over a trigger area that macro is run. Either with the areaName as argument or not.
d. additionally you could have a core set of functions that you can assign to an area (so no macro involvement) these could be:
- limit movement
- block movement
- limit vision (see other thread for further details)
----
Passed on arguments:
array of json objects. Each object consist out of "tokenName":"triggerType"
triggerTypes are:
triggerType ("start on area", "end on area", "total distance moved", " same length='total distance moved' - 'distance moved on trigger area' ")
- noInteraction (0000) should never happen (as nothing is triggered)
- movedOn (0110) move onto the triggerArea
- movedOff (1010) move off the triggerArea
- movedOver (0010) move over the triggerArea
- movedNot (1101) when you move the token but place it back on its original spot (without waypoints)
- movedReturn (1110) when you move the token AND use way points AND leave the token but end the move onto the token
- movedRemain (1111) when you move but remain on the token during the entire move (both the path and the triggerpath are the same length)

SUMMARY OF DISCUSSION SO FAR

So summarizing, what we have so far:

1. triggerables can both be set up for drawables and tokens (assets, but I find the term tokens less arbitrary).
2. a UI is required to link a 'happening' to a triggerable
3. drawables should be selectable, moveables etc. and if thats the case than activating the UI for both drawables and token can be the same and can be activated the same: select either by mouse click or area select and hit some menu button: create trigger. Question: should tokens and drawables be selectable at the same time or not? (e.g. are they on the same layer?)
4. multiple tokens and/or drawables (triggerables) can be selected at once and the UI will apply 'the happening' to all.
5. overlapping triggerables are triggered by z-order, lowest first.
6. and now for the spaghetti code: the UI.

Code: Select all

TEXTFIELDS:
o Enter the name of this trigger (will be used to link triggerables). If you leave this blank its NOT a triggerable (so below functions will NOT work).
o Enter macro_name@lib:token that will be executed on trigger. Leave blank for none.
o Enter audio file name (dropdownbox?). Leave blank for none.
o Enter movement formula with M as default movement variable (e.g. "M+1","M*2","(M-1)*3","(M+4)/3") this will influence the movement counter beneath your token when you drag it. Leave blank for default. Note that 'difficult terrain' *increases* the move counter!! (so e.g. M*2 not M/2). 
Question: should the movement influencer do anything else? e.g. also [wfunc]getMoveCount[/wfunc]

CHECKBOXES: 
o Link ALL triggerables with the same name (unchecked will trigger the event for EVERY triggerable a token passes over also if they overlap; checked will trigger the event once per movement.

trigger the event on:
o movedOn	move onto the triggerArea
o movedOff	move off the triggerArea
o movedOver	move over the triggerArea
o movedNot	when you move the triggerArea but place it back on its original spot (without waypoints)
o movedReturn	when you move the triggerArea AND use way points AND leave the triggerArea but end the move onto the triggerArea
o movedRemain when you move but remain on the triggerArea during the entire move (both the path and the triggerpath are the same length)

question: can you and what will happen if you set different event triggers for linked triggerables?

then remains the question: what to do with gridless maps... or no-snap to grid. In The BoT (IRC) ive disabled functionality for these cases as its too much hassle or not even possible. On the more agnostic scale of MT this might be taken into consideration.

The reason I ask is because I know you want 'coordinates' and 'pathlength' returned as arguments and as suggested, you would want that in the same format as the other functions (like getLastPath) thats [{x:0;y:12},{x:0;y:13},etc]. And when *is* a triggerable triggered? On pixel touch or on 50%+ ? Personally I'm in favour of the simplest solution: pixel touch. In that case the cell-coordinate where that pixel resided will be returned as argument.

[RPTroll]

It we go drawable vs. asset then consider adding an edit dialog, like the asset edit dialog, that allows for assignment of functions and editing of other properties. These may need to go onto a new layer.

Would tieing triggers to an asset be quicker to implement? The down side is that you'll always get a rectangle for the shape. The upside is that you can tie the macro/function directly to the stamp or token via existing functionality and you could move it around, rotate it, and scale it as needed.

[wolph42]

It we go drawable vs. asset then consider adding an edit dialog, like the asset edit dialog, that allows for assignment of functions and editing of other properties. These may need to go onto a new layer.

Would tieing triggers to an asset be quicker to implement? The down side is that you'll always get a rectangle for the shape. The upside is that you can tie the macro/function directly to the stamp or token via existing functionality and you could move it around, rotate it, and scale it as needed.

the bot supports both areas and tokens (assets). I started with tokens only and added areas later so you could create different shapes (and it was a lot faster). Both systems have the advantages/drawback as you describe. Again: both would be nicest. And again UI is something to figure out. the BoT UI is ok, but is also the way it is due to some restrictions, without those instructions you could probly create a more intuitive UI to create these triggerables.

[RPTroll]

For the drawables, where does the macro get stored in the BoT? Is it evaled from text inside the definition?

[wolph42]

For the drawables, where does the macro get stored in the BoT? Is it evaled from text inside the definition?

the coordinates of the area and its name is stored in a json object as part of an array on lib:EventMacros. When a macro is linked to that area, the name of that macro is added to that object.
When a token moves the movedOver is checked per area and on a hit the macro is called.

so IRC you have something like this:
[{areaCoords:[coords], areaName:"difficultTerrain1", triggerMacro:"difficultTerrain"},{...},{...}]

its possible that i have this lot nested in a json object to cover for maps.

[JamzTheMan]

Granted, I have not looked into drawables yet but...

1. Would it make sense to utilize the "Templates"? I can see it used for drawing a 30' "blast" template for difficult terrain, via Entangle spell. And drawing them quick/easy to grid would be nice.
1a. I envision adding a checkbox to the template color dialog to attach a "trigger" with another dialog with needed details, or if it fits, adding to that dialog?

2. What do we do for overlapping drawable (or tokens for that matter). Combine? Do in order? To top only? Allow to configure? could get messing on the last. May need to add a z-order

3. I'm lean towards drawables with supporting functions to drawl (duplicate existing drawVBL/eraseVBL/getVBL), same formats with additional json attributes for trigger info. This gives us most flexibility, and allows a prefigured token to be placed like a Fog or Web stamp/token that graphically represents as well as mechanically.

4. A token trigger may still be useful for other reasons, so maybe both.

5. Tracking drawables shouldn't be to hard, we would collect those and store as a map of Polygons. BUT, consideration would be needed if user wants to draw and combine multiple polygons or modify it like VBL. It becomes harder unless we take on a "add more layers" approach but that's another feature request...

[wolph42]

Granted, I have not looked into drawables yet but...

1. Would it make sense to utilize the "Templates"? I can see it used for drawing a 30' "blast" template for difficult terrain, via Entangle spell. And drawing them quick/easy to grid would be nice.
1a. I envision adding a checkbox to the template color dialog to attach a "trigger" with another dialog with needed details, or if it fits, adding to that dialog?

yup that would be nice, i would prefer to use the same tools as are currently available.
1a. yup again. a simple checkbox and field where you can enter the macro name. That or what i suggested triggerAreaMacroName, but that might be harder to implement. Whatever is easiest.

2. What do we do for overlapping drawable (or tokens for that matter). Combine? Do in order? To top only? Allow to configure? could get messing on the last. May need to add a z-order

order. lowest z first.

3. I'm lean towards drawables with supporting functions to drawl (duplicate existing drawVBL/eraseVBL/getVBL), same formats with additional json attributes for trigger info. This gives us most flexibility, and allows a prefigured token to be placed like a Fog or Web stamp/token that graphically represents as well as mechanically.

that would be even greater, but i would put that functionality lower on the prio list.

4. A token trigger may still be useful for other reasons, so maybe both.

what do you mean with that? You mean both assets and areas? in that case yes of course

5. Tracking drawables shouldn't be to hard, we would collect those and store as a map of Polygons. BUT, consideration would be needed if user wants to draw and combine multiple polygons or modify it like VBL. It becomes harder unless we take on a "add more layers" approach but that's another feature request...

my preference would be to use the checkbox-field approach. If you want to 'link' drawables just enter the same macro. This would however result in double execution when the 'linked' drawable overlap. Thoughts? (as in: is that a good or a bad thing?).

[JamzTheMan]

re #4, yep, that's what I meant.

re #5, it does present a problem. Let say I draw an area for difficult Terrain, but I over lap it. The macro could fire twice double counting the penalty?

We also have to consider "cells" in all this. The macro needs to know how many "cells" were triggered. Does it need a threshold? Does drawing 3 pixels over into a cell count as a whole cell? Does it need a percentage of the cell? for Gridless, does it just return the trigger? Does it need to combine with getPath in some ways?

New bonus btw: It will be useful on triggering "Audio" queues as well.

[wolph42]

re #4, yep, that's what I meant.

re #5, it does present a problem. Let say I draw an area for difficult Terrain, but I over lap it. The macro could fire twice double counting the penalty?

We also have to consider "cells" in all this. The macro needs to know how many "cells" were triggered. Does it need a threshold? Does drawing 3 pixels over into a cell count as a whole cell? Does it need a percentage of the cell? for Gridless, does it just return the trigger? Does it need to combine with getPath in some ways?

New bonus btw: It will be useful on triggering "Audio" queues as well.

first off: thank you for confirming my believe that it is better to split up all the features in seperate posts.

the bonus: AWESOME!!

the issue: well thats the point: double fire macro might NOT be a bad thing. (or might it...?). E.g. if you want to create a steadily more difficult terrain you could draw a bit rectangle and then smaller rectangles inside so they overlap (think the vision feature of the BoT). you need to be smart with coding but its a useful feature.
On the other hand if you have other triggers... say audio...then that would be a bad thing.
However if you have difficult terrain AND audio overlapping then its a good thing again...

The biggest problem with NOT firing them off twice is with difficult terrain: lets say it does not and you have some sort of square swamp that get more difficult when you go towards the centre. this means you need to create a square like onion (so an outer hollow square, in which is another hollow square, etc. upto the centre) and each layer needs its own macro. Now if two layers happen to overlap then 'difficulty1' and 'difficulty2' are fired both, so you have to be carefull with drawing them.

this is indeed a pain to choose from. What would be simplest to implement?

[JamzTheMan]

First, yep, easier to track thoughts. Good plan. I kinda figured once we started talking functions, it would get messy. Me and Wolf went through this already with VBL Macros. And it helps no not code in a vacuum.

Back to the problem. Yes, they both have pluses and minus.

The square within a square is a good example where you might want it. Think of a bomb/trap, the inner square may knock people out/back and do damage and catch people of fire, the outer square may just cause damage. Different saves/target numbers.

Maybe a check boxes like "Stop processing triggers per movement", "Trigger once per movement", "Trigger only once" could be used. It's something a little new to MT logic but could be useful. Although I suppose you could always set values and track it manually in MapTool.

I think the goal is to allow a end user who doesn't know macro script to set up some simple triggers like, "When a player moves to this stairway, send them here" or "when a player first moves into this room, play this scream.mp3".

[RPTroll]

So on drawables, I forsee an issue that you want to delete one, but drawables are erased, not deleted. I can see this being an issue. Also, they can't be moved once drawn. Would it be possible to add a grabber that would allow you to move the template?

Could the drawable be named or referenced somehow?

[JamzTheMan]

So on drawables, I forsee an issue that you want to delete one, but drawables are erased, not deleted. I can see this being an issue. Also, they can't be moved once drawn. Would it be possible to add a grabber that would allow you to move the template?

Could the drawable be named or referenced somehow?

Yes, we could select them, move them, show them on the map explorer, delete, etc. Editing them would be tricky, as far as the shape goes. Maybe allow you to redraw it keeping the configuration? Maybe resize?


Edit: Drawables are tracked separably today as we can undo them via cntrl+z. (Did the undo bug get fixed btw?) So we're part way there.

[wolph42]

So summarizing, what we have so far:

1. triggerables can both be set up for drawables and tokens (assets, but I find the term tokens less arbitrary).
2. a UI is required to link a 'happening' to a triggerable
3. drawables should be selectable, moveables etc. and if thats the case than activating the UI for both drawables and token can be the same and can be activated the same: select either by mouse click or area select and hit some menu button: create trigger. Question: should tokens and drawables be selectable at the same time or not? (e.g. are they on the same layer?)
4. multiple tokens and/or drawables (triggerables) can be selected at once and the UI will apply 'the happening' to all.
5. overlapping triggerables are triggered by z-order, lowest first.
6. and now for the spaghetti code: the UI.

Code: Select all

TEXTFIELDS:
o Enter the name of this trigger (will be used to link triggerables). If you leave this blank its NOT a triggerable (so below functions will NOT work).
o Enter macro_name@lib:token that will be executed on trigger. Leave blank for none.
o Enter audio file name (dropdownbox?). Leave blank for none.
o Enter movement formula with M as default movement variable (e.g. "M+1","M*2","(M-1)*3","(M+4)/3") this will influence the movement counter beneath your token when you drag it. Leave blank for default. Note that 'difficult terrain' *increases* the move counter!! (so e.g. M*2 not M/2). 
Question: should the movement influencer do anything else? e.g. also [wfunc]getMoveCount[/wfunc]

CHECKBOXES: 
o Link ALL triggerables with the same name (unchecked will trigger the event for EVERY triggerable a token passes over also if they overlap; checked will trigger the event once per movement.

trigger the event on:
o movedOn	move onto the triggerArea
o movedOff	move off the triggerArea
o movedOver	move over the triggerArea
o movedNot	when you move the triggerArea but place it back on its original spot (without waypoints)
o movedReturn	when you move the triggerArea AND use way points AND leave the triggerArea but end the move onto the triggerArea
o movedRemain when you move but remain on the triggerArea during the entire move (both the path and the triggerpath are the same length)

question: can you and what will happen if you set different event triggers for linked triggerables?

then remains the question: what to do with gridless maps... or no-snap to grid. In The BoT (IRC) ive disabled functionality for these cases as its too much hassle or not even possible. On the more agnostic scale of MT this might be taken into consideration.

The reason I ask is because I know you want 'coordinates' and 'pathlength' returned as arguments and as suggested, you would want that in the same format as the other functions (like getLastPath) thats [{x:0;y:12},{x:0;y:13},etc]. And when *is* a triggerable triggered? On pixel touch or on 50%+ ? Personally I'm in favour of the simplest solution: pixel touch. In that case the cell-coordinate where that pixel resided will be returned as argument.

[RPTroll]

o movedNot when you move the triggerArea but place it back on its original spot (without waypoints)
o movedReturn when you move the triggerArea AND use way points AND leave the triggerArea but end the move onto the triggerArea
o movedRemain when you move but remain on the triggerArea during the entire move (both the path and the triggerpath are the same length)

Assuming this is down in the code and not bound to getLastPath, wouldn't these functionally be the same as moveOver? I'm trying to think of a use cases where that wouldn't work but drawing a blank.

[wolph42]

o movedNot when you move the triggerArea but place it back on its original spot (without waypoints)
o movedReturn when you move the triggerArea AND use way points AND leave the triggerArea but end the move onto the triggerArea
o movedRemain when you move but remain on the triggerArea during the entire move (both the path and the triggerpath are the same length)

Assuming this is down in the code and not bound to getLastPath, wouldn't these functionally be the same as moveOver? I'm trying to think of a use cases where that wouldn't work but drawing a blank.

in the code they are all different and in functionality you will check different things. Note that if you do NOT check them then the event will NOT trigger for that case. So leave-waypoint-return will result in NO trigger, while if this e.g. a nest of thornes that do damage every step your in them you do want the macro to trigger.
But to give a difference idea: a pit
- moveOver 1.spot check and 2. in fail apply damage; in success stop movement before pit. (negate rest of movement)
- moveRemain should be turned off as you do not want the macro to run!
- moveReturn 1. check to see if you can climb out. 2. apply damage because you fall back in.
-movedNot is something you will rarely use, but say the audio of a squeeky floorbord. You hear it, wonder what that was so you 'wiggle' your token a bit so you can hear it again.


that reminds me: you do need some sort of 'abort' function that negates ALL remaining happenings when your move is negated due to an event.

Example: you drag your token over 3 pits and fall into the first. However currently ALL three pit-happenings would occur. AbortTrigger() would be ok, truncatePath() would be better!