OutSim With Dirt2 and Grid?

[bvillersjr]

Hello,

As I mentioned before, I am developing an app that utilizes InSim/OutSim. I've learned that Codemasters uses an OutSim similar mechanism to export Dirt2 and Grid info. It would be nice to get a couple of extra supported games with minimal additional effort.

Does anyone know what differences exist between the two or any gotchas I should be aware of?

[Dygear]

I had no idea they had anything like that, but if you could post the documentation I'll be happy to read over it.

[bvillersjr]

Turns out it's F1 2010, Dirt2 and Grid that have an OutSim similar output.

I was posting here in hopes that someone had more infor about the subtle differences because I can't find an docs for this.

However, for each of the games mentioned, a line starting with "<motion enabled" exists in the hardware_settings_config.xml file (which is usually located in My Docs\Codemasters or MyDocs\My Games\(Dirt2 or FormulaOne).

Changing this line to:

<motion enabled="false" ip="127.0.0.1" port="20777" delay="1" extradata="0" />

-OR-

<motion enabled="false" ip="127.0.0.1" port="20777" delay="1" extradata="1" />

will suposedly output in an OutSim similar fashion.

[bvillersjr]

It is indeed LFS compatible per the following (and only related info btw) from the Cody site:

If your system has a motion platform, then GRID™ should be able to control it. This feature is completely untested beyond checking that the basic data output is correct, and as such should be used entirely at your own risk. The output format is designed to be compatible with the "Live for Speed" outsim motion platform format. To enable, just open the hardware_settings_config.XML file and edit the motion attributes:
< motion enabled="true" ip="192.168.0.10" port="20777" delay="1" extradata="0" />

enabled – Set “true” or “false” to enable or disable the motion platform
ip - The IP address of the motion platform
port - The port of the motion platform
delay - the time between data updates from the game (1/100ths second).
extradata - This should always be set to “0”

[MadCatX]

You have to find more about the packet format, Codemasters most likely have it documented somewhere.

[bvillersjr]

No luck locating any docs, but I think it's safe to assume that since they claim OutSim compatibility, that there will at least be that much.

I'll let you know after a few trials in case anyone else is building software that can benefit from additional suported titles.

[morpha]

It's been brought up before but no additional information was found, apparently.

[bvillersjr]

OK, Here's the story.

Grid, Dirt2 and F1 2010 are all OutSim compatible and are working with InSim.Net.

However, just to muddy the water I guess, they chose to use only one UDP port and have a config option ExtraData = 0 or 1

ExtraData carries some derivative of the OutGague stuff. It may even be in the precise format, I'm not sure yet.

That said, whatever format it is in, when ExtraData=1 is enabled, it will be a different struct so unless DarkTImes has an interest in having this as part of InSim.Net, I'm looking at a derivative work, which I'm not wildly ehthused about.

Nontheless, it would seem foolish to ignore the similarities for the sake of not parsing a few extra bytes. Actually, it looks like it will be 1 byte (8 floats)

[DarkTimes]

If you can show me an example of the struct, then I will compile a special version of InSim.NET for you with support for those games. I would need to know exactly what data the packet is to contain however, as without that I can't do anything. If you provide the specification, it's no problem to create a new build.

I'm not sure I'll add this to the main trunk, I may create a separate fork for it. It depends what data the struct contains really. You could create a fork for it yourself, if you're so inclined. :)

[bvillersjr]

I'll try to get ahold of CM, but I'm not certain I will be able to get an answer. I can say that I've scoured the net for this struct with no luck.

I believe its 8 bits of additional data as follows:

public float exd1;
public float exd2;
public float exd3;
public float exd4;
public float exd5;
public float exd6;
public float exd7;
public float exd8;

I would have to see the data to determine what it is. I'm more than happy to sort out the proper filed labels.

What method would you recommend for viewing the raw data so I can begin to sort it out?

Thanks for all your help btw! I really hope I can return the favor.

[DarkTimes]

So all I need to do is add eight floats onto the end of the OutSimPack struct? If so, that's very easy.

unsigned Time; // time in milliseconds (to check order)

Vector AngVel; // 3 floats, angular velocity vector
float Heading; // anticlockwise from above (Z)
float Pitch; // anticlockwise from right (X)
float Roll; // anticlockwise from front (Y)
Vector Accel; // 3 floats X, Y, Z
Vector Vel; // 3 floats X, Y, Z
Vec Pos; // 3 ints X, Y, Z (1m = 65536)

int ID; // optional - only if OutSim ID is specified

float Ext1;
float Ext2;
float Ext3;
float Ext4;
float Ext5;
float Ext6;
float Ext7;
float Ext8;
};

If that's all I need to do, then I can create a new built with those floats added on the end, then you can figure them out in your own time. Once you've figured out what they mean, I can update the field names.

[morpha]

I'm looking into this now, testing it with GRID. So far I've observed:
GRID does not provide angular velocity (always zero) GRID will always send an ID, meaning the packet will never be 64 bytes (as it is when sent by LFS without an ID). The ID sent is 1094938452, which spells ToCa when interpreted as C string, which suggests that earlier CM titles (the ToCa series, obviously) already implemented OutSim. ExtraData 1 will increase the size to 148 bytes, however the 80 additional bytes are not a simple extension but change the structure entirely. So no, Alex, that won't do unfortunately :(

€: Also, it's not OutGauge but OutSim :razz:

[DarkTimes]

Is there no documentation anywhere that shows what this OutSim derived packet is supposed to contain?

As I said, I'm happy to add it, but without knowing what the actual struct contains I can't do anything. I don't personally own any of those games, so I can't test them myself.

Edit: Whoops, it's OutSim, shows how much attention I'm paying. :p

[morpha]

The few lines bvillersjr quoted in the 4th post are all you get in terms of documentation. I guess they intentionally keep the ExtraData proprietary to use with their own motion simulators exclusively, or they consider the entire feature to be too exotic for anyone to really get into (it says it's untested after all).

At first I thought they probably packed a modified form of the OutGauge packet into it, it would fit size-wise if all the redundant info is omitted. I'm still investigating in that direction, but I don't think that's it.
€: Seems I wasn't that far off, sirnoname from x-sim seems to have obtained the necessary information from CM directly. Surprisingly, by calling the their customer support, which I guess makes them just about the only useful customer support people anywhere? :razz:
I guess one could simply do the same, or ask sirnoname, but I'll keep on sniffing and apply deductive reasoning just for the fun of it.

€²: bvillersjr, you're apparently on the X-Sim² BETA crew, you even posted in the plugin release thread (http://www.x-simulator.de/forum/dirt2-extradata-1-plugin-available-for-test-t2257.html) for this about a year ago. Memory loss? :schwitz:

€³: Meh, apparently the ExtraData struct differs between products, the x-sim one I found is for DiRT2.

[bvillersjr]

No memory loss. I helped test his plugin, but the source for the plugin was never published, nor was any additional information about the ExtraData extension.

SirNoNames project is closed source :( and it's plugin architecture is limited to C++ only.

A friend of mine in Germany has been trying to reach him for months with no success.

Glad to hear that someone has fun with this sniffing!

[morpha]

Well I've made progress with the GRID extra data, the entire structure is made of floats, which made things easier once I realised it. So far I've got:offset type description
-------------------------------
0 float time elapsed in seconds (since sending these packets started, not the race)
4 float laptime in seconds
8 float position on track in metres from the start/finish line
12 float race progress, this - laps = lap progress
16 float world-Y position in metres
20 float world-Z position in metres
24 float world-X position in metres
28 float indicated velocity in m/s (= actual speed, there is no differential or wheel speed based reading)
32 float world-Y velocity in m/s
36 float world-Z velocity in m/s
40 float world-X velocity in m/s

44 float ?
48 float roll ?
52 float ?

56 float ?
60 float pitch counter-clockwise from right ?
64 float ?

68 float ?
72 float ?
76 float ?
80 float ?

84 float ?
88 float ?
92 float ?
96 float ?

100 float velocity rear left wheel in m/s
104 float velocity rear right wheel in m/s
108 float velocity front left wheel in m/s
112 float velocity front right wheel in m/s
116 float throttle 0 to 1
120 float steering in quarter turns (90°), -1.0 = 90° to the left, 1.0 = 90° to the right (GRID's wheels only turn 60° in either direction though)
124 float brakes 0 to 1
128 float handbrake, always digital, thus quasi-boolean (1 on / 0 off)
132 float gear 0 Neutral, 9 Reverse, forwards speeds counting from 1
136 float lateral acceleration in g
140 float longitudinal acceleration in g
144 float lap counting from 0 (first lap = 0)

I'm reasonably sure about everything labeled, except for the X & Y velocity and position, which could be the other way round. Unfortunately the map cannot be fixed to align with north and lacks an "N" indicator, so it's difficult to know which world axis you're actually moving on. verified via ExtraData 0 comparison.

[bvillersjr]

@Morpha - You're the man! If I'm ever in Austria, I owe you a beer!

If DarkSide puts this struct into the app as he mentioned above, I'll be able to see it and can try to help determine what the other data is as well.

What do you use to sniff these packets with?

I'm happy to buy you guys copies of F1 2010, Grid and Dirt2 for your tsting efforts. If you don't already have em, let me know and I'll PM or email them to you.

[morpha]

What do you use to sniff these packets with?What I use for everything hacky & simple, Python :razz:

I'm happy to buy you guys copies of F1 2010, Grid and Dirt2 for your tsting efforts. If you don't already have em, let me know and I'll PM or email them to you.Well that's very generous, might take you up on that offer :)

[bvillersjr]

Not a problem. You have saved me alot of time. It would have taken me weeks to sort that out to the extent you already have. Please send me an email address to send the Steam unlock codes to.

[morpha]

I'm gonna stop with GRID for now, had it running for 21 hours non-stop and the PC just let me know that it's enough by crashing on me :shy:

The remaining unknown data are cryptic, I believe the first 6 floats (with presumably roll and pitch in them) also contain the heading, in some overly complicated way. The 2x4 floats are probably some per-wheel force information, but without a way to reliably apply force to one wheel only, it's very difficult to confirm.

[bvillersjr]

Email sent. Thanks again!

21 hours just might be a record!

I would think that Engine RPM is almost certainly there somewhere since they now directly support the SLI-Pro hardware gauge but perhaps this integrates in some other way.

I believe that X-Sim had a Yaw value for this game if I'm not mistaken.

Maybe these are pieces to the puzzle.

[morpha]

Weirdly, the engine RPM aren't included. Everything X-Sim has, based on the screenshot in the plugin thread for GRiD (http://www.x-simulator.de/forum/racedriver-grid-and-extradata-1-t2709.html), is there. The yaw is within the 2 3-float groups, I just don't know how to interpret it correctly.

BTW DiRT2 and F1 2010 are on the way, thanks mate :thumbsup:

[morpha]

New post because this concerns DiRT2 now.

The DiRT2 packet is 4 bytes larger than GRIDs, the additional float is - drumroll - the engine RPM :D

# offset type description
-----------------------------------
0 0 float time elapsed in seconds (since sending these packets started, not the race!)
1 4 float laptime in seconds
2 8 float position on track in metres from the start/finish line
3 12 float race progress, this - laps = lap progress
4 16 float world-Y position in metres
5 20 float world-Z position in metres
6 24 float world-X position in metres
7 28 float actual velocity in m/s
8 32 float world-Y velocity in m/s
9 36 float world-Z velocity in m/s
10 40 float world-X velocity in m/s

11 44 float ?
12 48 float ? roll *
13 52 float ?

14 56 float ?
15 60 float ? pitch *
16 64 float ?

17 68 float ? suspension travel front left?? *
18 72 float ? suspension travel front right?? *
19 76 float ? suspension travel rear left?? *
20 80 float ? suspension travel rear right?? *

21 84 float ?
22 88 float ?
23 92 float ?
24 96 float ?

25 100 float velocity rear left wheel in m/s
26 104 float velocity rear right wheel in m/s
27 108 float velocity front left wheel in m/s
28 112 float velocity front right wheel in m/s
29 116 float throttle 0 to 1
30 120 float steering in quarter turns (90°), -1.0 = 90° to the left, 1.0 = 90° to the right
31 124 float brakes 0 to 1
32 128 float clutch
33 132 float gear 0 Neutral, 9 Reverse, forwards speeds counting from 1
34 136 float lateral acceleration in g
35 140 float longitudinal acceleration in g
36 144 float lap counting from 0 (first lap = 0)
37 148 float Revolutions per 6 seconds, multiply by 10.0 to get RPM

* wild guess

Since I'll actually be playing the game (as opposed to running it solely for sniffing purposes, as I did with GRID), finding the remaining ones might take a little time :tilt:

[morpha]

Triple post :tilt:

F1 2010's extra data is the same size as DiRT2's, the differences are minor:
# offset type description
-----------------------------------
0 0 float time elapsed in seconds (since sending these packets started)
1 4 float laptime in seconds
2 8 float position on track in metres from the start/finish line
3 12 float race progress, this - laps = lap progress
4 16 float world-Y position in metres
5 20 float world-Z position in metres
6 24 float world-X position in metres
7 28 float actual velocity in m/s
8 32 float world-Y velocity in m/s
9 36 float world-Z velocity in m/s
10 40 float world-X velocity in m/s

11 44 float ?
12 48 float ? roll *
13 52 float ?

14 56 float ?
15 60 float ? pitch *
16 64 float ?

17 68 float ? suspension travel front left?? *
18 72 float ? suspension travel front right?? *
19 76 float ? suspension travel rear left?? *
20 80 float ? suspension travel rear right?? *

21 84 float ?
22 88 float ?
23 92 float ?
24 96 float ?

25 100 float velocity rear left wheel in m/s *
26 104 float velocity rear right wheel in m/s *
27 108 float velocity front left wheel in m/s *
28 112 float velocity front right wheel in m/s *
29 116 float throttle 0 to 1
30 120 float steering in quarter turns (90°), negative = left, positive = right
31 124 float brakes 0 to 1
32 128 float anti-stall / clutch
33 132 float gear 0 = Neutral, 10 = Reverse, forwards speeds counting from 1
34 136 float lateral acceleration in g
35 140 float longitudinal acceleration in g
36 144 float lap counting from 0 (first lap = 0) *
37 148 float Revolutions per 6 seconds, multiply by 10.0 to get RPM
float 33 (#32) is the only content change, representing the anti-stall or clutch in F1 instead of the handbrake (GRID/DiRT2) for obvious reasons. Other than that there is only a minor change to #33, where reverse is now 10 instead of 9. Finally, GRID and DiRT2 reset the first float (time elapsed) on restarts, F1 does not.

I haven't fully verified everything yet, but I'm reasonably sure that's all the differences.

I've updated the other two definitions with a more accurate interpretation of the steering value.

[bvillersjr]

Awesome! That was an amazingly quick reverse engineering time!

Now to sort out the best way to integrate this into InSim.

Since the ExtraData =1 outputs entirely different structs, I'm gusssing that DarkTimes has lost interest in this?

If so, I'll look at maintaining some kind of derived work that supports all of the above. 99.5% of the plumbing for this is already in the InSim project.

Also, who do I have to talk to about commercial use of LFS? A friend of mine wants to make a Sim Center and is interested in LFS as a basis for this.

[morpha]

Awesome! That was an amazingly quick reverse engineering time!Fortunately they didn't change the structure between titles significantly, that obviously made it a lot easier.
Still need to figure out what the remaining data is, or rather, how to interpret it. I'm fairly certain the first 6 (in the unknown slice) are roll, pitch and yaw, but I don't quite know how to interpret them. The last 8 (again, unknown slice) appear to be per-wheel / per-corner data, what exactly remains unknown.
I don't actually own a motion simulator and might lack the experience to recognise the type of information based on patterns or range.

Now to sort out the best way to integrate this into InSim.

Since the ExtraData =1 outputs entirely different structs, I'm gusssing that DarkTimes has lost interest in this?
The principle, that is, the way the communication happens, is still the same, the datagram just looks a bit different. It might not be directly InSim / OutSim related, but Alex might still be interested.

If so, I'll look at maintaining some kind of derived work that supports all of the above. 99.5% of the plumbing for this is already in the InSim project.That shouldn't be difficult, seeing as all of Alex's InSim related projects are, to my knowledge, open source and released under licences that permit derivative work.

Also, who do I have to talk to about commercial use of LFS? A friend of mine wants to make a Sim Center and is interested in LFS as a basis for this.
http://www.lfs.net/?page=commercial_use
2) Licensed Commercial Use

This is the situation where you use Live for Speed in a permanent or temporary simulator setup and you make profit by charging customers who use the system.

For this purpose, you must contact the LFS developers and arrange a commercial license. A commercial license requires a small recurring payment and gives you permission to charge customers and make profit from the use of Live for Speed. Payments may be monthly or annually. Although you have only a single license, we will provide sufficient unlocks to keep your machines up to date, and will always be available in less than 24 hours to help you with any support issues you may have.

Our charges for this are very reasonable and can be adjusted to your circumstances, such as how many machines you are running and how many days per week they will be in use. We can give good discounts for commercial license customers in countries where the exchange rate to UK currency is unfavourable. We will arrange with you a charge that we both agree is reasonable and suitable for the purpose.

Some example charges for a single machine setup at full price e.g. USA / Europe / Australia :

Full time use (5 or more days per week) : £24 per month
Part time use (for example weekends only) : £12 per month
Educational license (use in a school) : £24 per year

For more information about commercial licenses please contact the LFS developers (http://www.lfs.net/?page=mailus).

Thank you.

[morpha]

Recorded data from a run on Li River in my Mk2 Escort, see attachments :tilt:
track.png is the X and Y position samples plotted onto a grid, 1px = 1 metre, green = first recorded sample, red = last recorded sample.
driver_input.png, as the name suggests, are my inputs. green = throttle, red = brakes, yellow = clutch (technically not me), pink = gear.

If anyone cares, the time was 2:50.46, wasn't a particularly good run though.

I'm a little closer to identifying the remaining values, here's a single sample, vehicle standing still on relatively flat ground, facing south. The values in brackets are the range I observed.
11: 0.005378 [-1.00 1.00] Heading 1 (relative to road direction?)
12: 0.006104 [-1.00 1.00] Roll
13: -0.999967 [-1.00 1.00] Heading 2 (relative to world?)
14: -0.999944 [-1.00 1.00] Heading 3 (relative to world?)
15: 0.009186 [-1.00 1.00] Pitch
16: -0.005322 [-1.00 1.00] Heading 4 (relative to road direction?)

The remaining 8 floats are most certainly suspension related, the first set of 4 being the position (travel) and the second set appears to be force or acceleration, but I'm not sure what exactly and which unit it is in. I'll provide some samples once I've collected the range and average.

[m2yor]

11: 0.005378 [-1.00 1.00] Heading 1 (relative to road direction?)
12: 0.006104 [-1.00 1.00] Roll
13: -0.999967 [-1.00 1.00] Heading 2 (relative to world?)
14: -0.999944 [-1.00 1.00] Heading 3 (relative to world?)
15: 0.009186 [-1.00 1.00] Pitch
16: -0.005322 [-1.00 1.00] Heading 4 (relative to road direction?)

It seems to me they are using such a matrix (http://www.euclideanspace.com/maths/geometry/rotations/euler/AndyGoldstein.htm)
I mean that:

number |offset | value
14 | 56 | = sin(yaw)
16 | 64 | = cos(yaw)
or something like this. I still need some time to find out.

[m2yor]

Here example how to get Yaw (azimuth) of car.
Sorry that code written in object pascal, have no time to translate...

TMatrix33 = array[0..2] of array[0..2] of Single;
BufferRet = array[0..BufferRetLen] of Byte;
TVector = record
X, Y, Z: Single;
end;

LocMat : TMatrix33;
eul : TVector;
FB : BufferRet; // our buffer
sinx, cosx : single;

Movememory(@sinx, @FB[56], 4);
Movememory(@cosx, @FB[64], 4);
LocMat[0,0]:=cosx;
LocMat[0,1]:=0;
LocMat[0,2]:=-sinx;
LocMat[1,0]:=0;
LocMat[1,1]:=1;
LocMat[1,2]:=0;
LocMat[2,0]:=sinx;
LocMat[2,1]:=0;
LocMat[2,2]:=cosx;
eul := CalcEulerM33(@LocMat); // direction in euler

Grad := eul.Y*(180/pi); // azimuth in degrees


function CalcEulerM33(M:PMatrix33) : TVector;
begin
if (M[0,1] > 0.9998) then // singularity at north pole
begin
Result.Y := arctan2(M[2,0], M[2,2]);
Result.Z := PI/2;
Result.X := 0;
exit;
end
else if (M[1,0] < -0.9998) then // singularity at south pole
begin
Result.Y := arctan2(M[2,0], M[2,2]);
Result.Z := -PI/2;
Result.X := 0;
exit;
end;
Result.Y := arctan2(-M[0,2], M[0,0]);
Result.Z := arcsin(M[0,1]);
Result.X := arctan2(-M[2,1],M[1,1]);
end;

[E.Reiljans]

track.png is the X and Y position samples plotted onto a grid, 1px = 1 metre, green = first recorded sample, red = last recorded sample.May I please ask you what software have you used to produce that image?

[morpha]

Here example how to get Yaw (azimuth) of car.
Sorry that code written in object pascal, have no time to translate...
Awesome! Have you verified the results yet? I'll port this to Python and/or PHP later and try it myself :thumbsup:

May I please ask you what software have you used to produce that image?

You may, you may also burst out laughing once you read it: GD via PHP :D

I needed a really quick way to do this, GD/PHP is the quickest I could think of, faster than anything available for Python that I'm familiar with. I had this running collecting live samples and rendering them out to PNG every second. When I opened the two images in Windows Photo Viewer, I discovered that it had the very pleasant feature of detecting file changes and reloading the image upon such changes. In effect, giving me telemetry data at 1Hz while in-game.

It works reasonably well, especially considering that I didn't keep the images in memory between renderings but re-allocated them every time. A Li River run is about 7500 samples.

[E.Reiljans]

You may, you may also burst out laughing once you read it: GD via PHP :DWhy laugh? That's very handy way to do it compared to e.g. Excel (which some ppl use to plot data :| )

Btw, thanks for the idea - I just wrote a C++ app that.. writes a PHP script. :D (due to lazyness of learning any graphical funcs in C++ myself)
This app parses a .pth file, and outputs PHP code which plots the node data on a PNG. Optionally you can lay it down directly on track's TIF.
An example of how it looks (after merging with TIF using PS): http://localhostr.com/files/LwY8BId/BL1.png#include <stdio.h>
struct data { int a[3]; float b[7]; };
int main(int argc, char **argv)
{
FILE *file;
struct data data;
if (argc != 2) { fprintf(stderr, "usage: %s <file>.pth", argv[0]); return 1; }
file = fopen(argv[1], "rb");
if (!file) { fprintf(stderr, "error: cannot open file"); return 1; }
fseek(file, 16, SEEK_SET); // first 16 bytes are of no use for this
printf("<?php\n");
printf("Header('Content-Type: image/png');\n");
printf("$gd = imagecreatetruecolor(2560, 2560);\n");
printf("$color = imagecolorallocate($gd, 255, 0, 0);\n");
while (fread(&data, sizeof(struct data), 1, file) == 1) {
printf("imagesetpixel($gd, %d, %d, $color);\n",data.a[0]/65536+1280,data.a[1]/65536+1280);
/*printf("imagesetpixel($gd, %d, %d, $color);\n",data.a[0]/65536+1280,data.a[1]/65536+1279);
printf("imagesetpixel($gd, %d, %d, $color);\n",data.a[0]/65536+1279,data.a[1]/65536+1280);
printf("imagesetpixel($gd, %d, %d, $color);\n",data.a[0]/65536+1279,data.a[1]/65536+1279);
// uncomment this part to have nice bold dots. :P */
}
printf("imagepng($gd); ?>");
fclose(file);
return 0;
}

In effect, giving me telemetry data at 1Hz while in-game.Didn't PHP raped your CPU tho?

[morpha]

DiRT2 has a pretty efficient multithreading strategy, which is great in normal conditions but was indeed noticeably affected by PHP's single threaded high load bursts. The socket stuff was fine, but the GD rendering was comparable to the kind of microlag associated with SLI / CrossFire.

I had thought about rendering PTH or LYT files and I probably would have used PHP+GD for that too :razz:

[E.Reiljans]

Any thoughts about Dirt 3? :)

From hardware_settings_config.xml:
<motion enabled="true" ip="dbox" port="20777" delay="1" extradata="0" />

[morpha]

It's likely to be identical to DiRT2, but I don't have it so I can't make sure.

[Jackske]

Wow morpa congrats on figuring out the new data structure so fast!

I have been looking for these values for quite a while now, without succes however.. Contacting sirnoname from the xsim forums and Codemasters directly and repeatedly were also dead ends.

Is there any possibility this new data structure could be integrated into Insim DarkTimes? Or can the number of bytes and filetypes from the udp packets be configured somewhere already?


Thanks alot for al the efforts so far!


Cheers

[bvillersjr]

Same question here. Any chance these will get integrated into InSim. If not, any recomendation as to where I should inject this so as to not be suffering when new InSim releases are made?

Also, does InSim have some kind of proxy capability that can be used to forward the raw data steam back out on a specificed port for other devices to grab? Or is there another recognized way of forwarding?

[morpha]

Integrating this into an InSim library is rather pointless since CM titles don't actually implement InSim, only OutSim, and not 100% to LFS's specification at that. With ExtraData=1, it becomes something entirely unrelated altogether.

What is it you're ultimately looking for? Logging? Displaying? Sending to a motion sim?
Receiving and processing the data is simple in virtually ever language, so the choice depends on how interfacing with the motion sim works, if that's what you intend to do.

[bvillersjr]

Integrating this into an InSim library is rather pointless since CM titles don't actually implement InSim, only OutSim, and not 100% to LFS's specification at that. With ExtraData=1, it becomes something entirely unrelated altogether.

What is it you're ultimately looking for? Logging? Displaying? Sending to a motion sim?
Receiving and processing the data is simple in virtually ever language, so the choice depends on how interfacing with the motion sim works, if that's what you intend to do.

I want to send data to a motion sim and log as well. The way the data is split into two streams in LFS is an issue for me since I need all of the OutSim data and a few tidbits from OutGauge. I need to do all of this without interfering with other devices like gauges that also need OutGauge data. I can write a UDP forwarder for this. I'm guessing that this problem has already been solved though, or that LFS has a way of sending OutGauge data to multiple ports?

[Whiskey]

You need the Pythoin interpreter to run og_rely (http://www.lfsforum.net/showthread.php?p=1329031#post1329031). This send OutGauge packets to several IP/ports