Mote Kickstarter: We are going LIVE!

[Bone White]

Personally, I'm in the NWOMTC (New Wave of MapTool Coders - slight nod to the NWOBHM with the acronym), and I've been holding off on making additions/extensions/improvements on my campaigns because of the niggles I and my other users' have with MapTool. If a new script or javascript was introduced to replace the old one, you'd actually see more activity from me not less.

[Full Bleed]

Personally, I'm in the NWOMTC (New Wave of MapTool Coders - slight nod to the NWOBHM with the acronym), and I've been holding off on making additions/extensions/improvements on my campaigns because of the niggles I and my other users' have with MapTool. If a new script or javascript was introduced to replace the old one, you'd actually see more activity from me not less.

The strange thing about this is that I understand that javascript will be faster, more powerful, more "standard", and have better documentation. What I'm not so sure about is that it will be *easier* than the current macroscript is for the average user.

For all the oddities in macroscript I'd argue that it's a pretty easy language that a non-coder can, with a little effort, start using pretty quickly. And with the wiki and the forums, there aren't many quirks in it that haven't been worked around by someone at this point.

Javascript, on the other hand, is a language I've put ZERO time into. I haven't even read "An Introduction to Javascript" article or a FAQ on it. So I can only go by looking at some raw code. And by the look of it I don't go, "Wow! That looks soooo much easier than macroscript! Like writing a letter to my grandma."

To the contrary, it looks significantly more programmatic and seems like it might be much harder for the non-coders out there while only being easier for the coders (by virtue of their experience with it and languages like it). In short, I don't think macroscript gets enough credit for its relative simplicity when compared to the other options that have been talked about.

In MT I can pop a window with 3 functional menu options with respective nested options pretty easily. Compare it to this monster: http://www.javascriptfreecode.com/19.htm

Sure, macroscript would not be as pretty with animated drop downs and you don't have the same formatting controls. But I only have to learn a few functions to get the same basic functionality.

If people think MT is "too programmatic" now, I have to wonder how many heads will implode if you just drop javascript in front of them.

[Raileth]

I have to say i'm on the same page as Full Bleed here.

The macro system, for all its foibles is fairly straight forward and logical to a non programmer like myself. Everytime i look at anything to do with java my brain implodes as it tries to understand it. I already have enough trouble with the bracket rules and strange sysntax of IF statements (I'm used to VBA), without having to learn a completely new language. I appreciate that there is a lot more you could do with a a full programming language but that would only be of use if there was a relatively shallow learning curve for the non-coders amongst us.

To an extent I'd rather see the introduction of additional functions / features / updates to the existing scripting language rather than a completely new one. That way people with existing frameworks can gradually move over to the new functions that would hopefully still make sense but just work more efficiently, or have a wider functionality. I think they would migrate naturally to the newer functions in order to take advantage of new features / increased performance. I would have thought that a change to the scripting language was more of a step change for a version 2.0 of Mote rather than the gradual change that is currently on the table (at least as far as I understand it )

[Bone White]

If people think MT is "too programmatic" now, I have to wonder how many heads will implode if you just drop javascript in front of them.

It's a question of product placement really - do we want a moderate attempt at being different, a sort of hybrid between something powerful and simple, or do we want a product which is something completely different to the other virtual tabletops out there? I'd go with the second.

Not sure why the existing MapTool script can't be left in there, but JavaScript added alongside, or is this actually possible? Then we'd have a true hybrid (and once the connectivity/new user issues are solved, we'll have a hybrid which can out perform both the standard VTT market, and the new niche market that MapTool would actually be the only member of - programmable VTT.

[JML]

that's an interesting point of view. And its certainly true, but in my case it would extend to being relieved completely as my contribution will stop as soon as the old script is abandoned.

Which I know and is why I'm hopping for a way to get a choice between two scripts. As I said, you guys are the present power users and no one wants to see you go, not sooner nor later.

The strange thing about this is that I understand that javascript will be faster, more powerful, more "standard", and have better documentation. What I'm not so sure about is that it will be *easier* than the current macroscript is for the average user.

For all the oddities in macroscript I'd argue that it's a pretty easy language that a non-coder can, with a little effort, start using pretty quickly. And with the wiki and the forums, there aren't many quirks in it that haven't been worked around by someone at this point.

Javascript, on the other hand, is a language I've put ZERO time into. I haven't even read "An Introduction to Javascript" article or a FAQ on it. So I can only go by looking at some raw code. And by the look of it I don't go, "Wow! That looks soooo much easier than macroscript! Like writing a letter to my grandma."

To the contrary, it looks significantly more programmatic and seems like it might be much harder for the non-coders out there while only being easier for the coders (by virtue of their experience with it and languages like it). In short, I don't think macroscript gets enough credit for its relative simplicity when compared to the other options that have been talked about.

In MT I can pop a window with 3 functional menu options with respective nested options pretty easily. Compare it to this monster: http://www.javascriptfreecode.com/19.htm

Sure, macroscript would not be as pretty with animated drop downs and you don't have the same formatting controls. But I only have to learn a few functions to get the same basic functionality.

If people think MT is "too programmatic" now, I have to wonder how many heads will implode if you just drop javascript in front of them.

The problem you're having would be the same with JavaScript, Java, Groovy or any other language used on an "industrial" basis. The examples you gave are tailored for professional use, thus all the options and library calls that make them so much confusing. All this stuff would be of no use in MT and you just get to the language bare bones.

Here's quite simple examples in which you should be able to tell HTML from JavaScript (hint: it lies between the <script> tags ):

• Declare a variable, assign a value to it, and display it
• Alert box

You're right in saying MT Script syntax is quite easy to pick. The problems arise when you want to create full fledge frameworks. Then you've got to take care of the two nested levels limit, heap munching techniques, performance friendly ways of writing code, etc. At this point it's not this easy any more and a significant part of your code is dedicated to taking care of all this. The problems are not coming from MT Script syntax, but from the underlying engine that's powering it.

And then again, I'm not really asking to get rid of MT Script. It's just me ranting. I'm just hoping to get a choice someday

[RPTroll]

I would also like a choice. It would be nice if the old MT Script were kept around but a standard language added, like groovy. I'm not a big fan of javascript but would use whatever was available.

[Full Bleed]

Not sure why the existing MapTool script can't be left in there, but JavaScript added alongside, or is this actually possible? Then we'd have a true hybrid (and once the connectivity/new user issues are solved, we'll have a hybrid which can out perform both the standard VTT market, and the new niche market that MapTool would actually be the only member of - programmable VTT.

I think this question has been asked a couple times now in various threads... and I'm not sure I've ever completely understood the responses given. If the answer is "no" I'm not sure, exactly, why.

It suspect that the real issue would be with making the two work together... but I'm not sure that's where the "hybrid" method needs to start or that it's what we users should expect. For example, if a chain 5 macros makes up your current macroscript attack system I wouldn't expect to be able to just replace 1 or 2 in the chain with Java and have it work. I'd expect to have to redo that chain entirely to get that feature in java script. But I'd hope that wouldn't mean I'd also have to redo my entire initiative, skills, spells, inventory, and character sheet chains as well.

For example, Wolph is a performance slut. So while he won't give up all the work he's done so far (and I don't blame him) if he had two options at his disposal for something new he wanted to do... I would not be surprised if he didn't more organically transition to the quicker, more efficient methods within his framework if they were available. And, likewise, if he could transition parts of his system slowly (by choice and at his own pace) I suspect he would.

Macroscript would probably just slowly die out if we had that sort of option.

[JML]

@Full Bleed:

Agreed on all points.

Anyway, end of off topic teasing. Just waiting to see Mote 1.0 come out for now. Glad you made it Lee.

[wolph42]

Wolph is a performance slut

good to know how I'm known here...

but yes if an organic transition would be possible then yes I would take it. But that is something entirely different from throwing away 3+ years of work and starting from scratch again. (not that I've have not done that in the past, but this actually works )

[yorick]

I missed the Kickstarter, and sent you some money via Paypal.

You said you'd "only support Java 7", so that people would need only one Java version on their system. That'd actually make it two Java versions: Java 8, and Java 7 for Mote. Given closures, excuse me, "Lambda expressions", and what that could bring to dynamic lighting on multi-core machines, will you consider basing Mote on Java 8 instead? Or at least make it compatible with it, even if you don't go the full closures route initially.

[wolph42]

IVe ran some tests on j8 and so far mt is completely compatible (as far as I tested it). There are however compatibility issues between j6 and j7 so I know that mote will at least not be compatible with j6 and that's what they're referring at.

[Lee]

I missed the Kickstarter, and sent you some money via Paypal.

You said you'd "only support Java 7", so that people would need only one Java version on their system. That'd actually make it two Java versions: Java 8, and Java 7 for Mote. Given closures, excuse me, "Lambda expressions", and what that could bring to dynamic lighting on multi-core machines, will you consider basing Mote on Java 8 instead? Or at least make it compatible with it, even if you don't go the full closures route initially.

Thanks for the contribution, yorick (thanks wolph, for doing the early J8 testing)

I believe we mentioned Java 7+ as our support vector, though we might have forgotten the "+" somewhere. Rest assured, we're keeping an eye on Java 8, as it looks absolutely great on paper. We have to keep track of all the libraries and resources Mote is dependent on to be sure they mature along with the new standard, or at least, not break by any new imposition. It's tempting to bump it up 8, so we can urge users to only managing one version in their systems, and, on our part, upgrade several aspects of the code (several concurrent collections, and single-function interfaces, for instance), to take advantage of the closures, but, with several release schedules close at hand, we're iffy about rocking the boat for now; unless, of course, everyone is okay with getting Mote a few months later (closed Beta included ).

For now, I think people will be quite surprised with how the current vision system performs in Mote. It's something we will continue to tinker with until such time we get to make a new one.

[yorick]

Thank you for clarifying, Lee! 7+ is great, and taking it slow is a sensible approach. I was worried after reading "Mote runs exclusively on Java 7." on the Kickstarter page. That's where you dropped the "+". So it is "Mote runs exclusively on Java 7 and beyond", and that makes me much happier. I was so worried about having a return to "let's troubleshoot Java for an hour, EVERY session, before we play, people." Those were the b87 and below days, and I don't ever want to go there again.

[yorick]

@wolph, in my testing of j8 with b89, there are issues with window placement, and I can get MT to show Java errors. I haven't tested that with b90 yet, that'll be next.

[wolph42]

@wolph, in my testing of j8 with b89, there are issues with window placement, and I can get MT to show Java errors. I haven't tested that with b90 yet, that'll be next.

Can you elaborate on the window placement?