MapTool 1.4

Progress reports and musings from the developers on the current gaming tools.

Moderators: dorpond, trevor, Azhrei

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.4

Post by Azhrei »

jfrazierjr wrote:Azhrei, I still plan to modify the IF stuff based on our talks, so give me at least until Sunday before you do a second patch... of course, I would like to have you and/or Dorpond do some heaving testing on it once I have the patch ready....
I can wait. A couple of these reports will take some time to test. And one of them (a drag/drop issue) will need some testing on Windows and Linux and I don't have development environments installed in those virtual machines so it'll be a bit time-consuming.

I'm going to be traveling on Sunday for a gig next week. That means it's unlikely there would be a build Sunday night, but Monday night is a definite possibility.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: MapTool 1.4

Post by jfrazierjr »

Azhrei wrote:
jfrazierjr wrote:Azhrei, I still plan to modify the IF stuff based on our talks, so give me at least until Sunday before you do a second patch... of course, I would like to have you and/or Dorpond do some heaving testing on it once I have the patch ready....
I can wait. A couple of these reports will take some time to test. And one of them (a drag/drop issue) will need some testing on Windows and Linux and I don't have development environments installed in those virtual machines so it'll be a bit time-consuming.

I'm going to be traveling on Sunday for a gig next week. That means it's unlikely there would be a build Sunday night, but Monday night is a definite possibility.
Cool.. I have a game Sat, so I HOPE to finish up coding and get some testing before then so I can do my prep. I have been REALLY slack, so I am quite a bit behind....
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

msilvernail
Kobold
Posts: 6
Joined: Sun Jul 26, 2009 12:34 am

Re: MapTool 1.4

Post by msilvernail »

Craig wrote:Macro Language Changes
GM's will be able to add macro libraries written in JavaScript -- only the GM, the players will not have access to JavaScript code in the campaign so that the GM can still control the game and this will remove a lot of the confusion over trusted functions. The GM will be able to decide (or let the library defaults decide) which functions the players can call in their macros using the [ ] / { } syntax the way they call user defined functions today. The complicated parts of the old macro syntax -- looping, conditional branching, code blocks -- will not be carried over, simple expressions such as [2d20 + 2 + strMod + bonus] will still work.
I'm a bit confused and concerned about this. Are you saying players won't be able to write macros in JavaScript no matter what settings the GM chooses, and would be limited to completely trivial (no conditionals?!) macros? A move to centralized GM control without a setting to disable it worries me, if I'm reading you correctly.

I understand that people have been moving largely to Frameworks to run their games, but our group consists of folks who know how to code and like to customize their own macros, and our GM trusts us to not do anything stupid. I wrote the "framework" we use for D&D 4e - it primarily consists of a macro which generates individual token macros for powers, as a foundation for them to then further customize as their needs dictate. Basically a tool instead of a centralized all-inclusive Framework, and it has worked extremely well for us. Just a bit of perspective on where I'm coming from, and why this would be a major loss of functionality for some users... Switching to JavaScript, we're looking forward to. Changing the way we use MapTool entirely, not so much.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.4

Post by Azhrei »

msilvernail wrote:Are you saying players won't be able to write macros in JavaScript no matter what settings the GM chooses, and would be limited to completely trivial (no conditionals?!) macros?
Correct.
I understand that people have been moving largely to Frameworks to run their games, but our group consists of folks who know how to code and like to customize their own macros, and our GM trusts us to not do anything stupid.
I'm in essentially this same boat. I will often write macros during the game session and I'd like to be able to use them during that session. It's a bit of a pain for the GM if they need to somehow "bless" each creation before I can use it.

We (the dev-team) haven't discussed this particular issue in much detail. I'm waiting to see how things shake out.

But be aware that the JavaScript macros will have much more power than the current MTscript macros have now. The JS engine provides access to any public classes and methods (by default) and restricting access would require MapTool to create a lot of new code (turning off importPackage() and importClass(), adding a wrapper around individual pieces that we want JS to be able to access, then creating a lookup for everything we want excluded using ).

Java programmers interested in seeing some examples of what the Java code will look like when interfacing with JS should look here. It's not a huge document, but it gives a good overview of how things will be done.

msilvernail
Kobold
Posts: 6
Joined: Sun Jul 26, 2009 12:34 am

Re: MapTool 1.4

Post by msilvernail »

Azhrei wrote:I'm in essentially this same boat. I will often write macros during the game session and I'd like to be able to use them during that session. It's a bit of a pain for the GM if they need to somehow "bless" each creation before I can use it.
Ah good, I shall rest assured that the dev team is aware of the issue then. :)
Azhrei wrote:But be aware that the JavaScript macros will have much more power than the current MTscript macros have now. The JS engine provides access to any public classes and methods (by default) and restricting access would require MapTool to create a lot of new code (turning off importPackage() and importClass(), adding a wrapper around individual pieces that we want JS to be able to access, then creating a lookup for everything we want excluded using ).
Thanks for the explanation. Players trashing a campaign is one thing, trashing the host's file system is quite another. Hrm...

User avatar
Scubba
Cave Troll
Posts: 90
Joined: Fri Oct 30, 2009 12:47 pm
Location: Oakland, CA

Re: MapTool 1.4

Post by Scubba »

Azhrei wrote:But be aware that the JavaScript macros will have much more power than the current MTscript macros have now. The JS engine provides access to any public classes and methods (by default) and restricting access would require MapTool to create a lot of new code (turning off importPackage() and importClass(), adding a wrapper around individual pieces that we want JS to be able to access, then creating a lookup for everything we want excluded using ).

Java programmers interested in seeing some examples of what the Java code will look like when interfacing with JS should look here. It's not a huge document, but it gives a good overview of how things will be done.
OK, I think I finally grasped the enormity of what that means. Suddenly the whole app is scriptable. Suddenly your Javadoc becomes the scripting API. *drool*

On the other hand, suddenly people are exposed to the warts and weirdnesses that years of open-source development wreaks on a codebase. Are there plans to somehow design & demarcate private/non-exported packages?

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.4

Post by Azhrei »

msilvernail wrote:Thanks for the explanation. Players trashing a campaign is one thing, trashing the host's file system is quite another. Hrm...
No problem.

I think we're going to have to do some "containment" work. Using importClass() the JS code could get access to the java.io package and hence, access to the local filesystem. By restricting the JS code to just certain classes, we can allow or disallow this at the GM's discretion. But that means adding a lot of wrapper code.
Scubba wrote:On the other hand, suddenly people are exposed to the warts and weirdnesses that years of open-source development wreaks on a codebase. Are there plans to somehow design & demarcate private/non-exported packages?
Warts? What warts?

;)

The JS code only sees what we expose. The problem is that exposing methods means another layer of code and we'd rather keep that to a minimum. It's possible to add JS-specific methods with names like jsGetProperty(), but that means adding engine-specific code and I don't want to do it.

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool 1.4

Post by Craig »

msilvernail wrote:
Craig wrote:Macro Language Changes
GM's will be able to add macro libraries written in JavaScript -- only the GM, the players will not have access to JavaScript code in the campaign so that the GM can still control the game and this will remove a lot of the confusion over trusted functions. The GM will be able to decide (or let the library defaults decide) which functions the players can call in their macros using the [ ] / { } syntax the way they call user defined functions today. The complicated parts of the old macro syntax -- looping, conditional branching, code blocks -- will not be carried over, simple expressions such as [2d20 + 2 + strMod + bonus] will still work.
I'm a bit confused and concerned about this. Are you saying players won't be able to write macros in JavaScript no matter what settings the GM chooses, and would be limited to completely trivial (no conditionals?!) macros? A move to centralized GM control without a setting to disable it worries me, if I'm reading you correctly.
Correct. Only the GM will be able to load JavaScript macros/libraries. If your GM trusts you to make macros then it wont be hard for you to send the JavaScript and them to load it :) Essentially since there will be not be trusted/non trusted functions because it causes too much headaches only GMs will be able to load JavaScript. This is nothing new by the way it was always the way it was intended to be implemented right back to when Trevor was originally thinking about adding it. Adding a flag that would allow anyone to make JavaScript macros would lead to headaches I don't want to support -- with all the questions about why is it this way and all the other crud that has to be added into the code to account for such and such conditions etc, so don't hold your breath too much hoping for a change in this. :)

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MapTool 1.4

Post by Craig »

Azhrei wrote: The JS code only sees what we expose. The problem is that exposing methods means another layer of code and we'd rather keep that to a minimum. It's possible to add JS-specific methods with names like jsGetProperty(), but that means adding engine-specific code and I don't want to do it.
This is unavoidable, since the API code will have to massage data going between MapTool and JavaScript and back again. And in any case the JavaScript macro system will have to be sandboxed so that it can't mess with the internals of MapTool and only go through a well defined API.

msilvernail
Kobold
Posts: 6
Joined: Sun Jul 26, 2009 12:34 am

Re: MapTool 1.4

Post by msilvernail »

Craig wrote:Adding a flag that would allow anyone to make JavaScript macros would lead to headaches I don't want to support -- with all the questions about why is it this way and all the other crud that has to be added into the code to account for such and such conditions etc, so don't hold your breath too much hoping for a change in this. :)
Actually now that I've had some time to think about it, I'm not too concerned. As long as you still include an analogue of the current metamacro functions, if the new work flow turns out to be too much bother I can always write a GM-approved macro editor. That's the beauty of powerful, flexible scripting.

It would involve enough work that I don't think anyone would accuse you of supporting it directly, and anything malicious that could be done with a player-accessible macro editor could be done much more directly if the editor (or any other code) is approved carte blanche. As a bonus it wouldn't even have to be modal, so I could still take my turn while tweaking code! Consider my breathing resumed. :wink:

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.4

Post by Azhrei »

Craig wrote:This is unavoidable, since the API code will have to massage data going between MapTool and JavaScript and back again.
Probably. For many things, anyway.

I can see some things not needing any managing. Such as numbers and strings (which come into Java as Doubles and Strings). So methods like Token.getName() will work without change, but any code that modifies objects will need to be checked to ensure that related information stays up to date. That's what I expect the additional layer of code will do.

The use of Bean properties with method names that start with js might take care of some of that. We're going to want a layer for other plugins anyway, so we could create one ProxyToken object that has functions like getName() and jsGetName(). The first is for use by Java-based plugins and the second is for use by JS. The JS one might handle permission issues that the plugin doesn't need to deal with, or maybe the JS one needs to do data conversion. But it keeps the interface layer for both in one place.
And in any case the JavaScript macro system will have to be sandboxed so that it can't mess with the internals of MapTool and only go through a well defined API.
Yep, as expected. :)

I read something the other day on Oracle's site regarding JSR-223 and integration of Java and JS. There are a lot of ways that Java functionality could be exposed that would reduce the amount of work needed in building the extra layer. The requests to the importClass() and importPackage() functions can be filtered, for example. And direct use of Java package names can be turned off as well.

I expect that the simplest approach will be to turn off access to everything, then put an object into the JS "script context" that acts as an interface layer. We then build the code for that object dynamically at the time we build the JAR files. The build process knows what to include by reading a config file, so when we decide to open a function up to JS, we edit the config file and we're done. Creating that build process is going to be a pain, though. ;)

User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

Re: MapTool 1.4

Post by Jagged »

As you are on the subject of JS, is this the place I should express my interesting in doing the script for Hero System dice? Although its no doubt a long way off, I am pretty sure I will still be around when the time comes :D

*checks pulse* *touches wood*

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MapTool 1.4

Post by wolph42 »

so to bumb this topic once again. I'm curious, can any of the dev tell anything about 'how its going' with 1.4. I've read the interview done by 'the Bard' which covers most questions, one however remains unanswered...time. In terms of time, what is your guestimation towards the first alpha release of 1.4? weeks, months, years? Any bumbs during the ride (well obviously their will be), still in 'design' stadium or has the (re)coding commenced?

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.4

Post by Azhrei »

I haven't started yet. I've been working long days and long weeks so I haven't accomplished anything MT-related since early May. I have no idea if Craig has done anything with it, but we were planning to move from SVN to Git prior to doing 1.4 and there is nothing checked into Git on SF yet so I don't think anything has happened yet.

User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

Re: MapTool 1.4

Post by Jagged »

Craig wrote: Correct. Only the GM will be able to load JavaScript macros/libraries. If your GM trusts you to make macros then it wont be hard for you to send the JavaScript and them to load it :) Essentially since there will be not be trusted/non trusted functions because it causes too much headaches only GMs will be able to load JavaScript. This is nothing new by the way it was always the way it was intended to be implemented right back to when Trevor was originally thinking about adding it. Adding a flag that would allow anyone to make JavaScript macros would lead to headaches I don't want to support -- with all the questions about why is it this way and all the other crud that has to be added into the code to account for such and such conditions etc, so don't hold your breath too much hoping for a change in this. :)
Is it appropriate to ask where the JS will run? On the client or on the server? I mean the only way to make the stuff truly secure is to run it on the server. I suspect the answer is that it needs to be run on the client but if the JS can only be served up by the server and the clients cannot modify it, might there be less network traffic involved if it wasn't sent was simply executed on the server?

Post Reply

Return to “Developer Notes”