Love it or Leave it: Current Macro Language

[RPTroll]

This poll is to give the developers a feel for how much we love the currently implemented macro language or how ready we are to move on to Javascript. Please vote and comment if you currently write macro code.

[plothos]

There's no option for:

Keep it. For the love of all that's holy, I didn't write all this code for nothing!

If current code gets dropped, I will be VERY upset.

[RPTroll]

There's no option for:

Keep it. For the love of all that's holy, I didn't write all this code for nothing!

If current code gets dropped, I will be VERY upset.

I think that's the 4th option.

[plothos]

Except I don't love it, and have no wish to be represented as such.

[RPTroll]

Except I don't love it, and have no wish to be represented as such.

ah. sorry. Unfortunately I can't find a way to change the wording. Perhaps option 3?

[plothos]

Heh, except the implication there is I'll just have to recode it all later.

Not looking to be difficult. I just imagine a lot of people are in a similar position.

[Rumble]

Hard to choose, also. I voted for Drop It, though I have a ton of stuff written in it. I guess I'm between "Drop It Right Now" and "Drop It If It Will Cause Problems."

For me, the thing is, 1.3 won't disappear, and I am probably not going to leap into 1.4.b1 for my ongoing games. So, the old language will still be useful.

And, since I've done this once already, I have the method in my head. I just need to learn a new syntax.

[jfrazierjr]

There are many reasons why we need to get to javascript, groovy, ruby, python, lua or whatever (God I hope it's javascript!). How often do people have issues with quoting or parenthesis in the current macro language? What about the nesting limits(3 levels deep if I remember correctly)? Javascript fixes that quickly and easily without resorting to having hundreds of lib functions defined.

Also since the existing macro language parer is based on regular expressions, it consumes far more memory and takes far longer to process a macro than it would with an external scripting language.

[jfrazierjr]

Just for the record, my vote would be to:

• Add scripting in as soon an early build as possible for 1.4
• Wait until near the end of development to drop the existing macro support for 1.4 OR wait until 1.5 and don't include it in the 1.5 release at all.

This should give people several months at least to begin switching over to the implemented scripting language slowly, macro by macro.

[neofax]

I voted even though I don't think I really have a say as I have not invested as much as others into the old macro code.

[Nonsapient]

There are many reasons why we need to get to javascript, groovy, ruby, python, lua or whatever (God I hope it's javascript!). How often do people have issues with quoting or parenthesis in the current macro language? What about the nesting limits(3 levels deep if I remember correctly)? Javascript fixes that quickly and easily without resorting to having hundreds of lib functions defined.

Also since the existing macro language parer is based on regular expressions, it consumes far more memory and takes far longer to process a macro than it would with an external scripting language.

Considering this (problems I have run into quite a lot, including the time lag and memory) I would definitely say to go to Javascript. I'm more than happy to toss everything I've done if it means a leaner meaner machine.

[jfrazierjr]

Considering this (problems I have run into quite a lot, including the time lag and memory) I would definitely say to go to Javascript. I'm more than happy to toss everything I've done if it means a leaner meaner machine.

If it's javascript thats added, it also means a smaller download size since there are quite a few lines of code around macro processing and the javascript stuff is automatically included in Java 1.6(except for Mac from what I hear), so no need to include that with the Maptool zip.

[plothos]

I was under the impression this wasn't an either/or situation.
I'm all for adding javascript. But pulling the plug on existing code is cruel and unusual.

[Nonsapient]

I was under the impression this wasn't an either/or situation.
I'm all for adding javascript. But pulling the plug on existing code is cruel and unusual.

It isn't really. this is just a hypothetical 'what if' scenario, where the waters are being tested.

IF it were a pain in the donkey to do both, what would the community prefer?

[biodude]

There's no option for:

Keep it. For the love of all that's holy, I didn't write all this code for nothing!

If current code gets dropped, I will be VERY upset.

Ditto
I voted for the second option. I would also be very disappointed if support for the macro language was dropped soon. It would force users to decide between performance and support for previous older frameworks. I agree that javascript (or TLTSBS) will allow for so much more functionality, and better performance, so I don't want to prevent that. But, I'm in the same boat of having invested a lot in something and not wanting to see it go down the tubes.


What is the challenge to keeping both, exactly?
Is it because the changes planned in 1.4 involve so much gutting that the old macro functions would no longer work? Or will the macro code parser itself cause problems?

I suppose I could live with Rumble's point that all my macro code will still work in 1.3 final. But, the time & effort needed for me to re-write it all in javascript will mean it will be a while before I even think of doing that (if ever). Then again, I expect it my take a while before javascript is added, so I will wait and see either way. My problem is that I don't really have oodles of time to spend learning it all over again. If the time & effort I invested were no longer applicable to 1.4, I would probably just not upgrade.

If macro code gets dropped, be prepared for a lot continued questions about it from legacy users of 1.3. and "just upgrade to 1.4" will not be an acceptable response.

Furthermore, I actually think the macro code will continue to be useful. While it sucks for complicated multi-line script automation, it works really well for inline rolling and commands. A command-line scripting option is still useful in MapTool, so unless javascript is accessible from the (new) chat interface, macro code is still useful. It was built for this purpose, and I don't yet see why it can't continue to perform this function. I don't mind if the more "advanced" functions get dropped or shifted to javascript, due to other changes in the MapTool code, but users will still want to roll [ 1d20 ] from chat.