jMonkeyEngine 3.1 seems to never get into stable, there is no release date for this?
In 8 ulatrons.
3 Likes
Ok… 
Sorry to correct you dude, but I thought we agreed on 8 ulatrons and a half…
@Dimalenus you must realise new features never come without bugs. It takes time and lot’s of tests to make it “stable” enough. And there are also features being removed and/or changed.
Can you remind me - there’s 17 filtars to an ulatron right?
Well… depends on the radial velocity. If below 238 it’s 17 but after that it’s 38, obviously.
1 Like
Seriously, though… we were on the glide path to a 3.1 release with regular alphas into the first of what would be a handful of betas when our web site went offline. Since that time we had been unable to push new betas so effectively no progress was made in testing.
We’re working towards a beta2 release soon… as soon as we agree what happens to things like jbullet.jar now that we don’t have updates.jmonkeyengine.com anymore.
We should talk about that, but we have jbullet.jar here sdk/lib at master · jMonkeyEngine/sdk · GitHub (It’s what jme3-jbullet seemed to depend on runtime, taken from jmonkeyengine/lib at master · jMonkeyEngine/jmonkeyengine · GitHub) and I have a jme3-jbullet locally and could include it to that libs so the sdk works without publishing jbullet.
But of course there are also other considerations to drop engine support, I just wanted to point that out
We’ve been talking about just defaulting to the native bullet and letting folks get the jbullet stuff from contrib. The SDK would have to be converted to default to native bullet also. May be a bit late in the process to do that for 3.1 but probably half the reason anything is still not right in native bullet is because it’s too easy for people to ignore it. jbullet is a bit of a dead end at this point since there is no source and no one to maintain it anyway.
3 Likes
Dropping jbullet would certainly reduce the maintance work. Especially since the current interfaces must be kept in sync with jbullet and following this rarely have support for some native only features.
I don’t know what the problem is there. If its additional features its just additional API, main thing is that the jbullet “baseline” is implemented the same on the bullet side. Theres several features like joints that only exist in the native wrapper.
The problem is we can’t distribute jbullet. and it’s not available on any maven repo whatsoever.
Dropping it would solve the problem. Asuming we have a better/workable alternative with bullet native.
I was responding specifically to Empires objection.
oh sorry 
Hm seems like I remembered wrong then 
Reegarding the soure code, the problem here is that our version had modifications?
Yeah, I meant to upload the source code of “our” jbullet somewhere as branches seem to have been deleted on googlecode but my laptop broke down and I still have to dig out the code from the backup disk.