Letting someone play is permitted, giving someone your login credentials is not. Might be a good idea to actually read the EULA just about now, don't you think?
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?
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 for this about a year ago. Memory loss?
€³: Meh, apparently the ExtraData struct differs between products, the x-sim one I found is for DiRT2.
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
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.
It's not strange, it's actually a sound and simple concept. Point the tech support (and tell them to pass it on to the developers) to http://msdn.microsoft.com/en-us/library/aa905330.aspx and they shall not be clueless any longer.
If anything I'd say it's more monstrous. Simply put, C hands you a shotgun to shoot yourself in the foot with, C++ offers a wide array of weaponry. Some very elegant, some very bloody, but the end-result is still a missing foot.
To keep the foot-analogy going, a foot in your mouth is a foot safe from being shot
Programmers need to shoot themselves in their feet though, best way to learn. Also, often times it's actually good fun.
memcpy takes a pointer dst and will fill the memory from that location onwards with size bytes of src. The compiler doesn't know (well, it does, but by passing it to memcpy you're casting it to a void*) that the pointer points to an array (strictly speaking, to the beginning of it) of 3 chars, it's simply an address.
That's the C way though, C++ offers a much safer way already in the form of the STL containers. They take care of everything memory-related (allocation, reallocation on resize, freeing on destruction).
std::string c; c = "XXXXXXXX";
doesn't overflow, is properly initialised (empty string) and doesn't leak.
€: Obviously there are less error-prone ways in C as well, didn't mean to make C look completely hopeless :P
Also, shouldn't you be more worried about your tyres? Actually more to the point, why the hell don't you just use the brakes? They're much more effective at slowing the car down, because, you know, they're kinda made for that.
Well I don't think it's important, but if your analysis takes driver input into consideration at all, it might as well take all available factors into account.
You could add handbrake and clutch as flags in the Info byte, clutch would be disengaged, slipping (some friction, enough to cause heat/wear but not sufficient to move the vehicle / overcome the inertia), gripping (slipping but sufficient friction to move the vehicle) or fully engaged, handbrake could be 0%, 33%, 66% or 100%.
Even if it weren't in the OP, any normal person would limit their search to Scawen's posts within this thread, which brings the number down to 23 potentially relevant posts.
The same kind of ignorance Dustin exhibits in the Driving habits thread. It's not about normal driving conditions, it's about the unexpected. You can compensate for some of the shortcomings, but by driving closer or at the limit of the tyre, you're lacking the margin of error a good winter tyre would offer.
It's not just about snow, the temperature plays a mature role in how a tyre behaves. Winters will beat summers in temps as high as 8°C, unless it's really bone-dry, in which case the summers stand a chance.
I don't even blame any of those 95% or 85%, you simply aren't properly educated. Here in Austria, advanced driver safety training became mandatory in 2003 and to everyone who's gone through it, the importance of winter tyres should be painfully obvious. Even the most ignorant fools, like a certain someone here who thinks he's the uber-authority on things he doesn't actually know anything at all about, should get it.
The number of laps is reported via IS_STA, but I don't think there's anything for the cars, aside from reading the hostXXXXXX.txt file. Could be done via a SMALL.
Try experimenting with your FoV and the "Acceleration shifts viewpoint" settings in Options -> View. With the correct settings on a reasonably sized (24" or more should do, maybe even 22") widescreen display, it's pretty immersive.
If memory serves me right, you should see a list / drop-down box of available graphics adapters in either Options -> Graphics or Options -> Screen, I'm not sure which one and can't check at the moment. The selected adapter is the one fullscreen will go to, and it's also the one doing the rendering in windowed mode regardless of the window's position.