PDA

View Full Version : DeviceLink improvements please



BaldieJr
07-11-2004, 08:29 PM
We could use some optimizations, thats for sure, but there are a few other things that would be most helpfull.

Firstly, the off-line only limitation should be lifted. Maybe there is some exploit that I'm unaware of, but it would be nice to have access to flight data while flying online.

Secondly, multiple sets per packet would make life a lot easier. Performance is just too poor to allow too many packets as it is. If you are trying to set multiple parameters, the game slows to a crawl. Sending multiple sets per packet would ease some of the stress.

Lastly, I'd really like to be able to get the current state of every control. I want indicator lights on my panels, but I also want to script things like signaling over nav/landing lights.

Thanks for adding devicelink. Its not overly usefull now, but its still a lot of fun to experiment with.

BaldieJr
07-11-2004, 08:29 PM
We could use some optimizations, thats for sure, but there are a few other things that would be most helpfull.

Firstly, the off-line only limitation should be lifted. Maybe there is some exploit that I'm unaware of, but it would be nice to have access to flight data while flying online.

Secondly, multiple sets per packet would make life a lot easier. Performance is just too poor to allow too many packets as it is. If you are trying to set multiple parameters, the game slows to a crawl. Sending multiple sets per packet would ease some of the stress.

Lastly, I'd really like to be able to get the current state of every control. I want indicator lights on my panels, but I also want to script things like signaling over nav/landing lights.

Thanks for adding devicelink. Its not overly usefull now, but its still a lot of fun to experiment with.

tHeBaLrOgRoCkS
07-11-2004, 10:24 PM
RGR that Baldie S!

Boink !!

http://img78.photobucket.com/albums/v323/tHeBaLrOgRoCkS/planes/signiture3.jpg

WWSensei
07-12-2004, 06:09 AM
I concur. What is really needy is abandoning this UDP external approach and go with a control/instrument SDK allowing an external DLL to be loaded into the program space.

In its current state, after I've tested this extenisvely, I've determined devicelink is simply too inefficient for anything like a home built cockpit.

Even on the same machine (and tested on a variety of machines and networks) on average fully 1/3 of the commands fail to execute. I'm not talking complex commands. I have a test program that sends the Toggle Gear command once every 30 seconds.

In a run of 1000 of these commands 458 failed to execute. A second run had 348 failing. I verified the packets went out the port and were received into the appropriate port so it isn't typical UDP dropping but the game server itself is failing to process the commands. A 1/3 or better failure rate is simply too poor to be reliable.

Commands sent while in game menu screens cause port blocking on the server side--and it's non-recoverable. This prevents multi-threaded callback usage utilized by most external devices. Pretty much makes tools like GoFlight and SimKit useless.

The use of strings in sending and receiving the commands is terribly inefficient and I cannot understand why this methd was chosen. It requires data conversion on the server side of most data, transmission of about 4 times as many packets, and the then converting back into original form on the client side. This has "kluge" written all over it.

1C doesn't need to "fix" devicelink. They need to rethink this whole interface more inline with something like trackIR. More serious minded flight-sims have been doing this for years so it isn't new territory. This is one area where a Microsoft flight sim actually outperforms Oleg's.

BaldieJr
07-12-2004, 09:46 AM
Try flipping the nav lights on/off with a 100ms delay between states and 3 seconds between loop executions. It will eventually get reversed, some packets will disappear, and the best part: the guages lights will start flashing instead of the nav lights. http://ubbxforums.ubi.com/images/smiley/blink.gif

http://ubbxforums.ubi.com/images/smiley/35.gif

WWSensei
07-12-2004, 10:17 AM
Doesn't even need to be that elaborate. Gear state reversals can happen in as little as 3 lever changes spaced about 15 seconds apart.

The server seems to actually drop the entire command...it's really pretty useless to me at this point.

tHeBaLrOgRoCkS
07-12-2004, 03:15 PM
Not as clued up as you on the tech side. But maybe just a focus on data output would be sufficient? All I personally am interested in at the moment is getting the insturments displayed on a seprate montitor such as altimeter and verticle speed indicator. Sorry if I am missing the point here.

http://img78.photobucket.com/albums/v323/tHeBaLrOgRoCkS/planes/signiture3.jpg

WWMaxGunz
07-12-2004, 04:40 PM
Would it be any better if they went serial bytes through USB for external machines?

If the sim knew the name of an exe to run for same-system controls then IPC pipes would
be very lean and very fast, unlike UDP.

The idea to communicate in and out of the sim-box is great though, no doubt about that!
And while they're at it... how about actual position data? http://ubbxforums.ubi.com/infopop/emoticons/icon_cool.gif


Neal

BaldieJr
07-12-2004, 06:34 PM
We play video games via UDP over countless hops, but its not good enough for same-network string pushin'???

C'mon guys. Just ask for optimisation and minor changes. A complete rewrite isn't necessary, and would probably never happen.

I like the simpleness of devicelink. A complete programing newbie could be hitting it with perl in less than a week.

WWSensei
07-12-2004, 09:38 PM
"Not as clued up as you on the tech side. But maybe just a focus on data output would be sufficient?"

Problem is you need to send a command in order to get the data back. From my tests it seems as if the UDP server code in the app is very inefficient and misses about 1/3 of the requests. It also has a nasty habit of sometimes returning the commands in a different order than you requested. Even worse is it quite often, when queried for two values in two seperate commands (say, the RPMs of engine 1 and engine 2) it will send you the engine RPMs for engine 1 twice and never send the engine 2 RPMs.

Max, serial bytes through USB would be even slower. UDP in and of itself is ok, it's their implementation of a server that is inefficient.

Baldie, not asking for a rewrite, they need to merely add the interface layer (which they could do via HID) like they did for trackIR. Same level of effort as adding multi-quadrant support on a scale of things.

It probably took them twice as long to write devicelink as it would have taken to do it right from the beginning. This has "code and fix" kluge written all over it. I don't have a problem with UDP in and of itself but using for this type of stuff is like deciding you are going to drive from Scotland to England via the Great Wall of China.

HID controllers in a DLL loaded into the program space is not a new concept (just look at FS2002/2004, Fly, X-Plane, Project Magenta, Glasshouse and just about every other decent simulator out there). Their native support for trackIR shows they know how to do it.

I agree devicelink is simple, but right now it's been done too simple and too buggy to be useful.

BaldieJr
07-13-2004, 10:09 AM
One other recomendation, if I may:

Slashes stink. How about : and ; instead? This would make scripting a lot easier since the slashes wouldn't have to be escaped. Plus, I somehow have the feeling that the game is not handling the slashes properly.

So thats my complete wish-list.
* Optimizations/ code cleanup/ beter general performance
* Multiple sets per packet, in whatever order, or documentation on preferred order.
* Gets for status of every control
* No blocking during menus
* Online functionality
* Current map, map coordinates, and player name so we can build an online ATC application http://ubbxforums.ubi.com/infopop/emoticons/icon_smile.gif

Matz0r
07-13-2004, 10:57 AM
Speaking of scripting, I've been playing around with devicelinks in perl. It's resulted in a perl class with a very easy to use interface to the devicelink.

get it here:
http://www.pfy.nu/perl/devicelink/Games-IL2Device-Link-0.01.tar.gz

http://www.pfy.nu/tmp/fw3.jpg

WWSensei
07-13-2004, 11:39 AM
Did a similar one for C++.

http://www.wingwalkers.org/sensei/devicelink.zip

BBB_Hyperion
07-14-2004, 12:57 AM
I still think it would be much more usefull to use a dummy system driver for a unknown interface which would allow to work with different inputs or input devices. This has 2 advantages and 1 drawback. cpu usage is lower , interface devices can be used in key or other setup. Data from the Game must be available from the driver what it isnt. Workarounds over devicelink just slow it down.

High Ground is not only more agreeable and salubrious, but more convenient from a military point of view; low ground is not only damp and unhealthy, but also disadvantageous for fighting.

Sun Tzu : The Art of War

Regards,
Hyperion

WWSensei
07-14-2004, 07:12 AM
"I still think it would be much more usefull to use a dummy system driver for a unknown interface which would allow to work with different inputs or input devices."

Concur Hyper. That's essentially what you would get if they simply coded for HID inputs via DirectInput and external dlls. Shoot, they do that already in order to talk to your keyboard and joystick...which is one reason I don't understand the route they took...

tHeBaLrOgRoCkS
07-14-2004, 08:38 AM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by tHeBaLrOgRoCkS:
Not as clued up as you on the tech side. But maybe just a focus on data output would be sufficient?

<HR></BLOCKQUOTE>

What I meant was that it might be simpler if udp data focused on intrument data and not switching on landing lights and flaps or gear or what ever. I don't think that kinda control is neccessary as we can do most of that via game port devices. But I appreciate that some of you may need that level of control Me I just want my dam compass and altimeter on a different display lol.

Also if you allow control of the aircraft via udp then you also open the gates for scripted auto pilots and similar 'hacks' that may not be in the spirit of the game and may explaine why the feature is currently not enabled online?

http://img78.photobucket.com/albums/v323/tHeBaLrOgRoCkS/planes/signiture3.jpg

WWSensei
07-14-2004, 01:20 PM
"What I meant was that it might be simpler if udp data focused on intrument data and not switching on landing lights and flaps or gear or what ever."

I understood what you meant I guess I wasn't clear in my response. Flipping that status of lights or gear isn't the problem. In fact, that's easier than reading instrument data.

In order to read the instrument data I have to send a command and read it's result whereas to toggle a switch I only have to send a command.

To read instruments I would have to send several commands in a realtively short period of time in order to get meaningful data. The problem is their current implementation seems incapable of properly handling the simple toggling of landing gear consistently and I might only do that 3 times in a flight (twice if I fly right! ;-)) much less handle querying an instrument the several times a second it would take.

For instance, I could easily right a program to query and display engine RPMs on a different display...however, under the current system you would only get about 10 FPS from the game in doing so.

tHeBaLrOgRoCkS
07-15-2004, 05:04 AM
I see.

Thank you for the clarification.

I will get my coat.

http://img78.photobucket.com/albums/v323/tHeBaLrOgRoCkS/planes/signiture3.jpg

BaldieJr
07-15-2004, 12:03 PM
Some input on controll sets/gets:

The P40's flap indicator is a good example of why its good to have. I could create a replica indicator and mount it in my 'pit. In order for it to work, I would have to reset the device every time I fly a new mission or hit refly. Being able to read the state from the game will allow it to match itself to the game. Same with gear, lights, magnetos, superchargers, and radiator flaps.

As far as bots go: I don't see it happening, but if it did, I seriously doubt that it would be very effective. It might actually be a handy thing to have in DF's, when you think about it, but honestly, I don't think effective AI could be created without having some way for the bot to see other players.

WWSensei
07-15-2004, 01:17 PM
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>As far as bots go: I don't see it happening, but if it did, I seriously doubt that it would be very effective. It might actually be a handy thing to have in DF's, when you think about it, but honestly, I don't think effective AI could be created without having some way for the bot to see other players.<HR></BLOCKQUOTE>

Agree. Best you could do is code them to fly a specific pattern or something...maybe useful for practice bounces etc...

BaldieJr
07-20-2004, 07:16 PM
Any changes to devicelink in the patch?

BaldieJr
07-22-2004, 01:54 AM
I see you Oleg http://ubbxforums.ubi.com/images/smiley/16x16_smiley-very-happy.gif

What say you?

BaldieJr
07-22-2004, 04:37 PM
383 people have taken a look at this thread, while on a few have added comments.

If devicelink is something that interests you, please post something in this thread. I can't see Oleg and 1C making changes to something that appears to go unused.

Please show support for devicelink. Thanks.

Fillmore
07-22-2004, 05:30 PM
I am very interested in see this developed into a tool that can be used to automate flight performance testing. I havn't tried it but have been looking at all threads relating to it. I voted for it to get its own forum so I could keep tabs on it more easily. As far as I can tell it isn't effeicient/fast/reliable enough to be used in this manner for all testing (I saw someone had made a program to test climb performance, but never saw much else), which is too bad http://ubbxforums.ubi.com/images/smiley/cry.gif

Matz0r
07-23-2004, 04:58 AM
I've upgraded my devicelink class http://ubbxforums.ubi.com/infopop/emoticons/icon_smile.gif

http://search.cpan.org/~matja/Games-IL2Device-Link-0.02/

I'm thinking it would be cool if someone made a website service to record variables for users while playing, saving them the trouble to setup complex stuff on their own system.

flyboy_112th
08-05-2004, 08:18 AM
I would like to start building my own Sim 'pit and to be honest I only fly Falcon 4, IL2FB AEP and LO:MAC.

I've been looking at the GOFLIGHT stuff, but until they either come up with a keymapper (which only handles the key input) or changes are made to FB then I'm stuck.

IL2:FB AEP is universally acknowledged to be the best WWII flight sim around but I must admit that I find the current system of external control frustrating in the extreme.

Come on chaps, what do you say? Can you give us IL2 fanatics a chance to improve our immersion in this wonderful game even further?

http://112th.redhalibut.co.uk/112thflyboysig270704.jpg