Discussion: Future Macro Possibilities

[Craig]

This Thread is so the Visual Representation of Targets/Marks (Not Just 4e))does not get derailed with comments about macros.

I have made modifications that allow me to add/remove targets and marks to tokens I have also started adding the ability for macros to interact to targets and and marks.

What I have working on the code on my computer so far are.
- Reading the name of the target/mark.
This can be used with {} to display in your macros who attacks are against.

- Reading the states of target/mark.
So yes you will be able to build up attack macros that give you +/- based on the targets state (e.g. Prone, Sleeping etc).


At the moment I have not implemented
- Reading properties. Do you really want players being able to read any property of a token they don't own?
- Setting of any properties/states etc of targets. Again it comes down to what you want players to do/not do?

Feel free to add comments or list any other suggestions or ideas that you may have and I will see if I can add them.

Craig

[Mathemagician]

Craig, did you ever know that you're my hero?

I think that reading properties and setting properties have to be an option for the GM to set in the campaign settings. I think most of us trust our players not to cheat, but if the player can read the token properties, it's far too easy to set "whisper macros" to strip out the token data without the DM knowing (unless of course we have that Big Brother DM feature )

I think I would really like to see my players being able to _set_ states and _read_ properties. In this way, I could have my players implement a macro like the following:
[AttackRoll="1d20"+bonus] {target.state.Hit = max(0, AttackRoll - target.Defense)}{target.state.Miss = 1-target.state.Hit}

Where "Hit" and "Miss" are graphical states for the tokens, so that as the DM I can quickly read who got hit or missed by an (area) attack, and apply appropriate damage.

Edited for math and grammar

[brad]

Wow! I didn't expect this stuff for a while.

I do see the many possible problems of a player's token being able to read and set another token's properties, but I think it is a necessary option to have. Some Gms won't want that hanging out there, but some(like myself) very much do. That would allow a one step macro that targeted someone, would be able to automatically determine if it hit, roll damage, subtract target's defenses, apply damage, and apply appropriate states for wounding. This would be a great option to have.

Of course, it would need to be an option that could be turned off, as sometimes GMs are playing with players they don't really know. Maybe some sort of an alert option when a PC token reads or modifies a NPC token?

[Mrugnak]

At the moment I have not implemented
- Reading properties. Do you really want players being able to read any property of a token they don't own?

I think I'd restrict this to visible properties, the ones marked with (IIRC) @'s on the property sheet. Those ones are already public, so there shouldn't be an issue about seeing secrets.

- Setting of any properties/states etc of targets. Again it comes down to what you want players to do/not do?

I think you're right that this would perhaps be a bit much. Although it would be nice to automatically apply damage, I start wondering when this becomes a stand-alone video game, instead of a virtual table top and GM/Player's assistant tool.

[RPTroll]

This Thread is so the Visual Representation of Targets/Marks (Not Just 4e))does not get derailed with comments about macros.

I have made modifications that allow me to add/remove targets and marks to tokens I have also started adding the ability for macros to interact to targets and and marks.

What I have working on the code on my computer so far are.
- Reading the name of the target/mark.
This can be used with {} to display in your macros who attacks are against.

- Reading the states of target/mark.
So yes you will be able to build up attack macros that give you +/- based on the targets state (e.g. Prone, Sleeping etc).


At the moment I have not implemented
- Reading properties. Do you really want players being able to read any property of a token they don't own?
- Setting of any properties/states etc of targets. Again it comes down to what you want players to do/not do?

Feel free to add comments or list any other suggestions or ideas that you may have and I will see if I can add them.

Craig

On reading target properties... I would restrict the visibility of non-owned token properties to those visible to all players. You can make a property invisible to others if you put an @ at the beginning of the name under campaign properties. You can also have several different versions of the token properties for one campaign if you wanted some NPCs to be special and non-updatable. I really want the ability to read a targets parry/AC/Defense bonus and calculate attacks based on that.

I don't think you should be able to set properties if you are not the owner. Thus a DM could run a 'damaging' macro but players could not but that's just me. I can see the speed advantages of having macros that damage a target run by a player. Again, you could make the @ do double duty and allow properties without an @ changeable by macros or you could come up with a different symbol to mark a property as updatable by another tokens macro.

[Brigand]

Hrm. I like the ability for a macro to affect only the public display stats and states on a token. With the ability to reference a tokens hidden properties through a macro, it will be possible to create the Simplicity RPG inside MapTool and have the hit quality stuff calculated automatically.

[panzuriel]

Targeting, and access to (at least some) properties of your target from a macro would be incredibly useful. Possibly the easiest to code would be something like

Code: Select all

{ t = #target# }

which would prompt for you to select a target when running the macro, and then access properties like

Code: Select all

{ if(HitRoll > t.AC, " Yay! ", " Doh! ") }

Ooo... how's this for a way to hide values from players? (Probably more distant future) Call a macro on the other token. Something like (DnD example but other systems could work - by defining different macros on the target)

Code: Select all

{if(t.Attack("AC",+4), " Yay ! ", " Doh! ")}

And assuming the Attack macro is defined on the target (t), it is called with those arguments, and returns true/false. That way even the dice roll is hidden from the client. (Might want to have the target macro display something to prevent a cunning player from spamming the macro and using a probability distribution to determine the AC).

[Cweord]

A Right click option of set target would be nice - associating that target with that token, you could then use a multiple token macro to get all of your npcs to perform that action.

One thing that is going to need to tie in with this though will be range detection between the token and the target - are they close enough to perform the said action, are they too close?

I can see a great use of this for banks of archer, and for speeding up combat in systems with dodge or damage resistance rolls . . . .

The biggest trouble with having it effect player visible properties, is you then have to let players know how much damage the npc has currently taken - I do like the idea of having another option for player modifiable properties.

[panzuriel]

Another post for another suggestion:

I'd LOVE a way to conditionally prompt for a value, eg:

Code: Select all

{ fnords = if(HaveFnords>0, HaveFnords, getFnords) }

Assuming that HaveFnords is a property of our token, but getFnords is not, (actually, I may use that as a convention in my code from now - properties start with Caps, temporary variables don't)... we only get prompted for a valued for getFnords if HaveFnords is <= 0.

[Mathemagician]

Maybe I'm wrong, but as soon as the GM is prompted for values to send to the player, or the GM has to click on a macro to let the player's attack go through, the ability to pull properties from the targetted token is going to be slower than me just reading the number and saying hit/miss.

I thought this was mentioned earlier, but I was wrong. There's been some discussion as to "We should be able to pull properties everyone can see" and those sorts of things. What are the odds we can add a delimiter to the campaign properties? We already have *, @, # for who can view the property on the stat sheet. Why not add one like !, for "macros can access this stat?" This way, GMs who trust their players can enable it, and if trust becomes an issue, the GM can make a quick adjustment to fix it (besides right-click-boot )

[Mrugnak]

What are the odds we can add a delimiter to the campaign properties? We already have *, @, # for who can view the property on the stat sheet. Why not add one like !, for "macros can access this stat?" This way, GMs who trust their players can enable it, and if trust becomes an issue, the GM can make a quick adjustment to fix it (besides right-click-boot 8) )

That's a good suggestion. I'm wondering, also, if there should be a campaign-level option to set the level of "Macro security" - a GM who wants to could open up all the properties for macros, another could restrict it to properties flagged for macro access, and paranoia mode might allow only public properties flagged for macro access.

While we're in a thread discussing targets interacting with macros, being able to get the range from my token to the targeted token in map-scale would rock my tiny world.

[BigO]

Feel free to add comments or list any other suggestions or ideas that you may have and I will see if I can add them.

Craig

Craig, are you also the one working on the syntax of the macro commands? I have several thoughts/suggestions about that.