How can we help JME

Hello guys,

I am the C.E.O of a software development company which develops games as well. We absolutely love JME3. We have started building an M.M.O.R.P.G with it which is close to the first alpha.

However I have noticed that the releases for the next betas of JME 3.1 are postponed due to some problems. All I know is that you can’t publish new releases. Now, since we have some architecture setup and because we love JME I was wondering if there is any possible way we can help with your problematics? We have some servers which we use for our development however if it can help I would be more than happy to share it with you guys.

Let me know what can we do.

Best Regards.

4 Likes

The only problems with a release right now are time.

I asked the community to help make sure that patches to ‘master’ that should also be applied to the 3.1 branch are applied. There was no response. Not even the sound of crickets.

A new beta release will have to wait until I have the few hours it takes to learn the buggery of GIT enough to do this myself. Else, assuming the build scripts haven’t broken in the mean time, it only takes five minutes to kick off the process.

I mean, there are some other space-related logistical stuff related to jars we can’t release on jcenter or possibly the SDK uploads… I don’t remember. But also relying on an external party for such stuff was what got us in the position we’re in now. And anyway, it doesn’t keep us from pushing a new beta release of the officially supported stuff. (Long overdue.)

3 Likes

I understand, well for the space related issues we have a repository server which might be handy. Let me know whether you need a hand with it.

About the patches there is little we can do unfortunately. Well I hope betas get released quickly as we are waiting for the final release all time long.

Keep up the good work guys!

Best Regards.

I’d be willing to help but it would depend on the nature of the task. Keep in mind I’m a newb to github and java/netbeans. I’m officially down to a 6 day work week with Sundays off so I have more free time now.

I may not be capable of fixing complex shaders and other problems but if you need someone to do the computer grunt work such as updating and compiling files I’ll lend a hand just give me the instructions.

The SDK side of this is:
First of all: What we originally had was a little server/webspace where we had our custom maven repo and the netbeans update-repo.

With this gone, our jcenter maven repo lacks some jBullet and test-data, I guess. This part is up to the engine guys, the sdk currently simply builds the engine from source. I’ve heard that this is due to some Licensing/ToS (Since the jbullet.jar isn’t our code but 3rd party and test-data isn’t code at all)

We also miss our current update repository for netbeans/sdk updates but this is non-critical to engine releases (as actually anything sdk-related). I’m looking for a good solution and am evaluating bintray for this. I have to check their ToS.

Other than that, the SDK is fine and can even build the Engine from source.
The Problem here is only that we can’t/shouldn’t rely on any person, simply because we want something accessible by any team member easily. Any webspace/ssh access does not satisfy that criteria.

If that means Cherry Picking, then someone “simply” has to check every commit after the v3.1 branch was opened (and master became 3.2) to see if it is missing on v3.1 and if so, if it makes sence to have it.
For example we added PBRIsComing Branch to 3.2, that is a new feature and as such 3.1 unrelated.

Feel Free to search a bit and post the list on the Hub. I highly suggest you to use some graphical tool which shows the multiple branches (so you can see PRs and which was PBR and such).
When using SourceTree or comparable, cherry picking doesn’t even need fancy git commands. Other than possible merge conflicts it’s only about selecting a commit and a branch.

Now onto my personal opinion:
I don’t really understand why people are so focused on releases, especially on the actual name. I can only speak for JME but our Alpha Releases were simply at a fixed time on Sundays every 14 days. And so will be beta, etc.

Releases are only timestamps or pointers on commits at a given time. No-one can guarantee you that a release called stable is stable.

I’d rather use master and take the risk on experiencing some bugs because usually you have less bugs than on a fixed release because you have the latest possible version.

(I’m talking about the v3.1 Branch/master after alpha-1. When using 3.2 (which is currently master) you could always have some possible bugs introduced by new functionality or the functionality itself doesn’t yet work).

Keep this in mind: With 3.0 you have 0% chance of having the bug fixed, but with master, it’s only one Pull Request away :smiley:

This brings me to what I think could always help: There are so many people which don’t report the issues they come across if they find a suitable workaround. I know it takes time but that is what let us improve our engine.

What’s also important is contribution via Pull-Requests: If you had to implement something new which the Engine doesn’t offer, don’t hesitate to contact us about how we could integrate it into the engine or rather if it’s useful to be added to the engine.

This is what I believe a reason for the stalling a bit. We don’t have that much activity lately because no-ones reports an issue so no-one can fix an issue. (Maybe that’s a sign that it becomes more stable? :wink: )

I recently fixed the iOS Deployment (it still has issues), but there is only one user actively needing it/testing it out, so those issues stayed there for like a year.

So my advice would be: Simply use master (or rather v3.1 branch) and simply report the issues you might get. I think you can safely consider this “3.1-beta2”, given the time and bugfixes that have passed since.
Also since you are doing an MMORPG for which you need to know your engine tightly, you might be able to fix some issues you’d encounter and contribute them via Pull Requests. That would be the most helpful actually. Most issues are simple ones, you only have to find the root :slight_smile:

3 Likes

First, jcenter is for delivering maven-style lirbaries… thus they must include source and javadoc. This makes no sense for binary data and that’s what other distribution platforms are for (like bintray proper).

Regarding jbullet.jar. For a long time we didn’t have the source at all… just the jar. That meant that we couldn’t put it on jcenter (see above). I guess maybe someone located the source or something?.. but it still feels weird to push an ‘official maven-style’ release of something that doesn’t really belong to us. I mean it’s technically ok I guess but it feels weird. Maybe we are the only ones even maintaining such a thing now?

@Darkchaos

That was really long.

About the space, well what I wanted was to help and not make things harder. It’s really your choice whether to take the offer or not, it will stand there as long as JME3 exists. Basically providing access to all members of the team is not something impossible. I am not seeing the problem.

About stable obsession, it really takes importance when you use the piece of software professionally. Probably if I would have spare time and use a game engine to do a personal project with not much relevance it wouldn’t matter stable or not. On the professional side of view there are deadlines and milestones to be reached, an engine bug wouldn’t help the cause now would it? Not saying stable has no more issues but hopefully not visible ones.

About issues and pull requests. I totally agree with you, but thats something lets say normal, doesn’t everybody do it? Posting issues and developing the engine further its a must for every software product to take off. We will do all we can :slight_smile:

JME 3.0 really works fine for us on our current project, we started the whole project as a test for JME as we were reluctant on the engine, however it passed it successfully. There are things we would improve but since the project is a side project for us right now the focus isn’t there.

Anyway, I thank you for taking the time to write such a descriptive answer.

Best Regards.

Ok. Poof! It’s stable. I’ll tag it right now… but I doubt it would make you feel any better. (Kidding, not really going to tag it… point is made.)

The point is that we are fallible human beings. 3.1 final is not likely to be that much more stable than beta 1 or beta 2 or beta 50. It’s just a label that some people like to rub and coo and massage oil into lovingly… but ultimately means nothing.

The last folks who provided us space for free were going to do it forever and ever, too. If it’s not space we control or that is a public service (and even then) it could disappear without warning. “But no, for realz we wouldn’t do that to you!!!” Yeah, I’m sure you have the best of intentions… so did the last guys. Stuff happens.

Well, despite it’s ‘stable’ label… there are plenty of bugs and gotchas with 3.0. Glad you aren’t finding them but from a label perspective, 3.1 beta 1 is more stable for a lot of uses.

…except for those few folks who tried it, found some issue, and switched back to 3.0 until 3.1 went stable. (Thereby guaranteeing the issue will still exist when it does…)

No perfect answers here. It’s a community driven process and so far the community has been relatively absent on getting 3.1 ‘stable’.

Stable does not mean perfect and errorless. We both agree on that. Still would prefer something tested ( test of time ). I think we all understand that the discussion is about the concept of stability rather than the label right ? :slight_smile:

Well I understand your concern and really it doesn’t bother me at all if you don’t want to. Really, what do I gain by sharing space? Still I repeat if you change your mind the offer will stand.

About 3.1. We will convert the project to it as soon as we restart development. This way we can help putting the label “stable” quickly on it. :slight_smile:

Best Regards.

I agree (and lol), but from a marketing perspective I think it helps. I don’t like that this is how it works, but I think it does impact the perception of many people.

I’d help out myself, but I don’t feel comfortable enough yet that I can determine what “should” be applied to 3.1 in Git… and so on.

Well, you can ask. Answering a question and discussing it is a lot easier (for me) than doing all of the leg work to find the patch.

…and if it’s something you are pretty sure about and/or don’t feel like asking, you are only submitting a PR anyway. We can always look at the change and reject it.

It also would be helpful if someone could put together the list of changes since 3.1 was released. I knew how to do this trivially in SVN but never tried it in GIT. (changes on this branch since branching)

…heck, if someone would do that for me by Sunday night I’ll even cut a beta 2 without the additional patches and we can try for beta 3 for those.

My big fear was that this change list would be really small because of my other earlier request.

In my opinion I would just lable the current beta stable and provide maybe regular bugfix and improvement releases from now on and add a third number for that. The current beta really feels much more stable than the current stable 3.0. I guess there are not much bugreports because there aren’t much beside some rare used stuff like iOS or so. As well the current beta of SDK feels more stable than the old “stable” one.
And as I like to have multi light shadows I even would need the master and honestly I think it is not worse than the current beta or the old stable I guess ist it is even better. A continouse release cycle would be easier to maintain and would provide me fixes early and even after it is marked stable.
If I do software professional I do it strikt TDD for nearly every line if code to guarantee te that I or anything else breaks my code or break backward combatibility. There are a couble of articles about that from Noel Llopis about testing including that crazy monkey idea where they feed random clicks to there game.

Just my two cents

Except from my point of view, we get half-bug-reports, as in: “Oh, I’m still using 3.0 because 3.1 broke for me…” :confused:

It’s even worse for Blender Importer. I have to admit that our Maintainer isn’t really active anymore but still people say “If Blender doesn’t work, fall back to ogre”, which is (if I’m not mistaken) actually a jme2 relict.
Nobody reported an issue for this.

But I also think we don’t have that many active users in general, although the sdk counts 4,6k downloads on the latest release, we only have feedback from like 100 users per year. Even the hub is sometimes dead, no one posting something :stuck_out_tongue:

In my case it is the opposide I use 3.1 because 3.0 was broken :smile:
Ok but I see your point. So then everybody is using 3.0 instead 3.1 make your detailed reports then :wink:

1 Like

Ah damn I had - and forgot about as I postphoned it for a while - an issue where my bones do stretch my model even when I set all my scale rotation and translation to 1 as proposed in the forum. If you like I can share that model but to whom?

Well in General to the Github Issues Page of the Engine itself. It would actually be @Kaelthas but he isn’t around often anymore

You know, we could really use a bug reporting tutorial. It might sound silly but i still have no idea what a bug report look like on git hub. When i have a problem I just report it here, because well this is where I have seen every bug report.

Maybie someone could add that in the tuto section. Might help getting every newbie to report bugs direcly.

3 Likes

Hm I kinda use the master branch for like ever, and stopped worrying about releases.
If I find a bug I can fix it, submit a pull request and be happy about it.

But I’m also using a rolling release linux, and people often ask how often it breaks down, answer is, it did not at all since I installed it. The worst I had to do was input one error to google, follow the 2 steps listed and done.

Other benefit of master is, that it is java 9 capable.

Well it is the same as on here. It’s only humans who process the github issues as well.
You might post here first to ensure it’s not a failure of yours, though.

Other than that, sdk/docs/reporting_issues.md might be helpful for you.