Hey Folks,
Can someone with a JNLP that works with JInput post their JNLP file as an example for others trying to do the same?
Thanks
JK
A template for JOGL, JOAL, and JInput use via JNLP should be put in the Wiki and/or shared files area of the games project or relevant sub-projects.
Does anyone have a JNLP that works with JInput?
I’ve been playing around for half hour but don’t seem to be able to WS to even notice the plugin jars.
Kev
Everything seems to work apart from the “controller” directory. If I want to package the controllers with my app they’ll get put in the java web start cache directory.
However, the “current” directory when you run webstart is the directory where the webstart executable is installed. If I stick a controller directory with the appropriate files in there it works fine.
Now, I could use the property “jinput.controllerPluginPath” (thanks endolf), to point jinput at the web start cache, if I knew where it was. Now, I could just assume the structure of Java Web Start to path to it, but I can’t be sure that other JNLP implementations will work that way (or JWS in the future)…
So… I appear to be stuck. I could hack round it. It seems the plugin directory location needs to be slightly altered… or rather finding it does (if JInput is to work with webstart).
Kev
In addition… since the plugin jar name and plugin dll name have to the be same, you can’t deploy it with web start since it renames jars but not dlls.
EDIT: If this is actually a problem, it might be fixed by having the plugin class be able to report the name of the library it expects to load.
Kev
I believe the webstart issues are solved.
There’s a past thread on it, I forget all the details. Take a look for it and if you still can’t make it work pls post back here.
Hey again,
Apologies for the spew above, was getting frustrated. However, the problem still exists. I had actually read all the threads about webstarting with JInput. The only solution provided so far seems to be to have the plugins already present on the target system in a specific location (I believe $JAVA_HOME\controller was the example given).
That sort of negates the idea of deploying via webstart tho.
EDIT: Everything above still applies I think.
Kev
PS. Incidently, I only started to play with JInput yesterday and I’m already finding it easy to get on with. Thanks for making it a clean API. 
Ok, I have a deployable jinput webstart, but to do this I’ve had to introduce a bit of code and a property. There are no updates to JInput however.
I implemented a new Controller environment:
import net.java.games.input.ControllerEnvironment;
import net.java.games.input.Controller;
import java.util.StringTokenizer;
import java.util.ArrayList;
/**
* A controller environment that will pick up default controllers but
* in addition will also looks for a property specified plugin.
*
* This environemnt will obtain controller specified via the default
* environment and any environments specified in the "jinput.plugins"
* property. This allow webstart to simply path through all the files
* required and then specify the property.
*
* @author Kevin Glass
*/
public class DirectControllerEnv extends ControllerEnvironment {
public static final String PLUGINS_PROPERTY = "jinput.plugins";
private ControllerEnvironment defaultEnv = ControllerEnvironment.getDefaultEnvironment();
private Controller[] controllers;
public DirectControllerEnv() {
String plugins = System.getProperty(PLUGINS_PROPERTY);
if ((plugins == null) || ("".equals(plugins))) {
controllers = defaultEnv.getControllers();
} else {
ArrayList trolls = new ArrayList();
addAll(defaultEnv.getControllers(),trolls);
StringTokenizer classes = new StringTokenizer(plugins,",");
while (classes.hasMoreTokens()) {
String className = classes.nextToken();
ControllerEnvironment env;
try {
env = (ControllerEnvironment) Class.forName(className).newInstance();
} catch (Exception e) {
System.err.println("Failed to instance environment");
continue;
}
addAll(env.getControllers(),trolls);
}
controllers = new Controller[trolls.size()];
for (int i=0;i<trolls.size();i++) {
controllers[i] = (Controller) trolls.get(i);
}
}
}
private void addAll(Controller[] controls,ArrayList list) {
for (int i=0;i<controls.length;i++) {
System.out.println("Detected Controller: "+controls[i]);
list.add(controls[i]);
}
}
public Controller[] getControllers() {
return controllers;
}
}
This environment allows the developer of the application to specify plugins that he/she knows are going to be distributed with the app in a comma seperated class list property (“jinput.plugins”).
These classes are instanced using the “context” class loader. The libraries likewise are loaded with the “context” class loader.
The DirectControllerEnv does also include any controllers found by the DefaultControllerEnvironment. This way, when running at the command line the controllers directory can be used as normal.
However, when distributing via webstart no user is going to have access to the “controller” directory (since it’ll be hidden away in the webstart cache) so the only plugins that are going to be available will be the ones the developer distributes.
In the JNLP the property can be specified to point at the distributed plugins and the jars and native libraries for the plugins can be packaged just the same as any other webstart jars/libraries. So the JNLP looks a bit like this:
<resources os="Windows">
<j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>
<property name="jinput.plugins" value="net.java.games.input.DirectInputEnvironmentPlugin" />
<jar href="lib/jogl-win32.jar"/>
<jar href="controller/dxinput.jar"/>
<nativelib href="lib/dxinput-native.jar"/>
</resources>
For a full JNLP file that seems to be working check out http://www.newdawnsoftware.com/martian/jnlp/martian.jnlp.example.txt
Kev
PS. For details on how to package stuff for web start I wrote this tutorial that I’m trying to get checked: http://www.cokeandcode.com/info/webstart-howto.html
Thanks. I thought we had this covered already 
Vote time guys:
Should we:
(a) Fold this code into the ControllerEnvironment.
(b) Add it as an additional API class (maybe change the name to JAWSControllerEnvironment ?)
© Leaves it as an example and exercise to the reader?
JK
Hi
my vote is a, I think it probably belongs with all the other controller discovery, the Idea of it as another controller is a good work around, but I don’t think its a permanant solution.
Let me know and I’ll do it tomorrow after work, it should take a few minutes to do :), just got to agree on a property name, jinput.plugins works, which matches the jinput.contrllerPath one, on the other hand I saw jeff with a property along the lines on net.java.games.input.blah at some point, I suggest we make them consistant before version 1.0 release :).
Cheers
Endolf
Could we stick with the simple property names, i.e. jinput.* . Just find the long ones unwieldy. The other property is the one about using the context class loader which you don’t need if you make the change above.
EDIT: Incidently, martian madness now how JInput support. Woo hoo!
Kev
hmm. The reason for the long property name is so that there arent potential property collisions with other code.
But I agree its a pain in the arse.
In the end, either direction you guys want to go is fine with me
Hi
I understand the reason for it, there are a number of properties in my own code that run something like org.newdawn.darkvoid.starfighter.blah. I’m easy on this one, at the end of the day as long as it’s settled before 1.0 we can always change out minds if we want to after it’s done (with maybe a grace period where the outgoing technique, if set, prints a warning to the screen but continues to work). I’m not sure the shorter version will cause problems as it’s unlikely that a games dev would have jinput in there project, and then something else called jinput too with a plugins property, but I could be just being short sighted.
I’ll start on the short ones as I hate this keyboard :), let me know if you have any objections (apart from my silly reasoning to start with the short ones :)).
Endolf
I think we should be consistent with the other core packages. I don’t know if that means I’m voting for long or short properties
The package name should really be net.java.games.jinput - with a ‘j’ anyway to be consistent , shouldn’t it? Things that are named a certain way only for historical reasons should be changed before going to 1.0 if it makes sense.
But since CVS doesn’t handle directory renames very well, perhaps that isn’t such a good idea
[quote]But since CVS doesn’t handle directory renames very well, perhaps that isn’t such a good idea
[/quote]
Meh. Before 1.0 stabilises any code history is going to be mostly irrelevant anyway.
Rule of thumb: Anything that will appear in an FAQ a year from now containing the word “historical” should be culled at the earliest possible moment! ;D