![]() |
Been a long time proponent of this sort of thing, and in these days of 'shiny' tablets etc it is unusual not to have some sort of official output protocol in a flight sim
Yes the data Artist points to is what is needed- infact CoD has many more types of data that is readable than old IL2 devicelink. I've messed about with coding based on that to do 'speedbar' type readings of various parameters but that's about my limit of coding- hacking other peoples work:sad: One of the 'tricky bits' of coding required is to 'translate' the request packet from say udpseed into an answer packet from CoD Not only are there instrument reading parameters available but also many other useful ones- for a full list see zip in 1st post http://forum.1cpublishing.eu/showthr...338#post342338 Apart from deciding which CoD parameter is most relevant as an output (gauge users will want instrument readings whereas performance chart makers will want 'absolute' values) some values might need converting to the relevant units The more I look at what is involved coding wise to export this data via udp, the more I realize that it's beyond me:oops: If anyone gets to do this a more MKI version of this would probably be my first project:D http://i240.photobucket.com/albums/f...nk/th_SPIT.jpg |
Quote:
COD is a different kettle of fish. As stated beore I tried to use a C# script to set up a UDP server wfrom within COD but due to my limited C# scripting skills failed. Anyone else had any luck? Could be that there is another way to get the info out of cod. I guess we need scripting documentation for COD. Cheers |
If this becomes doable?
I'd jump on it in a heart beat.:grin: |
Quote:
|
It really is a shame - there is all that information in getParameters and yet there is no official info on how to utilize it. I am busting to get my motion platform cockpit working with CoD. It works great with IL-2 and Devicelink, but why does getParameters have to be so complicated with no clues about how to use it?
|
Quote:
|
Quote:
btw, isnt it also 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. err, please be aware i know nothing of programing, so i am probably overlooking some obvious reasons why some of this is an issue :) |
Quote:
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:rolleyes: Indicated ASI is also possibly nit accurate 4)write this converted data into the reply packet 5)send it:cool: 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:
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 |
I for one, Support this Thread!
|
I hope the devs gives this a mind. With the complexity of the engine, this would likely help reach another niche of the market too.
Please, do go on, Gents! |
All times are GMT. The time now is 01:51 PM. |
Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright © 2007 Fulqrum Publishing. All rights reserved.