Reserved for later use?

Ah OK makes sense, I haven't done algorithm stuff for ages, am I right in thinking to get the individual flags that are on I try taking away the largest flag number, if the result is minus it means its false, if its positive I make the flag number that amount less and then do the same with each of the rest of the flags in reverse number order?

I would do a Bitwise AND check to see if the bit is set or not. Basically as not as the expression's value is not Zero (0) then the bit is set.

So basically:


would check if the pressure is in bar?

Would clear what I have up a touch lol


edit:
Think I'm doing something wrong, the only flags I seem to be able to get are BAR and KM :/

Quote from ghowden :

would check if the pressure is in bar?

That's correct as far as I can tell.

Just had a look at the source on SourceForge, it looks to me that JInSim has not been updated for quite a while, and doesn't have the updated DashLights/ShowLights flags. So it seems you can't use JInSim with the latest version of OutGauge, you'd either need to modify the source, or find another library.

Edit: Or as Morpha below says, use his nifty script.

Or use a relay with conversion ability, like the one (simple python script) I posted in the CarSoundRemixer thread somewhere. It can convert Z25+ OutGauge packets to pre Z25 packets on the fly.

Ah thats great didn't know it was outdated code, the main download link pointed to 0.3, I went and got 0.5. Looking at this thread there seems to be a 0.6 out but I can't find source for it.

I'll use the relay for now, I can't seem to find the specs for outgauge atm, but I'll have a go at updating jinsim for new patches when I've finished my program.

Well I've just tried this:


With the values found here:

http://pyinsim.codeplex.com/So ... b8d279#pyinsim%2finsim.py

Which I'm assuming is current.

It prints nothing at all in normal use when flicking lights/indicators, but pressing 1/2 seems to give random flags and getting wrong route/restricted area seems to do the same. Even entering pits or pressing Esc seems to give results, anything but what I expected really. BAR and KM work tho.

Am I still using outdated flag values or has outgauage packets changed too and I need to fix parsing of them?

I think you misunderstood the problem. You want to use JInSim, which implements pre-Z25 (technically pre-Z22, but those were test patches) OutGauge, with the current LFS version (i.e. post-Z25). The actual content hasn't really changed, but the format did. What you have to do now, by means of the relay, is convert the post-Z25 packets to pre-Z25 (22) packets on the fly. That means you put the relay in-between LFS and your application, i.e. instead of specifying your application's port in LFS's cfg.txt, you specify the relay's and configure the relay to convert and finally forward the packets to your application's port.

In your JInSim application, you then treat the input as pre-Z25, or to clarify, like so:
which would make your code (I hope):

Yeah sorry, I decided to try updating jinsim instead of using a relay seeing as I'm trying to keep the thing pure java. Where can I find the technical details about insim/outgauge?

LFS comes with extensive documentation, located at LFS directory/docs/ where you'll find, among others, InSim.txt, OutGauge is at the end of the file.

For comparison, and to familiarise yourself with the protocol based on how it's currently implemented in JInSim, use the outdated version I posted above for reference.

I have renamed the latest 0.5rc6 JInSim version to 0.5 and uploaded the version to Sourceforge and here:
http://liveforspeed.at/download/jinsim-0.5.zip

I should have done that a long time ago: :sorry:

JInSim 0.5 covers LFS Z28

I have not yet started to add the new insim features that come with Z30+. I indent to do this in the near future. If anyone wants to help me with that I gladly accept patches or can give commit privileges on sourceforge.

You have:


in that version for OutGaugeResponse, shouldn't the DL_* ones be:

seeing as the documentation says its bit numbers?

EDIT:
Yes it is, worked out dashlights wasn't in flasg (duh), then tried working with dashlights, then realised its in showlights lol xD I blame the alcohol. Anyways works fine now, thanks a lot Now to the program itself lol

Here's what I have for the new car contact stuff, I added COLLISION_REPORT(50) to the PacketType enum and registeredTypes.put(PacketType.COLLISION_REPORT, CollisionResponse.class); to ResponseFactory too. Testing shows nothing happening at all atm

You have to initialise the connection with ISF_CON for LFS to send CONs

Quote from morpha :

You have to initialise the connection with ISF_CON for LFS to send CONs

ah great work , added the flag for collision events. Now I get buffer underruns, need to have a look at my response code now

EDIT: Buffer underrun fixed, I thought char would mean char, but no it's a byte. Closing speed seems to be returning 0 though, still needs more work

I reckon its java not having unsigned stuff messing with me, ffs

Here is the latest source code plus my collision packet code seems to work fine now. Learnt bitwise operators in java at long last lol

Quote from ghowden :

Here is the latest source code plus my collision packet code seems to work fine now. Learnt bitwise operators in java at long last lol

I have created a new development branch for the Z30+ changes add have added your changes (with some modifications):
https://jinsim.svn.sourceforge.net/svnroot/jinsim/branch/z30

I have not applied the changes in the OutGaugeResponse file, cause the current version is correct.

(If you want build the jinsim jar use gradle (http://www.gradle.org/))

Quote from Brilwing :

I have created a new development branch for the Z30+ changes add have added your changes (with some modifications):
https://jinsim.svn.sourceforge.net/svnroot/jinsim/branch/z30

I have not applied the changes in the OutGaugeResponse file, cause the current version is correct.

(If you want build the jinsim jar use gradle (http://www.gradle.org/))

Thats great thanks, its ok I merge the source with my code and build in eclipse in one final jar using fatjar

Is there any other changes needed for z31? I looked at changelog and it seemed to be only a couple of length changes

Fixed a couple of spelling mistakes and what looks like a numbering issue for Aston in the Track class, also added all the new open configs

EDIT:
new MessageToConnectionRequest with larger message size and sound field

I noticed you updated the Track list, how about the MessageToConnectionRequest? Is that alright?

Quote from ghowden :

I noticed you updated the Track list, how about the MessageToConnectionRequest? Is that alright?

I have updated both now. I changed the MessageToConnectionRequest to use the existing Sound enum for the setter.

Changes needed for z32:

Still wrong code for VW in Car.java, should be VWS (non essential)

In SetDirectCameraRequest, CameraPositionResponse and StateResponse the line:


Is no longer needed as the flag can be removed (Shouldn't the flags be in some kind of ISS State enum anyway?)

In OutGaugeResponse the following two lines need to be added:


Attached is the new code for RaceStartResponse to be cleaned up to be inkeeping with the style of the rest of the library

Assuming everything was implemented for z28 this is all that needs doing/testing for it to work with z32

First of all, Thank you for developing the Java library!

Just a short question, will you continue developing the Java library?