Preview of macro additions/changes in b51.

[Craig]

So, other than speed in "large" variable settings, is there anything that JSON does that setStrProp styled coding doesn't do?

JSON objects can contain other JSON objects which can contain other JSON objects...
You can use encode() to get 2 levels with string props but that is it (and its messy). There are a few JSON functions that are not available to string lists and properties. This is why some of the advanced options to a couple of the functions above can only be done using the JSON argument version of the function.

JSON objects can also store a greater range of characters, so they wont choke where string properties will.
Really if you are starting new macros I would say always go for the JSON path.

er Also the usefulness of json.evaluate() should not be underestimated. You can use it to store skills/powers in a JSON object and perform all the rolls with one call on the current token, then you can pass the resultant object onto another function for formatting etc.

(And what is large? My string property lists typically contain 4 to 5 variables?)

4 - 5 is not going to be much of an issue. But the performance of string lists and string property list does drop off quickly. A foreach() of a string list takes exponentially longer as the list grows O(n^2) JSON array is constant growth per element O(n). The foreach performance is similar for string property list vs JSON object too. For grabbing a random value from the array/list/object/property the string list/property has to iterate through the whole list every time, for the JSON versions this is usually not the case, and will be no worse than the list/string prop if it has to do so.

[Brigand]

At this point, why don't you move all this coding into it's own module as part of maptool that is not macro's? I like learning how to script, but typing in all the required brackets for MapTool Script is ridiculous.

All the brackets makes reading a maptool macro very hard and is much more limiting to getting new users to learn how to script in maptool than using pure javascript would be.

[trevor]

Technically the macros have grown outside their original intention.

The scripting interface to the macro functions should be deprecated and replaced with a formal javascript engine. Which is actually closer than one might think.

[Big_Mac]

WEEEEEE!!!! Trevor been a busy little beaver lately. That heavy sedative in the kids juice and moms wine is being put to excellent use. and blackmail his boss

[Craig]

Technically the macros have grown outside their original intention.

The scripting interface to the macro functions should be deprecated and replaced with a formal javascript engine. Which is actually closer than one might think.

Is it something we are likely to see in 1.3? Just curious to how close it is

[Craig]

All the brackets makes reading a maptool macro very hard and is much more limiting to getting new users to learn how to script in maptool than using pure javascript would be.

I would prefer JavaScript too, but who knows if that will even make it into 1.3? Adding JavaScript to MapTool is something that is not up to me and there is nothing I can do about it. So for people who run 1.3 this may be their only option (if JavaScript is in 1.4 only).

[DrVesuvius]

Technically the macros have grown outside their original intention.

The scripting interface to the macro functions should be deprecated and replaced with a formal javascript engine. Which is actually closer than one might think.

Can you clarify this statement please? It's being interpreted by some to mean that a lot of the macro code syntax that's been introduced in the last half dozen builds will be thrown out before 1.3 goes final.

Which, if this is truly the case, means there is no frelling way I'm going to waste any more time and effort trying to implement anything new. It sounds like I've already wasted dozens of hours learning syntax that's soon to be deprecated and writing macros that are going to be useless in a few versions' time.

Sorry, I'm all for seeing a proper Javascript implementation in MapTool, and I've already had the "If you're using anything newer than 1.2 then you can't complain if things change" lecture from the fanbois, but any extensive gutting of the macro engine is definitely throwing the baby out with the bathwater.

If 1.3 final is as near as you've been hinting for a while, please let us keep using the macros we've developed over the last couple of months. Tweak the functions however much you need, but leave the macro/scripting fundamental structure the same. Make the Javascript-only macro engine the first bullet point on the 1.4 feature list.

Dr Vesuvius
(who was going to spend the weekend writing Mutants & Masterminds macros for an upcoming game, which now looks like it may have to be canned)

[jfrazierjr]

...

If 1.3 final is as near as you've been hinting for a while, please let us keep using the macros we've developed over the last couple of months. Tweak the functions however much you need, but leave the macro/scripting fundamental structure the same. Make the Javascript-only macro engine the first bullet point on the 1.4 feature list.

I can understand your feelings. I have no idea what Trevor has in mind. What "I" would like to see is to get javascript included WITH 1.3 in something more than a "alpha" mode. I have no problem in leaving the existing stuff in 1.3 and removing it in 1.4 or later. This approach will get let people who stick with 1.3 final for a few months the ability to have their existing macros work while they work on converting to javascript over time if they need the time, while letting those that can and want to spend the time right away with getting javascript macros out in 1.3 final.

[Lindharin]

I too would like some clarification from Trevor on this, but I don't think the sky is falling on macros or the time you've spend learning to write them. In the computer industry, the term "deprecated" does not mean removed or even unsupported. For example, the use of the <b> tag for bold in HTML has been officially deprecated for years (you are supposed to use <strong> instead), but all browsers still support it and probably will for years to come. It is just a way of saying that the functionality isn't the intended way to do something any more, there is a new option that is the intended solution for the future, and that some day the deprecated feature may be removed if it causes problems with other things we want to do.

[Lindharin]

Also keep in mind that very little of the macro syntax has actually changed in recent builds. The last major addition to the macro syntax was when the [Macro():], [IF():], [FOR():], etc. commands were added.

The vast majority of recent changes have been the addition of dozens of functions that we will still need even when we have javascript. The addition of a javascript parser doesn't magically give you the ability to get a list of all token ids within 3 squares of a given point, for example. But as of b51, we'll now have a function (written in java, accessing program internal data structures), that can be called from a traditional macro and presumably can also be called from a javascript macro when we get those.

When it comes right down to it, the main thing javascript would "replace" is the syntax of your looping structures, etc. My guess is that most of the dozens of functions that have been added recently for accessing/setting tokens, buttons, etc., will still be needed in some fashion.

But that is all just a guess, until we hear more about how this will work.

[RPTroll]

I've used Maptool for a long while now and here's my opinion based on what I've seen in the past.

The current macro language will not go away but new options will be put in place that should be used and will be the official path for things going forward. I've never seen functionality on this scale completely gutted. What I have seen is the RPTools staff bend over backwards to keep the users happy. So in the end I don't think you'll have to rewrite anytime soon.

When JavaScript is introduced it will be in a small way at first so things can be tested and prodded to see what works and what doesn't . I suspect the initial version will be in the form of function calls from macros much like the macro() command does now but hopefully with a little cleaner syntax. Not slamming the current implementation, the contributors did what the could with what they had.

So I suspect the first few rounds will simply allow you to call a new macro function type that allows for return values. That way, you can slowly take your Lib:token macros and replace them with Javascript where it makes sense as the Javascript functionality improves. Those starting new will be able to code mostly in JavaScript but you'll still need the macro language to make the calls.

So I think Lindharin is dead on in his opinion.

[Azhrei]

Yep, I agree with RPTroll.

First, the goal of 1.3 going "release" (or "gold" as they say in the biz ) is to get something stable into the hands of users that is feature-complete, or at least as feature-complete as practical. There's no way the macro stuff will go away before 1.3 goes final -- that would require an awful lot of work and it's too close to the endgame to do that now.

Second, the point of 1.4 is to "tie off" the loose ends of 1.3 so that riskier development can take place on a new branch of the tree, so to speak. This leaves a solid, stable platform for people to use for gaming while developers focus on adding experimental stuff to 1.4.

This was the same approach taken with the 1.2-to-1.3 transition, although some of you may not remember it.

"Don't worry. Be happy."

[verisimilar]

These new features look great! Is it taboo to ask when we might see a build available for download, or should I just grab it from the repository?

I partially agree with Aria about the brackets. Coming from a programming background I don't find their use impeding at all, but some of their usage still remains a bit of a mystery to me... mostly when it comes to the JSON objects. This might not be the right place to ask, but could anyone explain why each was used in its particular way in one of the examples Craig posted?

Code: Select all

[getTokens("json", '{npc:true,
                         unsetStates:["Dead"],
                         range: { from:1, upto:1, distancePerCell: 0}
                        }'
)]

I guess I'm most confused about why unsetStates' value is surrounded by square brackets, yet range's values are surround by curled brackets. Is it because unsetStates appears to store an JSON array, and range appears to store a JSON object?

[jfrazierjr]

These new features look great! Is it taboo to ask when we might see a build available for download, or should I just grab it from the repository?

I partially agree with Aria about the brackets. Coming from a programming background I don't find their use impeding at all, but some of their usage still remains a bit of a mystery to me... mostly when it comes to the JSON objects. This might not be the right place to ask, but could anyone explain why each was used in its particular way in one of the examples Craig posted?

Code: Select all

[getTokens("json", '{npc:true,
                         unsetStates:["Dead"],
                         range: { from:1, upto:1, distancePerCell: 0}
                        }'
)]

I guess I'm most confused about why unsetStates' value is surrounded by square brackets, yet range's values are surround by curled brackets. Is it because unsetStates appears to store an JSON array, and range appears to store a JSON object?

EDIT.... did not read your last sentence.. but yea.. thats pretty much it...

That part's easy. unset states takes an array of values (at least I assume given the context. JSON uses [] to "denote" an array. Range takes a hash/assosiative array/map/dictionary/key-value pair/whatever you want to call it, and JSON denotes that type of value with {}. Note sure of other languages, but perl has been this way for years, long before JSON was around. Note that my understanding is that JSON is just a formal syntax for expressing objects in a stringified way that can be stored in a file and then evaluated to rebuilt objects from the string form. This is much in the same way as objects can be transformed to xml and xml can then be parsed back in to the target objects.

[Craig]

[getTokens("json", '{npc:true,
unsetStates:["Dead"],
range: { from:1, upto:1, distancePerCell: 0}
}'

I guess I'm most confused about why unsetStates' value is surrounded by square brackets, yet range's values are surround by curled brackets. Is it because unsetStates appears to store an JSON array, and range appears to store a JSON object?

Correct. unsetStates is an array of state names (in this case it has only one item) and range is another JSON object.

JSON stands for JavaScript Object Notation, you are just defining objects the same way you would if you were using JavaScript.
So objects are surrounded by { } and arrays by [].