Depends. If it was for what I say about “being silly”, I don’t see a reason why not be there. Not as a support or official representation of problems, though. Those have to be on the hub. Maybe we should add some policy of not “asking” questions on Discord?
And to take that example: I guess people were just emotional as they hit a problem. They would’ve said that with every other engine as well. [Not to discuss about that but rather to not disencourage others reading this]. Emotions happen, especially in something so “direct” like a chat.
There’s also a bit truth in that though, other engines make shadows feel like a no-brainer, where in jME it’s kind of a rocket science (adding one renderer/filter per light, worry about statistical distributions (Poisson?), parameters etc).
Do they? Personally I never got that feeling, but it might be just me. Most people there do know their way around jme though and are often trying to do stuff jme wasn’t designed (yet) for, so there might be a bit more “can’t manage to do XY” discussions.
I wasn’t even thinking of a specific example as it happens all the time.
Person one: “This engine sucks because it can’t even do X.”
Other people pile right one: “Yeah, this engine sucks.”
Some voice of reason: “You just have to pass a boolean like it says in the javadoc.” Or something similarly trivial.
And it’s fine to have that. I agree emotions need to get out.
But to have that be the “official” channel? I don’t know.
I’m no discord pro at all in any sense. I’ve used it a handful of times to catch up with old friends, but isn’t that what channels are for? I have no idea how it all works.
Meh, i think the discord is fine, but i see that you have a point, some people might not like it expecially if they expect a “professional” environment that you would expect from something marked as official.
So in the case of say Normen, who amongst many things, was something of an Audio and Phsyics officionado. He doesnt post a great deal these days, so it might be better for the user to see directly that they are no longer “regularly” active. I’m not saying dont@mention them, I’m just saying that their title clearly explains that they don’t actively maintain their contributions anymore, so don’t get your hopes up for a reply. You can still give it a go if you want, but at least you have a good indication if they don’t reply.
I’ve already added a new group called “Engine Leaders”. Currently only Paul is a member until any other member responds to say otherwise, else they will be put in the “retired” category. This means we now know who is active, that they are active, and where in the team we might need to look for people to fill the gap. It is part of a slightly longer than I would like process of sorting the active from the inactive.
Since you have access to titles, should be easy to just edit the Core Team title and add [Retired] so everyone who has Core Team now is retired. Then create a new Title Core Team and pass that out to current members.
indeed @sgold recently did much into engine(releases/bug solve motivation/physics), so should have “Core Developer”. Ofc giving too many of it will also have no sense.
also great idea with [Retired]. It leave the rank just saying the person is like inactive currently.
I am 100% agree with what @jayfella said in the first post and vote for him to be the project manager.
Totally agree. And to add to it, IMHO another very important factor to make JME an outstanding game engine is to have some successful commercial games made with this engine. For example, an online multiplayer RPG that uses most of the cutting edge features provided by the engine and related projects like Simsilica LLC, Minie,…
This is what I am working hard on it at the moment.
Well I’m hoping the store will provide a means for people to be able to do this.
There is talk on other threads of “adding x to core” - when in fact if anything core should be reduced. Terrain should be gone for one. It’s been said many times but now it’s there as a legacy thing. The core should be the core.
With the store it will let people create a library or catalog of add-ons where you literally copy-paste a single line into your gradle file and you have it. In the future I would like to see it built-in to the SDKs. I will do it for the intellij integration at least. It’s all one big JSON API so it’s not some crazy html parser magic that breaks every time the CSS changes.
I personally have a lot of sub-projects I’m going to share and I don’t think I’m the only one. Pacejka vehicles, heightmap & density-field terrain, Shader controls, out-of-the-box minimaps… the list goes on. Just add a line of code.
It also means that developers working on the engine don’t have to fix a ton of other peoples code that isn’t even vital to the engine. Plugin stops working? Developer stops developing? No problem, we have alternatives. The nature of developers will work in our favour. If you look at any other plugin system this is how it works. If it really is that great it gets picked up by someone else, if not it gets replaced by something better.
Imagine a store where you could grab infinite terrain, grass, sky, terrain editing tools, pacejka-simulated cars, a minimap, shader-based GUI controls, tree planters, and being able to get it all working in a matter of days. And those are just some of my contributions.
This sounds like mixing two things, though: What should be in “core” and what should be officially “supported”/part of the engine. Like for me, jme3-core should contain Spatial, Geometry, Vector3f etc, but that doesn’t necessary mean we have to give up control over all the loaders (gltf loader being an external plugin?, Terrain?, …) because the latter also means that it’s not anymore tested with breaking changes.
If something, we could add some of these add-ons to the testing process of the core or something.
And it’s a question how good such a pluggable approach is (see the confusion many people have with GUI Libraries). But we will see how things go.
It’s a bit moot because we can’t undo what’s been done without breaking everybody’s chain.
Having said that my personal opinion would be that yes, GLTF loaders and terrain should be external. They aren’t required in almost all situations. I dont always want the terrain plugin, I dont always want the GLTF loader - in fact I only want it in production (in almost every case) - you could argue really that the GLTF loader is an SDK extension unless you’re letting people import from external sources.
It reduces carrying around things you don’t even use in production, cleans up the codebase and is just a much more generally cleaner approach for developers.
When we have multiple solutions doing the same things in the core, we should choose the best one and develop it. Eg instead of having 99 importers, we should keep only the best one (gltf?) and fix/improve it.
need to find the Golden mean.