Preview build for 1.4.somethingorother

[Craig]

I have created a preview/test/dev/whateveryouwanttocallit build for people to play around with and hopefully provide feedback.
The campaign format should be completely compatible with the latest 1.3 builds but as always backup before trying it


Edit: Update and a new build viewtopic.php?p=256785#p256785

You can download what you need from http://maptool.craigs-stuff.net/test-builds/

This build adds either one or two new features (depending on how you want to look at it) that are not yet ready to be used in anger.

• Added a new macro command /experiments. This command allows you to start experimental features that may be in a build.
• The MapTool client now contains a webserver that allows you interact with the local client via web browser (well just about anything but we will say browser for now).

To start the webserver use the /experiments macro

Code: Select all

/experiments webapp [port]

e.g.

Code: Select all

/experiments webapp 8000 

You will then get a message in the chat box about where you can point your browser at to continue, before you continue though I must warn you that the HTML is butt ugly as I only threw it together to test as I was developing, and what can I say I haven't had the need to do much html5/css/javascript before, nor have I ever used jquery before, (but you can try your own and make it prettier, more on that later in post). I also expect this functionality might be a little flakey still so don't get frustrated if things dont work the way you expect, also if you run MapTool from the command line you will see copious amounts of debug info printed out (sorry about that). None of the messages are localized yet but they are just place holder messages (and sadly most of my knowledge of other languages is restricted to profanities learnt in the school yard during early high school which I didn't think would convey the message adequately)

I have tried Chrome, Safari, and Chrome on Android. It should also work on Firefox, Firefox Mobile, Safari Mobile, IE 10, IE 11, and Opera (but not Opera Mini).
If you have an error on one of these (ignoring the HTML formatting for now) can you please let me know.

What you will see when you first load the link is the initiative, so if MapTool looks like this

Screen Shot 2014-12-08 at 10.57.19 pm.png (54.28 KiB) Viewed 3654 times

Then the browser window will look something like this

Screen Shot 2014-12-08 at 10.58.18 pm.png (137.13 KiB) Viewed 3654 times

Any advancing of initiative in MapTool will be reflected in the browser (or browsers) and any in the browser will be reflected in MapTool and other browsers connected.
If you click on the "Sheet" button you will get a really rudimentary (and did I mention quite ugly) stat sheet (based on the properties defined as visible) and a list of the
macros. If a token changes this will be updated (no need to refresh). You can also run the macros by clicking on the macro buttons, the results will appear in MapTool chat.

At the moment everything is run as the logged in user in the client you attach to. What I want to do is add the ability for GMs to allow users to connect as specific players to a GM client, this will be handy for around the table/projector type games where the GM can allow players to view character sheets/run macros etc from tablets or what have you. This of course means I intend for a way for GMs to add their own HTML/Javascript/CSS to be served. Also once HTML5 is available in MapTool (shortly after we get everything working well on Java these would be viewable within MapTool so you can have HTML5 character sheets that should be viewable from within MapTool or on a table without any changes being made (possibly phone too but thats a screen based thing).

But this is so ugly and doesn't show me really what can be done... You are right, its very basic and ugly (but functional) luckily for those that want to (and I am really hoping that some people will want to so I can get some feedback) I have added a way to serve up HTML files from a directory on your machine (there will eventually be a way of getting these into the campaign file).

I have only tested this on Unix based systems at the moment but there is no reason it shouldn't work under windows, please let me know if you have problems.
To do this you need to start the webapp with a URI path and directory on your local file system for example

Code: Select all

/experiments webapp 8000 /test=/tmp/my-new-mt-website

Will serve up files in the /tmp/my-new-mt-website, in the URL in your browser you will replace the /webapi with /test
So if the message you got was

Code: Select all

Webapp server has been started Connect to 
http://172.0.01:8000/webapi on your browser/phone/tablet.

Then unzip the web-stuff.zip (from the above link) into this directory
You would point your browser to http://172.0.01:8000/test (http://172.0.01:8000/webapi will still work but will show you the original that comes with MapTool not your changes).

You can the create your own web pages to be served up, you should not change the mtwebapp.js file or add/change anything in the bower_components directory.
But what can you do? Well I am glad you asked (ok not really since that means more typing for me).

The mtwebapp.js contains the MapTool javascript object that is used to get/send information from/to MapTool.

You can look at the index.html, initiative.js, tokensheet.js files to see how things are
To start with you will need to include

Code: Select all

    <script type='text/javascript' src='bower_components/jquery/dist/jquery.js'></script>
    <script type='text/javascript' src='bower_components/handlebars/handlebars.js'></script>
    <script type='text/javascript' src='mtwebapp.js'></script>

Once you do this you will have access to JQuery, handlebars (templating), and the MapTool api object.

API Functions available

• registerInitiativeListener(listener) - Registers a function to be called when ever the initiative is updated.
  Example
  

  Code: Select all

      handle = MapTool.initiative.registerInitiativeListener(function(data) {
          console.log('Received: ' + JSON.stringify(data));
      });
  

  
  The argument passed to the listener looks like
  

  Code: Select all

  {"initiative":[
      {
          "id":"000000003320F4F64700000000000000",
          "name":"Elf",
          "holding":false,
          "initiative":"14",
          "tokenIndex":0,
          "playerOwns":true
      },
      {
          "id":"000000003320F4F64700000000000000",
          "name":"Elf",
          "holding":false,
          "initiative":"11",
          "tokenIndex":1,
          "playerOwns":true
      },
      {
          "id":"000000003220F4F64500000000000000",
          "name":"Eagle",
          "holding":false,
          "initiative":"10",
          "tokenIndex":2,
          "playerOwns":true
      },
      {
          "id":"000000003320F4F64900000000000000",
          "name":"Elf 1",
          "holding":false,
          "initiative":"8",
          "tokenIndex":3,
          "playerOwns":true
      }],
      "current":1,
      "round":30,
      "canAdvance":true
  }}
  

  
  Where
  
  • Initiative - A list of tokens in the initiative list
    
    • id - The id of the token.
      
    • name - The name of the token.
      
    • holding - Is the token holding in the initative window
      
    • initiative - The initiative value
      
    • tokenIndex - The index within the initiative window.
      
    • playerOwns - Is the player (MT client connected to) owner of token
      
  • current - The index in the array of the token with the initiative
  • round - The iniative round
  • canAdvance - can the logged in player advance the initiative
• removeInitiativeListener(handle) - Removes an initiative listener
  Example
  

  Code: Select all

      MapTool.initiative.removeInitiativeListener(handle);
  

  
  
• getCurrentRound() - Returns the current initiative round.
  Example
  

  Code: Select all

      round = MapTool.initiative.getCurrentRound();
  

  
  
• nextInitiative() - Advances the initiative.
  Example
  

  Code: Select all

      MapTool.initiative.nextInitiative();
  

  
  
• previousInitiative() - Sets the initiative to the previous token
  Example
  

  Code: Select all

      MapTool.initiative.previousInitiative();
  

  
  
• sortInitiative() - Sorts the initiative list.
  Example
  

  Code: Select all

      MapTool.initiative.sortInitiative();
  

  
  
  
• tokenHold(tokenId, tokenIndex) - Toggles on hold for a token in the initative
  Example
  

  Code: Select all

      MapTool.initative.toggleHold('000000003320F4F64700000000000000', 0);
  

  
  
  
• registerTokenChangeListener(listener) - Registers a function to be called when ever a token changes/is added/is removed.
  Example
  

  Code: Select all

      handle = MapTool.token.registerTokenChangeListener(function(data) {
          console.log("Tokens changed: " + JSON.stringify(data));
      });
  

  
  
  The function receives a value like the following when a token changes.
  

  Code: Select all

  {
      "tokensChanged":["000000003220F4F64500000000000000"]
  }
  

  
  
  The function receives a value like the following when a token is added.
  

  Code: Select all

  {
      "tokensAdded":["000000003220F4F64500000000000000"]
  }
  

  
  
  The function receives a value like the following when a token is reoved.
  

  Code: Select all

  {
      "tokensRemoved":["000000003220F4F64500000000000000"]
  }
  

  
  
  
  Due to the way changes happen you may get more than one change event for
  a token change as well as a change event in addition to a add event when
  a token is added.
  
  
• removeInitativeListener(handle) - Remove a token change listener
  Example
  

  Code: Select all

      MapTool.token.removeInitiativeListener(handle);
  

  
  
• getTokenProperties(tokenId, callback) - Retrieves the tokens properties.
  This function retreives the list of defied properties for a token (this registered in the campaign properties).
  Example
  

  Code: Select all

      MapTool.token.getTokenProperties('000000003320F4F64700000000000000', function(data) {
          console.log('Received: ' + JSON.stringify(data));
      });
  

  
  The value received by the function looks like
  

  Code: Select all

  {
      "tokenId":"000000003220F4F64500000000000000",
      "name":"Eagle",
      "properties":{
          "Strength":{
              "name":"Strength",
              "shortName":"Str",
              "value":"10",
              "showOnStatSheet":false
           },
           "HP":{
               "name":"HP",
               "value":"27",
               "showOnStatSheet":true
          },
      }
      "macros":[
          {
              "label":"1d6",
              "tooltip":"Roll 1d6",
              "index":1,
              "fontColor":"black",
              "displayGroup":"Rolls",
              "group":"Rolls",
              "autoExecute":true,
              "maxWidth":"",
              "minWidth":"",
              "applyToTokens":false
          }
      ]
  }
  

  
  Where
  
  • tokenId - Id of the token
  • name - Name of the token
  • properties - The defined token properties
    
    • name - The name of the property
      
    • shortName - The short name of the property
      
    • value - The value of the property
      
    • showOnStatSheet - Is the property displayed on the stat sheet when the mouse hovers over the token
      
  • macros - The macros defined for the token
    
    • label - The macro button label
      
    • tooltip - The macro button tooltip
      
    • index - The macro button index
      
    • fontColour - The font colour of the macro button text
      
    • displayGroup - The display group for the macro button
      
    • group - The group for the macro button
      
    • autoExecute - The auto execute flag for the macro button
      
    • maxWidth - The maximum width for the macro button
      
    • minWidth - The minimum width for the macro button
      
    • applyToTokens - The applyToTokens flag for the macro button
      
• callMacro(tokenId, macroIndex) - Runs a macro on the MapTool client.
  Example
  

  Code: Select all

      MapTool.token.callMacro('000000003320F4F64700000000000000', 1);
  

  
  
  
• getProperties(tokenId, propertyNames, callback) - Retrieves the properties of a token
  Unlike getTokenProperties() this function can be used to get the properties of a token not registred in the campaign properties.
  Examples
  

  Code: Select all

      MapTool.token.getPropertiest('000000003320F4F64700000000000000', 'HP', function(data) {
          console.log('Received: ' + JSON.stringify(data));
      });
  
      MapTool.token.getPropertiest('000000003320F4F64700000000000000', ['HP', 'AC'], function(data) {
          console.log('Received: ' + JSON.stringify(data));
      });
  

  
  
  The propertyNames argument can be either a single property name or an array of property names.
  The value passed to the function looks something like
  

  Code: Select all

  {
      "tokenId":"000000003220F4F64500000000000000",
      "properties": [
          {
              "name": "HP",
              "value" 10
          }
      ]
  }
  

  
  
  
• setProperties(tokenId, properties) - Sets the properties on a token
  Example
  

  Code: Select all

  {
      MapTool.token.setProperties('000000003320F4F64700000000000000', {HP: 10, AC: 8});
  }
  

As well as the API functions above you can use the following URLS to fetch images.

• .../token/image/<tokenId> - Fetches Token Image.
• .../token/portrait/<tokenId> - Fetches Token Portrait.
• .../token/portraitOrImage/<tokenId> - Fetches Token Portrait if it has one otherwise its image.

I realise that using this API character sheets are going to be a little fidely to write, what I intend to do is add the ability to serve a standard(ish) web page that follows a few conventions and the API be able to connect up the properties to fields in the form etc without the person creating the character sheet needing to do much (if any) javascript coding, but that all depends on the API above, and the API above will still exist for the ore complicated stuff people may want to do. So hopefully people get a chance to play around with this and I get some feedback. Also if anyone wants to try their hand at prettying up the HTML before I get around to it (I have quite a bit more to do before I do that) you won't hear me complaining

[aliasmask]

Just got in. Looking good. I can't wait to use the initiative listen.

[JamzTheMan]

Interesting and awesome!

I could see a android app that does one simple task for me, alert my players that their init is up. Sometimes with 7 people they get distracted...

[Craig]

I could see a android app that does one simple task for me, alert my players that their init is up.

Ahah! I see that my group is not really on hiatus at the moment, instead they have just gone to play in your group

[wolph42]

frkn awesome! can't wait to check it out...but i guess it has to wait due to huge time limitations...

[RPTroll]

Holy Freakin' Crap!

Craig, if you weren't an ocean away I'd kiss you (assuming I could overcome the social awkwardness of that action and survived the possible pummeling afterward).

[wolph42]

ok found a couple of minutes to test it on a windows machine. Findings so far:

1. maptool-1.4.0.initial-2fbe259.jar and maptool-1.4.0.initial-7aeeed9.jar which one do I use?
2. started: /experiments webapp 8000 it works!! (used chrome). fiddled a bit with initiative and sheet and it all works.
3. next tried: /experiments webapp 8000 /test=/tmp/my-new-mt-website and got:

Could not execute the command: "experiments webapp 8000 /test=/tmp/my-new-mt-website", exception = Can not add a resource directory to a running Webapp server.

which I guess is the right answer to that command... but it begs the question: how do I STOP a running webapp server??
4. so restarted mt. And then ran:

Code: Select all

/experiments webapp 8000 /test=d:\dump\web

and went to: http://xxx.xxx.xx.xxx:8000/webapi/test also tried http://xxx.xxx.xx.xxx:8000/webapi/d:\dump\test but both failed (404: not found)
Probly doing something wrong... but unknown what.

I guess thats it for now. Awesome stuff!!

[Craig]

ok found a couple of minutes to test it on a windows machine. Findings so far:

1. maptool-1.4.0.initial-2fbe259.jar and maptool-1.4.0.initial-7aeeed9.jar which one do I use?

Well now thats odd, I need to look at the build and see why it included both versions :\
But for now use the 7aeeed9.jar (the one that matches the zip file).

2. started: /experiments webapp 8000 it works!! (used chrome). fiddled a bit with initiative and sheet and it all works.
3. next tried: /experiments webapp 8000 /test=/tmp/my-new-mt-website and got:

Could not execute the command: "experiments webapp 8000 /test=/tmp/my-new-mt-website", exception = Can not add a resource directory to a running Webapp server.

which I guess is the right answer to that command... but it begs the question: how do I STOP a running webapp server??

You can't at the moment. It is something that needs to be added though.

4. so restarted mt. And then ran:

Code: Select all

/experiments webapp 8000 /test=d:\dump\web

and went to: http://xxx.xxx.xxx.xxx:8000/webapi/test also tried http://xxx.xxx.xxx.xxx:8000/webapi/d:\dump\test but both failed (404: not found)
Probly doing something wrong...
thats it for now.

You want to replace the webapi with your URL path so in your case it would be
http://xxx.xxx.xxx.xxx:8000/test

[wolph42]

had a bit extra:

5. stopped there and read your entire OP. I'm curious about the callMacro one. Nearly all macros in my framework result in a [frame :]or sometimes an Wiki: input() request, which I guess would run on the MT client not the Browser client, resulting in a pop-up on the MT client. Now the Wiki: input() part I can imagine that would be a problem, but the the [form:] I would guess could make it to web client right (as its all html)?
Then remains the point of stuff the form sends back, which are always one macro call (the result handler) together with the chosen parameters in the form of a json.
Another potential challenge are form updates, e.g. a value which can be changed by a + button and a - button, will also update the entire form (by closing it, sending result to a handler macro, which starts the form again with the updated info), which means quite a bit of interaction between the MT and browser client.

Is this something that can/will be implemented in the foreseeable future?

You want to replace the webapi with your URL path so in your case it would be
http://xxx.xxx.xxx.xxx:8000/test

yup that was it! it works!

[Craig]

had a bit extra:

5. stopped there and read your entire OP. I'm curious about the callMacro one. Nearly all macros in my framework result in a [frame :]or sometimes an Wiki: input() request, which I guess would run on the MT client not the Browser client, resulting in a pop-up on the MT client. Now the Wiki: input() part I can imagine that would be a problem, but the the [form:] I would guess could make it to web client right (as its all html)?
Then remains the point of stuff the form sends back, which are always one macro call (the result handler) together with the chosen parameters in the form of a json.
Another potential challenge are form updates, e.g. a value which can be changed by a + button and a - button, will also update the entire form (by closing it, sending result to a handler macro, which starts the form again with the updated info), which means quite a bit of interaction between the MT and browser client.

Is this something that can/will be implemented in the foreseeable future?

So its still early days, there is a lot that remains still to be done.

The first step was really getting things hooked up (which they are now) and getting something that functions fairly well (its ugly but it seems to work well).
Now that that is working I have done a bit of behind the scenes clean up and started working on the next part which is the ability to define character sheets with just HTML/CSS where no JavaScript or MTScript is required (but still available as an option) and all the wiring up is done "automatically". The next step after that is getting a HTML 5 frame working in MapTool (which will require us moving to Java 8 first), and then fixing up the JavaScript library I have already written so anything you write now will work seamlessly in either the MapTool window or the browser.

Then comes the least fun bit... How to get the stuff in the browser/MT HTML 5 frame to work better with the current MT Macro script. The following are the thoughts at the moment "off the top of my head" while I am going through it some more I might come up with some thing better. For Prompt we could possibly implement the Prompt stuff in JavaScript as well, so you could prompt in the browser before calling the MTScript macro and pass those values, and change the current MTScript prompt to read from "passed" values if there are any otherwise perform the prompt so the macro works as it previously did if called from the button but can take values collected in the browser before hand if called from the browser, if called from the MT HTML 5 window this prompt() could just call the normal prompt and pass the values or ignore it and pass nothing having the MTScript macro prompt. There are probably some cases where scripts are prompting dynamically where this may not work but hopefully this will get most cases.

HTML dialogs/frames are more difficult. There are two options here, 1) try to patch them up when they are loaded so that they can be displayed in the browser, 2) have a tool (possibly built into MapTool that converts them). I am not sure how viable either option is, but I would be leaning towards the second as given the difference in HTML renderers there is bound to be a difference in output and the second option would be easier for people to fix up. Having said that there will be some times where no conversion will be required and its ok to have the macro still display into a HTML 3.x window as it currently does. Anyway as I said I will think about it while I am creating that bit and see if I can come up with a solution, it might be that current relatively static dialogs are so easy to convert by hand that it makes little sense to worry hugely about it, although I can see forms that have a lot of code generating them would be more troublesome.

[wolph42]

funny to see how off I am in the assumption that input would be a problem and forms most likely not. As it turns out the other way round.

You mention that a conversion of the frames/dialogs would be required for it to work. What kind of conversion are you talking about, so I can get a feeling of what to expect (I know this is still in a galaxy far far away, but I like to dream ).

It might help to have an example, here is one:

Code: Select all

[h:'<!-- -------------------------------------------- InputAttackForm --------------------------------------------->']
<!-- no new scope -->

<html><body bgcolor='[r:bColor]' style='font-size:8.5px; text-align:center'>
<table width='100%' cellpadding='1' cellspacing='0'><tr><td>

<table width='100%'><tr><td align='center' style='font-size:10px' valign='middle'>
    Ship: <img src='[r:getTokenImage()]' height='20' width='20'></img> &nbsp;  <b>[r:ship]</b>
</td><td align='center' style='font-size:10px' valign='middle'>
    Operator: <img src='[r:operatorPic]' height='20' width='20'></img> &nbsp;  <b>[r:operator]</b>
</td></tr></table>

[h:shipFacingList = "Fore, Port, StarBoard, Aft"]
<!-- Build four groups (fore, port, etc) and sort the weapons in these groups. Weapons with multiple facings will appear in multiple groups-->
[r, foreach(face, wpnFacingList,""), CODE:{
    [r,if(eval("has"+face)),CODE:{
        [h:groupTitle = listGet(shipFacingList, listFind(wpnFacingList, face))+" Weapons"]
        <!-- renders html code for a macro button -->
        [r:strformat(macroGroup)]
            <!-- in case multiple macro batteries are facing in the same direction and have not yet been fired, then the 'Salvo' optio is available -->
            [h:salvo = if(listCount(eval("wpnMacrobattery"+Face)) > 1,1,0)]
            [r,if(salvo): "<table width='100%'><tr><td width='80%'>"]
                <!-- add each weapon group subsequently -->
                [r,foreach(wpnGroup, wpnGroupList,""): eval("wpnFace"+wpnGroup+face)]
            [r,if(salvo): "</td><td width='20%' valign='top'>"]
                <!-- htmlMacroButtonSS generates a button build out of html code (basically a colored table cell with a shaded background image) -->
                [r,if(salvo): HTMLMacroButtonSS(100,"#440909","white", "<br>SALVO<br>&nbsp; ", "InputTargetForm", json.append("",eval("wpnMacroBattery"+face),ship,operator, "salvo", 0), shadow, "@this", "Use this button to fire ALL the macrobatteries which are left in this group<br>in one salvo. If you have more than 2 macrobatteries you can choose to fire one<br>of them first and then the rest in one salvo. To do this click the INDIVIDUAL<br>macrobattery FIRST and THEN this button.")]
            [r,if(salvo): "</td></tr></table>"]
        [r:macroGroupEnd]
    }; {}]
}]

[r,if(locWeapList == ""):"<b>You have fired all the ships weapons, click 'Resolve' to continue"]
[r:HTMLMacroButtonSS(100,"red","yellow","<br><b>RESOLVE ATTACK</b><br>&nbsp; ", "ResolveAttack", ship, shadow,"@this","First click on the weapons in the order you wish to fire them at the target.<br>When done, click this buttonand the actuall attack will commence. If you wish<br>to reset, you can do so BEFORE you hit this button, by clicking on the <i>Attack</i><br> button on the macro panel once more.")] 

in this form there is no 'submit' button, but only 'virtual buttons' which basically are colored table cell with a shaded background which look like buttons and with a hyperlink text inside that fires of the relevant macro.
Note that this only renders the html the form():{} is done outside of this macro to prevent stack overflow.

edit: hmm probly the nicest example...

[RPTroll]

HTML dialogs/frames are more difficult. There are two options here, 1) try to patch them up when they are loaded so that they can be displayed in the browser, 2) have a tool (possibly built into MapTool that converts them). I am not sure how viable either option is, but I would be leaning towards the second as given the difference in HTML renderers there is bound to be a difference in output and the second option would be easier for people to fix up. Having said that there will be some times where no conversion will be required and its ok to have the macro still display into a HTML 3.x window as it currently does. Anyway as I said I will think about it while I am creating that bit and see if I can come up with a solution, it might be that current relatively static dialogs are so easy to convert by hand that it makes little sense to worry hugely about it, although I can see forms that have a lot of code generating them would be more troublesome.

Thinking option 2 as well from a support standpoint with the adapter being outside-ish rather than inside-ish. The code is interfacing with a moving target in browsers along with other interfaces once people figure out how to use services to interface between non-MT components. The option 2 outside-ish path would blaze that path while still keeping the interface creation close to the base.

Good stuff, Craig. I hope to have some time to test this weekend.

[Craig]

funny to see how off I am in the assumption that input would be a problem and forms most likely not. As it turns out the other way round.

You mention that a conversion of the frames/dialogs would be required for it to work. What kind of conversion are you talking about, so I can get a feeling of what to expect (I know this is still in a galaxy far far away, but I like to dream ).
.

Hmm I might need more thinking time (and music for this) but at the moment the only real way i can see that one working is the [frame()] command doesnt open a frame when being run remotely instead it generates the html and sends it to the browser where it can be displayed wherever... This also means any click would need to be sent back to maptool to be processed (which could of course update the html requiring it to be resent/redrawn). any included css would also need to be patched up, but assuming that part works ok then they require no changes, but you still may have to make somecchanges to formatting/css. If that bit cant work well then more drastic changes might be needed (what though i couldnr tell tou just yet)

[wolph42]

thnx for the heads up.


Ill be patiently waiting....

....



....



....



....

you done yet..?

[Tanthos]

How's the future looking for changing from the former regex parser to a lexical parser?