No, in this case the % sign isn't the modulus operator at all, but part of the "sprintf" syntax: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Formatter.html

The sprintf syntax works really well with varargs feature because varargs allows you to specify values for the exact number of placeholders in the sprintf formatting string.

This is a technique known as object pooling. There are third-party libraries available for this as well.

Windows XP Pro, Java 1.6.0_03: works fine

Note: 'Safe the sheeps' => "Save the sheep"

I'm afraid I am unable at this point to offer more than moral support, but I just wanted to say: keep up the good work!

AFAIK, most racing games use samples. I know of only one or two that are based entirely on synthetic sounds (http://www.liveforspeed.net/). Don't know how they do it, though sry...

Post the full stack trace.

You don't strictly need a game engine, but it will make your life a lot easier if you use one.

Java3D is indeed more of a graphics engine (scenegraph engine) than a game engine.

I'd recommend taking a look at LWJGL and JMonkeyEngine.

When you return from a method, control is passed back to wherever the method was called from (i.e. another method). The return value of the method is inserted into the expression that called the method. For example, in this code there is no method call, and the value 1 is assigned to the variable x.

In this code snippet
The expression is evaluated by passing control to the add() method, executing the code inside the add() method and inserting the result returned from it back into the expression. So after the return from the method, the expression is equal to:That's all.

Please note that the Application Data directory is inappropriate for things like save games (or any other data the user "creates" or "manages" himself). As you have found out, the Application Data directory isn't exactly obvious, so user created data should not be stored there because the user won't be able to find it. It is appropriate to store application settings or any other data that can be easily recreated in there, though. Although for some data, using the preferences API might be even more appropriate. This last approach has the advantage of being platform independent too.

Also note that the "Application Data" directory is Microsoft Windows specific. Mac OSX has directory that serves a similar purpose called "Library". On Linux, the custom is to store application data in the user's home directory in "hidden" directories (e.g. ".myapp"). Sadly, there is no API for retrieving the "application data" directory in a platform independent manner (yet).

I would love to have "real" force feedback in Java.

I have looked into doing force feedback in the past, and as far as I've been able to determine, Immersion pretty much owns the tactile feedback marketplace. Most if not of the force feedback gaming products I know (mostly Logitech joysticks and wheels) use Immersion boards. Immersion offers several (commercial) SDKs, including a Java one which provides a JNI binding to a native (ActiveX) component, which (sadly) seems aimed at mouse feedback effects for applets.

As far as I've been able to determine, the protocol is rather simple, but may be illegal to reverse engineer 

Well, the limitation only applies to extensions hosted elsewhere, which does seem to make some sense in light of the "only connect the host you came from" restriction of the default sandbox, but I agree it seems a bit weird not to allow unsigned extensions from different hosts. I don't see any holes in the trust/security model resulting from it.

I've looked into this some more, and the behavior you're seeing is consistent with the spec. I'm quoting from section 5.5 Untrusted Environments (JNLP 6.0 spec), emphasis mine:

"Extensions: The JNLP file can request extensions and JREs from any host. An application cannot make a socket connection back to any of the hosts where JREs or extensions are downloaded from (unless it happens to be the same host as for the JAR files). Extensions requested from hosts other than the one that the JAR files were downloaded from must be signed and trusted as per section 5.4."

So while you are able to download extension from any host you want, even if your main application is not signed and trusted, those extensions have to be signed and trusted themselves, regardless of whether or not they need to be permissions-wise. This would mean your slick-ext needs to be signed if you want to include it from a different host, regardless of whether or not it includes the lwjgl extension.

Ok, I was thrown off by the relative reference to lwjgl in slick-ext.jnlp. So you want slick-ext.jnlp to be on a different host than lwjgl.jnlp, right? Mmm...

You have the codebase in the extension JNLP set to "http://www.kevinglass.com/", I think that's the problem.

Someone has separated the docking framework from Netbeans: https://jdocking.dev.java.net/

I think you should be able to configure Norton to allow java.exe and javaw.exe to do outgoing connections. I'm not sure on the specifics, though.

Thanks for the response. Yeah, I noticed it's Windows-only, which sucks, but it's still 80+% of the target audience I guess  Do you have actual experience with that SDK?

I've come across some information on other forums that Immersion may indeed be the only way to do force feedback, Java or otherwise (hurray for patents, I guess  ) It won't be possible to include this stuff in JInput (or anywhere else for that matter) without paying a license fee to Immersion (with all kinds of strings attached, apparently)...

Oh well...

For some time now, I've been toying with the idea of writing an Open Source racing sim in Java. Of course it will eventually have brilliant physics and stunning graphics but I'm running into a wall when it comes to Force Feedback.

I've noted that several Java gaming libraries (jinput, lwjgl and jME are the ones I checked) have support for "rumblers" on their controllers, but those don't seem to do what I want. Turns out rumblers do just that: rumble. And while you may be able to create some nifty effects by using several rumblers at the same time in the right way, this won't give the "true" feedback needed for a racing sim: the grip of the front tires. Unless I'm missing something with regards to these rumblers?

I've looked around some more and I've come to the conclusion FF pretty much means Immersion. Is that right? Does anyone have any experience with their Java SDK? Does anyone know of any other way to do Force Feedback from Java?

I voted "Bought it, Loved it" although I agree that "Loved" is a bit too strong.

I would recommend writing your tools as OSGi bundles instead of Eclipse plugins. Eclipse provides support for this. The advantage would be that you're not tied to Eclipse (and by extension SWT), although bundles automatically qualify as Eclipse plugins as well. Several implementations of the OSGi framework. Equinox (the foundation for Eclipse) is one, Apache Felix is another, Knopflerfish is a third. OSGi is an open standard maintained by the OSGi consortium. OSGi is an implementation of a Service Oriented Architecture within an application.

Of course if you're set on using the Eclipse RCP and/or SWT, going the plugin route would probably make more sense.

What are you trying to accomplish, and why do you think you need to extend Windows Explorer for that to happen?

Should your game Objects really be responsible for having that knowledge? It's hard to say without knowing more specifics, but I would probably create some kind of "Board" or "World" class that holds a list of your game Objects and their "locations". It would be this class that is able to answer "distance" questions.

Where and why do you need to know this address? Do you really need to know the address on the client?

I general, I don't think you can ever know the "external" IP address of the client on the client itself without connecting to an external server. If you're going to connect to an external server anyway, it might as well be the real server, instead of some script intended solely to determine your IP address. The server will be able to get the client's IP address from the connection/socket.

The default implementation on Windows will indeed use the registry to store preferences. I think on Linux a file-based solution is used. It should be possible (at the expense of more code to download, of course) to roll your own always-file-based solution.

I like the prefs package, it's easy to use as-is and does what I want most of the time.