Scripting/JS API wiki?

[Calvin McGowan]

I'm aware of the original Maptool wiki, and I'm familiar with Javascript and HTML5, but I've yet to figure out mote's specific way of handling it all. I see people referring to a wiki or docs in this google group, but I have no idea if that means the existing maptool docs, or some other mote specific docs. I'm particularly interested in how I might get something like the vanilla maptool [input()], but I haven't been able to figure it out. I also I tried HTML buttons with an onclick script in a frame, but the buttons didn't even render. So these would be my questions:

1. Where do I find docs for the mote JS stuff, since clicking the little brain button in the macro editor just takes me to the wiki for the standard version of maptool.

2. How would I create an input dialog with a JS Macro?

[Idle Ideas Inc.]

Hi Calvin, and thanks for tackling the new features :)

1. We intend that all JS functions work the same as their Motescript counterparts. So everything should expect the same input, and produce the same output (whenever possible). I say "whenever possible" because, for example, Motescript uses BigDecimal prevalently, whenever a function means to return a number. There is no direct translation to and from the JS engine, so we utilize primitives like integer, float etc. Back to the point, the MT and Mote wikis contain the relevant information for the JS macro functions. More info is found in code-completion, as well.

We, long ago, made a move to standardize how functions are grouped and named. You will notice we have alternate names for most of the old MT functions. We carried over this scheme, into the JS feature, but didn't keep the old MT ids. Under Tools, there are a couple of methods to translate MT script to the Mote standard, which you may find useful if you intend to translate over to JS, any of the MT script that is found out there. 

2. We have yet to get to importing the input function. However, I believe it's better to use the new features, since you can make a modal HTML dialog/frame, and retrieve form data from these. OF course, I don't know your design intent and maybe the input function is what you're really after, so I've earmarked the team to translate it to the JS API, to be ready on the next release.

Have you gone over our (evolving) blog post on the JS and HTML5 features? While these technologies are inter-related in the real world, in Mote, they are separate modules. We apologize for the sparsity of information, we released both as simple implementations, with the intention of making them robust via direction coming from the user base. We assure you, we work fast and we're very responsive.

Outside of the application, expect that the features should behave as they would, based on "real-world" usage.

With that being said, please feel free to sound out your design goals, and needs, and we'll do our best to meet them.

Thank you for your support :)

[Calvin McGowan]

So I'm reading the HTML5 post, and I have got forms rendering now, but I've yet to figure out how to get any actual use out of them.

What I'd like to do is create a form that allows the user to select an enemy, either by having them selected in mote or via a dropdown menu with all the visible targets, and then enter other miscellaneous attack info like the number of shots to fire or any special attack modifiers. The macro would then take this input, make some rolls, apply the damage and other effects to the target, and then print out some output to the chat log.

I get as far as the form, but it's unclear how I'm actually supposed to make use of any of the entered data. The blog post tells me that I can use <script> tags, but then immediately afterwards says that it's vanilla JS only. That's interesting I guess, but it means I can't even do something as simple as client.tell("some words"); Near the bottom of point 5 it mentions using window.data to handle passed information, but as far as I can tell that's only information passed into the HTML macro, and no information is passed out of it. Is there some way to do that? Because I haven't figured it out so far. Using action= in the form tag also seems to do nothing, putting the title of another macro in there doesn't seem to run that macro pass the form data for example.

Translating the MT input dialog to JS would vastly simplify things, and its really cool that you're doing that for next release, but if there's a way to do it with an HTML5 form I would go with that. The old [input:()] is great if you need something quick and straightforward, but the flexibility of a full featured HTML5 form is hard to beat. The only roadblock being that I can't figure out how I'm supposed to pass the form input along to another macro when I press the Submit button.

[Idle Ideas Inc.]

Hi Calvin,

We're really happy to have this design conversation! As you may have noticed, while there are others who we see using these, you're the first to bring these up.

I apologize for a hasty reply, I'm currently in an important meeting but took a break to reply.

Our ideas on what you said are these:

• Scripts in forms/sheets etc should just involve the form/sheet i.e. display, data manipulation and return
  
• For the stuff you want to do, do it in the macro. So it would be like:
• Collect information you want to use e.g. token data
• Pass it to the form via the intermediaries we made e.g. user data object
• The sheet does its thing and then submit the data back to Mote, for the rest of the macro to use. There is a DataBinding object you can use in the Javascript to do the pass back. Acceptable data types are numerical, JSON, and String. You can get a hold of this data, by using the window.data function
  
  I wasn't the one who worked on this portion, but IIRC, do not use the regular form submit button, but instaed, use a button that calls a function that collates your data, processes it to be passed back via DataBinding, and close the form (or leave it open)
  
  I now see we missed documenting this last bit. Please try it out and let us know how it goes.
• Once the modal form closes, the rest of the macro, with the returned data from window.data, continues to execute.
  
  
• I think the last bullet may answer what you're asking for in your last line.

Sorry, I have to go back. Please keep posting and I'll address it later.

Thanks.

[Calvin McGowan]

It sounds like all the functionality I need is there, I'm just having a little trouble figuring out how to access that functionality. Below is my idea of how this is supposed to work, and to some extent I'm essentially repeating what you just said, but I'm just trying to get this all straight in my mind. Let me know if I'm on the right track.

1. Run the base JS macro.

2. The base JS macro calls getVisibleTokenNames("json") or whatever the JS method name is called to get a list of all the tokens that the player can see.

3. The base macro calls the HTML5 macro which contains the form. The json object containing all of those tokens gets passed along via the DataBinding object, which is used to populate a dropdown input thingy.

4. The user makes their inputs, chooses whichever target in the dropdown, etc.

5. The user presses a button for a function that collates the data and processes it to be passed back via DataBinding.

6. The form automatically closes, and then the base JS macro does the rest of it's work.

Seems sensible? I do have issues with a couple points though.

For #3 I'd access the DataBinding object via window.data(), but how do I get the data to the DataBinding object in the first place? I'm aware of the User Data button in the F5 menu for the macro editor, but the blog post says that acceptable values are strings, numbers, JSON, etc, and while I do want to send the data as a JSON, I don't see how I could send a dynamic JSON. Predefined JSON sure, but I can't predefine the list of people that the player will be able to see at any given time.

For #5 the code completion notes for window.data() tell me that it's only useful for the HTML5 feature. How then am I supposed to reference the DataBinding object from the base JS macro? And if I'm supposed to "push" it from the HTML5 form what method am I supposed to be using? And now that I type that out it just doesn't sound right at all. After all, why not allow window.data() in normal JS macros? That seems at first glance like the way it's meant to be done, and I've yet to figure out the way that it's actually done. Unless I'm misinterpreting the remark about window.data only being useful for the HTML5 feature, and I can call it from the JS? I must admit that while I am currently trying this all with a prototype, my difficulties in getting this to work might not necessarily be due to this one specific portion of the script.

Also for #5, the function that is called from the button would be defined in the HTML5 macro itself using <script> tags, correct? Or would it be defined in the base macro using function.define() or function.create()?

Ultimately the answers for those questions seem to come down to "Use the DataBinding object", I just don't know quite how.

And I really appreciate you taking the time to help me out with this. My last version of this macro was 1006 lines long when written in MapTool's scripting language, mostly due to the fact that it's looping and if statement logic is really not very powerful at all. Being able to recode this all in JS is going to make things much easier.

[Idle Ideas Inc.]

Give me some time Calvin, I read this, but I'm currently on a call with someone.

[Idle Ideas Inc.]

Actually you use the DataBinding object to return data back to the macro. As for passing data, you can use one of the newer forms of window.new, that allows the passing of user data.

Yes, the flow you outlined is indeed sensible. However, getVisibleTokenNames has not yet been ported over. IIRC, it's Mote counterpart is token.visible or something close to that. A You'll see a mention of deprecation on getVisibleTokenNames, that refer to the Mote's version. We'll port it for you on the next release. Do mention what other such functions you'll be needing so we can toss them on the pile :) A tip though, it's almost always better to work with token IDs, instead of their names. While resolution will eventually find the token needed, it's more direct to use the id.

Regarding #5, for now, yes, you'll need to define it on the script portion of the html form. We will (soon) eventually write the referencing of macros to store Javascript that can be called, in the form most Mote users are familiar with e.g. javascript_macro@lib:token. We are also open to white-listing script libraries that are found online, as long as we get informed of its usefulness and safety etc.

Macro JS, on other hand, allows the definition of functions that are passed to the global context, so they can be used during execution.

No problem. We're happy to help. You're helping us too, flesh out this feature and this will make everyone happy :) We did as much as we can with MT script and parser. while there are still several ideas we'd like to pursue in the future, it's pretty much what it is, in terms of what it can do with regard to what you mentioned. We did defeat nested code levels issue long ago :D

[Calvin McGowan]

So the base macro passes data to the HTML5 macro with window.new, and the input from the HTML5 macro is passed back with the DataBinding object? Alright, but I still find myself asking how. 

Regarding window.new, all of the versions of the method create a brand new window that I then need to define within the JS macro. Is this what I'm meant to do? Not use a separate HTML5 macro, and instead define it all within a single JS macro? If this is not the case what method name would I use to pass data from the JS macro to the HTML5 macro? Also none of the variants of window.new I see in the code completion dialog seem to pass user data. Prefs, props, and type, but not data/input/etc. 

Regarding returning the data from that window, again what method am I meant to use? I'm guessing that it's window.data since it specifically references "this window's Data Binding object", but it asks for the window id and I don't see a way to get that. A test with "client.tell(window.list());" confirms that all it gives me is the name of the window. If window.data is the correct method, then how is the window id determined?

It also doesn't quite explain how to put data into that DataBinding object in the first place. Above you mentioned defining a function to collate the data, etc, to be passed back via the DataBinding, but if a <input=submit> doesn't actually do anything then I don't see how. A search in the code completion dialog also doesn't give me anything for setting the DataBinding object's values. Again, what would the method name be here? 

[Idle Ideas Inc.]

Yes. Sorry we're still catching up with the documentation.

 

Also none of the variants of window.new I see in the code completion dialog seem to pass user data. Prefs, props, and type, but not data/input/etc.

....what method name would I use to pass data from the JS macro to the HTML5 macro?

 

We missed adding the description for "data" in window.new. You pass it as a member of the "props" JSON object argument (one of the code completion entries says "prefs" - corrected on the next release). You can then, in the HTML code, reference it via the window.data . 

the input from the HTML5 macro is passed back with the DataBinding object? Alright, but I still find myself asking how. 

Ah I see I forgot to say this. To use the DataBinding object, in your HTML's JS script, it has a member method called set, which takes an argument of arbitrary data type i.e. DataBinding.set(arg). We're thinking of renaming it something more intuitive like Return. We'll let you know of the final change, on the next release.

Is this what I'm meant to do? Not use a separate HTML5 macro, and instead define it all within a single JS macro?

If I got your question correctly, you can do both. Define everything in one macro, or use a separate macro to store the HTML code, and then fetch it via function.command, to be passed to window.new's html argument.

Regarding returning the data from that window, again what method am I meant to use? I'm guessing that it's window.data since it specifically references "this window's Data Binding object", but it asks for the window id and I don't see a way to get that. A test with "client.tell(window.list());" confirms that all it gives me is the name of the window. If window.data is the correct method, then how is the window id determined?

A window's ID is the name/title you gave it. So the JS macro might look like this pseudo code (Edited on 03/13/2018 to reflect API and feature changes):

html = macro.command(macroSource);
args = <your json object that holds window properties; user data is passed here>;
window.make("id", html, args);
returned = window.data("id");

The HTML:

<script>
function ret() {
   //process data to be returned
   window.data.set(data);

   window.host.close();
}
</script>


<body>
   <button onclick="ret()">Submit</button>
</body>

HTH. Do let us know of your progress :)

[Calvin McGowan]

I think I have the form itself sorted out, but I'm having issues with the function.[whatever] methods. 

I'm trying to use function.indicies() to get the index of the macro button, since function.command() can only take the reference as an index, but both of those methods give me errors. 

".indices" and ".command" both get underlined in red with the tooltip saying "missing ; before statement"

I tried a simple test run with the following:

var macro = function.indices("ToHitForm");

client.tell(macro);

but the output is simply

Parser Error

SyntaxError: Unexpected token .

Error on

var macro = function.indices("ToHitForm");

Executed from: Lib:Rules

Macro name: ToHitRun

Trusted Macro: true

Also, is there any plan in the future for function.command() to take something like "ToHitForm@Lib:Rules" as an argument, in addition to the current index method? Since I can only assume that the index would change if the buttons were ever re-ordered. Though I don't really know for certain since I haven't gotten function.indices() working.

[Idle Ideas Inc.]

We're ahead of you on several of these issues.

Yes, unfortunately, since function is a reserved word in JS, this causes a problem. We were able to used these in the past due to some string manipulation that we since removed on one of the previous updates. To resolve this, we're renaming the API group to "macro" i.e. function.command  => macro.command

We've already made that form of macro.command (function.command). You can pass a macro name, instead of an index. But since we have the function token bug, you won't be able to test it.

ETR for the next release is within the next 48 hours. Let us know how else we can help :)

[Calvin McGowan]

Awesome, if only some of the software vendors I deal with at work were so great with their support.

I have only two remaining questions then, at least until that update comes out. 

1. Would it be possible to allow DOM manipulation in the HTML forms and dialogs? Using onclick or other functions to switch the display type between "none" and "block" for example so I can create tabbed character sheets, more complex macro input dialogs, etc. Right now it simply doesn't update. Though I suppose I could do this with a Javascript macro as the base and repeated use of window.update(). The only trouble there is that it's a little less flexible.

2. Why does clicking a button, defined as "<button>Test</button>" or anything else really, blank out the dialog? At first I thought it was a misapplication of what I was trying to implement above, but even that example there with no called code causes it to blank. That's not a problem if clicking the button is the last thing I do with that form before it's closed, but I could see it causing issues with stuff like character sheets.

[Idle Ideas Inc.]

We aim to please :)

1. We'll get there, again, starting from a simple foundation, and evaluating what get's added, over time. Our first addition, on the next update will have an option to use jQuery. It is passed on window.new (will become window.make, on the next update, due to reserved word conflict in Java i.e. new), as part of the props JSON, member key is jquery, taking a boolean value. For HTML5 macros that uses the properties panel, there is also a toggle for that, as well :)

I haven't checked it myself, but isn't the document object working? In the absence of jQuery, I surmise that'd be the thing to use.

2. That shouldn't be a problem on the next update. It's a new feature and we're playing around with refreshing content within the Swing container. In the version your using, we utilized the same scheme we wrote to use for the older version of HTML frames and dialogs. We recently discovered that it doesn't play well with our HTML5 view, so we wrote it a new one. It looked good, the last time I ran it. If you can post a script sample we can use to test, we can fine tune things even further.

[Idle Ideas Inc.]

As of this time, the data binding (Java) object that is bound to an HTML5 form/view, is accessible via the window.data object. So, setting its value (in the HTML5 form/view) will be done through window.data.set(value). Retrieving this in JS, will be as usual, via the window.data(windowId) function.

We've also changed how the data passed to the HTML5 view/form is accessed. From window.data, it's now going to be window.args. We'll provide samples on the documentation, soon.

We're still working on some feature additions, so there might a slight delay to the next release. We're sure everyone will see it's worth the wait :)

[Idle Ideas Inc.]

The update is out :)

do let us know of your progress.

Thanks.

On Friday, March 9, 2018 at 4:57:02 PM UTC+8, Calvin McGowan wrote:

[Calvin McGowan]

So with my Mote working once again, I'm back to this problem, using the new functionality this time. The code I have is as follows:

A JS Macro named "Window Creation Test"

var html = macro.command("window");

if (html == null){

     html = "<html><body>Test Failed</body></html>";

}

client.tell(html);

window.make("window", html);

And an HTML Macro named "window"

<!DOCTYPE html>

<html>

<body>

   <button>Submit</button>

</body>

</html>

I have two problems currently.

1.   When I try to run "Window Creation Test" from the campaign macros, with "window" also in the campaign macros it fails, and says that the macro with index/ID "window" does not exist on token information. This seems to be resolved by placing the "window" macro on a token and impersonating it. Is this intentional? If it is I suppose that I should be using library tokens for macros like these, rather than storing them in the campaign section? (Now that I write this down, I feel almost as if I already asked you guys about this, and you might have told me already to do the library thing.)

2.   When I do the above, placing the "window" macro on a token and impersonating it, trying to run "Window Creation Test" still fails, but differently. The error in this case is "Invalid string for JSON passed. Please check: null", error on the "window.make". But I'm doing a null check, and not only that but the client.tell actually does print the html from the "window". Granted, it prints it as HTML 3.2, and the <button> tags don't work, but it does print it to the chat window. The same goes for running the "window" macro directly, a little box pops up with a submit button. I'm also not trying to use the version of the method that passes JSON.

In the long term I would like to be able to create an HTML/JS macro that allows me to create a window that can be updated by clicking buttons within it, likely using the window.host.update method, but for now I'd like the get my proof of concept in order before I start getting into more complex logic.

[Idle Ideas Inc.]

Hi Calvin,

Aside from the MT wiki, there's another one for Mote. Both are accessible via the Help menu. We'll admit that there's a lot to improve in the Mote wiki, but the good news is, we've ported most, if not all, of the useful macro functions as is, into JS counterparts. The functions/methods are the same. When in the editor, set the language to JS and just try out each letter. Auto-complete will pop with whatever is available.

IIRC, an input window can be made just the same way. I'll have to ask the one who implemented it for details. Also, IIRC, we made an alternate window component that is also modal. I'm not sure anymore, but I do believe I mentioned it before.

On Friday, March 9, 2018 at 4:57:02 PM UTC+8, Calvin McGowan wrote:

[Idle Ideas Inc.]

Let me go over this with the others who know more about it.

1. No. We want macros to run like they always do, wherever they're on.

2. We'll get this fixed as soon as we can. It will help a lot if you can share a campaign or token that have these issues. 

Sorry for all the inconveniences, Calvin, and thanks for helping us straighten all things out :)

[Calvin McGowan]

Here's my test campaign as it exists now. And thanks for all the help.

[Idle Ideas Inc.]

Thanks for sharing, Calvin. We've addressed a couple of issues that got in the way of creating windows. I don't know how those crept in after testing, sorry XD

On another note, I was right, you can make a modal dialog using the new HTML5 window. You just have to pass "modal" in its properties, and set it to true.

We are in the process of putting together an update and a new installer. It should be out in a couple of days. 

Thanks for your patience :)

[Calvin McGowan]

I see that an update was put out. I don't know if it was the one you mentioned might fix my window problems, but I haven't been able to check because I've been getting the following error again since updating:

[Idle Ideas Inc.]

sorry about that, Calvin. we're doing tests and had to flip a few switches.

Please try again, and do let us know how else we can help :)

[Calvin McGowan]

Unfortunately it's still giving me that error.

[Calvin McGowan]

On the other hand, I just directly copied one of my old Maptool macros to Mote. It's a little over a thousand lines long and is built so that it ends up looping through the majority of those 1000 lines depending on what the user enters. In Maptool it causes a stack overflow if you try to loop through it more than twice. In Mote however it seems like it's working fine for 10+ loops through. So really really good job tightening up the macro parser.

[Idle Ideas Inc.]

thanks :) it was a labor of love and we believe users still have not yet scratched the surface of what can be done in mote :)

[Idle Ideas Inc.]

really sorry for missing this! I flipped the switch in the wrong service instance. it should we working now.

really sorry for the lost time :(

[Calvin McGowan]

No problem man, stuff happens. And it looks like the update fixed my issues with the macro as well.

[Calvin McGowan]

Alright, I have the window appearing when it's HTML macro is called from my JS macro. However my test button is non-functional. When I click the submit button on the window it should print "Hello World" to the console, pass it's data back to the JS macro, and close itself. However it doesn't even do the client.tell(). I've got the campaign file attached, and I'm not really sure what I'm doing wrong here. Additionally it appears that the JS macro can only call the HTML macro if it's attached to an impersonated token, never from the Campaign macros.

[Idle Ideas Inc.]

hi Calvin,

As it is now, scripts referenced via the src attribute, are the only ones that get executed. Furthermore, only scripts hosted on an in-app location i.e. Token, Campaign, Global, are allowed (i.e. no http etc). So a proper script tag will look like this:

<script src="example@lib:token"></script>

However, it was always intended for this to be expanded to allow declarations such as the one your test macro, defines. The good news is, we're working on it right now and should be available on the next release.

[Idle Ideas Inc.]

Had time to look at this myself, and here's what:

• Your code works
• However, our HTML5 windows aren't directly linked to the main JS parser (which is linked to the underlying scripting system). Windows use their own "engine".
• This is the reason why processing is done within the window, and any resulting data is returned back to the app, via the data bridge.
• With that being said, once data is returned, you can use it with the main JS engine and all it's built-in functions.
• The current prescribed flow is to write your html, but call it from another macro so its return can be used by the invoking script, like so
  
  
  window.make or window.open //for pre-created windows. remember to make it modal
  //process any in-form data within the window. note that it cannot directly access the Mote API.
  //store results in window.data before closing the window
  //do something with window.data e.g.
  client.tell(window.data)

We'll eventually write a process where an HTML macro, such as the one you wrote, can be used directly. It's not that difficult, but we don't have the time right now. All that's needed is a callback or a registered hook back to the app that users can exploit.

[Idle Ideas Inc.]

We've finished making process flow 2 i.e. direct HTML macro call, with callback. Works like a charm. We'll need to test several things out, as well as give more time to flesh out the concept, if it can be expanded further before release. 

It should be ready by mid-week, hopefully :)

Thanks.

[Calvin McGowan]

Would that make proper DOM manipulation possible? Or at least easier? I'm thinking of a window that modifies itself when buttons within it are pressed. Or should I be relying on window.update here?

[Idle Ideas Inc.]

Isn't it already? What script/code do you have in mind. You can enable jquery by passing the argument for it (setting it to true).

As long as you don't make any "out" calls to the Mote API and keep things within the window object, what you have in mind should work. If not, then I imagine it will take just a bit of writing on our part, to make it so. Give us a sample and we'll get to it ;) 

Thanks for working with us on this, Calvin :)

[Calvin McGowan]

Expanding on my previous window test macros, I have the following.

An HTML macro with this code, called "window":

<!DOCTYPE html>

<html>

<script src="example@Lib:Macros"></script>

<body>

<div id='test'>Does the button work?</div>

<button onlick="test()">Submit</button>

</body>

</html>

And a js macro with this code, called "example":

function test() {

document.getElementById("test").innerHTML = "Yes!";

}

Now when I run the HTML macro and click the button I expect to see the text within the test div change to "Yes" but it doesn't. However, when I change the JS macro to just include the following:

document.getElementById("test").innerHTML = "Yes!";

It immediately changes the test div upon the loading of the window, which is what I would expect if I was referencing the script correctly. So referencing the script works fine, but defining functions does not. Or at least, if it does, the button I made can't call the function.

[Calvin McGowan]

"i.e. direct HTML macro call, with callback. Works like a charm"

I'm not quite sure what's meant here. Does this mean that you can just write the JS within the HTML with <script> tags?

[Idle Ideas Inc.]

You are able to set, in the HTML window properties, a macro id, that runs immediately after the modal window closes. In it, you'd probably do window.data, and process it from there. You can either do your script(s) within the tags, or reference scripts stored in other macros.

[Idle Ideas Inc.]

I'll take a look at this, though any changes will be seen on the update (or 2), after the next release. 

Thanks!

[Idle Ideas Inc.]

This code works in the upcoming release :)

Also you have typo for "onClick" ;)

[Idle Ideas Inc.]

The update is out. Thanks.

[Calvin McGowan]

I just went to re-test my macro with the update, and now when I go to run the window the button doesn't render as a button. If I had to guess, I'd say that it's rendering in the HTML3.2 standard, instead of HTML5. The only change I made was to fix that typo you mentioned. And even when I undid the change it still fails to render as a button, and instead there's just the word "Submit".

As for modal dialogs calling a macro upon close, the particular use case I have is for a character sheet built as an HTML macro. The idea would be to have the sheet open constantly, throughout the whole play session. The values, stats, skills, etc would be fetched from the player's token (Or even better, and XML macro) and that would get formatted nicely by a script that puts the appropriate values in the appropriate divs in the HTML. Some light DOM manipulation would be used so that players could press a button to expand or collapse certain sections, and there would be buttons next to skills and stats that would then call a macro to roll against that stat.  The macro in that case would be either JS or Motescript. 

Now if I were to break that down into specific features they would be as follows:

1. Ability to fetch data from an XML macro. (Maybe this already works, I just haven't made it this far into my experimenting.)

2. Ability to write JS within <script> tags in an HTML macro that can then be called by pressing buttons, etc, on the HTML window (Which judging from your above remark works now? In which case that's super awesome)

3. Ability to call external JS/Motescript macros from an HTML macro, either by leveraging point #2 or some other method. (Which judging from your above remarks either works now, or will very shortly? Also awesome.)

[Idle Ideas Inc.]

That's weird. It works just fine on our end. Did you check if you're logged in and/or have the proper content type set?.

1. This is already possible. Use macro.command

2. Also possible

3. You can call JS found on other macros, as one would as if they were declared using script tags. However, as I also mentioned, the application's API (Motescript, and the methods accessible by the new JS engine) is not yet reachable. We will eventually implement a link or bridge between the 2 features, but it would take quite a lot of work.

[Calvin McGowan]

I am logged in, and I do have the proper content type set, like I said, other than the typo nothing has changed. However I do notice something odd, when I first load the macro it does have the right content type selected, but the syntax highlighting looks like the Motescript syntax highlighting. If I toggle it from HTML/JS and then back to HTML/JS it recognizes the content type and highlights the syntax properly. However every time I close and re-open the macro it reverts to MoteScript style syntax highlighting despite still claiming that it's an HTML/JS macro.

I thought that the issue might be with the existing macro buttons, so I made new ones and copied the scripts over, but the button still fails to render as an actual button. The issue persists in both my actual campaign, my test campaign, and a brand new campaign freshly made. I've attached a screenshot of that last test case, both the result I get, and the entire view of my Macro Editor window. Also, just to verify that it actually knows I'm logged in, I tried to run a simple client.tell() in a JS macro and that does print to console.

As for your responses to the questions I asked...

1. Awesome.

2. Also awesome.

3. I'll be honest, I'm still not sure I totally understand the answer here, especially since this answer seems to conflict with answer for #1. 

So I can use <script> tags, and I can write JS directly within those script tags that will run/be called in the HTML below. But it needs to be vanilla JS, I can't use the Mote specific JS methods? That also means that I can't use macro.command() to call true JS macros that themselves contain Mote specific JS methods, or to call MoteScript macros, correct?

So if I wanted to get data from an XML macro and have it end up in an HTML window on the page I could not:

Create an HTML macro, and within that macro use <script> tags to access the XML via macro.command() and then parse it. OR Create an HTML button that calls any Mote specific JS or MoteScript.

But I could:

Create a JS macro, and within that macro use macro.command() to access the XML, parse it, and then use window.make() to create the HTML window. And if I wanted to do any DOM manipulation in the window I'd need to use window.update() from the JS macro?

Basically, if I want HTML and Motescript/Mote specific JS to live in the same world, I need the a JS macro to be in charge, not the HTML macro?

I'd try to test some of those examples before bothering you about them, but JS/HTML macros don't seem to be entirely behaving themselves for me right now. On the other hand, MoteScript macros are fine, and I've been testing something like what I described above, but with MoteScript rather than HTML/JS. I always ran into memory issues when I tried it with the questionably sound Maptool parser, but despite my best efforts I cannot get the Mote parser to break. So it looks like I'll be able assemble my crazy character sheet macro with the existing functionality, rather than expecting you guys to work yourselves to death to fill a niche use case :P

[Idle Ideas Inc.]

Hi Calvin,

A bit busy right now, so sorry for the late reply. Also, being busy, I might not give quite as good an answer as I usually do.

I'll check on the editor acting up like that.

As for #3, if you write things on a purely JS perspective (in the context of the window and the limitations placed by Mote i.e. no referencing of scripts found outside Mote), where you can reference scripts located on other macros using <script src="macro@lib:host"/>, and then it should make better sense, I hope :)) 

We will eventually bridge the 2 engines. When we say we will, we will. It's just a matter of when LOL

As for XML, have you tried just running it directly? The engine should be able to render XML out of the bat. As I wrote that line, however, I'm not sure if the logic for XML-type content branches directly into the HTML5 feature, if not, look forward to it being done by the next release :)

But I could:

Create a JS macro, and within that macro use macro.command() to access the XML, parse it, and then use window.make() to create the HTML window. And if I wanted to do any DOM manipulation in the window I'd need to use window.update() from the JS macro?

 

The method you describe is convoluted, and not something we want as standard in Mote. Let's hash things out to get it to be as easy and seamless as possible ;)

Basically, if I want HTML and Motescript/Mote specific JS to live in the same world, I need the a JS macro to be in charge, not the HTML macro?

Right now, yes, though the last release might help make HTML macros more workable for your ideas. Ideally, everyone should have both.

We do hope you'll keep working with us to get the JS feature working to your liking. It helps us perfect it, for everyone else to enjoy :) 

Lastly, while no one has attempted it yet, I think it's perfectly plausible to use MoteScript for everything, then just use an HTML5 window, for a better display/UI. 

[Idle Ideas Inc.]

We checked on the issue shown by your screenshot and it happens if you're not logged into Sandstorm. When that happens, the html is sent to the old 3.2 renderer.

Do you log in manually or let Mote automatically log you in? Perhaps in one of those chains, is the source of the error.

[Idle Ideas Inc.]

We've started a thread to field input from users, which relates to this topic. Please feel free to add to the discussion :)

[Calvin McGowan]

I was logged in manually. Seems like the bug I was getting before. But now it's not telling me that it thinks I'm not logged in.

[Idle Ideas Inc.]

But you're still able to run JS and use the other features?

[Calvin McGowan]

Yeah, which is weird. A "client.tell("test")" works just fine, but HTML still renders as HTML3.2, despite my best efforts. I've also got the Doctype declared properly as well, as I'm pretty sure that's what makes the parser parse in HTML5 instead of 3.2.

[Idle Ideas Inc.]

Please try again. I'm sorry for only getting to this now. It's been toxic at work recently... :)

[Calvin McGowan]

Works perfectly now thanks.