Love it or Leave it: Current Macro Language

Discuss macro implementations, ask for macro help (to share your creations, see User Creations, probably either Campaign Frameworks or Drop-in Resources).

Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice

Should we drop the current macro language and start fresh with javascript in 1.4?

Poll ended at Sun Jan 17, 2010 9:23 am

Yes, drop it. We should standardize on Javascript
24
60%
Yes but only if keeping the old macro language involves significant work.
6
15%
No, keep it for 1.4 but drop it in a later version
7
18%
No, I love it. Keep it forever
3
8%
 
Total votes: 40

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

Re: Love it or Leave it: Current Macro Language

Post by Craig »

jfrazierjr wrote:
Craig wrote:Not having JavaScript in MapTool 1.3 has nothing to do Apple at all.
I would disagree, depending on your point of view.. see below

Craig wrote:You don't need 1.6 for Rhino (the JavaScript engine).
It works perfectly well under 1.5 with only a tiny bit more work than it takes to get it working in 1.6.


You a are quite correct and I am sorry if I accidentally miss represented things. Again, this is where your point of view (and history) comes into play. Javascript can be used under Java 1.5(and from what you say, previous versions of java(of which I shall defer to your knowledge). The reason why I say the hold up was on Apple's end was due to the fact that users would have to download (and config??) Rhino separately.
So... in some contexts, you can blame Apple's slow support for Java 1.6


That might be true if there was any extra download/configuration required by Mac users, but there isn't. The current MapTool code contains Rhino (the version included has been there since August in 2008). So there is nothing to download. Also there is nothing to configure. The code that exists in MapTool now would load Rhino is such a way that it works under 1.5 and 1.6 on any platform.

So my point of view that there is no hold up based on Apple is because
1) Rhino is already in MapTool
2) Rhino is already hooked up in a way to work with 1.5
3) It works exactly the same no matter what platform, no user intervention is required, no user configuration.

So I don't see how any can blame Apple for not moving to 1.6 or including JavaScript script engine, when the code that is already in MapTool does't not require either of these to work seamlessly from the users point of view :) Not that I am justifying or happy with their moving so slowly mind you ;)

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

Re: Love it or Leave it: Current Macro Language

Post by jfrazierjr »

Craig wrote:
jfrazierjr wrote:
Craig wrote:Not having JavaScript in MapTool 1.3 has nothing to do Apple at all.
I would disagree, depending on your point of view.. see below

Craig wrote:You don't need 1.6 for Rhino (the JavaScript engine).
It works perfectly well under 1.5 with only a tiny bit more work than it takes to get it working in 1.6.


You a are quite correct and I am sorry if I accidentally miss represented things. Again, this is where your point of view (and history) comes into play. Javascript can be used under Java 1.5(and from what you say, previous versions of java(of which I shall defer to your knowledge). The reason why I say the hold up was on Apple's end was due to the fact that users would have to download (and config??) Rhino separately.
So... in some contexts, you can blame Apple's slow support for Java 1.6


That might be true if there was any extra download/configuration required by Mac users, but there isn't. The current MapTool code contains Rhino (the version included has been there since August in 2008). So there is nothing to download. Also there is nothing to configure. The code that exists in MapTool now would load Rhino is such a way that it works under 1.5 and 1.6 on any platform.

So my point of view that there is no hold up based on Apple is because
1) Rhino is already in MapTool
2) Rhino is already hooked up in a way to work with 1.5
3) It works exactly the same no matter what platform, no user intervention is required, no user configuration.

So I don't see how any can blame Apple for not moving to 1.6 or including JavaScript script engine, when the code that is already in MapTool does't not require either of these to work seamlessly from the users point of view :) Not that I am justifying or happy with their moving so slowly mind you ;)


Thanks for the clarification Craig. It seems my information is out of date, but no one who knows me would say I have a stellar memory as is, so I may very well be remembering information from prior to when gilaith added the Javascript stub stuff(which I remember him doing, just not the when... I thought it was sometime mid last year.)

Personally, I prefer your approach much more since it appears much more like standard javascript object notation, but thats just me, plus I would rather have the low level compiled Rhino engine do the string parsing rather than having Maptool do it as I can't see an possible way for it to not be more efficient.
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..

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

Re: Love it or Leave it: Current Macro Language

Post by Craig »

jfrazierjr wrote:Personally, I prefer your approach much more since it appears much more like standard javascript object notation, but thats just me, plus I would rather have the low level compiled Rhino engine do the string parsing rather than having Maptool do it as I can't see an possible way for it to not be more efficient.


The problem is that MapTool needs to deal with tooltips/expanded rolls, so
[1d20 + strMod + bonus]
becomes
1d20 + strMod + bonus = 4 + 2 + 1 = 7 
At the moment the parser that MapTools uses performs all that work so it knows about the intermediate steps and
can generate the required string. Where as if you pass [roll(1d20) + strMod + bonus] to the JavaScript interpretor
then you only get back 7 not the intermediate step. So its quite possible/probable that MapTool will need to retain
the current parser (not necessarily the MapToolLineParser looping and stuff). But its not all bad! For starters the parser (in the parser project in rptools) is quite fast but it only does single lines, the looping is done outside of the parser (which is part of the speed, not to mention stack problems).

So strings in [] would still be broken up by the parser and run as it is now, so it wouldn't be JavaScript -- but could access JavaSript functions and variables -- and I would lean towards not having loops like [for():]. {} could contain JavaScript, but only if it was running as trusted (there are very good reasons for only allowing GM approved JavaScript to be executed. The unfortunate consequence of this though would be only GM's could create macros with loops in them. So maybe then the [for():] type loops would still be required -- although implemented very differently in the code. As I implied before there are quite a few things to think about and balance when deciding which way to go :)

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

Re: Love it or Leave it: Current Macro Language

Post by jfrazierjr »

Craig wrote:
jfrazierjr wrote:Personally, I prefer your approach much more since it appears much more like standard javascript object notation, but thats just me, plus I would rather have the low level compiled Rhino engine do the string parsing rather than having Maptool do it as I can't see an possible way for it to not be more efficient.


The problem is that MapTool needs to deal with tooltips/expanded rolls, so
[1d20 + strMod + bonus]
becomes
1d20 + strMod + bonus = 4 + 2 + 1 = 7 
At the moment the parser that MapTools uses performs all that work so it knows about the intermediate steps and
can generate the required string. Where as if you pass [roll(1d20) + strMod + bonus] to the JavaScript interpretor
then you only get back 7 not the intermediate step. So its quite possible/probable that MapTool will need to retain
the current parser (not necessarily the MapToolLineParser looping and stuff). But its not all bad! For starters the parser (in the parser project in rptools) is quite fast but it only does single lines, the looping is done outside of the parser (which is part of the speed, not to mention stack problems).

So strings in [] would still be broken up by the parser and run as it is now, so it wouldn't be JavaScript -- but could access JavaSript functions and variables -- and I would lean towards not having loops like [for():]. {} could contain JavaScript, but only if it was running as trusted (there are very good reasons for only allowing GM approved JavaScript to be executed. The unfortunate consequence of this though would be only GM's could create macros with loops in them. So maybe then the [for():] type loops would still be required -- although implemented very differently in the code. As I implied before there are quite a few things to think about and balance when deciding which way to go :)


Yea, I wasn't advocating removing the Paser as your right, it is very fast as well as doing a heck of a lot of stuff "for free". I was more thinking in lines of your approach where the loops and branch statements would be "preferably" implemented as javscript code. The use of backticks for the literal javascript code was quite brilliant.

But as you said, there would have to be a heck of a lot of API changes to deal with how to present information back to the Javascript. Currently MTScript generates strings for many of the functions, but in Javascript, the equivalent functions may need to return objects instead and as you stated, that's a bunch of code changes to get working.
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..

User avatar
RPTroll
TheBard
Posts: 3148
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

Re: Love it or Leave it: Current Macro Language

Post by RPTroll »

For the record, I'm OK with only the GM being able to use/generate complex coding structures. If a player wants to code such things he could submit them to the GM. I would hope there's not a lot of coding going on during the game.
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image

User avatar
Raoden
Dragon
Posts: 381
Joined: Fri Dec 18, 2009 2:33 am
Location: San Diego

Re: Love it or Leave it: Current Macro Language

Post by Raoden »

RPTroll wrote:I would hope there's not a lot of coding going on during the game.

I dunno, seems like it could be an immersive element in a modern/sci-fi genre game. :lol:
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G. K. Chesterton

Wonderful HTML/CSS reference * Color Manager * Token Manager 2.0

prestidigitator
Dragon
Posts: 317
Joined: Fri Apr 23, 2010 8:17 pm

Re: Love it or Leave it: Current Macro Language

Post by prestidigitator »

I think if you were to retain some of the current parsing functionality, it could probably be stripped way down to simple dice/arithmetic expressions rather than trying to include the whole '[]' macro syntax. Even then I think it could be handled by a function or two that would evaluate a string and return an object (with fields denoting results, expanded tooltip type explanations, etc.).
Last edited by prestidigitator on Fri Jun 18, 2010 12:41 pm, edited 1 time in total.
"He knows not how to know who knows not also how to un-know." --Sir Richard Burton

bstrdsmkr
Cave Troll
Posts: 41
Joined: Sat Jun 05, 2010 8:58 pm

Re: Love it or Leave it: Current Macro Language

Post by bstrdsmkr »

I had a different implementation in mind that may solve some of the drawbacks mentioned. I was thinking of having javascripts loaded to buttons like mtscripts are now. The first function exposed should be the ability to output text to chat. This way you can do all the parsing/rolling/seperating/etc in the script and output whatever you wanted to the chat window. This way you're not limited to how much processing you're able to do in one script. As almost a side benefit you could still use the current MTscripts with some thing like this:

Code: Select all

chat.prntln("[1d20]")


or better:

Code: Select all

var strDieRollDetails;
for (die in Krog.lastroll.result[]){
    strDieRollDetails += die
    }
chat.prntln("Krog the Barbarian rolls "+Krog.lastroll.total()+" for damage! "+strDieRollDetails);


in my Other Thread i mentioned being able to attach scripts to gui icons as well for onclick or mouseover events

Would love to hear some feedback from those with "working" implementations =)

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

Re: Love it or Leave it: Current Macro Language

Post by Craig »

bstrdsmkr wrote:I had a different implementation in mind that may solve some of the drawbacks mentioned. I was thinking of having javascripts loaded to buttons like mtscripts are now. The first function exposed should be the ability to output text to chat. This way you can do all the parsing/rolling/seperating/etc in the script and output whatever you wanted to the chat window. This way you're not limited to how much processing you're able to do in one script. As almost a side benefit you could still use the current MTscripts with some thing like this:

Code: Select all

chat.prntln("[1d20]")


or better:

Code: Select all

var strDieRollDetails;
for (die in Krog.lastroll.result[]){
    strDieRollDetails += die
    }
chat.prntln("Krog the Barbarian rolls "+Krog.lastroll.total()+" for damage! "+strDieRollDetails);


in my Other Thread i mentioned being able to attach scripts to gui icons as well for onclick or mouseover events

Would love to hear some feedback from those with "working" implementations =)


IMHO thats the wrong way to go about doing things. Macro Buttons on tokens/chat panel etc should be as simple as possible. You don't want to write JavaScript code just to role dice, also remember all of this functionality has to be easily accessible from some one typing in the chat panel as well --not everything goes according to a script the GM has written-- in which case the second method is certainly out of the question.

Secondly no one should ever have to write a single line of code to play a game with MapTool should they not want to, and requiring even chat.println("[1d20]") would violate that. Macro buttons should continue to support what they support now, just a bunch of text that would get sent to the chat. This means that the same problem remains.

User avatar
metatheurgist
Dragon
Posts: 350
Joined: Mon Oct 26, 2009 5:51 am

Re: Love it or Leave it: Current Macro Language

Post by metatheurgist »

RPTroll wrote:If a player wants to code such things he could submit them to the GM.


I'm already playing that game with properties. "Hey Bob, can you add x and y?" 10 mins later: "Bob, I also need z, oh I found a better way to code that macro that means I don't need y anymore, you can remove that if you want." Not looking forward to doing that with structures.

RPTroll wrote:I would hope there's not a lot of coding going on during the game.


Sometimes the only time you have to code macros is during the game. :wink:

bstrdsmkr
Cave Troll
Posts: 41
Joined: Sat Jun 05, 2010 8:58 pm

Re: Love it or Leave it: Current Macro Language

Post by bstrdsmkr »

I think you misunderstood what I was saying. I don't intend for that method to outright and completely replace the chat window mtscript functions, and in fact i think that would be a mistake. What I meant was thid method allows the script writer to bypass the current parser OR use it ALSO. I intended that implementation to only add functionality and have the rest remain the same. Infact, due to the verboseness i personally don't think it would be very practical for me as a GM to use javascript "on the fly" and manually typed into the chat window. Now i do think it should be possible to invoke prewritten scripts from the chat window with something like [js:myprewrittenscript.js, arg1,arg2].

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

Re: Love it or Leave it: Current Macro Language

Post by Craig »

bstrdsmkr wrote:I think you misunderstood what I was saying. I don't intend for that method to outright and completely replace the chat window mtscript functions, and in fact i think that would be a mistake. What I meant was thid method allows the script writer to bypass the current parser OR use it ALSO. I intended that implementation to only add functionality and have the rest remain the same.

I completely fail to see how this would solve the drawbacks as you mentioned it might then :)

bstrdsmkr wrote: Now i do think it should be possible to invoke prewritten scripts from the chat window with something like [js:myprewrittenscript.js, arg1,arg2].

I think you are going down the wrong track here, MapTool shouldn't be running any external scripts, instead JavaScript should be used define functions that can be called in []/{} blocks (or other JavaScript libraries etc). There is no need for a [js:] flag for this either.

bstrdsmkr
Cave Troll
Posts: 41
Joined: Sat Jun 05, 2010 8:58 pm

Re: Love it or Leave it: Current Macro Language

Post by bstrdsmkr »

Craig wrote:
bstrdsmkr wrote:I think you misunderstood what I was saying. I don't intend for that method to outright and completely replace the chat window mtscript functions, and in fact i think that would be a mistake. What I meant was thid method allows the script writer to bypass the current parser OR use it ALSO. I intended that implementation to only add functionality and have the rest remain the same.

I completely fail to see how this would solve the drawbacks as you mentioned it might then :)

The drawbacks I had in mind were the nesting limitations, characters that can't be escaped out, speed issues with complex logic trees, etc. Now as for the per die roll example you laid out above, it should be easy to expose each step to javascript as an array.

Craig wrote:
bstrdsmkr wrote: Now i do think it should be possible to invoke prewritten scripts from the chat window with something like [js:myprewrittenscript.js, arg1,arg2].

I think you are going down the wrong track here, MapTool shouldn't be running any external scripts, instead JavaScript should be used define functions that can be called in []/{} blocks (or other JavaScript libraries etc). There is no need for a [js:] flag for this either.

I meant in the same way that it calls MT scripts now. The only real difference I see there should be is the syntax the macro is written in. Although I wouldn't be opposed to seeing the option to run then from .js files as well, bc that would make sharing macros easier. and one point of fact, manually typed javascripts could get hairy quickly seeing as [] and {} are used a lot in the syntax.

You've had your hands in the code for a lot longer that I have so it's really good to hear your feedback. Have you by chance taken a look at my Projector Mode/Skinnable GUI Thread? :mrgreen:

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

Re: Love it or Leave it: Current Macro Language

Post by Azhrei »

I'm happy to let the expert conduct the conversation (that would be you, Craig! 8)). But I admit to being confused about how the implementation would look.

We want the following to work in the chat window, right?

Code: Select all

/me grumbles about how hot it's been lately.
ARGH!  I'll get you!  (I run forward and attack with my sword: [1d20+6])
[fancyAttackMacro()]

If that can be done using your plan Craig, then I'm all for it. :)

If the JS needs to provide results and tooltips, then have it return an object. The object can be used to fill in an HTML template which is then dumped into the chat log:

Code: Select all

<div class="JS_output">
  <img src="...">
  <span alt="%{tooltip}">
    %{result}
  </span>
</div>

I'm assuming that the returned object has a result and tooltip property in it. The JS_output class would be empty unless filled in by the GM (this allows formatting that makes it obvious that the content is the result of a JS function).

bstrdsmkr
Cave Troll
Posts: 41
Joined: Sat Jun 05, 2010 8:58 pm

Re: Love it or Leave it: Current Macro Language

Post by bstrdsmkr »

I guess my main point is that if the current MTscript parser can be improved using javascript, then great, those are bonus points. But the implementation of JS itself shouldn't depend on any changes to the current parser.

As far as i understand it, the current parser takes each line entered into the chat window and scans it for matches with a metric ton of regex's, processes each match and calls the relevant java method on each match. Then the returns from each method and analyzed and the string returned is spit out to the chat log.

What I propose is just exposing those exact same java methods to javascripting. Literally:

Code: Select all

  jsEngine.put("chatTextParser", whatever.class.contains.the.functions.currently.called);

  try {
    jsEngine.eval("chat.writeln(chatTextParser(chatwindow.getinput()));");
  } catch (ScriptException ex) {
      ex.printStackTrace();
  }


That's a modified example from the reference at http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/

Post Reply

Return to “Macros”