FEATURE: triggerables

[RPTroll]

OK. Got it.

AbortTrigger() would be ok, truncatePath() would be better!

Shiney

[wolph42]

and then i realised that we havent discussed teleports yet. how were gonna do that? extra checkbox:activate teleport. that only works when there are two triggerables with the same name (identifier)?
and then there is the question of
- ofset of token if the two telports differ in size
- relative distance if movedOver is activated (you are teleported when you move OVER a teleport, lets say 10 steps...so you end up 10 steps beyond the other as well?)
- one way teleports (quite useful for inside maps e.g. a house, on a different map)
- and of course the question of whether to just send over the token or send the user (view) as well to the other teleport?

thoughts?

[JamzTheMan]

Yep, it's a can of worms alright.

I think this one may be able to be coded in steps though. If we can get the drawing down for trigger and the eventHook, we can go from there and start building on it?

Question, do we just fire an event "triggerDetected(String triggerName, list Tokens, Path location)" and allow macro's to capture 'onTriggerDetected, like onTokenMove?

Or do we only want a trigger to do specific things/call specific macro? Or both?

[wolph42]

well, see the UI description in th OP (and a few posts back) its all there. Basically you have a UI for a triggerable where you (optionally) link a macro to a triggerable. for teleports you can initialy start with linking macros that do the stuff for you and as you say build out support for that. but thought on this is required. note that all that stuff is currently supported in the BoT so no prio.

[RPTroll]

It think for now we call the existing moveTokenFromMap and moveTokenToMap for now and sort out the java method later.

[Craig]

Yep, it's a can of worms alright.

I think this one may be able to be coded in steps though. If we can get the drawing down for trigger and the eventHook, we can go from there and start building on it?

Question, do we just fire an event "triggerDetected(String triggerName, list Tokens, Path location)" and allow macro's to capture 'onTriggerDetected, like onTokenMove?

Or do we only want a trigger to do specific things/call specific macro? Or both?

I like the idea of registering a macro to be called for a trigger on a certain object/drawable/what have you.
That way we can start adding "standard" triggers for things like teleports/stop movement/instakill (wait did I say that) as we go along. So at some point the "add trigger" dialog would have a list of built in ones and then at the bottom "custom trigger" which would prompt them to fill in macro details. The object causing the trigger to fire should be passed in so the same macro can be used for many triggers (if I have 20 instakill traps with slightly different names I dont want to make 20 macros, I am instantly killing players so I have to juggle less things, not more!).

[RPTroll]

That way we can start adding "standard" triggers for things like teleports/stop movement/instakill (wait did I say that) as we go along. So at some point the "add trigger" dialog would have a list of built in ones and then at the bottom "custom trigger" which would prompt them to fill in macro details. The object causing the trigger to fire should be passed in so the same macro can be used for many triggers (if I have 20 instakill traps with slightly different names I dont want to make 20 macros, I am instantly killing players so I have to juggle less things, not more!).

Well, you'll certainly have less players to deal with.

Just thinking as I type: As we go forward with javascript, possibly register a js macro in the global area vs. on a token and have those in the list as user defined. Also the ability to call them on a lib:token like they are now.

[wolph42]

i like the dropdown idea!

[JamzTheMan]

K, lets go with registering macros first. I like the idea of building in some as well, whether they would be standard macros MT delivers or behind the scenes. Like Teleport, it game system agnostic, we should have a "wizard dialog" to allow a person to:

1. Draw a trigger area
2. Select "Teleport token"
3. Prompt them to select a Map
4. Prompt them to select another trigger area?

Ok, as I typed this, should we have it so a "trigger area" can be a "trigger" or "target"? I suppose a "Target" would just be a trigger with no macro, just a area with a name to use. Maybe you walk over a "trigger" and from a designated "target" area Zombies start to appear?

But start small, start with drawing triggers and assign a "macro" and create a function to get access triggers by name and get basic details.

[RPTroll]

But start small, start with drawing triggers and assign a "macro" and create a function to get access triggers by name and get basic details.

A bit more detail. Start small but . . .

Triggerable create: Draw, (re)name (system assigned name?), assign macro
Triggerable update (or edit): Either select from map explorer or right click from trigger layer (will we have a trigger layer?). Future: Move vertices? Draggable?
Triggerable delete: Right click delete function or delete button from edit. Use Delete key while selected on map?

macro to access triggerable values
event for tokens moving over trigger (I think this is implied)

So, trigger layer or no? Z-ordering?

[JamzTheMan]

I don't think we need a new layer for this. I think we can use the existing mechanics for viewing layers so we can just subclass Drawables (and add a z axis param).

I can see me drawing 1 of two ways:

1. Draw on the hidden layer in a nice red box so I can see it but it's just a generic area that triggers xyz.
2. Draw on the background/object layer some difficult terrain for a trigger and let me use this rubble texture...

Mechanically, I see no reason for a drawables layer. Instead, show them in map explorer for selection?

[RPTroll]

1) Thoughts on the map explorer route:
Currently it is a tree view with a folder per layer. Object invisible to players (except for the hidden layer) have a grey background and appear at the bottom of the list. Objects in tree view are non-draggable. The right click menu the same as if you were right clicking the asset (token).
Options for the tree view include:
a) You could create a subfolder for triggerables.
b) You could mark a trigger with an icon or something else like *, + or ~
c) You could find another color code to indicate triggers.


2) Thoughts on creating a stamp from trigger drawing.
You select the trigger tool and draw. When complete the drawing becomes an asset. This maintains consistency with the rest of maptool. If it's on a stamp layer, you can reshape as needed. It would appear in the tree. Anything could be a trigger. Trigger editing would be another tab on the existing properties window. Deleting a triggerable is just deleting any other asset.

I think I like 2 better with some designation on the map explorer showing its a trigger. You turn an existing asset into a triggerable with a check on the right-click menu or via some mechanic from trigger tool.

[JamzTheMan]

So if we go with #2, it gets all the normal token properties, states, macro's, stat sheet, etc? (not bad, just confirming we don't need to turn "off" anything?) ie Portrait image would be the drawable, you can drag a new image on that window to change it, that would be bad for triggers. We need to store the polygon as well so the Token class would get a new object (and would cause break back porting to 1.3 tokens)

Regarding "reshape". Lets start with "resize" for now. Adding/deleting/stretching/moving points in a polygon would require all new code. We could allow redrawing but that would take some code and thought as well.

The other issue with tokens, get footprint today gets you the rectangle coords, and locked to cells unless snapToGrid is off. Obviously we want full polygons so more changes required to get that from the asset.

[RPTroll]

Well, I guess assets come with a lot of benefits and drawbacks. I like all the code you wouldn't need to write.

Right now, there are differences in the code between tokens and stamps. They must inherit from a base object, or maybe they're just views into the same underlying object.

So, going further, if you turn something into a trigger would it be like turning something into a stamp from a token? Would it just be extending the class and casting it back and forth?

[JamzTheMan]

It's the same token class (as you can freely move tokens to/from layers and retain props).

There are just calls to return tokens by layers and some call them "stamps" on other layers as they have different menu options. Internally, I don't believe there is a difference.