When you look at jcenter it is common to first find that group. I wonder why do jmonkeyengine has both repositories?
It seems that com.jme3 is for 3.0 and org.jmonkeyengine is for 3.1 but is there a reason to separate it in different group id’s (farther than because of the group id was changed for whatever reason and the 3.0 branch was left there for compatibility) ?
We don’t own the jme3.com domain so it was a mistake to use that groupId originally. I don’t know why we left that group open… it’s possible that we weren’t even the ones to create it. I don’t know it’s history.
It really take efforts to make tonegodGUI and its other components to be ready with jME3.1 … It’s quite a headache because it’s not very well structure also only developed by tonegod her self at the time. I have to clean up a lot and still doing it nowadays. But it has its potential ability All the guys are welcome to fork and take your chance to continue this project. I will jump into it more sometime beside of my project.
Aside from the javadoc warnings, I’m not aware of any great effort needed
to port tonegodGUI to 3.1.
Part of my hesitation to work on tonegodGUI comes from the fact that
tonegod’s coding style is so different from my own. Every time I look at
her code, I feel the urge to convert it in my own peculiar style, but that
would make it difficult to compare my fork with other forks.
Plus I keep hoping she’ll return to the project, in which case my efforts
would be better directed elsewhere.
I’ve barely scraped the surface when it comes to understanding ToneGod’s code, so I can’t offer much in the way of support. But if anyone encounters an issue with my fork, I’d like to hear about it. So I opened an issue tracker:
@sgold Thank you for making it work with 3.1 I just found your repo at Bintray and I’m trying to use it as a gradle dependency, however I get this error message:
For tonegodGUI users and forkers. If you ever had any lagspikes with animation effects even like drop down menu on select list (and I had because I have a lot of animated elements) then you should look at this:
Original code of effect manager breaks iteration when any effect is finished. So if you have 100 animated elements, it can freeze UI for some time. I have changed it with remove lists that don’t prevent iterations and all my lag spikes have gone. Maybe not the best solution but it works for me
Use actual iterators and call iterator.remove() for the completed things.
The for-each syntax spoils folks and they forget that iterators are even there.
Edit: but SafeArrayList does have other benefits as listed… and the existing code would be able to stay mostly the same. (Array iteration is faster so you get that too)
Trying to get back into the swing of things before picking up my visual editor project for tonegodGUI. So, I’m going to try to play around with tonegodGUI on some videos, for a bit.
If it’s useful, yay! oh, and the quick start part is at 14:25 ish.