Scripting Criticals

loogie · Post by **loogie** » Wed Sep 10, 2008 2:18 am

haha, i don't hate python either... and i'm sure if i used it enough, i'd like it as well...

but as a non*AHEM*crappy*COUGH* dnd player, i would like to stress the fact that this is not a dnd program, and there are MANY of us who will fight you tooth and nail to keep it that way. I think a major upgrade to 1.4 should be the implementation of a scripting lang, whatever it may be... mainly because so many little upgrades and patches are being added for system specific rules and games, which essentially should become a dnd extension or add on for maptool... with a real scripting system this would come to fruition, people who need something to happen a certain way can just script it out... or ask someone else to, and it doesn't change the way maptool works... THAT is the main benefit of a scripting language, and why i think we are at the very point where we are starting to need it.

in essence, maptool should just handle the main functions of the program, displaying windows, creating tokens and objects, moving things, and naming them so that the scripting language can edit them... from there the scripting language should be what does everything else... scripting needs to handle all and everything we would ever want to change on tokens and objects... it should allow us to change campaign properties... and it would be nice if it could change some of the actual things seen on the map (eg: a script that creates a timed "guard patrol" around a map).. the more scripts can do the more maptool can do... and the easier it is for all of use to get exactly what we want, without having to include the parts we don't want.

what i would like my final maptool experience to be would be an amazing map making interface (no worries on that part for sure) where you can go online to rptools "library of addons" and select say "dungeons and dragons>4ed>combat" and download the init system for dnd, install it... then go to "Generic>lighting" and download a script to make torches flicker.... or any other cool scripts you may want... i think that an open library of scripting resources that upgrade maptool will make it untouchable in the ever-increasing world of VTT... and a solid base like that requires a scripting language... the longer we wait to implement a scripting language, the harder it will be to make it work... so i say it should be done very soon.

Orchard · Post by **Orchard** » Wed Sep 10, 2008 7:05 am

loogie wrote:haha, i don't hate python either... and i'm sure if i used it enough, i'd like it as well...

but as a non*AHEM*crappy*COUGH* dnd player, i would like to stress the fact that this is not a dnd program, and there are MANY of us who will fight you tooth and nail to keep it that way. I think a major upgrade to 1.4 should be the implementation of a scripting lang, whatever it may be... mainly because so many little upgrades and patches are being added for system specific rules and games, which essentially should become a dnd extension or add on for maptool... with a real scripting system this would come to fruition, people who need something to happen a certain way can just script it out... or ask someone else to, and it doesn't change the way maptool works... THAT is the main benefit of a scripting language, and why i think we are at the very point where we are starting to need it.

in essence, maptool should just handle the main functions of the program, displaying windows, creating tokens and objects, moving things, and naming them so that the scripting language can edit them... from there the scripting language should be what does everything else... scripting needs to handle all and everything we would ever want to change on tokens and objects... it should allow us to change campaign properties... and it would be nice if it could change some of the actual things seen on the map (eg: a script that creates a timed "guard patrol" around a map).. the more scripts can do the more maptool can do... and the easier it is for all of use to get exactly what we want, without having to include the parts we don't want.

what i would like my final maptool experience to be would be an amazing map making interface (no worries on that part for sure) where you can go online to rptools "library of addons" and select say "dungeons and dragons>4ed>combat" and download the init system for dnd, install it... then go to "Generic>lighting" and download a script to make torches flicker.... or any other cool scripts you may want... i think that an open library of scripting resources that upgrade maptool will make it untouchable in the ever-increasing world of VTT... and a solid base like that requires a scripting language... the longer we wait to implement a scripting language, the harder it will be to make it work... so i say it should be done very soon.

i can agree with all that...

jfrazierjr · Post by **jfrazierjr** » Wed Sep 10, 2008 9:23 am

loogie wrote:haha, i don't hate python either... and i'm sure if i used it enough, i'd like it as well...

but as a non*AHEM*crappy*COUGH* dnd player,

Perhaps that came out wrong, but does that statement mean you are a really good D&D player? And if so, wow, you have a big ego....

There are plenty of arguments as to why D&D is the best Fantasy game mechanics, just as there are many arguments of GURPS, or hundreds of other games. Much of it depends on your style of play.

loogie wrote: i would like to stress the fact that this is not a dnd program, and there are MANY of us who will fight you tooth and nail to keep it that way.

That seems an like an indictment against something someone is currently doing that is pushing this to be a D&D only game table. While I for one play D&D exclusively (but have played other game systems in the past, notably Mechwarrior and Shadowrun along with a few other odd ball ones), I have no problem keeping Maptool system agnostic.

Also, while many people using Maptool do not play D&D in any more, I expect the majority of the users are using Maptool to play D&D, so at the very least, we as a community should listen to their needs and try to accommodate them as much as possible, AS LONG AS it does not block the use of other game systems. The question then is, given two features that take about the same amount of time, neither blocks the other, and there are no Wall of features votes (which are paid for by money or time spent on coding/docs of Maptool), if one is for D&D and one is for some other game system: which one should be worked on first. From a fairness point of view, as long as D&D's code is never exclusive, the one with the largest base of users should win more times than not. But, to be honest, I don't think there are that many code things left that would only benefit a single system exclusively so this is mostly a moot point.

loogie wrote: I think a major upgrade to 1.4 should be the implementation of a scripting lang, whatever it may be... mainly because so many little upgrades and patches are being added for system specific rules and games, which essentially should become a dnd extension or add on for maptool... with a real scripting system this would come to fruition, people who need something to happen a certain way can just script it out... or ask someone else to, and it doesn't change the way maptool works... THAT is the main benefit of a scripting language, and why i think we are at the very point where we are starting to need it.

in essence, maptool should just handle the main functions of the program, displaying windows, creating tokens and objects, moving things, and naming them so that the scripting language can edit them... from there the scripting language should be what does everything else... scripting needs to handle all and everything we would ever want to change on tokens and objects... it should allow us to change campaign properties... and it would be nice if it could change some of the actual things seen on the map (eg: a script that creates a timed "guard patrol" around a map).. the more scripts can do the more maptool can do... and the easier it is for all of use to get exactly what we want, without having to include the parts we don't want.

what i would like my final maptool experience to be would be an amazing map making interface (no worries on that part for sure) where you can go online to rptools "library of addons" and select say "dungeons and dragons>4ed>combat" and download the init system for dnd, install it... then go to "Generic>lighting" and download a script to make torches flicker.... or any other cool scripts you may want... i think that an open library of scripting resources that upgrade maptool will make it untouchable in the ever-increasing world of VTT... and a solid base like that requires a scripting language... the longer we wait to implement a scripting language, the harder it will be to make it work... so i say it should be done very soon.

I mostly agree with all that stuff. Modular is the way to go for as many of the component parts as possible, regardless of which game system you use.

loogie · Post by **loogie** » Wed Sep 10, 2008 8:09 pm

heh.. yeah.. apparently i am a non-crappy dnd player... it was an error of judgement at early o'clock..... i do not play dnd.

and i don't mean to say things are being shifted towards dnd, besides the fact that the majority of features asked to be included are in fact for dnd... also many features that are added are defaulted to dnd standards... i wouldn't care if that was an add-on made by a dnd player... but when i'm forced to say, start maptool for the first time, and change all the lighting from the dnd defaults to my game... it makes it harder for someone who is just starting and doesn't play dnd to just pick up and play... i know trevor, and most other people are committed to making maptool system inspecific, so i'm not worried about it happening... but i would like maptool to have NO assumptions in its original state, allowing addons and possibly campaign setting files to be able to add these for a specific game.

the library is something i've previously talked to trevor about as well, and its something he thought would be great as well...

Azhrei · Post by **Azhrei** » Wed Sep 10, 2008 11:41 pm

loogie wrote:when i'm forced to say, start maptool for the first time, and change all the lighting from the dnd defaults to my game...

It's got to default to something, right? Which ever default is used, players of the other systems will complain that they have to go back and change it. And if it defaults to nothing at all, a new user is going to be completely lost since there won't be any change on the map when they turn on a light source or change vision settings.

I'm sure that once the changes settle down, a bunch of campaign preferences will be created so that people can download MapTool + preferences for their preferred game system. And if their game system isn't supported yet, they can create their own preferences and upload them for others to use...

loogie · Post by **loogie** » Thu Sep 11, 2008 1:02 am

yup i figure that would be the case. so i'm not trying to female-canine-in-heat... its just... i think a scripting system would solve such issues... a dnder makes a script that does everything for spell casting... by dnd standards... you don't want it... don't use the script... problem solved...

palmer · Post by **palmer** » Sat Sep 13, 2008 1:45 am

applekor wrote:I am still in agreement with someone's post on my original scripting topic (I forget who, and I'm too lazy to try and find it again). Especially if we are talking about building community libraries, we need to keep the scripting language choice to one or two. Beyond that, and the forums will start to get filled with nonsense posts by non-programmers trying to figure out what language a particular script is written in and how to get it to work with someone else's script in a completely different language. In essence we will wind up with horrible, horrible kludging.

I am still trying to figure out why MT should support more than one scripting engine in the first place, quite honestly.

There's no end-user advantage to it. It really does nothing for usability.

There's the advantage that scripters can choose a preferred language. But then as mentioned, you get a plethora of scripts in various languages.

Can they even interact? Say I have an Attack script in JS, and a Critical script in Lua. Can the JS even call the lua script/function? More importantly, can it do so without any significant overhead either in processing or developer time?

Yes, developer time. If they have to code some kind of bridging system to let the two languages interact... that's wasted time and code. And if it can't be done, you ave language lock-in, rendering a large chunk of written scripts useless to someone.

The script-writers here have already shown themselves mroe than happy to learn a new (and constantly evolving) language just to support macros in MT.

The idea behind having multiple languages is scripter choice. Coincidentally, they're also the group who would have the least trouble learning a new scripting language.

Finally, look at trying to explain something basic to a noob.

"You can do that with a script function like this.

Or if you use Python, do this instead.

I don't know Ruby, so if you're using that, I can't help you."

Not a good situation.

loogie · Post by **loogie** » Sat Sep 13, 2008 2:56 am

i agree with palmer, i think apples reason why to use multiple languages only makes me think it would create more confusion trying to support more then one language in our libraries...

when we adopt a single scripting language we will all be working with the same thing, sure not everyone is going to know it inside and out, but some will, and will teach others... i think its much more benificial to all be working with one language then a multitude, because we're all working with the same tools.

i have no idea how each scripting language would play with eachother, i've never tried to implement a language in any programs i've made... and i've only ever used python to make some scripts for a GIS program ArcGIS so i'm not entirely skilled there either... tho i found it very easy to work with python, but i'm sure that can be said with almost any scripting language.

BigO · Post by **BigO** » Sat Sep 13, 2008 10:24 am

palmer wrote:I am still trying to figure out why MT should support more than one scripting engine in the first place, quite honestly.

There's no end-user advantage to it. It really does nothing for usability.

There's the advantage that scripters can choose a preferred language. But then as mentioned, you get a plethora of scripts in various languages.

It's a bit early to be worrying about that. We don't even have ONE in place yet, and though lots of people have talked about wanting that feature, I've not heard anyone in a position of authority say that they plan on allowing more than one to go in.

Craig · Post by **Craig** » Sat Sep 13, 2008 12:34 pm

Orchard wrote:
Frankly, it's probably a smart choice to have one C-type syntax scripting language and one python/VB-like syntax language and leave it at that. That would keep both groups happy while allowing for a minimalization of the number of languages. It might be difficult to translate macros/scripts between the two, but by only having two, you at least are dealing with known quantities.

Lets examine this for a bit and try start a pros and cons list for multiple scripting languages (feel free to add some if I miss them),

Pros
Script writers can choose the language they prefer which it could be argued will mean more people write scripts so there are more scripts to choose from.

Cons
a) Adding a second language adds more of a burden on the developers, apart from development time it more than doubles testing/bug fixing/documentation time (you suddenly have 2 language implementations to test/bug fix as well as the interactions between them). A third? that's more than 3 times the testing/big fixing/documentation.

b) An interpreter for each language would need to be included, not to mention more than likely moving to java 6 for several languages, so no longer do you have mac compatibility for most mac users. Yes there has been a mention of an "easy" way around the java 6 requirement, but honestly requires even more work and license wise questionable.

c) Scripts of multiple languages would require multiple interpreters to be running and increase memory requirements.

d) With the future direction of using JSON within MapTool and the scripting language what do you do for languages without support for JSON, create a JSON library for each of them? That is a rather significant task.

Trying to solve Cons
a) You could say no interaction between language A and language B to simplify this, but that solution is somewhat unsatisfactory as it leads to a lot of components that would be nice to use together not being able to be used together and user confusion as to why they can't, or worse still horridly complex work arounds being used by users to try get them to work together.

b) You could only require people to install interpreters for the languages they use to get around bloat issues. Yeah but honestly I like how I download MapTool and it works (I will get back to this in a bit), honestly I know people who would look right past MapTool if they saw a if you plan to be running this type of macro follow these steps to install, this one follow this...

c) Sorry folks this one is a case of "it is what it is"

d) Live without JSON support? This is probably not viable if it is going to be used a lot. You could expose the java JSON libraries to the script which would would alleviate the issue even if it may feel clunky in the scripting language. Or you could choose only languages with available libraries for JSON. This is probably the easiest of the Cons to work around but either limits script language choice or leaves the languages a "second class citizen" for JSON interaction.

User Experience (end user not macro coder)
Putting on my user hat, just downloading MapTool and having it work is wonderful, importance of ease of installation just can not be over estimated, moving to any sort of system that requires the end user to choose which interpreters to install would be a shame and detract from ease of installation, so I just don't like the install only interpreters required path.

Ok do I pick the JavaScript DnD4e or Python DnD4e scripts? Whats the difference? Why doesn't this one have what the other has...

Most tools that have a scripting language stick to one because its easier to test, maintain, debug, document etc. From an end user perspective having multiple languages adds nothing for the non script coder, but it comes with downsides.

Without question you are asking the non script coder to suffer a burden to allow script coders a choice of their language, you know javascript is not my favorite language but it does what it needs to so I will happily use it. I don't think I should be having such a large impact on all MapTool users just so I can choose a scripting language from a menu of available languages that suits me better. If you program and know a language then javascript is not hard to pick up, and if you don't but want to write a script then at least you have a target you don't need to go out and try learn the basics of X number of languages to decide which is best for you or pick one of X and hope its best choice.

Brigand · Post by **Brigand** » Sat Sep 13, 2008 12:40 pm

This is why I think MapTool should have a lightweight client that only has the bare minimum required for a player to connect, manage their tokens/character sheets and view the map.

Azhrei · Post by **Azhrei** » Sat Sep 13, 2008 5:12 pm

Aria wrote:This is why I think MapTool should have a lightweight client that only has the bare minimum required for a player to connect, manage their tokens/character sheets and view the map.

But it's naive to think that two programs with some common code is easier/faster/more stable than a single code base and a single program.

I agree with Craig's points on Pros and Cons. His only Pro (scripters have a choice of language) is good if you expect a huge user base, but not so important if the user base is small. For example, with 100k users, language choice might be important as someone familiar with Python my look at MT and ask, "It only supports JS scripting? I guess not, then." But with a small users base, say 1k users, you may still be turning away a potential group of users (say 10% who are Python programmers) but it's a smaller number of people in total. And with a single scripting language supported, the remaining group of users can find plenty of support here on the forums while they learn JS.

Oh, and you didn't know what JSON and Javascript were when you posted in the server/client thread, so here's a quick recap: Javascript is a programming language typically implemented as an interpreter, making it easier to write/test code than a truly compiled language like C or C++ since the turn-around time is very quick. JSON is Java Script Object Notation and simply uses Javascript syntax to record data, with the goal being to make it easy to save and load data in Javascript.

Most Ajax-based web sites use XML (that's the X in AJAX, Asynchronous Javascript And XML). But there's a wave building that uses JSON instead, since there are now parsing libraries available on the server side and using JSON on the browser side is very convenient and easy.

applekor · Post by **applekor** » Sat Sep 13, 2008 10:38 pm

palmer wrote:
applekor wrote:I am still in agreement with someone's post on my original scripting topic (I forget who, and I'm too lazy to try and find it again). Especially if we are talking about building community libraries, we need to keep the scripting language choice to one or two. Beyond that, and the forums will start to get filled with nonsense posts by non-programmers trying to figure out what language a particular script is written in and how to get it to work with someone else's script in a completely different language. In essence we will wind up with horrible, horrible kludging.
I am still trying to figure out why MT should support more than one scripting engine in the first place, quite honestly.

OK, stop! When I say one or two, I'm on the side of limiting the number of languages, not expanding them. Reread the second half of the stuff you quoted me on. I don't want kludge. I am personally all for one scripting language. There are those out there who are fairly adamant about multiple language support. The idea of a second language is a concession to them. I am NOT one of the RPTools team. I don't have final say in what does or does not go in. My point was that if they ever do decide to go with multiple language support, my vote is for not more than a primary language and a secondary one.

palmer wrote:Can they even interact? Say I have an Attack script in JS, and a Critical script in Lua. Can the JS even call the lua script/function? More importantly, can it do so without any significant overhead either in processing or developer time?

Yes, developer time. If they have to code some kind of bridging system to let the two languages interact... that's wasted time and code. And if it can't be done, you ave language lock-in, rendering a large chunk of written scripts useless to someone.

BTW, there are ways of letting multiple scripting languages interact without too much trouble. This is the wrong post to discuss methodologies, but I've got some ideas on how to remedy that. Also, I don't believe that macro/scripting parsing and execution eats up that much of the system resources. I would think the graphical rendering holds that heavyweight title. I've put a fairly good size script together and run it through the scripting engine. Execution is fairly instantaneous on a dual core Turion mobile chip in power saver mode.

Krattack · Post by **Krattack** » Sun Sep 14, 2008 8:12 am

Craig wrote: Cons
a) Adding a second language adds more of a burden on the developers, apart from development time it more than doubles testing/bug fixing/documentation time (you suddenly have 2 language implementations to test/bug fix as well as the interactions between them). A third? that's more than 3 times the testing/big fixing/documentation.

I would say that that estimate is very optimistic. I think the extra time needed for testing/debugging/documentation would more likely to be square of the number of languages offered.

Orchard · Post by **Orchard** » Sun Sep 14, 2008 8:28 am

Reading through all this, I have to say, as one of the ones clamoring for multi-language support, that I see the arguments for limiting the number of languages.

They are very good. At this point, I would agree that having more than one c-style language and more than one python/lua/vb-style language (blocks) is probably not worthwhile. The question then becomes one of JSON support in the secondary language.

If it's not there, then it's not worth supporting the second language. So whatever were chosen would need that at a minimum. IS it still worth doing? I'm not sure. But I do think that more than two languages, from what I'm seeing, is probably overkill. I'll agree to that. Whether there should be just one or two is still an open question in my mind, but I'm wavering.