MT: doing some refactoring stuff to get to know the code

The RPTools applications are written in Java. If you're interested in contributing to any project here by submitting patches to the source code, this is the forum to ask questions about how to do so. Please put the two-letter tool name abbreviation in your thread Title. To enter this group, go to the Usergroups page of your User Control Panel and join the Java Developer group.

Moderators: dorpond, trevor, Azhrei

Virenerus
Cave Troll
Posts: 36
Joined: Fri Jan 17, 2014 9:13 pm

MT: doing some refactoring stuff to get to know the code

Post by Virenerus »

Hey guys,
I am currently refactoring int the mp code, just to get to know it a bit. I commit everything I do here: https://github.com/virenerus/maptoolsfork
At the moment thats just so that I can sync my notebook and my desktop but maybe some of the stuff would be helpful for the project? Everything till 522851889ed59b3d0f0304114f237c9141d18cb0 should be stable and I could post a patch to the test forum. But refactoring is really intrusive. So my question is if it is ok to post a patch that changed something in many of the classes? Can it be tested properly?

Thanks for the answers and this beautiful tool^^

Stuff I did so far:
  • refactoring refactoring refactoring
  • made the loading of folder in the asset manager quite a bit faster
  • changed the chat so that the name of a person/impersonated token is only shown once per sequence of chats from him
Last edited by Virenerus on Sun Jan 19, 2014 9:06 pm, edited 1 time in total.

username
Dragon
Posts: 277
Joined: Sun Sep 04, 2011 7:01 am

Re: MT: doing some refactoring stuff to get to know the code

Post by username »

You may find the odd tester that will check out your refactoring, but usually only if that adds functionality. You picked the "wrong" time for refactoring (although this time has been with us for a while now). 1.3 is basically closed except for bug fixing and 1.4/2.0 hasn't been started and is only in the early prototype phase.

In fact there are a few people meddling with 2.0 prototypically (JavaFX, JavaScript as "macro" code), but this is a slow trickle. At the same time, some new features on the base of 1.3, tentatively called 1.4, are developed and these people are (relatively) more active.

Virenerus
Cave Troll
Posts: 36
Joined: Fri Jan 17, 2014 9:13 pm

Re: MT: doing some refactoring stuff to get to know the code

Post by Virenerus »

I got that. But I couldn't really find a code base for the more active 1.4 project. Is there one? I would like to help there if someone was willing to work with me. Otherwise I will probably just keep doing stuff on my github fork and nobody but my group would ever use it-.-


username
Dragon
Posts: 277
Joined: Sun Sep 04, 2011 7:01 am

Re: MT: doing some refactoring stuff to get to know the code

Post by username »

For 1.4 you could also contact Lee.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MT: doing some refactoring stuff to get to know the code

Post by wolph42 »

username wrote:For 1.4 you could also contact Lee.
check! note that azh and jfjr are quite busy and not 'here' much so it might take them a while to answer.

Virenerus
Cave Troll
Posts: 36
Joined: Fri Jan 17, 2014 9:13 pm

Re: MT: doing some refactoring stuff to get to know the code

Post by Virenerus »

Yeah. Got that^^

After some refactoring stuff (edited into the first post) I am now working on replacing the script engine of maptools. I actually decided against javascript, because the connection of javascript to java is sometimes not that good. I would have liked to be able to write the scripts in java, but that would have added a jdk to the requirements of maptools. So I decided I would work with groovy. It is a easily compiled language that can be run perfectly from within java. Also most Java and JS programms are also valid Groovy programms. That makes it very easy to learn. You can start with what you know and then learn one new language feature at a time.

Running Groovy from macros works fine now. I will now start adding all the old macro functions and options to the new groovy api tp create somethin testable.

What I broke with my work and is thus on the TODO list:
  • diffrent chat options (me, gm ...)
  • any scripting / dice rolling in chat -> everything you type there is currently posted as it is (already started on a parser for changing that)
  • these I personally don't find that important (but will do that if someone thinks it is^^):
    • trusted macros work always right now
    • anti cheat stuff is not in there
Seems like my refactoring stuff grew into my own 1.4 @.@

Is anyone actually intrested in something like that?

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MT: doing some refactoring stuff to get to know the code

Post by wolph42 »

To be honest... No clue. I am unfamiliar with groovy. What in most interested in is backwards compatibility with current campaign files and speedier scripts...

Virenerus
Cave Troll
Posts: 36
Joined: Fri Jan 17, 2014 9:13 pm

Re: MT: doing some refactoring stuff to get to know the code

Post by Virenerus »

Well, Groovy compiles java byte code. So it is more or less as fast as Java itself. So Groovy should be A LOT more faster than the current scripting language. And there should be a lot less constraints, like how many loops can be put into each other.

With backwards compatibility it looks worse. I don't want to go through all the hassle to allow the old macro language and groovy. So you would have to at least rewrite all the macros. The rest should work just fine.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: MT: doing some refactoring stuff to get to know the code

Post by wolph42 »

Virenerus wrote:So you would have to at least rewrite all the macros. The rest should work just fine.
well, that's about 80,000 lines of code and 3 years work, so guess what.

User avatar
CoveredInFish
Demigod
Posts: 3104
Joined: Mon Jun 29, 2009 10:37 am
Location: Germany
Contact:

Re: MT: doing some refactoring stuff to get to know the code

Post by CoveredInFish »

Yeah, I can see your point ... but I guess its still interesting for a lot of other projects ;-)


Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MT: doing some refactoring stuff to get to know the code

Post by Lee »

You may have a point regarding JS and Java, but from the core development team's point of view, JS is the language of choice for the next iteration, especially since JavaFX is the de facto standard for its implementation.

With regard to 1.3, if you somehow manage to get Groovy to play nice with the existing system (i.e. outputting properly) without modifying the output mechanisms it employs, and without requiring special bindings and the like, then that would be awesome, as you foster the growth of potential framework designers versed with Groovy, without alienating other experts unfamiliar with Groovy. IMO, I don't think it's impossible or even hard for that matter.

Virenerus
Cave Troll
Posts: 36
Joined: Fri Jan 17, 2014 9:13 pm

Re: MT: doing some refactoring stuff to get to know the code

Post by Virenerus »

Mh. Why is JavaFX the sdandard of a javascript implementation? 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.

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.

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.
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
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.

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?

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MT: doing some refactoring stuff to get to know the code

Post by Lee »

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." :lol:
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.

Post Reply

Return to “Java Programming Info”