Love it or Leave it: Current Macro Language

[prestidigitator]

Maybe PHP would be a better choice. LOL. Or perhaps something similar for embedding JavaScript code. Heck, maybe there is something already, but I was thinking a <?js ... ?> construct if nothing else seems more appropriate....

[bstrdsmkr]

there are very good reasons for only allowing GM approved JavaScript to be executed.

as a second thought on this, if the scripts were broken out into .js files or even .jar's, it doesn't seem that it would be that hard to have a GM approval screen. Maybe at setup time, the GM client receives a request to approve any scripts the user is trying to use, identified by a checksum of the file. It would be a toggle screen so that as long as the gm enables it, it will run, each time sending a new request containing the current hash, and as long as that hasn't changed, the gm client auto approves it. This may or may not be feasible depending on how fast this can be done. Or maybe there's another way to generate a unique id that would be altered if the code was changed? That way it wouldn't HAVE to be broken out into separate files, but the option is still a good one. The only "drawback" I can see to this is they couldn't be edited on the fly and would all have to be ready before primetime, but that's not much of a drawback. Thoughts?

Maybe PHP would be a better choice. LOL. Or perhaps something similar for embedding JavaScript code. Heck, maybe there is something already, but I was thinking a <?js ... ?> construct if nothing else seems more appropriate....

Check out https://scripting.dev.java.net/ for a list of script engines that could be added for roughly the same amount of effort. If you look toward the bottom, its looks like there are a couple of PHP implementations available. once a scripting framework is in place, adding those other languages would be MUCH easier. Literally one or two lines of code per object exposed. Personally, I'd like to see Python thrown into the mix. Now the above assumes that those other implementations gel well with all OS's but it should be pretty rare that they wouldn't since the only real requirement is an active JRE, AFAIK. Craig could probably shed a little more light on this though, as he seems to be better versed in JAVA than I am

[meshon]

I'm pretty new to MapTool and writing macros. I've been really happy with the things I've cobbled together so far, with some excellent help from the community and what seems to be a very strong willingness to share knowledge. Awesome.

Since I'm not a programmer and have no Javascript experience, there are some issues with switching that I'm definitely concerned about. I have read through this thread and I'm still not sure I get it. So, humbly submitted, here's my worries.

Right now MapTool has all sorts of ways to access information that are specific to the software which I can't imagine Javascript has. For example, using functions like getTokenNames() and input() to build a targeting and attack macro, the ability to set up token properties through the Campaign Properties window and access them (relatively) easily in macros, building custom states that I know exactly how to refer to and add or remove, creating and processing inputs, and even health bars.

Without the macro functions that currently exist, how will I be able to do any of that? If I want to display a health bar, will I need to write a function that draws a health bar, then another one that sticks it on the proper token, and then figure out some way to have that interact with a property on a token that exists as a bunch of Javascript objects?

I apologize since this is probably totally obvious to some of you, but how much of the sorts of things I've mentioned will still be under the hood, and how much will I need to make myself?

Maybe for a straight-forward example someone can tell me how a health bar might work in 1.4 (or any build that is using Javascript straight up).

Again, I should make sure my limited knowledge of Javascript is clear. I have some inklings, for example I figure that the nice clean Campaign Properties window probably takes my input and turns them into an object that I never really have to interact with directly, but how much of that functionality will be up to the user?

Sorry for the ramble, thanks for your patience, and if anyone has the time I'd appreciate a pat on the head and a sincere, "Everything will be okay, little MapTooler"

Concerns aside, having to learn a useful skill (Javascript) in order to play games is something I could definitely get into.

cheers,
Meshon

[jfrazierjr]

I'm pretty new to MapTool and writing macros. I've been really happy with the things I've cobbled together so far, with some excellent help from the community and what seems to be a very strong willingness to share knowledge. Awesome.

Since I'm not a programmer and have no Javascript experience, there are some issues with switching that I'm definitely concerned about. I have read through this thread and I'm still not sure I get it. So, humbly submitted, here's my worries.

Right now MapTool has all sorts of ways to access information that are specific to the software which I can't imagine Javascript has. For example, using functions like getTokenNames() and input() to build a targeting and attack macro, the ability to set up token properties through the Campaign Properties window and access them (relatively) easily in macros, building custom states that I know exactly how to refer to and add or remove, creating and processing inputs, and even health bars.

Without the macro functions that currently exist, how will I be able to do any of that? If I want to display a health bar, will I need to write a function that draws a health bar, then another one that sticks it on the proper token, and then figure out some way to have that interact with a property on a token that exists as a bunch of Javascript objects?

No one knows what it will look like yet, since we have not begun designing it. However, you fears are unfounded. The plan will be that the existing functionality in functions will be mirrored in some way in the javascript implementation.

Mostly, the syntax will be slightly different, but not that much. The benefit in javascript would be bypassing the MaptoolLineParser which result in a decent speed increase was well as being able to next structures (loops, if statements, etc) deeper than is now possible (due to the MaptoolLineParser's use of regular expressions to match open/close parenthesis and braces/brackets(which the javascript engine will do automatically for us.

So, for example getTokenNames() in javascript "might"( I say this again be cause it's not formalized yet and could be something different) return an array of token objects instead of a stringList. This "might"(again, keep the word might in mind!!!) make things easier as you might not have to do switchToken() since each token is a real object. Of course some type of trust mechanism would have to be in place if this approach was used.

[Rumble]

Meshon, jfrazierjr said most of what I was going to say. I think the understanding is that it will be a while before the javascript capabilities match what exists now, but that the ultimate goal is to map conceptually from existing capabilities to future ones (syntax variance aside). I would be champing at the bit to implement it and would happily spend months writing new functions but I have no clue how one integrates a script engine into Java. So I'm basically just sitting and waiting with eyes bright.

But even if that's not how it works out - that is, even if there's not a direct correspondence between MapTool-specific functions and javascript ones - my hope is that the javascript-based scripting is at least no more arcane than what we currently have.

[prestidigitator]

Oh, and to have actual return statements, and multiple levels of nesting, and 'else if' and....

Progrmmatic manipulation of HTML output (being JavaScript's true strength) would be cool too, but I won't hold my breath for that one.

[bstrdsmkr]

I would be champing at the bit to implement it and would happily spend months writing new functions but I have no clue how one integrates a script engine into Java. So I'm basically just sitting and waiting with eyes bright.

I feel the EXACT same way. I think your Java-Fu is probably stronger than mine though. Here is a snippet from the reference at http://java.sun.com/developer/technical ... scripting/
Have a read through and see what you think, I'd be ECSTATIC to help. I've got A LOT more experience in javascript and maybe between us we could get something going. It looks like it'd be pretty easy for someone with java skills.

Code: Select all

Code Example 8: Java programming language code adds names to a list.

  List<String> namesList = new ArrayList<String>();
  namesList.add("Jill");
  namesList.add("Bob");
  namesList.add("Laureen");
  namesList.add("Ed");
 
After creating a ScriptEngine object called jsEngine, you can put the namesList Java object into the scripting environment. The put method requires String and Object arguments that represent a key-value pair. In Code Example 9, the script code can use the namesListKey reference to access the namesList Java object.

Code Example 9: Script code can both access and modify native Java objects.

  jsEngine.put("namesListKey", namesList);
  System.out.println("Executing in script environment...");
  try {
    jsEngine.eval("var x;" +
                  "var names = namesListKey.toArray();" +
                  "for(x in names) {" +
                  "  println(names[x]);" +
                  "}" +
                  "namesListKey.add(\"Dana\");");
  } catch (ScriptException ex) {
      ex.printStackTrace();
  }
  System.out.println("Executing in Java environment...");
  for (String name: namesList) {
    System.out.println(name);
  }  

[JamzTheMan]

Just to throw in my 2 cents...

1. I would prefer JavaScript vs PHP/Python myself (simply because I am more familiar with JS).
2. It would be great to have the same JS interaction with the HTML as well like document.all.HP.value=20 and onClick support (a more robost HTML parser would be nice/needed)

And the big one, independant of the language choosen, can we PLEASE have a more friendly interface to develop the macro's in? Maybe expand it so "Campaigns" can have functions easily coded (with out the need for tokens/lib's/macro buttons. Kinda like a Global set of functions that don't need "buttons". The Lib tokens work well but can take time clicking token, finding macro, edit, go back to other token, test, repeat. Maybe just a way to leave a Lib macro list up on a screen for quick reference would work just as well. Anything to make getting around all your code easier.


I'd love for the ability to use includes or some way to code the macros outside the tool (so we can use our favorite editor like Notepad++) without having to using hacks and several clicks. Something like have MT watch a "directory" of files with .macro extensions and if change, auto load the files into MT (or even a manual refresh button to do the same is fine).

I tried to use the import/export macro, but it was taking up to 30 seconds to process which is way to long (and would prefer each macro to be in it's own file).

Anyway, ANYTHING that helps "development" would be a big bonus in my book!

[aliasmask]

I tried to use the import/export macro, but it was taking up to 30 seconds to process which is way to long (and would prefer each macro to be in it's own file).

Yeah, it can be a bit slow... I'm guessing you mean the import part. Are you importing the whole file or just the macros's you've updated?

I just added a feature for export, to only export specific groups rather than the whole file. I was thinking of some other features (listed in macroIO thread) but I also considered adding a flag to only update certain macros.

For example, if first line has @UPDATE@, then only macros with @UPDATE@ after the @@macroName line will be updated. Adding a couple of hotkeys will make that less of a pain. But still, if you're loading 2000 lines of code, that alone will take about 2 seconds. I've been trying to break my macro macros in to logical groups, and just work on those. There may be some ways to increase the speed as well... I never really analyzed that part... but I'm thinking using setMacroCommand may be faster than deleting and creating the macro button especially just for updates.

[Azhrei]

Progrmmatic manipulation of HTML output (being JavaScript's true strength) would be cool too, but I won't hold my breath for that one.

Well, there's nothing in JS that specifically helps with processing HTML -- HTML is just a text format. Similarly, there's nothing in JS that helps in processing a DOM model -- it's just an object structure.

Regardless, I think it would be super cool if I could use jQuery inside MapTool macros! I'd love to be able to whip up some dynamic HTML forms and such but as jQuery is highly dependent on the browser's support of "document" and "window", I doubt this is very likely.

Anyone with source checked out of SVN should be able to wade through the code and get some minimal JS functionality working. But the true work -- integrating MapTool objects with the JS engine -- is going to be time-consuming to design and implement. I will not be applying patches that simply expose the MT internals to JS. That path leads to madness.

Instead a coherent, well-structured API is needed. And that means that step 1 is to define the requirements. Minimal requirements at first, then perhaps expanding on them as we go along. But expanding in a way that maintains the existing API. (If we have to switch languages it's going to be painful. It would be best if the pain can be as minimal as possible.)

I've already offered to help with guidance, ideas, and suggestions if anyone wants to take on the task of defining what functionality needs to be exposed from MT. It requires a quick look through the "permissions" thread as well as the "wargamers: what do you need" thread as a lot of the basic concepts are covered there.

[jfrazierjr]

Anyone with source checked out of SVN should be able to wade through the code and get some minimal JS functionality working. But the true work -- integrating MapTool objects with the JS engine -- is going to be time-consuming to design and implement. I will not be applying patches that simply expose the MT internals to JS. That path leads to madness.

Instead a coherent, well-structured API is needed. And that means that step 1 is to define the requirements. Minimal requirements at first, then perhaps expanding on them as we go along. But expanding in a way that maintains the existing API. (If we have to switch languages it's going to be painful. It would be best if the pain can be as minimal as possible.)

I've already offered to help with guidance, ideas, and suggestions if anyone wants to take on the task of defining what functionality needs to be exposed from MT. It requires a quick look through the "permissions" thread as well as the "wargamers: what do you need" thread as a lot of the basic concepts are covered there.

Agreed 100%... the JS programmers don't need to know that a map is named Zone internally... Just as well, there are plenty of methods that I can't see any reason for scripting and we need to be very careful about what is and is not exposed via a scripting language. This is where the running context of being in a server would come in in allowing JS functions to be accessed..... lots of other stuff here about permissiosn...

Perhaps this is the time we need to see if we can capture Craig and chain him up in the proverbial dungeon to begin hacking on this...

[bstrdsmkr]

I assumed we'd start by exposing the functions exposed to MTScript already. From there I don't see a lot else that'd be required. Thoughts?

[Azhrei]

I assumed we'd start by exposing the functions exposed to MTScript already. From there I don't see a lot else that'd be required. Thoughts?

I'm reluctant to grow the API organically like that. The current MTscript has a bunch of overlapping functionality that really should be cleaned up. But it can't be because people could be using it.

Switching to JS is our chance to "do it right" so I would prefer to see it done carefully and thoughtfully -- not just adding some function "because it's there now". That's not good enough in my book.

Craig and I have been talking about using OSGI to provide a plugin architecture. He has suggested perhaps making the parser be the first thing attacked in this regard as the parser is mostly self-contained already so we would learn a lot about OSGI and how to do things correctly by starting with a thin veneer. Then we would likely pull apart other subsystems and put an interface-based API in front of them as well, in the process modularizing the MapTool code and reduce the internal dependencies. Once that is done and we are exposing the absolute minimal API to each OSGI bundle, we'd then take a look at building the layer between MT and JS, probably through another OSGI bundle to control the interface.

I don't have any time right now to learn new technologies (I know very little about OSGI) and I think Craig is mostly in the same boat regarding both OSGI + time. (Between now and the first of November I have exactly 4 weeks with no working gigs -- and when I'm working I have almost zero time for extracurricular stuff. Good for the wallet, but bad for contributing to MT. )

[Rumble]

I assumed we'd start by exposing the functions exposed to MTScript already. From there I don't see a lot else that'd be required. Thoughts?

If I'm not mistaken, that would fall closer to "exposing the internals" than a "designed" API.

[bstrdsmkr]

If I'm not mistaken, that would fall closer to "exposing the internals" than a "designed" API.

Hmmm... I should clarify. My main concern is not LOSING any functionality over MTScript.

inimal requirements at first, then perhaps expanding on them as we go along.

This is what I was gong for. Get the functionality that's already there in MTS up and running in JS. Obviously as jfrazierjr said, there are some functions that will be completely unnecessary, either bc JS supports them natively (loops and branching) or bc they are "compensation" functions which are only there circumvent some limitation of the parser etc.

I don't have any time right now to learn new technologies (I know very little about OSGI) and I think Craig is mostly in the same boat regarding both OSGI + time.

Honestly I'd like to try to waive you off from this approach for the exact same reason. Or at least keep this in mind: You and Craig are having to learn a new technology ON TOP OF what you already know. So does everyone else who wants to contribute. I'm trying to teach myself JAVA, how to use Eclipse, Abielle, MTScript, and brush up on my Javascript-Fu. If you add OSGI to that, my brain housing group might just explode lol. I feel like chaining scripting implementation to the implementation of whatever OSGI does, would lead to more burn out from the current contributers and a quicker loss of interest for those just starting out like myself. Again, since I don't really understand what OSGI is or does, I won't say it's a bad thing to implement, just that if it is, it should be a seperate project from script implementation. Now here's why I think that won't really make it much more difficult to implement something like that after (or during) script implementation. Somewhere in the code there is a point where MT says in psuedo code:

User wants to run a script (which is what a macro is)
create a variable and stuff the text of the script into it.
call up the parser and send him this variable, he'll know what to do with the text inside.
Parser sent a message back that we should execute these functions in this order.

Now in my vision of JS implementation we just change it to this:

User wants to run a script
create a variable and stuff the text of the script into it.
when the user created this script did they check the javascript button in the gui?
>>>>>yes
>>>>>>>>>>call .eval() on the variable
>>>>>>>>>>since we exposed everything we needed at boot up, we already know what to do with these commands
>>>>>no
>>>>>>>>>>call up the parser and send him this variable, he'll know what to do with the text inside.
>>>>>>>>>>Parser sent a message back that we should execute these functions in this order.

Then when you add OSGI (which i'm assuming is just a translation layer) there isn't much more to change. If i'm missing something huge or obvious, by all means point it out so that I can help find a better solution. I've always wanted a software that could handle all of my digital gaming needs and MT is so close I can taste it. For me the only thing it's missing is a usable touchscreen interface (which I can hobble through by translating gestures into key combinations, but thats ugly, tiresome and in acurate.), and a scripting/expansion language that I can understand. I know it's open source, but i don't yet have the skills to make it happen on my own so i'm basically having to live off the scraps of those that do lol