LOL!
Glad to help

Humm, I have been thinking, if you want the 'bodies' to show all those behaviours and more, perhaps the best would be to implement a physics engine (you already have a simple one), and then using some little reactive functions for the ships like:

get my destination();
pos = get my position();
apply me my thrust(pos);
//--physics
apply me external forces();
compute coordinates using inertial mass and forces();
//etc...
I.e, according to the ship's desired destination you apply it's thrust (force) and all external forces (whatever they are like friction, gravitational etc.) to the ship's body. Then you compute it's new coordinates from the resulting total force / energy. Remember, in space the ship's inertia mantains it's movement for some time...
(this is a very simplified physics engine but its more than enough for your game )

No problem.

It happens because the graphics's thread (handling jPCT stuff) isn't time synchronized. This one just executes at maximum speed and calls Thread.yield() so that the other thread (the one for AI) can do it's stuff. Because the purpose of the project was AI development, I couldn't loose time on visuals and etc. but I'll correct when I got the time.

PS: Perhaps forcing V-Sync on the driver as a temporary solution...

Why don't you check in a debugger? For instance, in eclipse (the one I use), start debugging the program, when your program appears to hang, press the pause icon on the debug perspective. Then check the threads and their callstack.

There is the extension WGL_ARB_pixel_format, now the problem is that if lwjgl has it (or similar).

One may do something like i'm doing in Robombs, i.e. open a small native GL window behind a JFrame, do you queries, close both([...)

You have one possible solution... I've never used lwjgl (but I've used OpenGL) so I don't know how it creates windows and sets up pixel formats but for what I've seen in <native> OpenGL there are extensions and ways to get this information (like hardware mapping units, maximum texture size, number of lights, etc.)

However, I've found this in NeHe's tutorials, which I quote:

This next bit needs to be added inside the CreateWindowGL function, the original code is left, with where you need to make modifications. Basically, we're doing a bit of overkill to get the job done. We can't request the pixel format (to query the multisampling) until we've created a window. But we can't create a FSAA screen, unless we know the pixel format will support it. Kinda the chicken and the egg thing. So, what I've done, is a little 2 pass system; We create the window, query the pixelFormat, then destroy/remake the window if multisampling is supported. Kinda nifty...

This is for the win32 case, but I'll bet there is a better way to do things...

When I load a material description where it's last material definition has empty properties, like the following example:

newmtl Explorer_Default
Ka 0.117647 0.117647 0.117647
Kd 0.752941 0.752941 0.752941
Ks 0.752941 0.752941 0.752941
illum 2
Ns 8
map_Kd
map_bump
bump
map_opacity
map_d
refl
map_kS
map_kA
map_Ns
I get this error on jPCT:

File models\bzz_Drunk_transparent.mtl loaded...643 bytes
Processing new material textures_alpha_t1!
Processing new material textures_alpha_l1!
Processing new material Explorer_Default!
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.lang.String.substring(String.java:1938)
        at java.lang.String.substring(String.java:1905)
        at com.threed.jpct.Loader.loadOBJ(Unknown Source)
        at com.threed.jpct.Loader.loadOBJ(Unknown Source)
        at CK.IA.Engine.loadObj(Engine.java:465)
        at CK.IA.Engine.loadAndSetupModels(Engine.java:380)
        at CK.IA.Engine.initializeScene(Engine.java:279)
        at CK.IA.Engine.initialize(Engine.java:225)
        at CK.IA.Engine.<init>(Engine.java:64)
        at CK.IA.Engine.main(Engine.java:25)

I don't know which of the:

map_Kd
map_bump
bump
map_opacity
map_d
refl
map_kS
map_kA
map_Ns
causes the problem, but if I remove them, leaving only those "tags" with description, the loading goes nice and well. But quite boring to remove when an *.obj has lots of materials...
Only happens at the last material definition, if all the others before also have empty definitions, the loader only "explodes" at the last material.

(This is caused by Deep Exploration, I don't know why, but mine always stores materials with all tags, empty or with parameters.)