RPTools.net

I was going to do the build yesterday but I had a crazy bad headache last night, so I postponed it. I'll keep fixing some more bugs today and do a build late late tonight.

Here is the current changelog:

Build 49
* Optimize token move clipping on player view
* General rendering optimizations
* Toggle to show "light" icon on tokens that have a light source
* Fix bug: attempt to auto correct when loading a campaign with blank token z-order
* Fix bug: two-image health bars are not scaling their image

Contributed by applekor
* Fix bug: Clear Macro Group issue
* Clarification: Two or more tokens with a common macro now add that macro to the common macro groups.
* Bug Fix: Common macros in the Selection panel now function as they did in b41. If you execute a common macro, it looks for the macro of the same name on each selected token and only executes those matching individual macros against their respective tokens. Tokens without a matching macro are not executed against. If any matching individual macro has "Apply to Selected Tokens" checked, it should still execute against ALL selected tokens.
* New Feature: An "Options" tab has been added to the macro editor dialog. The macro details now appear on a "Details" tab.
* New Feature: The criteria for comparing macro details when determining similarity for populating common macros on the Selection panel and for drag-and-drop operations are no longer strictly hard coded. The user can choose to have individual macros ignore Group, Sort Prefix, Command, Include Label, Auto Execute, and/or Apply to Selected Tokens when comparing against other macros by clearing respective check boxes on the new "Options" tab of the macro's editor dialog.
* New Feature: GM's can designate any individual macro as player editable/non-editable by setting/clearing a new check box in the new "Options" tab of the macro's editor dialog. Certain popup menu items are also made unavailable to players when this check box is set.
* New/Returning Feature: Common macro buttons/groups now have popup menus on right-clicks. Through this interface change, macros can be added/removed to all selected tokens simultaneously. Additionally, macro import/export features have been extended to common macros.
* New Feature: When hovering over a macro button, tokens that would be affected by execution of the macro are now highlighted with a new, thicker, red & green selection border. This feature isn't fully implemented yet for the Impersonate panel. The Global, Campaign, and Selection panels appear to have full functionality.

Contributed by Craig Wisniewski
Bug fixes
* Several fixes for line parser quote issues in [ ]
* Removed the [] {} [option: ] matching regex and coded the search in java
(the regex had errors and correcting it was getting ridiculas.
* Previously doing something like [a = "[" + "1d6" + "]"] [r:a] would work
but on certain strings or if variables were unresolved the whole macro
would die with an exception. Now it works, and is the string is not able
to be resolved the string itself is returned. This is also only able to
be done with full formating in a trusted macro to discourage cheating.
* setProperty()/setLibProperty() no longer causes exceptions in token
property dialog
* calling abort() from a macro link catches the abort exception correctly
so there will be no message in chat anymore.
* input and temporary meta tags should work in all cases now.
* Frames that are updated because of selection/impersonation/token change
will no longer maximise.
* Removed a few cheating expliots that provided easy means of faking rolls.
* onChangeToken call back for dialog works but is discourage where you can
find another method of doing it.
* Much improved error messages when trying to call undefied macros on
lib:tokens or trying to call a macro on a lib:token that does not exist.

New Functions.
* Functions to help build html
* evalMacro()/execMacro() can be used to execute macros and get the
resultant html since it is a lot easier to use macro output to generate
html than building a string. There are some tool tip gotchyas to look
out for which are described in the detaled notes. These are a trusted
macro only function so players can not call them directly.

* Retrieving token lists
* getVisibleTorkens()/getVisibleTokenNames() gets a list of the tokens
that are visible to the client when vision is taken into account.

* Frame/Dialog related functions
isDialogVisible()
isFrameVisible()
closeDialog()

* String
startsWith()/endsWith()

* Auto executeable macro links.
If a macro link points to a trusted macro and that macro has the autoexec
flag selected then the macro will be automactically run (i.e. MapTool will
run the macro without the user having to click on the links). The GM gets
to define exactly what can be auto run so this should head off any player
shenanigans.

* All output target available in macro links (works like say)

* String Property/String List compliment.
Since String properties and string lists have many limitations which people
have been running into there is now a third option. Macros can create and
manipulate json objects (they are just objects no javascript is ever
ever executed at any point, infact as far as macros are concered they are
just strings with special formatting). JSON was selected as the method
for storing the data to provide you with a way to store your data that
can be easily manipulated in the future and for its convenience.


* The following functions will return a json array or object if the
optional delim argument is "json".
getPropertyNames(delim]), getAllPropertyNames(type [, delim]),
getOwners(delim), getLights(type [, delim]), getMacros(delim),
getMacroProps(index, [, delim]), getMacroIndexes(name [, [delim]]),
getTokens([delim]), getTokenNames([delim]), getSelected([delim]),
getSelectedNames([delim]), getPCs([delim]), getPCNames([delim]),
getNPCs([delim]), getNPCNames([delim]), getExposedTokens([delim]),
getExposedTokenNames([delim]), getVisibleTokens([delim]),
getVisibleTokenNames([delim]), getWithState(state [,delim]),
getWithStateNames(state [,delim]), getOwned(name [,delim]),
getOwnedNames(state [,delim]), getSpeechNames([delim])

* [foreach(): ] works with json objects and arrays (there is no
need to tell foreach() which type of string you are passing it
is able to determine this.

* setMacroProps(button, props)
Accepts a json object with the properties for props, as with
foreach() the function is able to determine if you are passing
a json object or string property list.

* See the detailed post for more information on the functions for
manipulating json object strings.

* You can catch calls to non defined macros on a lib:Token in a macro called
!!unknown-macro!!. getMacroName() can be used to detrmine the name of the
macro that was called. You can use this to provide help for your lib:token
or macros that take arguments from their name, such as.
getWeaponsFromInvetory()
addLongswordToWeapons() (etc.)

* Start of support for "fully" trusted macros, where only the GM can edit the
buttons, hoping to complete this for next build.

Anyone with the source checked out is encouraged to update and test for bugs.

Thanks !

You want to comment out that println() on line 157 of EditTokenDialog.java?

Does this has to do with the long macros going bump?

Yes... Fixed no... better yes.

There are a several problems that cause long macros to go boom. Some of them are real difficult to address and I could not finish a patch to fix them before this build (I might not finish it before next build depending on when that is), so I quickly created a fix that addresses some of the problems for this patch.

I have to wonder about simply having the stack size increased by default. Even one bump seems to add a lot of elbow room for things. Given how much ram modern machines run with, bumping stack won't impact performance much, but will loosen up macros.

Seriously, it's like, 10 threads @ 1/4 meg each (default). Make that a half meg (512k) and you're still only using 5 whole megabytes.

There are clock programs that use more memory than that.

Bump itin the .bat and .sh, bump it in the webstart and let everyone be happy

That too is only a short term solution. The stack required increases exponentially with the complexity of the macro so people will soon be going past the next limit. Also at the moment { } blocks really slow down the parsing of your macro anything that would blow out the normal stack can be very slow on a slower computer, increasing the stack size to allow for complicated macros would mean more macros that are even slower for those on slower computers. There are a lot of issues with how [options: ] are handled and it is better to address all these issues than put in a band aid fix for just the stack issue

Thank you Craig. My particular macro is just over the limit (I think) so any fix will give the edge I need.

Craig's posts have convinced me that an arms race between macro complexity and stack sizes isn't something we want to get into, especially since the problem is reduced if we follow some good coding practices anyway.

However, I still believe that MapTools should explicitly set the stack size to at least 512K, just so we have a consistent environment. At the moment, some systems default to lower than that (256k presumably), while others seem to default to the 512k that is supposed to be the default. Until we explicitly set a consistent stack size, people working on systems with higher defaults will be creating macros that some portion of the user base cannot use, and forcing them to downgrade their stack size to test every moderate-to-complex macro they want to share doesn't seem reasonable to me.

I agree with you we don't need to increase the stack size, though it would probably be a good idea like you said to have MT default to 512K.

I've done a lot of complex things with macros so far and have never had a problem that could only be solved with stack size increase. I will admit that my system is set to the default 512K and until the stack size issue seem to show up in the forums I didn't even though others were running on different stack sizes.

On the rare case that one of my macros does run into the stack size limit I simply rework it and things run fine. Heck just for fun I took some time out set a batch file to run MT in 256K stack size then starting running some of my new macros. Only a couple had a problem and wouldn't run but some minor reworks and they were working fine in 256k environment.

The point of all this is you really don't need to increase the stack size and with some good coding you can get your macros running in even the low stack environment.

I would really like to have [ ] default back to expanded output. I want to be able to type [1d20] in my chat window and have it output the whole darn thing. I don't want to type [e: 1d20] every darn time. I'm still pissed this was changed from the way it used to always be.

Oooor you could set a global macro to [e:1d20], make it non auto executable and asign it a hot key. You don't even need to type [1d20] anymore!

You're missing the point. I want to be able to type [1d20+whatever] and other sizes of dice in my emotes and DM text. I also want { } to default to tooltip rolls like they were originally intended. All this macro code crap has ruined my way of using MapTool.

You could go back to build 38 or so (I think that was before { } changed).



Edit: nope, sorry. In b38, { } is "plain output".