Hello,
I think this one is for @pspeed and/or @normen :
Where do I get the latest “official” version of the joystick-mapping.properties file and where do I need to put that to run it together with the TestJoystick.java in a jME SDK project of type “JME_Test” ?
Thanks for any help,
(it’s for the game which I want to donate to the community)
That latest is already in jme3 core data… and is in git in the location of all of the other jme3-core-data stuff.
If you need to customize it then you put it somewhere that will be on the classpath… like the root of assets or the root of your resources folder or the root of your src folder. Depends on how your build is setup.
Hm, I can’t find core-data here: GitHub - jMonkeyEngine/jmonkeyengine: A complete 3D game development suite written purely in Java.
I only find links to googlecode and forks like these: IN4189/joystick-mapping.properties at master · btodorov88/IN4189 · GitHub
Okay, when I have the file, then I will try to put it in some of the mentioned locations of the JME_Test project.
The question here may seem silly for someone like you. I don’t know much about Java build systems and how the SDK works is quite a mystery for me. I would like to know more about, say, gradle or ant or how the SDK builds things. But that will cost precious time and is very painful to me because I just want to programm code and not manage things like build systems - my personal enemy.
Why do you want to mess with it at all if it’s already included in JME?
Are you trying to show them how to customize this? How much stuff are you putting into this one simple game tutorial?
Anyway, here is the file:
If you copy that and put it in the assets folder of your project then it will be on the classpath and get applied after that one. So if you aren’t changing anything in there then there is no reason to do anything.
Well, I just do what the SimpleApplication FlyByCamera does, but to move the monkey Jaime.
For now, I just want my gamepad to work with that game in a correct manner.
And yes, later the tutorial will explain to the students how to edit that .properties file so that their gamepads work properly in the game.
Thanks for the link,
I must have seen the .properties file but somehow not have noticed it.
Also, the “Find file” function now works correctly for me.
Sorry for having bothered you people with it.
Thanks for the advices.
If you are using the current version of JME then it should work without you having to do anything.
Please tell me more.
(I hope it’s not GLFW with that ancient 1990s API or forcing XInput?)
I’m not sure how many different ways to say this. That properties file… the one I linked… IS INCLUDED IN JME. When you include jme3-core.jar in your project dependencies you automatically get that exact properties file.
So copying it into your project does ABSOLUTELY NOTHING if you are running the current version of JME (ie: not the ancient 3.0 but the current 3.1).
Now, if you need changes since 3.1 alpha 1 (thought note: alpha 2 is ‘any day now’) then you will have to make them locally. Else there is nothing you can do to that property file that will make things work or not… as it is already included when you use JME. ie: any JME application that uses jme3-core will have that file… ie: ANY JME application will have that file already. The one that’s in git.
Edit: put another way… anywhere you can load a standard JME material like lighting or unshaded… you also get the joystick properties for free. Because they are distributed and loaded in essentially the exact same way.
Big misunderstanding, I meant this:
I don’t know if there is already an entry for one of my 15 gamepads I randomly grab from the shelve (I currently lent my XBox gamepad to my brother). So if things magically work without me having to edit the joystick-mapping.properties it would be a wonder (somethings I don’t yet know or understand - like a mystery or an enigma).
As for the build system, you can use any tutorial out there 
Basically Jme moved from ANT (which netbeans uses internally and builds the build.xml for your) to Gradle.
To build it, you only have to call ./gradlew(.bat) buildSdk and the JME jars are built.
If you then additionally want the sdk, simply open the supplied (downloaded with gradlew) “sdk/bin/netbeans/” netbeans and open the SDK Project Group there.
You can then simply build the project or by right clicking on it use the “Create Mac OS .app” (at least under Mac OS, you might see an .exe)
Note: you could also use ant to build the sdk but I think this one is more intuitive (especially when you want to debug the SDK, you launch it out of said netbeans!)
I have one more question about properties file in jME SDK 3.1 alpha1 / alpha2:
This is another variant of the “where to get” part of the originial question:
Just in case a user wants to add some lines to that file - where on the Windows / Linux / Mac machine would the user find it? (I know that the user can change the install location, but given the install location is either the default or some known string like DRIVE/JME_INSTALL_DIR/ we might still be able to derive the location of the .properties file on the machine which is being found and loaded per default)
As stated already… ANYWHERE ON THE CLASSPATH.
So, “put it in the assets folder” is the easiest of examples that I’ve already given.
And because I’m repeating myself, why not repeat this too: the original and the new one will BOTH be loaded… in that order. So, original JME one is loaded… then the ones the user might have on their classpath… in classpath order. So, repeating my repeat… if the user puts a joystick properties (exact same name as the original) in the root of their assets folder (the assets folder where they put all of their assets and the root of that is at the same level as Interface, MatDef, etc… so YourProject/assets/joystick-mapping.properties) then the JME one will be loaded and then the YourProject/assets/joystick-mapping.properties will be loaded.
…so start with an empty file because there IS NO NEED TO COPY THE ORIGINAL BECAUSE THE ORIGINAL IS ALREADY LOADED.
Is irrelevant. See above. If they want to see what one looks like then they can look on git.
Ah, okay, sorry must have over-seen that info.
So if multiple ones can be loaded and the data from all is kept, then it’s really very simple.
One thing that one would probably like to know: If a user adds a mapping for the same gamepad name which is already in the default joystick-mappings.properties, which one will be kept (I guess the new one, so that we can override the default config?).
And I would not say that it’s totally meaningless to be able to edit the default .properties file - because one could change all projects which are on the machine by centrally changing the default file.
But now I can tell users to unzip jme-core.jar, edit the file, rezip jme-core.jar - I think that’s okay. Since I have Linux and Windows, I can start a file search for that .jar file (for Windows I have a link to both the .jar and the unzipped .jar on my machine). Mac users would be asked to search this file for themselves.
Ugh… don’t do that.
“Just decompile your windows system DLLs, change one thing that’s easy enough to change in your app, and recompile.” Sounds ridiculous, doesn’t it?
You shouldn’t do that, especially since jme-core is in libs/ so it’s NOT shared across multiple JME Games (whereas the chance that a User has multiple is low, sorry guys ), you could ofcourse implement a shared directory to your classpath but that doesn’t all make sence 
What you should do, when you add a new controller mapping to jme is simply contributing it to jme, so we all can profit from your mapping.
Aside the default mappings (which should only be exactly that, only provide basic controls), you could/should have a custom thing in your UI, where users can change the controller mapping (Press a key to assign…)).
You could even use a Serializable Hashmap for that (Name to ButtonTrigger) or smth.
Ahem… why don’t you just run the test Joystick application? You will see by yourself if things works or not… 
What if the user deliberately uses a different mapping (like switching two buttons ore two axes)? So - there are reasons why people would not want to contribute their mappings and why they might conflict with the “official” ones. 
Write one for us, commit it to the engine and the newbies and maybe even I will use it. Until then I use low tech provided as is and tell users to do the same. :chimpanzee_wink:
I prefer thoughtful solutions rather than cynical negative attitude. I’m rather resistant to such stress (today), but other users might turn away and be frustrated after reading such things like those you posted in your last three posts.
With user do you mean developer or gamer?
For Users see the next bit of text and for the developer I don’t see any real reason Since the whole properties thing is more of changing the button numbers a bit.
The Joystick thing is alread implemented
You only need this exact RawInputListener. In the onXYEvent() simply change a Value in your HashMap and in the inputManager.addMapping().
Oh and maybe add a threshold of 75% for an axis or set the deadzone apropriately.
Also sometimes it’s tricky to see when the axis is inverted or not, when it’s doubled (-1 to 1) vs (0 to 1).
But well, this is something you can implement with ease 
Sorry, I know this code - and it’s not a Joystick mapping thing.
You can view what button you pressed but without the joystick-mapping.properties this TestJoystick.java is quite useless because most of the time buttons and axes are screwed up.
And it’s far from being a real mapping / calibration tool even when combined with joystick-mappings.properties.
That’s what we are talking about - the joystick-mappings.properties is all about mapping the right buttons and axis so that the user can use either a standard gamepad mapping or some special game-specific or user-specific mapping. It’s currently the only capability that jME has to offer for this.
Don’t get me wrong - I would really really like to make a tool with UI for calibration and mapping of a joystick and couple that with at least one of the major UI toolkits (say, Lemur or ToneGod). But it’s currently not going to happen - the pile of stuff that I need to finish is growing and my time is limited.
:chimpanzee_wink: