MapTool 1.3 Development Build 47

[Rumble]

Man, how frustrating! Maybe someone else will chime in with a solution. I swear I saw this issue raised elsewhere on the forums.

[FdL]

Yeah, I'm having a hard time finding any info on this. I'm trying to set up a basic campaign file for 4e, and I bump into this issue.

Could have to do with regional settings. I'd say it's a bug.

But in any case, now that I've interrupted this thread's usual flow, could anyone point me to some reference as to defining lights? I want to understand the syntax of that block of text, because I just copy-pasted it from a campaign I downloaded.

[Rumble]

So I'm experimenting with the calling of macros on other tokens (specifically, on a Lib:name token). I wanted to see if I could roll an attack macro on a player token, and have it call the "take damage" macro on a token called Lib:OrcFreak.

Here's what happens when I do this thing:

1. Our hero, Kalad, runs an attack macro called "Hit the Freak!" that randomly calculates some damage, and passes that number to the Lib:OrcFreak token with the following:

Code: Select all

[MACRO("takedamage@Lib:OrcFreak"): damage]

2. The TakeDamage macro on Lib:OrcFreak receives macro.args with the statement

Code: Select all

[HP = HP - macro.args]

3. Our hero, Kalad, has his HP reduced by the amount of damage passed to Lib:OrcFreak. The Lib:OrcFreak token, on the other hand, is unaffected.

From what debugging I've done, macro.args is receiving the value of damage as expected. However, it's using Kalad's properties in all calculations, rather than the Lib: token's properties.

So I assume I've either coded it improperly (entirely possible!), or I'm misunderstanding a limitation of the macro calling capability - perhaps called macros on Lib: tokens can't access their own properties, or assume that the properties being accessed are on the calling token, or something like that.

[Orchard]

So I'm experimenting with the calling of macros on other tokens (specifically, on a Lib:name token). I wanted to see if I could roll an attack macro on a player token, and have it call the "take damage" macro on a token called Lib:OrcFreak.

Here's what happens when I do this thing:

1. Our hero, Kalad, runs an attack macro called "Hit the Freak!" that randomly calculates some damage, and passes that number to the Lib:OrcFreak token with the following:

Code: Select all

[MACRO("takedamage@Lib:OrcFreak"): damage]

2. The TakeDamage macro on Lib:OrcFreak receives macro.args with the statement

Code: Select all

[HP = HP - macro.args]

3. Our hero, Kalad, has his HP reduced by the amount of damage passed to Lib:OrcFreak. The Lib:OrcFreak token, on the other hand, is unaffected.

From what debugging I've done, macro.args is receiving the value of damage as expected. However, it's using Kalad's properties in all calculations, rather than the Lib: token's properties.

So I assume I've either coded it improperly (entirely possible!), or I'm misunderstanding a limitation of the macro calling capability - perhaps called macros on Lib: tokens can't access their own properties, or assume that the properties being accessed are on the calling token, or something like that.

Well, you are further along in understanding this than I...

[Orchard]

Can Craig (or someone) please elaborate on the usage of the [MACRO("macro_name@location"): macro_arguments] with a lib:token_name example?

I'm totally lost!

My real goal is to be able to use this (somehow, if possible) to allow access to token props for players to target monsters (AC, specifically) to check directly if a roll was a hit, but I can't really wrap my head around this. It's probably a lack of sleep and stress and work combined, but I just can't brain this week, I haz teh dumb...

[Rumble]

And if such a thread would be better in the MapTool forum, I would be happy to start one there, rather than keep it going in this one.

[Phergus]

From my reading of Craig's post on the lib: tokens is that these are not tokens to represent your critters and such. They are just convenient holders for macros.

You access the macros from them but they are not supposed to be either NPC or PC tokens. IIRC, he even noted that they don't have to be visible to the players.

How you use them to modify other tokens I have no idea.

[Orchard]

From my reading of Craig's post on the lib: tokens is that these are not tokens to represent your critters and such. They are just convenient holders for macros.

You access the macros from them but they are not supposed to be either NPC or PC tokens. IIRC, he even noted that they don't have to be visible to the players.

How you use them to modify other tokens I have no idea.

See, I can see a use for that, but only moderately...I need something for being able to allow my players to safely access the AC on the critters without needing to be told that monster X has an AC of 54...(or whatever)

[knizia.fan]

Can Craig (or someone) please elaborate on the usage of the [MACRO("macro_name@location"): macro_arguments] with a lib:token_name example?

I'm totally lost!

My real goal is to be able to use this (somehow, if possible) to allow access to token props for players to target monsters (AC, specifically) to check directly if a roll was a hit, but I can't really wrap my head around this. It's probably a lack of sleep and stress and work combined, but I just can't brain this week, I haz teh dumb...

My documentation post was not as clear as it should have been. This feature does NOT provide cross-token scripting, or token targeting, or anything like that. It simply uses another token as a convenient storage place for macros that are used often. For example, you could write a macro that makes an attack roll and does all the mumbo-jumbo to check for critical hits etc. Instead of including that code in every single macro on every token you own, you can now have them call a shared macro stored in the Lib token. The macro statements still execute on the calling token, just as if the called macro were in the token itself.

[Rumble]

From my reading of Craig's post on the lib: tokens is that these are not tokens to represent your critters and such. They are just convenient holders for macros.

You access the macros from them but they are not supposed to be either NPC or PC tokens. IIRC, he even noted that they don't have to be visible to the players.

How you use them to modify other tokens I have no idea.

That could be (although the b46 announcement thread says that lib tokens must be visible to the player). They don't seem to be able to access any sort of properties of their own, so I assume they're just a place to cache "trusted macros." Interesting, but less useful than being able to interact with other tokens.

Though I certainly understand that inter-token coding falls squarely in the Large Can of Worms area.

Edit: Let me say "useful in a different way." A library of standard macros is pretty cool.

[applekor]

Thanks. I'm trying to paste these.

Code: Select all

4e - DM Only
----
Magma - 40 : square 40,50 
Campfire - 10 : square 10,50 
Forge - 2 : square 2,50 
Sacrificial brazier- 10 : square 10,50 
Huge or Gargantuan fire creature - 40 : square 40,50 
Large fire creature - 20 : square 20,50 
Phosphorescent fungi - 10 : square 10,50#000000 
Small fire creature - 5 : square 5,50 
Medium fire creature - 10 : square 10,50 
Fireplace/oven - 5 : square 5,50 
Tiny fire creature - 2 : square 2,50 

4e
----
Everburning - 20 : square 20,50 
Lantern - 10 : square 10,50 
Lamp - 15 : square 15,50 
Light - Wizard Cantrip - 4 : square 4,50 
Sunrod - 20 : square 20,50 
Torch - 5 : square 5,50 
Candle - 2 : square 2,50#000000

Try getting rid of the commas in your ranges (i.e. 40 50 not 40,50).

[Rumble]

FdL's going for 40.5, but that's represented with a comma in some regional settings (I don't know where FdL is from). MapTool doesn't handle that gracefully - even if he replaces it, MapTool switches it back.

[Craig]

So I'm experimenting with the calling of macros on other tokens (specifically, on a Lib:name token). I wanted to see if I could roll an attack macro on a player token, and have it call the "take damage" macro on a token called Lib:OrcFreak.

Here's what happens when I do this thing:

1. Our hero, Kalad, runs an attack macro called "Hit the Freak!" that randomly calculates some damage, and passes that number to the Lib:OrcFreak token with the following:

Code: Select all

[MACRO("takedamage@Lib:OrcFreak"): damage]

2. The TakeDamage macro on Lib:OrcFreak receives macro.args with the statement

Code: Select all

[HP = HP - macro.args]

3. Our hero, Kalad, has his HP reduced by the amount of damage passed to Lib:OrcFreak. The Lib:OrcFreak token, on the other hand, is unaffected.

From what debugging I've done, macro.args is receiving the value of damage as expected. However, it's using Kalad's properties in all calculations, rather than the Lib: token's properties.

So I assume I've either coded it improperly (entirely possible!), or I'm misunderstanding a limitation of the macro calling capability - perhaps called macros on Lib: tokens can't access their own properties, or assume that the properties being accessed are on the calling token, or something like that.

This is working as intended. The Lib:Blah tokens are only a repository for code and not supposed to be used for your monsters (after all who wants all their monsters named Lib:SomeThingOrOther). Any code executed from them is executed on the current token.
This gives you a few useful things.

• Easily transportable macro library
• Ability to create more complex macros since you can chain macro calls

For example the TK macros for 4e could be distributed as a set of Lib: tokens and then players would only need to create macro buttons that call it with something like [macro("Cleave@Lib:TK.FighterPowers"): ""].
Once you get to more complex macros it will make things easier to be able to split things up over separate macro functions.

It also allows you to create a repository of macros that are completely under GM control if you want to.

The ability to affect other tokens rather than the current one is coming, and builds on the Lib:Blah tokens, thats not to say that without it Lib:Token doesn't offer nice possibilities.

[palmer]

Edit: Bleh, I'll just go back to NOT using light, or visibility or any of that stuff at all v.v

Stop using fractional light?

[Azhrei]

Edit: Bleh, I'll just go back to NOT using light, or visibility or any of that stuff at all v.v

Stop using fractional light?

A better solution would be for MapTool to use locale-cognizant functions for parsing the numbers. I'd be willing to bet that the source code is using Integer.parseInt() instead of creating a NumberFormat object in the correct locale and using that...

(But don't ask me any more about it. I HATE working in other locales! I understand the need for it, but it's a major pain regardless!)