1.3b42 Progress

[trevor]

Will tokens and other settings also be moving to a JSON config? Please?

We'd be moving away from xstream/xml and towards json for all the save files

[trevor]

Trevor, do you know how far along it is?

It's not hooked up to the command processor yet.

giliath will post some instructions when he gets to a point when you can start using it. Then I'll slap a UI on it.

[BigO]

Update
giliath and I discussed some features he's been working on. Wanted to give you guys an update.

Currently I'm primarily focused on bug fixes, mostly light and sight stuff.

In the mean time, he's been working on integrating in a formal javascript engine. The way it's going to work initially is that the GM can create/import javascript functions that can be called just like all the other functions. We're creating an API that the javascript can call to get access to tokens and stuff.

One of the interesting new paths as of today is that to help facilitate that framework giliath will be adding JSON libraries. We then discussed using JSON to do the campaign save files instead of XML. That will make creating version updates even easier (which means it'll be likely to actually happen!). The nice thing is that existing campaigns will continue to work and will be automatically converted to JSON. Those that have scripts that work with the XML will be happy to know that JSON is really not all that different so your scripts should very easily be migrated to the new format.

I don't know when that change will take place, it's whenever giliath finishes his work on it. But wanted to give you an idea of the direction we're headed.

Personally I think it's very exciting. Imagine being able to write javascript functions that are callable directly from the command line or token macro. After the first pass we'll be looking at including triggers that you can write callbacks for, e.g. onTokenMove() or onNewToken(), or whatever. Powerful powerful stuff.

Woo Hoo!

(drink)

[plothos]

Can you give some idea what sort of doors this is opening for users? I have no idea how to write javascript functions, of course, but more to the point I have no idea what sort of things such functions can do, so the news that they're in our future is soaring over my head.

[Lindharin]

Javascript is the de-facto scripting language of the internet. It is easier to say what Javascript can't do, rather than what it can. You probably are using javascript (without knowing it) on most of the web sites you visit, in some way or other.

It has all the features of any normal programming language: variables, functions, flow control with if/then/else and for loops, etc. It has string parsing (both through built-in functions and regular expressions) allowing for easy use of substrings, pattern matching, etc. It is pseudo-object oriented. It isn't fully object oriented, but it can fake it really well, which means it is fairly straight-forward for the coders on here to start building a library of objects that we can all use and extend to easily support a variety of game systems. It can be used with events to have functions automatically trigger when something happens (like anytime a token moves, etc.)

In terms of what it means for MapTools in specific, it will make coding (and maintaining) macros MUCH easier. You can have a pre-defined set of functions to handle your attack rolls, damage, hit point tracking, etc, etc, and those functions only need to be defined once in one central place. Then individual token macros will be really simple, and just call those functions. Something like: [JavascriptAttackFunction()] could run an entire script to figure out attack, damage, etc. And because that function is maintained centrally in one place (presumably either in your GM's campaign properties or an external file), it doesn't need to be put into each token button individually, and more importantly, it can be updated just once without needing to update each token macro individually.

It is as big of an improvement over our current macros as it was when the current macros were given the ability to access and set token properties. It is a really big step forward.

[Lindharin]

A question for Giliath: I see where you load the local javascript files in the script manager class. Any chance that will eventually provide support for http access to load javascript files from a remote web server? Then a community script file for a game system could be maintained either here or on an individual's web server and be used by anyone who wants to, without needing to download it or copy/paste into a UI.

[BigO]

A question for Giliath: I see where you load the local javascript files in the script manager class. Any chance that will eventually provide support for http access to load javascript files from a remote web server? Then a community script file for a game system could be maintained either here or on an individual's web server and be used by anyone who wants to, without needing to download it or copy/paste into a UI.

That's a great idea.

[Craig]

A question for Giliath: I see where you load the local javascript files in the script manager class. Any chance that will eventually provide support for http access to load javascript files from a remote web server? Then a community script file for a game system could be maintained either here or on an individual's web server and be used by anyone who wants to, without needing to download it or copy/paste into a UI.

That's a great idea.

There are some issues if you go down the public/community script server route. Your macro library is at the mercy of the owner, they update you update no choice or chance to test, you can implment some sort of standard to alleviate this, but you then have to enforce it. Server is down while you run your game you can't play...

On your own webserer doesn't have this issue, but then you can't share your campaigns.

Although the other option is to load the scripts into the campaign file (they would be small compared to the graphical assets so its not that much more data, you can share your campaigns and you know the script you added is the script you are running without having to worry about is the remote server up or did someone change the script.

[thecyberwolfe]

Woo Hoo!

(drink)

Something tells me giliath won't be buying any of his own drinks for a while.

[Lindharin]

There are some issues if you go down the public/community script server route. Your macro library is at the mercy of the owner, they update you update no choice or chance to test, you can implment some sort of standard to alleviate this, but you then have to enforce it. Server is down while you run your game you can't play...

I agree these are issues, but they are easily solved. For example, the files get put on the server with a version number appended. Unless the end user chooses to adjust the URL in their client, they'll keep using the old version if that is what they are happy with. That's how the YUI library is handled, for example. Server down can be alleviated by having it hosted here and a mirror (manual or automated) on another web server. Certainly they are things to address, but I still think it would be a useful option. Not required, and not something to delay release over, but useful at some point down the road.

[trevor]

A question for Giliath: I see where you load the local javascript files in the script manager class. Any chance that will eventually provide support for http access to load javascript files from a remote web server? Then a community script file for a game system could be maintained either here or on an individual's web server and be used by anyone who wants to, without needing to download it or copy/paste into a UI.

My initial knee jerk reaction was that we won't ever support having campaign content/configuration stored outside the campaign itself. But then it occurred to me, as was mentioned, that at some future point we could make it check versions, and even give the GM a notice if there's an update available for a specific script they've installed. But I imagine that won't show up for a while.

[giliath]

A question for Giliath: I see where you load the local javascript files in the script manager class. Any chance that will eventually provide support for http access to load javascript files from a remote web server? Then a community script file for a game system could be maintained either here or on an individual's web server and be used by anyone who wants to, without needing to download it or copy/paste into a UI.

That will most likely be a UI level thing, but the file will have to be local (downloaded already) before it gets to the ScriptManager.

I imagine that the UI Trevor mentioned will be able to contain something like this where you say, I want to load a javascript file and your sources are (file, copy-paste, URL). Then it will load it into your campaign. Later we could potentially do auto-update or at least auto-notify of new versions, but initially we probably won't have anything like that.

As several people mentioned, it is probably not a good idea to auto-update a javascript file. What if you are using it the way the author didn't intend and he changes something which breaks your campaign? Personally I would rather see GMs get to choose when to update their javascript.

Anyone who wants to play around with the early stages of the implementation (and I mean early) can play around with the test cases I am writing to do the development in. It won't get hooked into MapTool proper or the macro engine for a little while because I don't want a partially implemented version to leak when Trevor does his releases and I am no where near ready.

Just a couple of things about design decisions.

1) Users won't be able to write javascript, only call javascript functions the GM has pre-loaded. We talked a lot about this and it seemed pretty dangerous because we don't have an extensive permission system in place that would prevent users from doing stuff they shouldn't.

2) Javascript is only called from the parser. Those who have looked at the code know that macros call into the ExpressionParser which wraps the Parser. Initially Javascript will only be exposable as functions in the parser. If you read this far, say woo hoo. As Trevor mentioned, later we will add other hooks to call javascript depending on events. This decision means that you won't have javascript tied directly to a token, but it will protect the GMs a little because users won't be able to drop javascript into the system without their prior and very specific approval.

3) Some framework will be implemented so that you can register GM-only functions. This is so that the GM can write macros to automate certain things they don't want their players to do. I am not sure what this will look like at this point and this may not be implemented in the first release.

[Lindharin]

I just had another thought about that, Trevor. Even if you do not want to expose it to end users for design reasons, having the ability to load remote javascript may be useful for internal purposes. I noticed that some of the EXT javascript library is being used. As of version 2.1 of EXT, I do not think it can be redistributed as part of the internal code of another project. They tightened up their licensing quite a bit with 2.1. However, I believe you could load the javascript library at run-time off of a web server without licensing issues (that's what browsers do, after all). I'm not an expert on open source licensing, though, so don't take my word for either piece of that.

And eventually exposing that capability to end users would let us make use of those public javascript libraries. I use EXT myself, but I've also played around with Dojo and YUI, and there are many others. If we have the ability to open remote javascript files then those libraries could be used too.

Again, that is a LOW priority. I'm certainly not suggesting that this should delay release of the javascript functionality, or should be done without considering the ramifications. I just wanted to mention it now so that it could be in the developers minds while they are working to make sure the framework could support it at some point in the future.

** Edit: Whoops, simultaneous post - I'm a slow writer sometimes. Thanks for the info Giliath. **

[applekor]

This decision means that you won't have javascript tied directly to a token, but it will protect the GMs a little because users won't be able to drop javascript into the system without their prior and very specific approval.

Food for thought (not necessarily reply):

What about covering permissions by making up separate interfaces to pass to the scripting engine?

For example, make a ScriptableSecureToken interface for the Token base class that only exposes player-level methods and properties. Then have the parser decide whether to pass token data through this interface or the full token class to and from the scripting engine based on the currentPlayer.isGM() method.

[Azhrei]

So what's the plan with storing images in JSON? Would the image be converted to some encoded format and then the decode function would be called inside the object definition?

Just curious. I suppose that binaries could be somehow "attached" to the JSON and referenced, but I'm not sure how. For example, the token could be the JSON data, plus an assets directory, like it is now. But the JSON would contain URLs such as "asset://long-string-digits". When the token is loaded, the assets directory would be copied to MapTool's assetcache...

JSON is a cool idea. It allows for easier building of UI tools to manipulate the token data since a web page can easily host such tools. I can see some jQuery in my future that allows drag-n-drop of token macros form a "library" of code into a token...