RPTools.net

Not at all, it remains on my todo list, unfortuneatly for that list I am also GMing the Return to the Temple of Elemental Evil, so I have to get my weekly prep done for that before I get to add features or document. Those darn demanding players

fair enough, that's understandable. i think i got what i need on there and have worked it out. looking forward to seeing more of your work, would you care to reveal more of your to do list?

Mal

Imarkus: Thanx i had seen the edit macros, I assumed that they were just shortcuts to the setup options..Ill play with them and see what I was missing. Thanx for the help.

Edit: 1st that is what i was looking for. It was in front of my face.

Quesstion: What does "#ERR" Mean? And this shows up in one of the colums in the char. sht.(in the UMD colum and a few others) "#ERR00"

Question: the little mini char sheet that pops up when U mouse over a token, Can U shut it off or make it only viewable by owner?

That's a standard feature of MapTool controlled by the Campaign Properties. It's called the "statcheet". The image that appears next to it is the "token image" unless a separate "portrait" image was provided on the token editor's Config tab.

Go to Edit -> Campaign Properties... and read the notes at the bottom of the first tab. Select one of the property types on the left (such as Pathfinder) and compares the notes to what you see in the text box on the right.

Az: Thanx again. That did what I was looking to do.

Sample Campaign File for MapTool 1.3.b49 UPDATED Jan 26

1.3b49_03
===============

• Handout macro -- Select a token, this prompts for Image/Portrait/Handout then sends a link to chat. Players that click the link get the image in a dialog.
• Enlarge/Reduce macro -- Runs on all selected tokens. Changes image size, and adjusts StrMod & DexMod. Will not reduce Strength+StrMod/Dexterity+DexMod to less than 1 (so this can cause erroneous Mod entries as you change size again if your starting stat was very low). Does not modify the Weapon damage entry as the tables for this are too ugly... so the user will have to modify there weapon.
• ConditionToggle -- Smaller icons in the selection list so fits on screens better
• HP Change & HP Dying -- Move NPC tokens to Object layer if Dead
• Revamped Timer Token -- On Setup dialog there is now a Target tab with a list of visible tokens. Any state image selected for the Timer can be additionally set on the target tokens. When the timer runs out the state images will be cleared. Note that this does not change any temporary modifiers or stats, it simply applies/removes the state icon.
• Conditions Table -- Re-defined row 0 where I store the number of conditions (currently 28) so the condition list can be programatically retrieved.
• Property Set Changes -- Renamed "Creature" to "DnD35" (I left in Creature for Legacy campaign file support). Added properties to the "Effect" property set to support the new Timer token funcitonality.
• setupBlank__ -- These macros now verify the correct Property Set has been selected before they will run.

In my most recent gaming session we heavily used the Timer token. From this I saw a few areas I could improve it so have added those in here.

Quicky Timer Token Guide:

Copy (Ctrl-C) the token then Paste a copy on the mat for each player, then edit the Ownership of these copies and assign one to each player. Now when player casts a spell with a track-able duration, they can copy-paste their token and setup a timer.

Run the SetupTimer macro that is on the token (the token macros are on the token, not in the Campaign Macro window). A unique name must be entered in the Spell Name field. The order in the initiative goes in the Initiative field (for example if Merlin's initiative is 12.02 and he casts a Daze, then set the Daze to 12.021). Finally enter the duration of the spell in rounds.

There are extra goodies available as well. If you select a Condition, and you select target tokens, the SetupTimer macro can set the state icons on the Timer and the targeted tokens.

When the Timer receives initiative, the Next macro on the token (NOT the Next button in the initiative panel) should be pressed. This will decrement the timer bar on the Timer token. If you forget on a middle turn it is no big deal, but it is important to remember to use the Next macro on the final round of the effect. On that round the Timer will be removed from the initiative list and you will be given the option to remove the state image from the targeted tokens.

Awesome, I. Again, thank you for the effort.

great work as usual.
will have to try it out soon
just a quick note, the macros dont know how to deal with fractions/decimals (which was a pain when trying to input the info for a tiny monstorous spider). i think it's something to do with maptools tho. but it's good to let you know anyway.

Mal

Can you give me an example? I have used "Level-1.5" without issue for ECL...

His account here doesn't display where he's from, but I'm betting that he's talking about locale-specific numeric data. I.e. how dots are sometimes commas and commas are sometimes dots in other locales.

And yes, this is a general problem in MapTool (should be corrected now), but all input needs to be treated using the locale-correct techniques, and I'm betting that the macro functions don't.

Hopefully, there is a single place in MapTool where a class can be dropped to do all the locale-specific stuff, then other parts of the code can invoke it.

(Hmm, it just occurred to me that my patches to the I18N class that Craig wanted for doing a properties file lookup followed by formatting would probably fit the bill for output, but not input. Maybe that's the correct place to do input processing as well? double-Hmm...)

There are actually very few macro functions that do any conversion to a number (but there are a few), there are probably quite a few more that convert a number to a string. Those that do convert though are forced to do it in a non locale specific way (more details on this below).



You didn't really think it would be that easy now did you?
Most of the string to number parsing occurs in the parser project --not MapTool-- there are some exceptions --getProperty, getLibProperty, also I think in MapToolVariableResolver, some of the json functions-- conversely most of the number to string conversion happens in MapTool.

So the change would have to occur in the Parser project --possibly DiceLib too-- and MapTool at the same time. This will also affect DiceTool etc too if you wanted to keep them using the latest jars for parser/dicelib...

This would of course also introduce difficulties sharing campaigns that use decimals across some different locales, but that is a procedural issue rather than a coding one. Oh and don't forget breaking forward compatibility of campaigns in certain locales too. The campaign would still load fine but decimal numbers would cause parser errors when macros are run.

Hmm, interesting point.

Ideally, numbers would be stored in an internal format (binary?) and externalized using a "standard" format, whatever that might be. Perhaps it would be as simple as recording the locale in the XML data stream and using that locale only to read the values. The only place that locale specifics would be involved is in interactive situations, such as prompts requesting numeric input or the Sight or Light tabs...

From a practical standpoint, it would require a fair amount of work; the aforementioned Sight and Light tabs would need to be rewritten to use a structure that stores numbers instead of storing them as strings and reparsing all the time. We already have an incompatibility because someone using an English campaign can't load it into MapTool running in a French locale, for example.

If we use the example of storing the locale into the XML, then since numbers are stored as strings, the locale information must become part of the data so that it can be interpreted correctly. As new values are entered, they would use the current locale of the machine and be tagged as such.

Wow, that's ugly.

Hmm. I still think that all input functions that prompt the user should respect locale settings...

Input functions/output for the user should respect locale. Storing numbers in binary within the program, and when ever externalizing to XML using the internal java format (i.e. that of Integer.parseInt()). And yes that would mean that things like light input etc would have to be changed so they are not just a string. You shouldn't need to store the local within the campaign that would mean you may end up having to do other conversions, just write it out in the internal format generally those XML files are not supposed to be a primary method of user interaction with the objects

hmmm, well as imarkus should know, i'm from england so i was using dots.

i'll have a look on the 1.3.50b and see if i can get the right format, if not i'll post an example.

Mal

Hello,

Using latest campaign file, and b50 (though I tried the same thing on b49 and received the same results)

Add token, change config to "Pathfinder" than run PF setup. Everything looks good except the AC.

Ex. Riding Dog http://www.d20srd.org/srd/monsters/dogRiding.htm
When I was prompted for armor I put in "16" and this is what is showing: 28/12/26
Any ideas???

* Also, for weapon dmg, do we simply add what is present. For example, the dog above has 1d6+3 dmg for its bite. Can we just put that straight into the weapon dmg? I sure hope so, because more complicated monsters it gets crazy trying to figure out where the bonuses are coming from.

Thanks for any help!
E