RPTools.net

CoveredInFish wrote: But mostly I'd be happy if MOTE would get a subforum here. Its a sibling of MT so its of interest to the community here. It has to be seen as a different thing - for sure - but it has also lots in common.

For a good many reasons a subforum would get my vote.

Full Bleed wrote:I *hope* there is not a separate forum because that will likely force me to choose which forum I'm really going to visit regularly. And if I start using Mote (and there is no reason for me to believe at this point that it won't replace 1.3b89 completely) then it will probably be Motes'. I think it would result in a lot less activity here and a lot of redirection... ultimately, benefiting neither.

+1

Full Bleed wrote: If they can deliver a solid product on this kickstarter another could be run to hit some of the sexier features they didn't get to this time around. They'll have more street cred to sell as well. I was purposefully modest in my backing this time around for exactly that reason. It's better to under-promise and over-perform than the other way around.

Totally agree.

If the project delivers on its promises, I would be more than happy to dig into my pocket again.

Lee wrote:@JML: Yes, summer is where we want things to pick-up, when we deliver Mote to supporters expecting it in June.

As I'm sadly not part of the Mote backers, this surely means that I'll have to wait till summer end to get a look at your work. That's ok with me. I only wanted to have a rough idea on the delivery time to be expected.

Lee wrote:The interface changes promised in the 2nd stretch goal will come a little later, however, as there are a lot of areas that need a re-write.

No problem. I'm not really enjoying the kind of results you get from the "quick and dirty" attitude And again, as I didn't backed, I'm not really entitled to push on delivery dates

Lee wrote:@CoveredInFish: Hopefully we'll get to there eventually We will have some primitive implementations in the GUI revamp, however, that might allow users to refer to external resources and display them in-app. So, theoretically, people can use a WYSIWYG editor somewhere out there, add components, content, and script behavior on the page itself, and host it externally, to be displayed in Mote when it is fed with a resource location. However, there will still be no bridge between the page's data, and Mote, for the meantime, much less a connection to MT script, and, even less, leveraging the bridge between Java <-> Javascript that JavaFX provides.

Quite an old debate I must confess I'm on the "dump MT script and go for JavaScript" side… well may be not this extreme I fully understand reluctance from the heavy coders here to lose all they invested in MT till now. And they're the more active part of the users. On the other hand I'd be really glad to see all the MT script quirks disappear. There's so much coding energy sucked in dealing with them. It seems to me a real PITA and is surely one reason why I didn't invest so heavily in framework coding. I may not be the only one. I wish there could be a way to give us the choice, someday… but don't know if it's even feasible Anyway you've got plenty of hard work before even thinking of it.

My best wishes for Mote's futur

Thanks, JML.

I haven't waded in much in using the JavaFX' Javascript bridge, but I believe it allows JS to directly call Java methods, and Java to call JS functions in return. In principle, all the Java code for maptool script functions can be called without having to pass through the old parser, so that's something to look forward to when the time comes. I think it's how the Groovy fork does things through it's own parser, though I haven't really looked too much into it.

Try giving Mote's macro editing a spin to see if it changes your mind about MT script, at least to some degree

Lee wrote:I haven't waded in much in using the JavaFX' Javascript bridge, but I believe it allows JS to directly call Java methods, and Java to call JS functions in return. In principle, all the Java code for maptool script functions can be called without having to pass through the old parser, so that's something to look forward to when the time comes. I think it's how the Groovy fork does things through it's own parser, though I haven't really looked too much into it.

If it turns out to be this "easy", hope remains to get there someday. I don't know if I'm wrong or right on this, but I think it would gather some new framework coders as HTML5+CSS3+JavaScript have quite a broad user base and documentation. From this point of view, the Groovy choice seemed strange to me.

Lee wrote:Try giving Mote's macro editing a spin to see if it changes your mind about MT script, at least to some degree

I'm surely looking forward to it

Is there a reason the old MT script couldn't be kept for compatibility reasons? Something like the macro has a checkbox "Use legacy script" that will send it to the old parser. That way people could migrate functions over time?

Well, this would be perfect, but I'm afraid this could be a call for trouble

Anyway Lee's got quite a lot of work before this.

/agree. I don't think it's on the current radar to rip out the current script engine anyway, was more of a, "IF" you do. I can never see a version of MT that completely replaces the script engine to be to successful, at least for a long while. Even I wouldn't move to a new MT if it meant giving up my current Pathfinder framework until a new framework was available.

@JML: Groovy is great as a straight shot to Java, having the same syntax, but less formality, making it more concise. It has a lot of nice features to boot. With that being said, it's still relatively easy to learn, but documentation isn't it's strong suit, and hasn't been for quite some time, which drive some devs away from using it over the long haul. It also used to be slow, but 2.0 is said to have changed that, and 3.0 looks promising as well. With regard to MT, if it was used to write the macro functions itself, it can make for more concise code that do the same thing as the current ones, for less. But, as I said earlier, I'm not sure if the Groovy fork calls the old functions, or was written from scratch to do the same things for less code, or a combination of both.

JamzTheMan wrote:Is there a reason the old MT script couldn't be kept for compatibility reasons? Something like the macro has a checkbox "Use legacy script" that will send it to the old parser. That way people could migrate functions over time?

No reason at all. I'm totally for having multiple access points to just one API, though I would segregate macro code, and delegate them to their respective interpreters, rather than letting one do all the work. Segregation meaning, all or nothing, where a macro command gets sent whole to a particular parser, rather than sifting through it and sending bits to where it would be understood. Lines from other languages that are mixed in gets ignored, or interpreted plainly. The trick there, though, is to write that accessible API, and MT script isn't exactly that, but I also don't think most users will mind the sacrifices made on efficiency, and the like, if it ends up having more than one way to write for MT.

I think that's why the talk has always been about moving to another language instead of maintaining backward compatibility to MT script. It's a nightmare to write such a consolidated interpreter, and having multiple interpreters goes against the lean application ideals evident on the latter parts of MT's code.

Just my 2 cents, though

JamzTheMan wrote:Even I wouldn't move to a new MT if it meant giving up my current Pathfinder framework until a new framework was available.

Compatibility was the biggest + of Mote in my book. And the biggest negative of MT 2.0 was the thought of starting over, only to spend months (or years) just to get back to where I already am.

I hope there is an MT 2.0 (though I'm not all that optimistic about it). And I hope its scripting is less frustrating, faster, and more powerful than what we have in 1.3. But I'm not going to give up functionality to get those things right now... and I think Mote is going to prove that we don't have to... yet.

@Lee, re parsers, that was exactly my suggestion as well. The macro as a whole would either run in legacy mode or use the new parser, and of course any macros it runs as well.

But personally, energy is better spent elsewhere for now which you guys are indeed doing.

Lee wrote:@JML: Groovy is great as a straight shot to Java, having the same syntax, but less formality, making it more concise. It has a lot of nice features to boot. With that being said, it's still relatively easy to learn, but documentation isn't it's strong suit, and hasn't been for quite some time, which drive some devs away from using it over the long haul. It also used to be slow, but 2.0 is said to have changed that, and 3.0 looks promising as well. With regard to MT, if it was used to write the macro functions itself, it can make for more concise code that do the same thing as the current ones, for less. But, as I said earlier, I'm not sure if the Groovy fork calls the old functions, or was written from scratch to do the same things for less code, or a combination of both.

On this matter my perspective is user centred. For me the most important criteria are:

1. accessibility to non IT professionals:
   1. ease of use
   2. ease in finding documentation and help
2. plays well with coming HTML5+CSS3

• Regarding point 1, MT Script doesn't behave so badly from a syntactic point of view. It's reeling from what I think Azhrei once called its organic growth and all the resulting quirks are making it much more "user unfriendly" than it could have been.
• On point 1.b, giving up MT Script would relieve people like Wolph and AM (sorry for the ones I didn't mention) from spending so much time explaining how to accommodate its quirks.

• Now for Groovy and JavaScript, I don't know much about those ones for now, and much less Groovy than JavaScript, so I can't compare their respective ease of use (1.a), but I can tell it's far more easy to find documentation and help on JavaScript (1.b).
• Regarding point 2, I know JavaScript is "natively" supported and wondering how Groovy is. And I'm afraid we end up with two different languages, one for the HTML+CSS front end, and one for MT scripting in back end, which blows point 1   I think, from a user perspective, integration with HTML+CSS will matter more than integration with Java.
• I'm afraid the Groovy choice might just be an IT student hype. Groovy's site is bragging about all its "modern programming and additional power features", and I understand IT professionals rejoice, but I think the average MT framework coders, and much more the beginners, won't be interested in all the bells and whistles, and most of those will likely never be used. They already struggle with HTML and CSS, and having to learn two more languages instead of one would trump Groovy's benefits if it were to be this way.

Regarding script's execution speed, I think any existing script language will be much faster than MT Script, and thus don't think this choice would make a difference from a user perspective.

JamzTheMan wrote:But personally, energy is better spent elsewhere for now which you guys are indeed doing.

I wished this would be a bit higher priority but won't ask for it or complain about it. As I said I understand that the present power users come first. And I will take a look at Mote's scripting aids for sure. They're badly needed.

Hi,
Another lurker here, but I thought I’d join in on the discussion.

Firstly hats off to Lee for both taking the plunge with the kickstarter and getting funded. It’s really good to see Maptool getting some positive development. Like many I’m not optimistic about Maptool 2.0 coming out anytime soon so was happy to pitch in for the Mote kickstarter – after all I use the tool every week in my home game  .

Whilst I’m not a programmer I am an experienced ‘user’ of software, so my perspective is one of ease of use and getting a game running smoothly without having to learn a whole new computer language just to get running. For me the problem with maptool is less about the quirks of the scripting language and more about the user experience and ease of setting everything up.

I’d love to see a library of drop in resources that I can select. E.g you want an initiative control bar based on Pathfinder drop in this resource, you want a simple character sheet this one, an expanded sheet this one etc. Then once I’ve ‘configured’ my game I simply run the server and invite the players to connect.

Unfortunately there is a way to go on this, even installing Wolph’s bag of tricks into a campaign isn’t for the faint hearted, and he’s done a great job of explaining it step by step. At the moment it’s an all or nothing approach with the campaign file – e.g I didn’t use the main pathfinder framework because it was too complicated for my game, but there were parts of it I liked so have had to manually incorporate those ideas into my own framework.

That said I think Lee has a clear direction of what he is wanting to add in Mote, all of which adds to the user experience – dice bar, inbuilt script editor, sounds, etc. together with the wizards and help system, proposed will do wonders for the usability of maptool.

On point 1.b, giving up MT Script would relieve people like Wolph and AM (sorry for the ones I didn't mention) from spending so much time explaining how to accommodate its quirks.

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.
Don't get me wrong here as well, its not meant as a threat but a simple fact and if your certain of getting new and young enthusiastic blood into MT, by abandoning the old one for a new script, then by all means do!
I for one should not and want not to be in the way of progress (its my job to support progress).
From a personal point of view however, I have my group who plays W40KRPG I've developed (together with others) a pretty heavy system to support all W40K systems over the last couple of years (close to 80k lines of code and probly the same amount again if you count the rewrites) and its simply not feasible for me to start from scratch again.

For that matter I'm personally happy that Lee (at least for now) keeps the old script in MOTE.