DeviceLink

[GSENN]

Any word on CoD suporting/providing the DeviceLink interface?

[AndyJWest]

I'm sure that Oleg said that something similar will be provided. Given the relatively 'open' design of the software, this is more or less essential.

[ElAurens]

Can't see it not happening, though I would think that there will be more parameters available in CoD as things will be more complex in general.

And remember, we will have the Sukhoi 26 as an example to verify the global flight model. A very bold move by Oleg.

Onward and upward!!!

[bolox00]

so far nothing definite (but then Oleg can be somewhat cautious/cryptic), but as i recall his comments it is intended to have devicelink or something similar.

cautiously hopeful, but an official statement would be very welcome

[AndyJWest]

There was a thread on the banana forum about this: http://forum.1cpublishing.eu/s...highlight=devicelink (http://forum.1cpublishing.eu/showthread.php?t=16014&highlight=devicelink)
Again, nothing definite there, but I'm sure the topic was discussed by Oleg somewhere - though this was some time ago, so things may possibly have changed. In some ways, DeviceLink isn't an ideal way to do this sort of thing, particularly if you are communicating with other software on the same PC.

[GSENN]

Originally posted by ElAurens:
I would think that there will be more parameters available in CoD as things will be more complex in general.
I would not expect any more params let alone more complex ones in that the intended purpose of DeviceLink is to drive cockpit guages of home build cockpits.. and you don't need 64bit doubles to do that! http://forums.ubi.com/groupee_common/emoticons/icon_wink.gif

As a mater of fact it would be good if the format remained the same IMHO

[AndyJWest]

From DeviceLink.txt:

The DeviceLink interface is meant to provide the third-party software with the
current condition of the player's aircraft as well as allow an unified method of
connecting alternative operating controls.

It has always been intended for more than just driving cockpit guages, and given the increased complexity of the CloD control system, I think it is highly unlikely to be unchanged from IL-2. We'll have to wait and see though.

[GSENN]

Never said it was limited to driving gauges (outputs) my point was/is the 'intended' purpose was to provide an interface for home build cockpits, of which home build joysticks, rudders, throttle, etc (inputs) is part of that endeavor, sorry if me not mentioning the input aspect confused anyone. As for it remaining unchanged due to the increased complexity of the CloD control, I can see them adding additional function calls but I don't see any need to change the current set. Which is the thing most standards strive for, to be backwards compatible.

[M_Gunz]

Oh no, the format as it is is fat to begin with. And there's some shortcomings/bugs already well noted. Determining all AC states is not in there and really should be. As it is some important functions at the user end are impossible. A new game engine is a good time to clean that all up. But did it have priority and how much backward compatibility did they want?

[AndyJWest]

Thinking about it, if the new interface isn't compatible with DeviceLink, it would probably possible to produce a 'translator' application of some sort, though whether this will be worthwhile doing remains to be seen.

[GSENN]

Originally posted by M_Gunz:
Oh no, the format as it is is fat to begin with. And there's some shortcomings/bugs already well noted. Determining all AC states is not in there and really should be. As it is some important functions at the user end are impossible. A new game engine is a good time to clean that all up. But did it have priority and how much backward compatibility did they want?
As for fat format.. Not sure what you mean? I assume your referring to optimization? There is always a trade off between easy and optimized, so if fat is easier I can understand why Oleg would opt to reduce the amount of questions he would get on the subject, that and the network speeds these days makes it a non issue even if one is pulling all the aval DeviceLink data

As for bugs, I only know of a few and they are not show stoppers imho but would welcome any bug fixes

As for determining 'all' AC states.. This is not necessary for the 'intended' purpose of DeviceLink nor would it be a good thing imho when you take into account that Oleg even went as far as to disable most of the DeviceLink data when playing online.. With regards to cheating and all.. Knowing the state of aircraft other than your own would only make cheating more pronounced and thus if added would most likely be disable for any online play

As for backwards compatibility.. it is always a good thing as long as it does not cause you to avoid doing new things.. And I am sure that all the folks that went to the trouble to write programs to interface to IL2 via DeviceLink would love it if CoD worked with their current hardware and software configurations

We all need to step back and remember the intended purpose of DeviceLink is interface the game with home build cockpits than the choices Oleg made make more since. Knowing the state of 'other' aircraft does not factor into that intended purpose.

[GSENN]

Originally posted by AndyJWest:
Thinking about it, if the new interface isn't compatible with DeviceLink, it would probably possible to produce a 'translator' application of some sort, though whether this will be worthwhile doing remains to be seen.
imho translators make since for large software projects that would take too long to reproduce.. but writing a UDP DeviceLink program is pretty straight forward.. due to the simplicity (fat format?) of the interface.. Thus it would probably take one as long to re-write a new program as it would to write a translator.. Not to mention the inherent problems with translator delays and such