RPTools "next" Git Repository

Thoughts, Help, Feature Requests, Bug Reports, Developing code for...

Moderators: dorpond, trevor, Azhrei

Forum rules
PLEASE don't post images of your entire desktop, attach entire campaign files when only a single file is needed, or generally act in some other anti-social behavior. :)
Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

RPTools "next" Git Repository

Post by Craig »

badsequel wrote:Is this the "official" 1.4 repo in GitHub? Is "irisiflimsi" an alias for some mt dev?
https://github.com/irisiflimsi/maptool
Moving this to its own thread so it wont completely drown out the other thread.

The official RPTools next is currently at https://github.com/RPTools.
This may change in the future (git repositories are easy to move) but for now git hub is as good as place as any (and better than a lot).

At this point in time I am working on the scripting engine and that is all it currently contains. While not yet complete its very far along the path to complete (until people find bugs of course :) ), and there is still a lot of debugging code in there I need to remove.

Things that currently work
  • Parsing blocks of text for [ ... ] to execute.
  • Adding functions to the [ ... ] blocks scripts from JavaCode.
  • Adding JavaScript scripts which can also define functions to call in the [ ... ] blocks.
  • The JavaScript engine is completely encapsulated, so there is no need for people writing JavaScript macros to worry about conversion from/to Java objects.
  • The functions defined for [ ... ] blocks support permissions, so you can say a function is executable by GM only, or Players (which includes GM) or Observers (if we have this level).
Things I still need to add are
  • Ways to add dice roll patterns.
  • A way to export/look up/retrieve JavaScript libraries from other JavaScript code (each script lives in its own scope).
  • Several more utility/math functions.
  • Logging.
  • Internationalization of strings.
  • Some sandboxing so people cant run just any old thing on your machine :)
Things not planned for the scripting engine
  • It doesn't manage which JavaScript libraries (this is more the domain of the tool that uses the script engine).
  • Many more functions which will be added by the tools that use the script engine (get map etc).
So if anyone is interested in building what is there now you will need JDK 7 and maven, once you download the rptools and rptools-common repository you will need to run the following command to add JavaFX to the built
in class path (only required for building so something similar wont be required on users machines so no need to panic there :) ).

Code: Select all

 mvn com.zenjava:javafx-maven-plugin:1.5:fix-classpath
then change to the rptools-common directory and

Code: Select all

mvn compile
Since its just a scripting engine and not an end tool there is no GUI to run to interact with it or anything, but after I add a way to add dice rolls and the JavaScript library export/lookup I want to make a quick and dirty GUI tool so that people can at least try it out. Lets say a week or two from now as I currently have the flu which makes coding anything take a lot longer than I expect :)
Last edited by Craig on Tue Feb 26, 2013 9:56 am, edited 2 times in total.

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

Re: RPTools Git Repository

Post by Craig »

Originally I wanted the parser to be dead simple, the idea being that it would really only accept the usual mathematical expressions +.-,/,*,() what have you, dice rolls and function calls. The function calls would just be passed along to the macro engine that would find and call the bit of javascript that they were mapped to (think similar to how user defined functions in MT macros work now).

Then Joe had some requirements that he wanted the parser to meet for an updated DiceTool, and things went from simple to complex and messy and stuff.

The idea of the expressions and dice and function calls have remained the same, but a lot more has been added to the parser. So below are the details of the parser currently. I am hoping people will look over them and tell me if its all too complex or something seems too strange, or I am missing something that really needs to be there, or any other general comments. Keep in mind the parser only deals with the text that is within the [ ], so if your button contains "He swings at the dragon with his sword doing [4d6] damage" it would only be interested in the 4d6 part.

So on with the details (except for a few small bugs this is all currently working) but only XdY, dY rolls (with modifiers, see later) have been coded at the moment.

The parser uses an updated version of antlr (for anyone who cares)
Better support for unicode so a much larger character set should work
Both " and ' can be used to enclose strings.

Obviously addition, subtraction, division, and multiplication are supported (+,-,/,*)
% is the remainder operator (it performs a remainder as it does in Java not a mod like C)
^ Exponent, (e.g.) 2^3 = 8.

Supports long (integer), floating point, string, and list, dictionary (maps string to value), "result" data types.
Results are basically a value + information about how that value was derived.

Variables are prefixed with $ and properties are prefixed with @ so there are no chance of setting
the wrong thing (unlike now how a property overrides a variable)
examples
$dex = @dex
1d6 + @dexMod

Statements are separated with a ';', eg $toHit = 1d20; $damage = 2d6 + @strMod

?$var prompts for a value and places it in the var variable. It also supports prompt with a description in the form
?$str:"Enter your strength"

Dice rolls look the same as the previous version 2d5 or d5 etc, but as the parser is now aware of what makes a dice roll (rather than the string replace before going to the parser that used to happen) it can now support modifiers. There are currently the following modifiers
! return details of the individual rolls in both the detailed results and the normal results.
!s return details of the individual rolls in the detailed results and a sum in the normal results.
The detailed result is generally the string to be displayed, the normal result is generally the value to be used in calculations (or passed to function or assigned to variable/property)
An example, say you were rollong three dice (of six sides), and you roll 4, 2, and 5.
3d6 the detailed result would be the string "11", the normal result would be the integer 11
3d6! the detailed result would be the string "4, 2, 5" and the normal result would be the list [4, 2, 5]
3d6!s the detailed result would be the string "4, 2, 5" and the normal result would be the integer 11
These same flags would work for other roll formats too (where it makes sense).


Functions are passed off to the relevant Java or JavaScript code. I will post more information about this in a day or two when its not so late at night :)


Repeat groups.
There are 2 types of repeat groups, repeat and return a sum [] and repeat and return individual values {}, what ever is in the brackets is evaluated multiple times, they take the form.
x[expr] / x{expr} where x is an integer which is the amount of times to repeat
$x[expr] / $x{expr} where x is a variable that containes the amount of times to repeat
@x[expr] / @x{expr} where x is a property that containes the amount of times to repeat
?[expr] / ?{expr} prompt for the number of times to repeat.
?"message"[expr] / ?"message"{expr} prompt with a message for the number of times to repeat.
[expr] / {expr} is the same as 1[expr] / 1{expr} potential uses described later.

Some examples
4[2] = the integer 8
4{2} = the list [2, 2, 2, 2]

Advanced stuff you may never need...
To support the case where DiceTool needs to add a value within a [ ] repeat group but still be able to obtain the different values you can use the & operator. (See labels for how this works).

The parser supports labeling values, this is probably something that is going to be more useful in DiceTool than anywhere else. To label a value you use the syntax |label| expr
for example
|label 1| 3d6 will set the value of "label 1" label to the result of the dice roll (for the first index).
|label 2| (3d6 +2) will set the value of "label 2" label to the result of the dice roll plus 2(for the first index).
|label 3| 2[d6] will set the value of "label 3" label to the result of the dice rolls added together for the first index.
If a label appears within a repeat group then it will have multiple indicies with values, for example
2[|label 4| d6] will assign the first d6 result to the first index, and the second result to the second for "label 4"
Labels also allow you to record the values when & is used in a repeat group
$var = 3[|label 5| (d6 & 2)], for example. $var would be set to the sum of rolling a d6 and adding 2 to it 3 times, where the "label 5" would have 3 values, each of them would be a list with the result of the d6 roll and the number 2.
so it might look like
"label 5"(0) = [4, 2]
"label 5"(0) = [2, 2]
"label 5"(0) = [5, 2]
in which case $var would be set to 17.

+,-,* and strings or lists.
+ works as an append to a string where it just convers the other argument to a string and concatenates it, for lists it adds the value to the end of the list.
- for strings is only valid if both arguments are a string, in which case it removes all occurrences of the second string from the first. eg. "there is a great big red dragon on a great pile of treasure" - "great" = "there is a big red dragon on a pile of treasure"
- for lists is only value if both arguments are lists in which case it does the minus set operation, [1,2,3,4,4,5,6] - [1,4] = [2,3,5,6].
* is valid for a string and an integer, and repeats the string multiple times, so 10 * "-" = "----------".

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

Re: RPTools "next" Git Repository

Post by wolph42 »

you're mainly talking about the dice tool but I get the impression that it also (could) apply to maptool. Can you elaborate on that?

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

Re: RPTools "next" Git Repository

Post by Craig »

wolph42 wrote:you're mainly talking about the dice tool but I get the impression that it also (could) apply to maptool. Can you elaborate on that?
Most definitely could be used in MapTool and thats the plan, any of the tools could pick it up and incorporate it (not that it would make much sense in TokenTool :) ).

The DiceTool comments are more around some of the features such as the & operator and labels, they would be there for MapTool to use, but not necessarily as useful as they would be in DiceTool.

User avatar
Vhex
Giant
Posts: 162
Joined: Fri Sep 09, 2011 4:41 am
Location: Honolulu, HI

Re: RPTools "next" Git Repository

Post by Vhex »

I really like the roll breakdown. It also warms my heart that you used antlr. It's great to see this level of communication.

For the javascript export/look up/retrieve -- are you planning something like include availability? (ie, script source for this macro = myfile.js)? That would definitely speed up macro development.

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

Re: RPTools "next" Git Repository

Post by jfrazierjr »

Vhex wrote:I really like the roll breakdown. It also warms my heart that you used antlr. It's great to see this level of communication.

For the javascript export/look up/retrieve -- are you planning something like include availability? (ie, script source for this macro = myfile.js)? That would definitely speed up macro development.
Yes. In essence, you would either point to one or more javascript files or copy/paste javascript code into a window(at this point, Craig would have to answer which of the two approaches MT will take IF NOT BOTH) that would be saved as part of the campaign. If you copy that campaign file onto a USB and use somewhere else, everything you will need for the scripting engine would be in place(ie, the campaign file won't point to a location on a machine as that would not be portable at all) to begin using the campaign file copy.

Does that answer the question?
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
Vhex
Giant
Posts: 162
Joined: Fri Sep 09, 2011 4:41 am
Location: Honolulu, HI

Re: RPTools "next" Git Repository

Post by Vhex »

That does answer the question, thanks. I prefer editing files directly myself, rather than copy & paste is why I ask.

User avatar
Vhex
Giant
Posts: 162
Joined: Fri Sep 09, 2011 4:41 am
Location: Honolulu, HI

Re: RPTools "next" Git Repository

Post by Vhex »

antlr 4 is out by the way.

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

Re: RPTools "next" Git Repository

Post by wolph42 »

Ok, please treat me here as the biggest n00b in the area, a couple of questions:

Overall I have no clue what 'the new parser' would look like. The only thing I've picked up so far is what Craig mentions in the OPs:
- the parser will only check out [that what is found here]
- supports JS (to what extend?)
- has additional features concerning dicerolls
- will (at least) require all existing script to mark out properties and variables with $ and @
- so what effect does that have on the current scrip?
a. will it still function
b. will it require 'some' change
c. can we throw it away and start anew
d. will co-exist with JS
e. wil be based on JS and thus every function needs to be rewritten
f. some combination of the above

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: RPTools "next" Git Repository

Post by Full Bleed »

This is all pretty interesting.

Thanks for sharing, Craig.

I, too, am interested in most of what Wolph is asking about future compatibility with current macroscript.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

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

Re: RPTools "next" Git Repository

Post by jfrazierjr »

wolph42 wrote:Ok, please treat me here as the biggest n00b in the area, a couple of questions:

Overall I have no clue what 'the new parser' would look like. The only thing I've picked up so far is what Craig mentions in the OPs:
- the parser will only check out [that what is found here]
- supports JS (to what extend?)
- has additional features concerning dicerolls
- will (at least) require all existing script to mark out properties and variables with $ and @
- so what effect does that have on the current scrip?
a. will it still function
b. will it require 'some' change
c. can we throw it away and start anew
d. will co-exist with JS
e. wil be based on JS and thus every function needs to be rewritten
f. some combination of the above
I don't want to speak for Craig and say "this is how things are going to be", but I am going to throw out my thoughts here based on guesses, being a coder, and being a somewhat frequent contributer of code to MapTool specifically. There are no doubts(well.. very, very few) in my mind that by the time 1.4 is "gold", there will be zero support for the current macro script language as you know it today.

Will 1.4 start out supporting existing MT script? My guess is no. I can't see MT being able to support BOTH parsers at the same time. IF there will be support for both for a certain time period(which I am beginning to quite doubt), there would have to be some type of global toggle to tell MT which one to run as there really is no possible way I can imaging that they would be usable together.

As noted many times though, I suspect that the VAST majority of the functions currently available will remain and will likely remain mostly untouched in their inputs/outputs(though, I would highly suspect that there will be no StrProp functions left and that all inputs/outputs to other functions that take StrProp or StrList would be converted to take/output JSON only)

At the end of the day, 1.4 will be a brand new build of MapTool... not just in name/version number, but a few things will fundamentally change from the way you do some things today.
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
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: RPTools "next" Git Repository

Post by jfrazierjr »

Vhex wrote:That does answer the question, thanks. I prefer editing files directly myself, rather than copy & paste is why I ask.
Yea.. I don't know yet and I don't know if Craig/Azhrei knows for sure at this point. One problem with any file base approach would be the whole edit,save, "import", test, repeat problem. This may not be a problem if your doing one time utility functions such as complex math(or even simple roll string formatting) that could be tested outside of MapTool's environment(ie, there are no references to tokens, or maps, etc), but once you add things that you need to build/test it's a major drag to do a file approach. Also as I said, no matter the input path, the finalized form has to be stored in the campaign file for portability. There was some talk some type of code editor built in, but I have no idea if that's going to be possible or not and worse yet, I would hate for us to add a code editor with syntax highlight and the such that's supportable in Swing and then not have the same thing or worse nothing that would do that job when we converted to JavaFX for the UI layer. I don't know the details as I have no checked in a while so I have no idea if there is an open source or freely available code editor with both Swing as well as JavaFX ui's available out there...
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
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: RPTools Git Repository

Post by Azhrei »

Craig wrote:The parser uses an updated version of antlr (for anyone who cares)
Heh. Vhex immediately comes back with, "ANTLR v4 is out".

I know we had talked about v3 but did you get in the game late enough to use v4? It appears it could have some advantages but it doesn't seem to be necessary for the RPTools apps.
Better support for unicode so a much larger character set should work
Both " and ' can be used to enclose strings.
Hm. Doesn't Unicode have an entire class of characters that represent string delimiters? Is there any value in allowing all of them as delimiters?

I'm primarily thinking of people writing code in an editor that replaces the quotes around a string with a left-open-quote and right-close-quote. When they copy/paste into a window they'll get errors. It would be nice if the parser could accept them instead. Here's the ones I found by grep'ing the Unicode Character Database (hm, the forum's Preview works correctly but I've also included the HTML that generated this list):

x0022 = "
x0027 = '
x2018 = ‘
x2019 = ’
x201A = ‚
x201B = ‛
x201C = “
x201D = ”
x201E = „
x201F = ‟
x301D = 〝
x301E = 〞
x301F = 〟
HTML that generated the list
Copy/paste this into an HTML file and then open that file in a browser:

Code: Select all

<div>x0022 = "</div>
<div>x0027 = '</div>
<div>x2018 = ‘</div>
<div>x2019 = ’</div>
<div>x201A = ‚</div>
<div>x201B = ‛</div>
<div>x201C = “</div>
<div>x201D = ”</div>
<div>x201E = „</div>
<div>x201F = ‟</div>
<div>x301D = 〝</div>
<div>x301E = 〞</div>
<div>x301F = 〟</div>

(And later...)

Ah-ha, I found one! On this page of the Unicode web site is a reference to "Quotation_Mark" under the Miscellaneous category. So it should be possible for the parser to check the flag (using something similar to the \p{} construct from the Pattern class) to check the delimiter type.

There are two issues: an open-quote should be closed by a close-quote and the \p{} won't help in that regard, and the notation is Informative, not Normative, which means a given implementation of Unicode doesn't have to support this property. :|

Oh well. :roll:

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

Re: RPTools "next" Git Repository

Post by Azhrei »

jfrazierjr wrote:
Vhex wrote:That does answer the question, thanks. I prefer editing files directly myself, rather than copy & paste is why I ask.
Yea.. I don't know yet and I don't know if Craig/Azhrei knows for sure at this point.
Joe's got it right. We don't know yet. :)

It would be nice to load a campaign, "export" the macros to a directory, and be able to do all of your edits there using your favorite editor (vim!). The campaign would keep track of the exported directory and automatically suck them back in when it's saved. MT would need to monitor the directory and filenames and automatically reload them when it sees a timestamp/file size change as well.

It might be possible to do editing and testing of macros without MT at all. If a browser environment could be made to resemble MT's operating environment, then tools like Firebug could greatly simplify JavaScript macro development. Consider a scenario where a user loads a "maptool.js" or "dicetool.js" file into a web page. That gives them a simulated framework that is 90% the same as running inside MT, thus allowing all of today's browser tools for debugging JS to be used.

This may be infeasible, it will depend on what features of MT are exported into the JS engine and how intricately those features are tied to the implementation of the macros...

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

Re: RPTools "next" Git Repository

Post by wolph42 »

jfj wrote: concerning the parser
I still would like to hear Craigs view, but you did help me to sharpen my question and view a bit;

- in the end there willl be only support for ONE parser and it will be the new one, right ?
- assuming so: how will the current scrip 'relate' to the new parser, its basically back to my original question:
will it
a. have no effect, with that I mean: old script is still completely useable without any rewrites
b. still usable but require 'some' rewrites, e.g. you mention strprops leaving the door, I won't be happy with seeing them leave but is that the *only* thing that needs a rewrite ??
c. all old script will be useless as the syntax and supporting functions are completely different ?

likely somewhere between b and c but I like to have a grasp of what it is.

Post Reply

Return to “MapTool”