Next release of the Engine

Even if we were to drop

  • LWJGL v2,
  • the old animation system,
  • virtual reality,
  • jme3-nifty, and
  • the FBX loader

and replace jme3-jbullet with Minie, (far from likely at this point!) I believe all that would only impact about 5% of jme3-examples.

What scares me about these ideas is how much Wiki updating would be required to properly support them.

It wouldn’t be gone, just rolled into a separate library I guess like the other stuff.

I assume that if we rolled jme3-vr and/or jme3-nifty into separate projects, nobody would maintain and release them. That’s what’s happened with jme3-blender and jme3-bullet/jme3-bullet-natives since they were rolled into Jme3Bullet and BlenderLoader.

1 Like

Can’t all of this be served like the LWJGL download page already does?

https://www.lwjgl.org/customize

We should provide a few sample gradle files that manages the reccommended components (and point out the “deprecated” status of LWGL2/nifty etc). I don’t see a valid reason to snapshot a library; most users will just want to grab the latest of everything anyway…

Wiki and examples should be marked as deprecated as well, and eventually hopefully be updated.

Also lbgdx does the same

1 Like

Could be that some are just obsolete. Blender and Bullet. The small minority still using them need to either start learning how to maintain these (yikes…) or migrate to more up-to-date solutions. I totally understand the need for these actions. Just a heavy burden to carry. I already see myself maintaining the jme3-nifty library :frowning: Hopefully it doesn’t need much as the Nifty itself probably doesn’t get any new releases and maybe jME has a pretty stable API at this time…

I agree with @Pesegato that snapshots wouldn’t be the way to go. Maybe even no need to include. Just instructions, “want UI? get x”. SDK can be used to create build file with wanted dependencies. Even the web side could bake this build file (or just the dependencies in Gradle/Maven format) for experienced users to jump start their jME project in their favourite IDE.

2 Likes

I already see myself maintaining the jme3-nifty library :frowning: Hopefully it doesn’t need much as the Nifty itself probably doesn’t get any new releases

I have a fork of jme3-nifty you could probably use, and I’d love to have you as a collaborator/tester/user on that project.

I concur that new releases from void256 are unlikely. However, one of my ambitions is to transition my fork from Nifty v1.4.3 to StarCommander’s “1.5” branch.

2 Likes

Just want to remind you, that there is some people with less experience.
I remember that one fellow monkey using JME in his classroom to teach students.

What I am saying is: If it is to complicated to get even a small project started it might disencourage (new) users.
On the other side the question is: Who should and want to use the engine ?
Is it more hobby, should it be professional, is it for specialized people (replacing professional stuff) or should it be good and easy enough for pupils and students (like adi.bardas project) ?

2 Likes

Another thing for my wishlist for 3.5:

  • GLFW Gamepad APIs integrated on InputManager

see Proper Gamepad support with BigBanana

2 Likes

I totally agree with you. Trust me. That is why I’m trying to advocate the jME SDK even if for the professionals it is dogfood. But it would be the gate drug to get to jME when a person does not have any clue on any build systems or doesn’t even realize that jME is just a JAR file. It is entirely plausible to have some Java experience and a burning desire to create games but being clueless about Gradle and libraries. And hopefully via SDK (or other really easy start) mature into a healthy contributing adult monkey.

1 Like

Note: the SDK does not need advocates. It needs contributors.

2 Likes

Yes, sad truth too. Currently lacking behind, yes yes. I see the build system being the biggest problem there. It is frankly intimidating to try and get into it. I should try again to convert it to Maven…

1 Like

Replacing 25 year old tech with 20 year old tech. Hmm… but SDK contribs should be its own thread. It’s separate from the engine.

1 Like

I know. But it is the best there is with NB. And it works. Already offers features and ease of use comparable to Gradle. Nothing is sexy there. Netbeans. Outcast. But all may not know that so we might just get away with it :slight_smile:

All the other projects trying to create an SDK have failed. The Intellij plugin, dead. All the other non IDE based SDKs also dead as far as I know. It is just a huge undertaking. No matter what is under the hood (bonnet :slight_smile: ).

1 Like

Yes, we could create a setup form similar to LWJGL. If you want to take on that task, please go right ahead.

I still think adding library snapshots to the Engine would be valuable for newcomers. In general, newcomers favor built-in libraries (such as jme3-nifty and jme3-jbullet) over “supplementary” ones (such as Lemur and Minie). Rather than piece together a bunch of unfamiliar libraries that might have incompatibilities, they’d prefer to start with a set that have all been packaged and tested together, even if it’s incomplete and/or not the latest releases.

I had a comparable newcomer experience when I switched from Windows to Linux in 2019. Rather than piece together a bunch of Linux packages, I started with the Mint distribution. It didn’t include the printer support I needed, nor the latest releases of Java and Blender, but it enabled me to boot without knowing anything about kernel versions and package managers.

2 Likes

Nice but a few questions:

  • this look like the JME SDK purpouse. We might as well work on that instead.
  • who will actually choose the libraries version to snapshot and test them?
  • who will review or include the documentation/samples to make sure they match the bundled versions?
1 Like

Clearly, including a few default library versions is a WAY smaller task and affects a LOT more people than fixing all of the issues with the SDK.

1 Like

Sorry for derailing the thread, but I thougth we were talking about providing a “quick solution for newcomers” who just want to download something and be ready to develop.

I didn’t mean “Fixing all the issues” or even “mantaining the SDK”. Just “bundle a version that can build & run the examples”

EDIT: This might become the “JMonkeyEngine starter” to clarify its purpouse

There seems to be plenty of interest in issuing another release of the Engine. Let’s keep the discussion going.

Meanwhile, UNLESS CONCERNS ARE PROMPTLY RAISED, I propose to designate myself as release manager for a v3.5 Engine release, the contents of said release still to be determined.

Here’s a proposed action plan for the release:

  1. Create a “v3.5.0” Engine milestone at GitHub, without a due date.
  2. Target closed issues and PRs to the new milestone if they’ve been solved/integrated since v3.4.
  3. Open issues as needed for ideas that emerge (or have emerged) from this discussion.
  4. Target open issues and PRs to the new milestone if they seem like promising candidates.
  5. Publish an alpha version for testing, with a list of changes since v3.4.0 .
  6. Announce a feature-freeze date.
  7. After feature freeze, create a “v3.5” branch at GitHub and publish a beta version for testing.
  8. During beta test, integrate low-risk bug fixes from master into “v3.5”.
  9. Announce a code-freeze date.
  10. After code-freeze, publish the “v3.5.0” release.

A major Engine release is a large undertaking, so it’ll have to be a team effort. Please contribute to the effort by:

  • continuing to discuss the release here,
  • opening and discussing issues at GitHub,
  • opening pull requests,
  • reviewing pull requests,
  • testing alpha and beta releases, and
  • updating the Wiki.

While it’s likely I’ll do all these things to some extent, I’d better not be the only one!

7 Likes

What about user issues and pull request submission to snapshots, should they be allowed to submit them on the engine page? (Just a heads-up!)

1 Like

If someone submits an issue/PR against a snapshot library, we should direct them to the developer’s repo (assuming it’s still maintained) and close the issue/PR.

If the developer’s repo isn’t maintained, then have a choice. We either maintain the library ourselves (in which case issues and PRs would be welcome) or drop the library (in which issues/PRs would be quickly closed).

But this is starting to look like a moot issue. Unless there’s strong support for library snapshots in the Engine, it’s not going to happen.

2 Likes

Good point about the SDK. For instance, I believe the latest SDK includes Heart and Minie. But maybe the SDK isn’t the best/only start for newcomers. I’ve opened a new topic to discuss getting newcomers started.

Engine content is the responsibility of the Engine team (between releases) or the release manager (during a release). They would decide which snapshots (if any) to include.

Testing would be performed (and documentation would be updated) in the same manner as other libraries included in the Engine: by volunteers led by the Engine team or release manager.

But I reiterate: library snapshots aren’t going to happen without strong support from the community.

1 Like

Do we still have custom skeleton from code support in the current version?