In due time… no sense in asking stupid questions or things that have been discussed 5 times before, and annoying people with that. A lot of reading to do still. The other issue, for me, is that I was an SVN holdout up until only a month or two ago. Only just recently broke through that SVN->Git barrier, finally, but I’m still reluctant to try submitting changes just yet.
Yeah, I have to use GIT at day-job and I still mostly hate it. For my github work, I check the projects out as SVN repos because I don’t like the GIT-pain. Means I can’t submit PRs that way, though. (I also have proper git checkouts in case I need to do something git-specific.)
My minute-to-minute dev life is just so much easier when I can “svn commit” to get my changes in and not have to worry about the add/commit/push dance.
1 Like
Seriuosly, I would! 
Not sure if I fully understand your points… either release is important, or it isn’t.
If is important… then you are contradicting with the statement below:
If is unimportant… then why bother with releases to begin with? Just leave it on master.
As somebody said, I guess the magic work is marketing. And marketing is all about lies… well crafted lies, but still lies…
1 Like
Agreed, the label basically is given because of the stability of the software and not the other way around.
So that says it all, if a product is stable it is given that label.
1 Like
It’s not unimportant… but given the input the community has shown to making 3.1 “release-ready”, my guess is that stable will not have much more in it than beta 1 because we’ll simply eventually label it as such after two years of waiting for the last issues to be resolved.
So that was the missing part of the contradiction. I don’t want to just label it ‘stable’ because I believe that the label is important and I would be the one stamping it… so I won’t. But it seems like others think it’s fine or doesn’t matter… so given the number of people who say “I’m still using 3.0 because 3.1 doesn’t work for me” I guess 3.1 will never be much better than it is now.
I didn’t cut a beta 2 last night because no one was able to figure out how to give me the list of commits that have been applied to the 3.1 branch since beta 1. I may be able to get to it tonight else it will have to wait until next Sunday.
I will be converting my OGF project to 3.1 soon. The 3.0 release feels kind of outdated now that I’m close to it (took too long for me to write my stuff so I fell behind with every month that passed). For example I would like to learn more about the new cloning that was introduced in 3.1 and many more advanced features (shader nodes, light culling, etc.).
I always check out the engine source and link the source to the global jME libraries in the SDK to be able to browse through the jME source because I use that a lot. I think we should add a little tutorial on how to do that to the jME SDK 3.1 documentation.
It is definitely good decision. Even if you learn nothing about shader nodes and so on (like me 
), you will find that 3.1 works much faster in complex scenes.
For me 3.1 beta 1 works very well. I think it’s ready to make a stable release of it.
I also think it’s important form marketing reasons to make stable releases.
Well, I tried jMonkey 3.1 beta 1 today and it gave me a renderer problem when I tried to start the game. It just didn’t open, I am using ubuntu 14.04.
This would put me in the conditions to revert to 3.0 as 3.1 seems unusable ( seems ) . One of our boys tried it before and also reported something like this.
I will try tomorrow again, if it yelds the same results I will open a github issue.
Note, tried with both sdk of the beta and 3.1 by importing libraries. Actually I recalled today that this was the main cause we are still at 3.0.
As I recall my switch from 3.0 to 3.1 was not without issues. My recommendation: try to fix the issues you are having with 3.1 instead of reverting back to 3.0. You will probably gain a performance boost, will be able to use native bullet if you wish (which that is a totally different bunch of issues, but should probably do at some point since jBullet is gonna get dropped officially in the future), and by switching to 3.1 you’ll be able to continue using the most recent versions of JME. As I see it right now, the people that keep using 3.0 have two paths they can take: either they switch to 3.1 and you can use more recent versions of JME, or be stuck in 3.0 forever until they realize that they should probably switch to 3.x because that version as some cool feature that they want or something similar.
1 Like
Are you relying on OpenGL 1 support? JME 3.1 on requires GPUs that support OpenGL 2, ie: shaders.
Else “a renderer problem” can hopefully be made more specific in a PR.
Awaiting the issue report patiently…
1 Like
This should already be working in the SDK as we don’t only add the jar’s but also the source and javadoc.
Is the javadoc there?
On the other hand now that we build the engine ourselves, this might be a bug then. But it should be there.
I’ve also experienced that: 3.0 was more failure-tolerant than 3.1. For example you could have multiple FilterPostProcessors in your Scene but on 3.1 you get a black screen.
Same with jBullet/Native Bullet. They both have their pros and cons but by focusing on native bullet we have less things to fix.
I don’t know if this helps you or not, but semi ok documentation about our upgrade process. Mainly nifty issues though…:
OK. So let’s put it this way… I am a new user of jme3. I am like ‘cool engine, let’s download the latest stable release’ and get the 3.0 sdk (which, let’s not forget, is not compabile with Java8 and forces you to use an obsolete Java)…
I think the obsolescence of the 3.0 is overdue by now.
Good point. But we all have some responsibility to help out here too. As soon I as burn out and need a break from the stuff I’m learning and working on now, hopefully I can make myself somewhat useful on this front. It would be good to see a stable 3.1 release where “stable” actually means something.
1 Like
Hi, I can’t get sound on 3.1 on IOS.
Is that a known issue?
It was fine on 3.0.10
Any ideas?
I guess you picked the wrong thread but anyway:
No it’s not known since noone ever tried 3.1 on iOS so far, you’re an explorer 
The only “idea” is to try the simulator vs the real device and multiple file formats and such.
Maybe it’s lwjgl related or something
And note: IOS support has never been “officially” released as it’s only in alpha state or something… so issues with it won’t hold up a 3.1 release and therefore probably deserve their own thread. We definitely want to know about such issues, though.
For IOS, you really probably want to be developing with ‘master’, though.
Are you sure Apple didn’t remove the “sound” feature?
Sorry, couldn’t resist. 
2 Likes