Disclaimer: I'm not part of RPTools' core development team. Also, I don't get into debates as to what language is better or not. Expertise and context always says there's a use for everything in a programmer's arsenal
Virenerus wrote:Mh. Why is JavaFX the sdandard of a javascript implementation?
I must have missed a word or two on that line, but since I was referring to RPTools' core development team, that part about being "the de facto standard" was meant to say that it's RPTools' likeliest candidate for implementing 2.0.
Virenerus wrote:
...Doesn't it just use the js library from mozilla firefox?
...I tried to start working with js in the beginming. But I found the way to work with objects returned by js a bit problematic. You either need to transform them from js types in Javatypes in js or do a lot of magic in java.
...Groovy on the other hand uses all java objects without a problem. It supports most of javascripts features that are not in Java itself and it compiles to Java Byte Code, which means from the jvm point of view it is no diffrent to java. So there are no typing problems.
...Do you really think Javascript is the way? Groovy is nearly identical in syntax, better integrated in java, faster and would allow you easily (in the future) to export written macros into stand alone plug-ins for maptools. What are the pros you see for javascript? Beside making Maptool a few MB smaller as it is shipped with the jre?
While it did start on Rhino, Oracle's moved toward rewriting the JS engine from scratch, calling it Project Nashorn. JavaFX quite seamlessly lets JS run within its provided controls.
As for Groovy, you're preaching to the choir when it comes to my opinion, but what is evident here is, every dev/group here who's had an opinion as to where MT should go has their own view on how to do things. I went my way, pretty much for the same reasons you cited for doing your thing, as the core devs continue on their own path toward 2.0.
Virenerus wrote:That said the main problem is to rewrite the whole API of maptools. The one used by the old macro language is horrific from a code design point of view. When I have finished rewriting the API into a simpler format, it should be no problem to implement other languages than groovy. The groovy part itself is only a few lines of code.
As I've mentioned, if you could accomplish an interpreter that outputs cleanly without breaking the output system MT employs, then it would be something useful to all MT code bases.
Virenerus wrote:While I see that it would be cool to hold on to the old macro system for backwards compatibility, I don't think that this is the way to go. It would just need to much gime. In my vision I am working on the next version of the tool.
Well, every opinion has its pros and cons, and yours does have merits, but you'll also be alienating a huge amount of work done over the years. If you read discussions where the core devs mentioned everyone moving to JS is the best way, you can kind of read between the lines to see the user base saying "Good luck finding people who'll make stuff for your tool."
Virenerus wrote:I want features like:
- fast and more easily debuggable scripts
- typed properties for tokens (to store real numbers and allow stuff like HP=5/12. This would also allow diffrent other cool features
- a way to create game systems directly as jar libraries. Just to allow users easier access to them and would allow the writers of such libraries a lot of freedom.
- connected to that is my wish to modularize maptools and make everything and its grandma plug-ins. This would allow everyone to write extensions(e.g.minimap) without knowing the whole code.
- All the cool stuff that roll20 can do (sounds/scripted special effects / get tokens from the web ...)
- p2p file sharing for faster uploading maps to other players
Believe it, or not, most of these are the very same design principles espoused for 2.0. Particularly:
- a faster scripting language <insert choice here>. data typing most likely fits under here
- plugin architecture. Lord Ashes in this forum has created a primitive but workable version, whereas the core devs are after something more robust. "Cool stuff" fits here, IMO.
- Better ways to share content, although there are several other ways to disseminate beyond P2P, which of these RPTools will choose, IDK
Virenerus wrote:So I think I am more working on a next big version where backwards compatibility should not be such a big concern. I want to revitalize maptools and the people behind it. To create a a ever evolving software again.
@.@a bit theatralic I guess. The jist is while I am able to implement the stuff I need you guys here to discuss design decisions with.
With that being said, you really should get with Azhrei, jfrazierjr, and Craig. Most of what you want to work on is suited for 2.0, moreso since you're just starting to write stuff. Albeit, they're not quite vocal right now, username (who posted above) has been tinkering with several base components for it. This way, if development is hell-bent on a new scripting system, it won't hurt any user base. Of course, you could just work on 1.3, if you want.
On my part, my team and I am pursuing a path of our own. Some of our ideals are shared and are already tackled in some instances, whereas our grand schemes seem divergent at parts. It has too much momentum right now for further discussion and amendments; I
was looking for input about a year ago, but struck out on my own when nothing came out of it. Phase 1 of my fork will be open-sourced upon completion, in any case. I'm not sure if you could wait for it, I feel you're good enough at what you do to accomplish much with little help, but it will eventually make it out there.
Best of luck mate.