I meant you can use that code and simply wait for ANY Event to match that in your game, ex:
“Now hit the Gas” → Waiting for Event → Mapped Gas.
That way it doesn’t care as what axis it’s been seen, since you can’t map JUST ALL gamepads and even then there were three control styles back on the PS2, soo.
Since those things are highly game specific I think this is more of the developers task to match the Buttons to his game style.
But granted, it would be nice to have atleast the ps/xbox styled once to be consistant (but consistency is no real reason to seperate them from the master branch :P)
Sorry, but I don’t want to become mean, but you really don’t seem to understand.
It’s not about what I could do, but it’s about what’s in the engine right now.
And that’s what I’m going to use.
And “right now” means “stable” means jME 3.0.
Well, a) hopefully they’ll go back and see how I answered the same questions four or five times. And b) hopefully they’ll understand how crazy it is to directly modifiy the jme3-core jar just to update a properties file that is already easily included in their application and will override what’s in the core jar.
Responding to your posts (here and elsewhere) has become a bit tiresome so I should probably take a break.
Yes, I think that went a bit over-the-top what I wrote about attitude. I am sorry. Please accept my apology.
I understand that many noobs ask you the same questions over and over again. I don’t know how I would react after several years of “support” here. At least I hope that I would stay positive and treat people with respect and politeness (a thing which I learned just recently myself - obviously not yet with full perfection).
The elsewhere thing: You mean other forum posts in this forum? If the elsewhere is somewhere else then this guy is an imposter. :chimpanzee_closedlaugh:
The tiresome thing: I experienced that in the airplane discussion when my suggestion was not tested but was going under until another user suggested the same and then it worked. I did not read that physics book to then not at least have kept some useful information in my monkey brain. :chimpanzee_wink:
Also it’s hard to tell people why these things need be done that I need be done (e.g. let new users fiddle with their own joystick mappings). It’s tiresome to have to justify every step. In this discussion you see that there are (maybe) good reasons to want to achieve the goals I want to achieve - the technical details don’t really matter to me - if there is a good solution meeting the requirements and restrictions then I will use that.
So all in all: It would be sad if you “take a break” but a man must do what a man must do. You really helped me and others many times and I soon give something back so that you are not so very alone and new users have a new toy to fiddle with showing them how to (maybe) do things the right way (righ way is a variable which evolves as the user evolves into an jME expert).
a) I tried to get you to say why wanted them to do it. I even kept offering the “in case they want to edit it”… but because it didn’t seem to sink in that it was already being included by default then I had to keep repeating that if they didn’t want to add their own mappings then there is nothing the need to do.
b) directly editing the properties file in jme3-core.jar is flat out crazy considering that it is entirely unnecessary and was exasperating because it was yet more evidence that you still didn’t get what was going on.
c) the source code is available in would probably only take five minutes to confirm what I’m saying.
Me being usually right about such things on the forum is not some magic super power… it’s because I take 30 seconds to click through the source and javadoc and verify 95% of what I say before I say it. Non-JME stuff I may be completely off my rocker (though I generally google that, too) but for JME stuff unless I specifically say otherwise, I already looked before responding or have direct memory of having tested the exact thing already.
Okay, first of all: Sorry, maybe I did not get what you wanted me to say next.
Now the situation.
The situation is that a user with a gamepad most likely needs to edit the file in order to improve the overall experience and learning path. There are (at least) three reasons:
the gamepad of the user is not yet in the properties file
the name is a different one under the user’s OS (my German OS has different device names for some gamepads and when drivers are not installed it’s just called “Human Device Interface” even in an english Windows).
the user wants different mappings and does not have a magic mapping tool or doesn’t want to install a magic mapping tool (which may be better for the average user than to download some shareware from the internet).
I too thought it is (and I agree). I wrote that so that someone could come up with the right solution. I don’t know the right or best solution. That’s usually the reason why I post a question in the forum. I wrote that purely to let others tell me “that’s wrong - do it this way” but I only received “that’s wrong”.
It’s probably not the right way to communicate like that and maybe I should write: “is there a way to let users globally add entries on their machine to that file?” and “will the entries of a .properties file in the assets folder override the jME default values?”
I’m sorry for having used the wrong tactics to communicate.
It’s way harder for me and takes way more time for me. I don’t even know where to look in this particular case (that makes the difference between 5 minutes and 5 hours). I can’t estimate how and when these files are loaded. I don’t know where to put these files because I don’t know the mechanics of the environment (e.g. the inner workings of the SDK). I am designing software and writing libraries and I’m designing games. I usually don’t need to know these details, but I will try harder in the future.
I’m not so lazy - I can look into the source of some classes (because I can navigate in many things, e.g. look what an AbstractAppState does or the SimpleApplication or Application or other classes). But it’s very hard if I don’t know the workings of specific code like the (undocumented) feature of the .properties file - I am very happy that you wrote that feature and that it’s already in jME 3.0, but I need a little help, that’s all.
I’ve understood that part. No question. But I would really like to have a global solution.
I just missed the step to write: “Maybe I can have that for all projects in the SDK?” and “How about that: [crazy thing I wrote]” and “Sounds crazy? Tell me how (and if) it can be done the right way, please.” and “Please consider that my users will not understand very complex solutions involving to fiddle with SDK build config that even I don’t understand - but if it’s just a one-liner in a XML file it would be okay.”
So it’s not that crazy - there were just some details missing in the communication. Maybe some important details.
Anyways, thanks for your help so far. Even if communication failed (which is my fault).
Well, “include this file in each of your projects’ assets folder” to me is not crazy at all. Modifying core jars is pretty crazy.
“But I get tired of copying that file over and over…” “Ah, young padawan then submit it for inclusion into core.”
Else, it’s less unclean to just put it in your jre/ext folder and make your users do that, too. That’s only medium crazy and everyone who does that will hate themselves later. Not as much as they will hate themselves for screwing with their jme3-core.jar.
…6 months later: “I upgraded JME and now my joysticks don’t work.” Then pages of forum replies later with numerous code samples that all work as expected, etc… we finally figure out that they had modified their jme3-core.jar.
It’s a nightmare support problem that I cannot easily condone and I will continue to call it as crazy as it is because even the thought of it will make me lose sleep tonight on all of the potential time it can waste. It is not even to be considered. Taping the .properties file to your own eyeball should be ahead of it on the list of “crazy things to actually do”.
Can’t stress that enough.
Just copy the file into your projects. It’s the easiest, safest, best way. Treat it like any other asset that you’d want to include in all/most of your projects. Or any other jar file that you have to add to your dependencies. Heck, just put it in a jar file if that somehow feels really different to you and just include that jar in each of your projects’ dependencies.
Do not under any circumstances ever suggest that someone directly modify core jars. Nothing but trouble for everyone (but especially us attempting to provide support in our free time).
I think in the end there will be only 2 projects in the tutorial (the “all-in-one-file” and the “splitted-the-file”). For this “2 projects only” scenario it is still a somewhat viable solution.
And that’s the opposite of what I want to achieve - believe me. :chimpanzee_closedlaugh:
Well, yes, I understand, and will not write such things in future posts.
That’s maybe the best direction. Thanks for that hint! Should make another project in the SDK and let users reference this project from the 2 other projects. That’s how I currently set up other projects too - as a network of SDK projects referencing other SDK projects.
Okay, I see the need to let you forum angels decide whether my new tutorial is okay and ready for the community. Maybe I will post it in a separate space first so that you can point to the things that I really must do differently to avoid support nightmares for you. I currently don’t know what that might be, but we’ll see. Another goal of version 1.0 of the tutorial game should be to cause as few support hazards as possible here.
