The Contribution Mega-Thread


Since a recent discussion showed that some fellow monkeys would like to contribute to this project, but don’t know where to start in the forrest of issues/pr’s.
That’s why here everyone (mostly devs from the team) can post issues which require some sort of attention.

Note that the interaction still should take place on github for those and specifically I don’t want this thread to contain any posts commenting on issues. Every post should be an issue.


Starting with
What action is required? Running the test case on NON-QWERTY Keyboards with both lwjgl2 and 3 (code is provided, you only need to run the gradle build) and pressing the “z”/“y” key.


Good one, @DarkChaos. That one’s high on my list as well.

Here’s another:

This currently needs investigation to help characterize the issue. Does it happen on all platforms? Is it only for certain graphics adapters or drivers?


Mmmm… this thread is a good idea.

When we moved to github originally, I was promised by everyone who dragged me kicking and screaming that discussions like this would happen here. But they never really did and then those folks left the project. :smiley:


Feel free to check this PR out (especially the Test where you can fire balls) and maybe also if it breaks your use-cases.

I had the issue sometimes that picking on a mountain in rare cases only led to a collision with the backside of the mountain. Can someone confirm if that was the case before that? Or did I break something?

Edit: Regression has been fixed, feel free to check the PR out and see if you find something that breaks. If you report it, please include the ray (origin and direction) and also make sure that you’ve commented out setLocalScale(2, 2, 2) in TerrainTestCollision, because otherwise I can’t reproduce the values.


Here’s a very easy one, a 2-liner, in case someone wants practice creating pull requests:

Issues like this are labelled with the “Easy first fix” label so people can find them by searching:


Thank you for posting it. I’ve made a pull request. I’ll also take a look at the second one.



I recently stumbled upon this issue an created a PR for it:


Here’s another easy first fix:


Is there a 1070Ti as well? :stuck_out_tongue:


If someone is running OS X and wants to help out, we are looking for testers for this PR:


Another easy one:


While we’re looking at runtime access to interfaces, may I draw attention to AudioSource only having getters and no setters? I don’t know the decision process behind what interfaces have what access, but I feel this one is along the same lines as Renderer. Not having them defined really makes it difficult to make your own AudioSource while still maintaining compatibility with audio nodes if you still wish to use them on occasion.


AudioSource is an “engine facing” interface. It’s not really a user-facing interface… that’s why the only setters are for internal use only.

Why would you need to make your own AudoSource that is API-compatible with AudioNode? In what cases, from the user perspective, are these two things interchangeable.


Since audio node is basically just a container for AudioSource, most of the methods make sense across implementations, for example I was making some tweens for playing the menu music with my own AudioSource, I was hoping to use the same tweens to adjust audio on nodes if applicable. It just seemed odd that you are completely unable to do simple audio adjustments (volume, pitch) to what basically acts as a data container.


Other than removing a few unneeded things… what is your custom AudioSource providing that AudioNode does not?


Please note:


Another easy one: