Love it or Leave it: Current Macro Language

[Rumble]

If that turns out to be the case, I have pretty much no reservations any longer. I don't mind having to learn JS to code. I just hate the idea of having to redo everything I've done already.

A conversion tool would be the dog's bollocks, but yeesh - sounds hard.

On the other hand, personally, the more I think about it, the more I look forward to redoing everything to see if I can do it better.

[jfrazierjr]

If that turns out to be the case, I have pretty much no reservations any longer. I don't mind having to learn JS to code. I just hate the idea of having to redo everything I've done already.

A conversion tool would be the dog's bollocks, but yeesh - sounds hard.

On the other hand, personally, the more I think about it, the more I look forward to redoing everything to see if I can do it better.

First, I expect that no conversion tool will be 100%, so even if you run the tool, you need to know javacript BEFORE running it so you can fix things that don't convert easily.

One way to help mitigate this fact is to reduce your existing macros into logical units now and make liberal use of [macro..]. Also, don't forget that at least for D&D, there will probably be tons of people working to convert their stuff, so you should be able to borrow many common components such as attack(bonuses, critThreshold, targetDefense){} where bonuses is an object with things like {enhancementBonus=x, featbonus=y}, etc and targetDefense is something like {value=a, displaytext=b} This will return an object, with things such as

Code: Select all

var attackresult1 = attack(bonuses, critThreshold, targetDefense )
write attackresult1.roll 
write attackresult1.modifiedRoll
write attackresult1.IsCritical
write attackresult1.IsHit

Of course, I am simply using "write" as a placeholder for however it spits output to the chat window. Of course, instead of just using write here, you could then pass the above stuff to further functions for damage dealing(suggested to break out attack roll vs damage assignment)

The attack method would not do anything with the displaytext of targetDefense, that would be for latter printing out. Likewise, if targetDefense.value is not passed, then attackresult1.IsHit would not be set. etc.

At the end of the day, just because you can't start writing your javascript code and testing in Maptool today, that does not mean you cannot put some thought into how your code is arranged and how your objects in the future should possible look. For example, I personally LOVE the way Veggisama's framework makes liberal use of the [t:] (I think thats the one????) option to format the various elements in an attack or damage roll for the tool tip as you get the result and a tooltip with a nice break down the elements that made up the result.


Edit: The above was meant solely as an example of the top off my head and should not be considered a final thought product. Of course, there are more things that need to be incorporated into the thoughts about how each object should work and of course each person will have some differences as to how to deal with attacks, damages, and how verbose the output display information will look. It would be nice if the attack resolution stuff were separate from the display and everyone using the same GameSystem used the same attack() and damage() methods(again, just an example name) and then used their own custom displayResults(or whatever you want to name it) to build your output string for chat.

[Rumble]

I will likely just start from scratch. Since I don't know javascript, the best way to do it (for me) will be a start-from-zero rewrite. I've decided not to add any features or release anything new for my D&D framework until javascript is working in MT 1.4.bWhatever, and then I'm just going to start over.

I've given a lot of thought into how the code is arranged (within the constraints of the current language), and I know the approach I'll take, so it's a matter of learning the language. For that, I'll do better starting from zero (like I did with the MT script).

And I don't know if Veggie's framework uses tooltip rolls, or just tooltips via HTML <span> tags, but tooltips are my friend. I use them everywhere, except macro buttons.

[jfrazierjr]

I will likely just start from scratch. Since I don't know javascript, the best way to do it (for me) will be a start-from-zero rewrite. I've decided not to add any features or release anything new for my D&D framework until javascript is working in MT 1.4.bWhatever, and then I'm just going to start over.

Yea, I would probably start over also.

I've given a lot of thought into how the code is arranged (within the constraints of the current language), and I know the approach I'll take, so it's a matter of learning the language. For that, I'll do better starting from zero (like I did with the MT script).

I guess my thought where was reuse as much as possible. Ie, work with the other D&D 4E framework authors and try to come up with a single set of methods that do the "common" things and then leave the display output and UI interface to the individual authors.

And I don't know if Veggie's framework uses tooltip rolls, or just tooltips via HTML <span> tags, but tooltips are my friend. I use them everywhere, except macro buttons.

attackResult.png (13.57 KiB) Viewed 821 times

damageResult.png (13.34 KiB) Viewed 821 times

Opps.. yea, your right, he uses solid html to build the tooltips. But again, I like the specific output format of how it breaks down everything nicely.

[Rumble]

I guess my thought where was reuse as much as possible. Ie, work with the other D&D 4E framework authors and try to come up with a single set of methods that do the "common" things and then leave the display output and UI interface to the individual authors.

I don't object to the idea - reuse will just depend on what people are doing with their frameworks. I foresee easy reuse of the simple things - roll 1d20 and add modifiers, etc. - but it gets harder the deeper in you get. Given that I don't think any of the frameworks do the same things, I'm interested to see what shakes out.

[Darinth]

One of the very first things I see myself re-writing is my doAttack lib:token for 3.5 to be fully featured once javascript is worked in and hopefully we'll gain the ability to select any token for targeting purposes (including those we don't own) and that'll make that function vastly more powerful. It should, at that point, be universally usable to all 3.5 frameworks by taking an attacker, target, and all of the various modifiers it takes right now (with the ability to separate out the modifiers) and provide return tooltips.

I just realized... if the macroscript gets toned down as far as I'd like it to, it'd be really easy for Maptool to simply convert macroscript in to javascript at runtime and eliminate the runtime macroscript parsing all-together from the engine... You make a macro and when you press okay it converts it in the background to javascript and runs the javascript version which should be faster and allows us to give macroscript access to a few of javascript's features... maybe even more then just 'a few'.

[DrVesuvius]

The current macro incarnation has given us mucho goodness. Its provided use cases for the developers so they can see what Maptool can do and what the user community wants. Its worked through security issued and given the framework developers a way to contribute outside of submitting patches to the main code set. Those are not minor achievements.

Also, you don't have to rewrite your framework. You can continue playing in the 'production' version of 1.3 until 1.4 is finalized or you have time to rewrite in JS. That's my plan for the Savage Worlds framework. And you know what? I'm OK with that.

If I understand the dev path properly, 1.4 will have scripting as a major focus. That means things will change rapidly and my fear (and thus the reason for the poll) is that the developers will be dragged down trying to maintain the old language as the guts are ripped out of Maptool and reworked to support better macro/Maptool integration.

I know you don't want to lose all your hard work. I don't either but I'm more about new features and speedy development than I am about maintaining the old language in its current state. So I'm ok with ditching the current language early in 1.4 and moving on.

Also, your work isn't wasted. It will live on. If you don't believe that just take a look at the list of people stilling running 1.2.

(points) What He Said. Pretty much sums up my feelings on the matter now.

I'll be happy to carry on using 1.3.final until JavaScript is fully implemented on 1.4 AND 1.4 offers something cool that 1.3 doesn't.

[JML]

Hi everyone, sorry to ask a noob question, but I'm one after all

As I'm new to MapTool and I'm currently wrestling with macro language to code my own framework, I drooled reading about a switch to Javascript.

My question is : does anyone as a clue to when 1.3 will be considerer final and 1.4 development will begin ?

I tried to find an answer searching the board and the wiki, but I'm very bad at it and didn't find one.

My concern is the same as most newbies here, I think : how much time do I get to invest in the old macro language before the team's work and efforts brings us a more efficient one ?

[CoveredInFish]

Im pretty sure it will take a lot of time until 1.4 is in any state that can actually be used. Even if they step from concept to coding it will take its time until they have a stable and feature rich result.

[JML]

Which means I've got to invest in a thorough learning of the present macro language if I want to set up my framework before next year.

... and take notes for future translation

Thanks for the quick answer.

[Rumble]

Hi everyone, sorry to ask a noob question, but I'm one after all

As I'm new to MapTool and I'm currently wrestling with macro language to code my own framework, I drooled reading about a switch to Javascript.

My question is : does anyone as a clue to when 1.3 will be considerer final and 1.4 development will begin ?

There is no answer to this question. 1.3 is in release now, but it doesn't look like it will ever be final (not least because people like me can't stop thinking of new things to add).

[aku]

<smacks rumble> Well, just think about adding them to 1.4 instead.

[Rumble]

<smacks rumble> Well, just think about adding them to 1.4 instead.

The problem with that is, 1.4 is this "massive overhaul" thing, and may bear little resemblance internally to what we've got. So there's no point in thinking about new features for 1.4 in anything more than 'wouldn't it be nice if' terms. I can do stuff now for 1.3, but 1.4 is too nebulous to do anything but conjecture about.

However, I would completely support picking something like b63 or b66 and saying "This is MapTool 1.3" and freezing it completely. Take everything added since then (including chat notification and unowned selection and whatever else) and say "Wait for 1.4.b1, and resubmit this."

The powers that be went a different direction, though, and I get paid just as much to march as to fight.

[plothos]

I get paid just as much to march as to fight.

But only in battle do you get glory tips (which are tax free).

[bstrdsmkr]

actually i think what i'd like to see in a gradual implementation of javascript and depreciation of MTscript. say in 1.3b70 introduce the ability to run javascripts without access to any of the current objects in MT. That way you can use ajax calls to get info from the web and display it or calculate things, or display new html windows and etc, but not access token properties and etc yet. In that same release mark the equivalent MTscript features as depreciated, don't remove or disable them, just mark them on the wiki as depreciated, encourage new devs to use the JS methods and etc. Then with each build expose another couple of objects to the java scripting API until you've got the majority of it exposed, and then for 1.4 disable the remaining MTscript features. That way you can get everyone eased into it and devs with current projects have plenty of time to get everything converted.

If someone with some GUI chops created a loading system, the implementation doesn't look bad. here's the example from http://java.sun.com/javase/6/docs/techn ... index.html

Code: Select all

Evaluating a Script File
In this example, we call the eval method that accepts java.io.Reader for the input source. The script read by the given reader is executed. This way it is possible to execute scripts from files, URLs and resources by wrapping the relevant input stream objects as readers.

 import javax.script.*;
public class EvalFile {
    public static void main(String[] args) throws Exception {
        // create a script engine manager
        ScriptEngineManager factory = new ScriptEngineManager();
        // create JavaScript engine
        ScriptEngine engine = factory.getEngineByName("JavaScript");
        // evaluate JavaScript code from given file - specified by first argument
        engine.eval(new java.io.FileReader(args[0]));
    }
}
Let us assume that we have the file named "test.js" with the following text:

println("This is hello from test.js");

We can run the above Java as

java EvalFile test.js