JInput version?

[Nate]

Does JInput have the concept of versions? There seems to be only a "latest" download.

[Nate]

I found JInput has a Version class with a getVersion method.

I found that unplugging a controller, then plugging it back in caused it to not be recognized any more. I looked at JInput's code to see what it would take to reload the controller list each call to getControllers rather than just the first time. Thar be dragons in the JInput code! Yeesh. I'll just live with it.

[endolf]

I found JInput has a Version class with a getVersion method.

I wouldn't rely on that to tell you more than major version changes, which has only happened once. I really ought to get around to having a nice version control system (and I don't mean cvs), but I've yet to find one better than the build timestamp or svn revision.

I found that unplugging a controller, then plugging it back in caused it to not be recognized any more. I looked at JInput's code to see what it would take to reload the controller list each call to getControllers rather than just the first time.

There is still an outstanding request for having controller listeners working. There is a listener interface for this. At the moment, if a controller is unplugged the existing controller object in JInput gets closed, any new controllers are ignored. I know of one project that did handle this, but they can't release the code publicly . Maybe it's time I gave up hoping for other contributors and just did it myself.

Thar be dragons in the JInput code! Yeesh. I'll just live with it.

It has to handle native code on at least 3 platforms, what did you expect!!!

Endolf

P.S. Sorry for the delay in responce, spent a couple of days under a duvet with man flu.

Games published by our own members! Check 'em out!

[Nate]

Thanks endolf. I was starting to feel very alone! Hope you are feeling better!

I've yet to find one better than the build timestamp or svn revision.

My problem is that the only JInput download is simple labeled "latest". Maybe the build system could write a file named "version" into the root of the zip? I like all JAR files in my project to be named name-version.jar so I can keep things straight in the future.

There is still an outstanding request for having controller listeners working. There is a listener interface for this. At the moment, if a controller is unplugged the existing controller object in JInput gets closed, any new controllers are ignored. I know of one project that did handle this, but they can't release the code publicly . Maybe it's time I gave up hoping for other contributors and just did it myself.

Controller listeners work fine.

It would be ideal to support unplugging and replugging controllers, and also plugging in a new controller while the app is running. When JInput is first asked to get a list of controllers, it goes out and finds them all. When asked subsequent times, it just uses the existing list. Couldn't we just go out and find them all every time? Maybe have a new method for doing that?

It has to handle native code on at least 3 platforms, what did you expect!!!

Heh.

Well, I expect there to be some nastiness hiding somewhere. JInput does hide this from the developer, but does so with a complex API that is hard to use. Slick puts a thin veneer over JInput to make it easier to use, AFAIK without losing functionality, so it is possible to have a more friendly API.

I don't like some of the logging. At startup it dumps some stuff. When poll fails it dumps some stuff. Not sure if it is the JDK logging or System.out.

Man, java.net sucks. It is so slow! Also every java.net project seems to look inactive for some reason.

[endolf]

Hope you are feeling better!

Mostly, enough to be back at work and coding

My problem is that the only JInput download is simple labeled "latest".

There are nightly builds that have the build date on them. Hudons builds this every night.

It would be ideal to support unplugging and replugging controllers

Agreed, thats what the controller listeners were originally intended for.

Couldn't we just go out and find them all every time? Maybe have a new method for doing that?

We could, it's slow, and there are some clearup issues to resolve ,like people still having references to controllers from the last poll, those old controller/component objects do not always need clearing, we might have the same list, so then the old objects should work still. Thats my plan. Maybe I ought to get on and do this

JInput does hide this from the developer, but does so with a complex API that is hard to use.

Yup, it's not the simplest, but it is very flexible. The idea of JInput was always as a building block, not much more than a wrapper over the native layer. We could have had a JInput utils project that tried some other things.

I don't like some of the logging. At startup it dumps some stuff. When poll fails it dumps some stuff. Not sure if it is the JDK logging or System.out.

I recently did a couple of logging updates. Hopefully the logging is all done in JDK logging, which means it can at least be turned off

Man, java.net sucks. It is so slow!

I'm with you on this one!!!

Endolf

[endolf]

Ok, JInput builds under hudson now stick the build number in the version string, so any build from 200/12/12 or newer should have a build string like

1	2.0.1-b374

HTH

Endolf