RPTools.net

Discussion and Support

Skip to content

It is currently Mon Feb 19, 2018 7:22 am 






Reply to topic  [ 117 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

Previous topic | Next topic 

  Print view

Author Message
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12111
Location: Tampa, FL
 Post subject: Re: MapTool 1.4
PostPosted: Tue Feb 22, 2011 5:13 pm 
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.


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Sep 11, 2007 6:31 pm
Posts: 5412
 Post subject: Re: MapTool 1.4
PostPosted: Tue Feb 22, 2011 5:28 pm 
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..


Top
 Profile  
 
 Offline
Kobold
 
Joined: Sat Jul 25, 2009 11:34 pm
Posts: 6
 Post subject: Re: MapTool 1.4
PostPosted: Sat Mar 26, 2011 1:21 am 
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.


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12111
Location: Tampa, FL
 Post subject: Re: MapTool 1.4
PostPosted: Sat Mar 26, 2011 11:54 am 
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.

Quote:
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.


Top
 Profile  
 
 Offline
Kobold
 
Joined: Sat Jul 25, 2009 11:34 pm
Posts: 6
 Post subject: Re: MapTool 1.4
PostPosted: Sat Mar 26, 2011 2:05 pm 
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...


Top
 Profile  
 
User avatar  Offline
Cave Troll
 
Joined: Fri Oct 30, 2009 11:47 am
Posts: 85
Location: Oakland, CA
 Post subject: Re: MapTool 1.4
PostPosted: Sat Mar 26, 2011 11:04 pm 
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?


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12111
Location: Tampa, FL
 Post subject: Re: MapTool 1.4
PostPosted: Sat Mar 26, 2011 11:32 pm 
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.


Top
 Profile  
 
 Offline
Great Wyrm
 
Joined: Sun Jun 22, 2008 6:53 pm
Posts: 2104
Location: Melbourne, Australia
 Post subject: Re: MapTool 1.4
PostPosted: Sun Mar 27, 2011 5:49 am 
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. :)


Top
 Profile  
 
 Offline
Great Wyrm
 
Joined: Sun Jun 22, 2008 6:53 pm
Posts: 2104
Location: Melbourne, Australia
 Post subject: Re: MapTool 1.4
PostPosted: Sun Mar 27, 2011 5:56 am 
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.


Top
 Profile  
 
 Offline
Kobold
 
Joined: Sat Jul 25, 2009 11:34 pm
Posts: 6
 Post subject: Re: MapTool 1.4
PostPosted: Sun Mar 27, 2011 12:48 pm 
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:


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12111
Location: Tampa, FL
 Post subject: Re: MapTool 1.4
PostPosted: Sun Mar 27, 2011 1:02 pm 
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.

Quote:
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. ;)


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Mon Sep 15, 2008 8:27 am
Posts: 1205
Location: Bristol, UK
 Post subject: Re: MapTool 1.4
PostPosted: Wed May 25, 2011 6:19 am 
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*


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Fri Mar 20, 2009 4:40 am
Posts: 9479
Location: Netherlands
 Post subject: Re: MapTool 1.4
PostPosted: Wed Jun 01, 2011 5:51 am 
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?

_________________
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC

My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent and
DPI.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12111
Location: Tampa, FL
 Post subject: Re: MapTool 1.4
PostPosted: Wed Jun 01, 2011 8:40 am 
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.


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Mon Sep 15, 2008 8:27 am
Posts: 1205
Location: Bristol, UK
 Post subject: Re: MapTool 1.4
PostPosted: Mon Jun 06, 2011 4:04 am 
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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Reply to topic  [ 117 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:

Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
Most users ever online was 243 on Sun Nov 04, 2012 6:14 am

Users browsing this forum: No registered users and 1 guest





Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

Style based on Andreas08 by Andreas Viklund

Style by Elizabeth Shulman