Quote:
|
so what exactly do you need to be able to use the data accessed by the simhq guy, to be able to use it for your gauges ?
|
The easiest way would be for CoD to output 'old style devicelink' outputs.
This would entail the CoD script doing:
1) reading the request packet sent from udpspeed,
This bit would probably need to read from an ini file to set up the IP address and port
2)ordering the data from this packet into an array or similar.
This could be simplified/eliminated IF the contents of the packet is a fixed, known set say for a BFP gauge set using~ 10 parameters.
A more universal system would be better tho.
3)Then each parameter must be associated with the relevant CoD parameter and read this data, There is a problem in converting units as IAS is given in km/h in Luft AC and mp/h in British AC. Doable in code but another complication
Indicated ASI is also possibly nit accurate
4)write this converted data into the reply packet
5)send it
that's my take on what needs to be coded- actually doing it is beyond my talents
this is the nearest example of something similar i've found
http://msdn.microsoft.com/en-us/library/tst0kwb1.aspx
http://tools.ietf.org/html/rfc768
shows udp protocol
devicelink doesn't use checksums
Quote:
|
btw, isnt it possible to have some very limited 3D version of the gauges so it avoids the 3D/2D problem you mentioned before ? with most gfx cards having multiple connectors these days and the minimal GPU resources needed to display a 2 color static image i would have hoped we dont need to run a 2e pc to just display the 2e screen with the UDP method
|
anything is possible
An MG produced program that displayed the 'wondewoman' gauges- (editable, reposition/sizing ability, saveable profiles,...) would be nice as a free bonus in the sequel
As to wether modern cards won't affect fps i couldn't say for sure (4 yrs ago with IL2 it was definately a problem)
http://forums.ubi.com/showthread.php...-thread/page30