AI planes with smooth movement - possible?

[russell]

I've been trying for months to get AI planes in my FSHostClient program to move smoothly, and I've about decided it isn't possible with SimConnect. I challenge anyone here, or anyone from Microsoft, to show me an example of the local user's FSX plane flying alongside a SimConnect AI plane where the AI plane is moving smoothly instead of jumping forward and backward. :-)

FSHostClient is basically a SimConnect app that the user runs alongside FSX to relay data packets between FSX and an FS2004 DirectPlay (FSHost) session. So as other planes in the session move, they send their FS2004 DirectPlay "velocity" packets to FSHostClient, which then decodes the data and uses it to move an AI plane in the local user's FSX session so he can see them. I have to use AIReleaseControl() and AICreateNonATCAircraft() to make the AI plane have any chance of moving smoothly. This essentially means that the plane is in "slew" mode, or in other words, it's completely still with no movement of its own, and I have to step it forward a little bit at a time, every 25 ms, so it looks smooth. Since I get velocity packet updates from the other players a few times per second, I use their last known velocity and heading info to predict their movement along the same path between updates.

So I was wondering, is it the way I'm decoding the DirectPlay velocity packets? Is it the way I'm predicting the movement? As a test, I setup FSHostClient to update the AI plane every 25 ms like it normally does, but I changed the velocity packet updates from FS9 to only be every 5 seconds, and made it beep when it does these FS9 updates. So I see the AI plane moving with my predictions, and then every 5 seconds I hear a beep and the plane shifts slightly to the "real" position from FS9.

I recorded some video files, and uploaded them to my web site. They're really bad video quality, but it doesn't matter because they're small, and they're enough for you to see what's happening.

Ok, first, here's what it looks like when I'm just flying next to the AI plane -- you can see the AI plane jumping around a lot, and you can hear the beep every 5 seconds when the AI plane is moved to the "real" location using the FS9 packet:

http://www.chocolatesoftware.com/fshost/misc/fsx_fly.avi

And then the same thing but this time I'm slewing next to the AI plane (which is to the right of me this time) -- the jumping around is about the same, which you would expect:

http://www.chocolatesoftware.com/fshost/misc/fsx_slew.avi

Ok, now, something interesting... This video starts out flying and then after a couple of seconds I hit the pause button. Then you see the AI plane fly away from me, but notice how smooth it is!

http://www.chocolatesoftware.com/fshost/misc/fsx_fly_pause.avi

And then the same thing, but slewing first and then pause -- about the same as flying and pausing:

http://www.chocolatesoftware.com/fshost/misc/fsx_slew_pause.avi

Now... I remember a while back, Joel DeYoung was telling me that if you're flying next to an AI plane there's a bit of an optical illusion happening. The AI plane is completely still, but then it hops forward every 25 ms. If your plane is flying next to it, then in the time between 25 ms updates, your plane is moving forward but the AI plane is still, so it appears as though the AI plane is moving backwards. Then the AI plane hops forward again at the next 25 ms update. What you end up seeing is the plane drifting smoothly backwards, then jumping forwards, then drifting back, jumping forwards, over and over. Did you notice that all the jumping around was only forward-backward? There was hardly any side-to-side jumping. But if you pause your plane, or if you're sitting on the ground watching the AI plane, then there's no optical illusion and the movement is smooth.

Now, here's a video using FS9, with FSHost controlling an AI plane. It's the same type of thing, but FSHost is doing the AI plane instead of FSHostClient, and instead of creating an AI plane directly inside FS9 like we do with FSX, it's creating the plane and then sending in velocity packets to the session every 250 ms. But watch how smooth it is:

http://www.chocolatesoftware.com/fshost/misc/fs9_pace_fly.avi

So why doesn't it happen in FS9? Because when we create AI planes in FS9 we tell the AI plane to start moving in a particular direction, and then give it updates every once in a while. But in between updates, the AI plane keeps moving on its own. It's exactly how the multiplayer system works in FS9 -- each plane tells everyone else their current location, heading, velocity, etc., and then the other players draw an AI plane there, and FS9 keeps it moving automatically until it gets a new velocity packet. This isn't possible in FSX, so we have to use slew mode and hop the AI plane forward a step at a time. And I think that's what's causing the optical illusion, and the jumping around.

If that's the case, then it's not a problem with my decoding of the velocity packets. You can hear the beeps in the videos every 5 seconds when it gets a new velocity packet from the other player and jumps the plane to the correct location -- there's a bit of a shift in position, but not that much, and it's a lot less with the normal 250 ms data updates. So my predictions are fairly accurate.

And it's also not my predictions causing it to look jumpy. Because when my plane is paused, the AI plane moves very smoothly as it flies away from me. I've seen this also when I did a test where the AI plane was moving slowly on the ground -- very smooth.

So the question is, how do we fix the optical illusion?

One thing I tried was to update the AI plane at the same rate that the FSX plane was updating visually. I was hoping I could get them in sync that way, so they essentially moved forward at the same times. I changed the rate at which I was getting data from FSX to use "SIMCONNECT_PERIOD_VISUAL_FRAME" (instead of SIM_FRAME, which I normally use) and then updated the AI planes each time I got a data callback, but it didn't help.

The other thing I tried was to update the AI plane much more often, like 1000 times per second instead of every 25 ms. It had only a very slight improvement, but not nearly enough to make it worthwhile to update the plane that often.

So if the local FSX user isn't moving, the AI planes look great. But when flying alongside the AI planes, they look terrible. And somehow this doesn't happen when you have two FSX planes flying together using the built-in multiplayer system -- my guess is because FSX itself is updating both the local user's plane and the AI planes and it's keeping them in sync. But I haven't found a way to do that through SimConnect.

Has anyone been able to make this work with SimConnect? So far I've talked to two other developers that have tried but have given up in disgust. I'm about at that point also, but thought I might appeal to this forum to see if anyone had any ideas.

Thanks,
Russell Gilbert

[gggdude]

I am experiencing the same issue with my SimConnect client. I was waiting to release my FSX server and client until I had the AI aircraft issue with smoothness resolved.
I have tried many schemes to improve smoothness of AI aircraft, but they tend to bounce around a little bit which is annoying (actually really annoying) when flying in formation.
I have not found a solution, occasionally I can get perfect smoothness, but it appears to randomly alternate between jumpiness and perfect smoothness. The best results I have obtained involve sending position packets (consisting of lat/long/alt/bph-attitude, and using Freeze event Ids, and AIReleaseControl) to the AI aircraft at a very high rate, sending packets every 10-30ms.
This is a very BIG weakness of SimConnect. I am sure by now that ACES and Microsoft know about this issue.
Russell stated that he has tried to sync packets with known event id's in flight sim, unfortunately this solution has not worked for me, and apparently not for Russell either.
Several questions:
Is there a solution? (I suspect that there is not a solution with the most recent version of SimConnect)
Will there be a solution with the next version of SimConnect? (I hope so)
I have created a stable FSX server and client, which is good beta software (actually great beta software so far) at the moment. However, I do not intend to release software with the aforementioned issue with AI aircraft.
My FSX server and client represent a new paradigm for flight sim servers and clients, which does not use DirectPlay, contributing significantly to stability. With the resolution of the AI aircraft smoothness issue, I can finish developing the software, release a public beta, and after that an SDK for developing addons, as well as a custom SimConnect API that connects to FSX directly using sockets.
So for the current moment the AI aircraft smoothness issue (which is INCREDIBLY disappointing) has placed my project in a (holding pattern, pun intended), I am going to move onto other projects for the time being.
Resolution of this issue will allow further development of servers and clients for FSX, expanding the multiplayer experience beyond GameSpy and LAN sessions with FSX's built in multiplayer ability.
Ok Microsoft and ACES how about releasing a multiplayer SDK, its about time.
Thx

[Paavo]

Have you tried sending xyz velocity, rotation velocity and acceleration values along with pbh/lla?

See:
STRUCT BODY VELOCITY
STRUCT BODY ROTATION VELOCITY
STRUCT WORLD ACCELERATION

[Pete Dowson]

... occasionally I can get perfect smoothness, but it appears to randomly alternate between jumpiness and perfect smoothness.
...
Is there a solution? (I suspect that there is not a solution with the most recent version of SimConnect)

This does sound a lot like TCP/IP buffering latency, a typical queueing phenomenon -- are you using the SP2 / Acceleration version of SimConnect, locally (i.e. on the same PC as FSX)? If you are not manifestly linking to the SP2 version, the FSX <-> SimConnect exchanges will still be via TCP/IP, which I think virtually guarantees a variable latency. This is true even if you have SP2/Acceleration installed.

With SP2's SimConnect named pipes are used for the connection, which are implemented locally by shared memory, much like FSUIPC's methods (and DDE). I still think there will be some latency, but it should be a lot more consistent -- variability is the enemy of smoothness.

Regards

Pete

[gggdude]

Yes I believe that I speculated about the TCP/IP stack latency in a previous post.... http://fsdeveloper.com/forum/newreply.php?do=newreply&p=60555
there was no replies to it though :confused:

I have a feeling this issue has more to do with variations in network latency (TCP/IP stack, FSX itself when updating the AI Object), because if you updated lat/lon/alt/attitude, with AIReleaseControl and using FreezeIds, at 20-30 times a second then there should NOT be any jitter, if you could sync these updates. I am guessing what the issue is simply that there is no guarantee that updates arrive to the AI Object when they are SUPPOSED and that FSX updating the AI Object probably takes a variable amount of time internally.
I have tried some complex algorithms to account for network latency, but some can not be accounted for, this worked with marginal success. There is NO syncing mechanism in FSX.
If anyone has code or a method to perform smooth flight without jitters I would be IMMENSLY grateful.

Responses to Dowsons questions: (thx for the reply btw)
Yes the client is local, in addition my client does NOT use any SimConnect API, as I stated previously. I started this project quite some time before SP2 was released. I built my own application that talks directly to FSX via TCP socket, the SimConnect API is not referened anywhere in my project. That is actually something I considered releasing, the method I use to communicate with FSX without using SimConnect, however it is easy enough to figure out, with the exceptions of the SendId's for packet types, that unfortunately is not documented in the SDK, however it is easily extracted using a packet sniffer.

Some more background information: I have tried to solve this AI aircraft smoothness issue, by using the SimConnect API with C++/Win32, managed SimConnect API with C#/.Net, as well as my own application communicating directly to FSX using sockets. I get the best performance using my own application that communicates with FSX directly.

Well I am willing to experiment with named pipes (I am familiar with how they function and have experimented with them before), as I built my own SimConnect API based on sockets, perhaps I can do that same with named pipes. I will post results when I finish working on it.

What is the name of the pipe that FSX uses? (Would be nice to know)
This would be useful for those of use that want to communicate with the FSX pipe directly without the SimConnect API
Can the name of the pipe be specified? (This is the best option!)
Is there a way to enumerate the pipes owned by a process? (I have not been able to find a way to do this, have not worked with pipes very much, messed around with them for communication between threads once)
Will a syncing mechanism ever be incorporated into FSX for AI Objects?
Will a multiplayer SDK ever be released for FSX? (the lack of an MP SDK and perhaps the circumstances surrounding the FS2004 SDK, suggest to me that there is resistance to the idea of developers developing multiplayer servers and clients, hmmmmmmm)
Any help would be greatly appreciated.
G

Thx,
G

[Pete Dowson]

... my client does NOT use any SimConnect API, as I stated previously. I started this project quite some time before SP2 was released. I built my own application that talks directly to FSX via TCP socket

So, isn't it rather disadvantaged in that it cannot use the local named pipes interface which was implemented in the latest SimConnect version. It seems to me that TCP/IP (even in its less checked non-guaranteed UDP variant) is a very heavy protocol to use between two programs on the same PC -- the red tape and multiple layering is needed and valid for the Internet, but such a waste on the same PC. The named pipe mechanism uses shared memory techniques (as I see you know).

That is actually something I considered releasing, the method I use to communicate with FSX without using SimConnect

But is there any point? I don't see any advantage. You bypass the efficient part, the "stubs" provided by the DLL, and use the inefficient part, the TCP/IP protocols.

... as I built my own SimConnect API based on sockets, perhaps I can do that same with named pipes. I will post results when I finish working on it.

Well, certainly that would be much more interesting. In FSUIPC I notice a significant improvement in performance with heavy loads with the named pipes compared with TCP/IP -- and with no noticeable variation in latency (though I've not really tackled the latter scientifically I'm afraid).

As to your questions about pipe implementation, I'm sorry, I don't have answers. I've never used named pipes myself, only the SimConnect interface.

Will a syncing mechanism ever be incorporated into FSX for AI Objects?
Will a multiplayer SDK ever be released for FSX?

Good questions. I think the answer is "no" to any changes whatsoever before FSXI -- and I don't think anyone knows what's going to be done for that yet. Maybe some stuff will eventually fall out from "solution provider" requirements of ESP, but not before FSXI I think. Meanwhile you should be making your needs loud and clear near Aces' folks.

Regards

Pete

[russell]

I could be wrong about this (I often am), but my feeling is that this isn't so much a performance problem as it is a syncing problem.

It seems to me that there are two issues to solve here...

1) Syncing the frame rate.

If the local user's plane is "flying" (or, the graphics are being updated) at 30 fps and the AI plane is being updated at 10 fps, then the local plane is moving 3 times for each 1 time the AI plane moves. So if the local plane moves forward a frame and the AI plane stays still, the AI plane will appear to be moving backward. Then when the AI plane moves, it will hop forward. So you see two frames of the AI plane smoothly moving backward followed by 1 frame of it hopping forward. Do I have that right?

If so, then it seems to me the solution is to sync the two up so it's a one-to-one frame movement. Each time one moves, the other moves as well. I attempted to do that with the VISUAL_FRAME updates, and then calling the function that moves the AI plane each time I got a callback, but it didn't help.

I did verify, with log statements, that the callback is being called at about the same rate as the current visual frame rate in the game. So if the game is locked at 20 fps, I get the callback roughly 20 times per second, which is good. But I think there's another issue...

2) The time elapsed between visual frame updates of the local plane.

As an extreme example, if the sim was displaying at 1 fps, then every 1 second it'd update the visual frame and then call my callback, which would update the AI plane. And if my function checked the clock time each time it was called, it would hopefully see that it was exactly 1 second between calls.

But what if the sim was busy, and the time between calls to the callback function was varying? So maybe it was displaying the visual frame at about 1 time per second, but one time my function saw a delay of 0.9 seconds, then 1.2 seconds, then 0.8 seconds, etc. Right now my function checks the clock time each time it's called, to determine how much time has elapsed since the last time it moved the AI plane. Since it knows the AI plane's current speed, it can guess how much it would have moved in that elapsed time and move it forward a bit.

Ok, so you might be thinking that it's still ok, because if the time between callbacks varies a bit, it'll be noticed by the AI function when it checks the clock each time. Ahh, but what if the sim updated the frame and then waited just a bit before calling my callback function? Let's call that the post-processing time, before it has a chance to call me. And what if that post-processing time varied? So when it updated the local plane, it might have moved it forward based on an exact 1.0 second elapsed time since the last update, but by the time my function was called, it was 1.5 seconds. So my function moves the AI plane based on a 1.5 second elapsed time. If the two planes are flying at exactly the same speed side-by-side, the AI plane moved further forward than the local plane did. Over time the plane movements would even out and they'd still stay roughly side-by-side, but I think you'd see this movement as the AI plane shifting forward and backward. Does this sound right?

If so, the solution would seem to be that we'd need a game counter, which was updated each time the sim updated the visual frame. So if it updated it at millisecond 2000, it'd send that value to us, even if it took until 2050 before it could call us. That way we'd be able to compare it to the previous time, which might have been 1000, and we know it was a 1000 ms lapse between visual frame updates of the local plane, and we could move forward based on a 1000 ms lapse instead of 1050. This would be different from the clock time that my AI function is currently checking, because the time FSX sent to my function would be the time it did its visual frame update, not the time the callback was eventually called. However, I couldn't find a game counter in the docs -- maybe someone else has seen one?

Russell

[gggdude]

Hmmm,


So, isn't it rather disadvantaged in that it cannot use the local named pipes interface which was implemented in the latest SimConnect version. It seems to me that TCP/IP (even in its less checked non-guaranteed UDP variant) is a very heavy protocol to use between two programs on the same PC -- the red tape and multiple layering is needed and valid for the Internet, but such a waste on the same PC. The named pipe mechanism uses shared memory techniques (as I see you know).


But is there any point? I don't see any advantage. You bypass the efficient part, the "stubs" provided by the DLL, and use the inefficient part, the TCP/IP protocols.



There are plenty of advantages, or else I would not have spent the time to develop my own API, perhaps at some point I will start a thread discussing in detail why I decided to implement my own SimConnect variant, and refute the reasons listed to not build such a project.
Several quick points, I started development of my own API before the pipes support was released for SimConnect, almost immediately after the release of FSX. One of the primary reasons I did so was because of the issues I described regarding AI smoothness, it initially started as an experiment to see if SimConnect contributed to that problem. I was VERY pleased with my API, so I decided to develope it further, and eventually release it to those that wanted a SimConnect alternative.
I develope for both .net and win32. I was very disappointed with the managed SimConnect API, for many reasons, and that also contributed to my choice to develope a SimConnect alternative.
In addition, my own API better suited my multi-threading requirements, (the primary reason)


Meanwhile you should be making your needs loud and clear near Aces' folks.


That has already been done, If you checked the 'Wishlist' section of the forum,in the past, this problem was posted by myself, the purpose of that forum board was to make ACES aware of issues and desires for FSX. I discussed the synching problem and TCP/IP latency at that time. There was feedback on that thread, but the forum administration did not approve, so I edited the post and removed most of the content present in my posts. http://fsdeveloper.com/forum/showthread.php?t=8144
That is the link where the discussion occured, I heavily edited my posts and removed most of my discussion, but you can see responses in quotes by others.

I appeal to the developers here because we have a better chance to solve these issues using eachother as resources. This also builds our case to have something addressed in SimConnect/FSX if more of us desire a specific feature or change. It is now clear that there is more than one person with this issue.

Anyone have luck writing to ACES directly? hmmm

So back to what matters.
Hopefully we will solve the AI aircraft smoothness issue. It is essential. I truely have great software that is contingent upon solving that very issue. I am unwilling to devote further significant time to developing software unless the AI smoothness issue can be resolved.
I will delve into the pipes alternative and see what happends.
As always I appreciate constructive ideas and suggestions.
In my opinion FSX needs a synching mechanism just for this purpose, that would seem to be the best solution.

One other question:
I have never developed using FSUIPC, does it support AI object creation and manipulation? If it does, does it do so using SimConnect? If it does not, will it ever have these abilities?
I would challenge you and anyone else to throw some code up here that solves the AI aircraft issue, I think many of us would be eternally grateful.

Thx for your feedback.

btw found this on an forum talking about FSUIPC (INTERESTING PIPE INFORMATION) web page http://forums.simflight.com/viewtopic.php?f=54&t=68523


Re: FSUIPC wont work.
by bouncerhal on Sun Feb 10, 2008 12:12 am

Hi Pete,

Yes FS Passenger is a 3rd party Add on for FS2004 which i thought was for FSX but the newer version is to come out some time next month for FSX so i deleted FS Passenger anyways i have done the log thing and it is below.


0.00000 SimConnect version 10.0.61259.0

0.06169 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64
0.07529 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=2512, MaxClients=64


looks like the name of the fsx pipe, hmmm
might be very useful for working with pipes in FSX


So, isn't it rather disadvantaged in that it cannot use the local named pipes interface which was implemented in the latest SimConnect version.....


Disadvantaged? Never was, now it just gets better.

If that is indeed the name of the pipe and using that pipe contributes significantly to smoothness of AI aircraft, assuming it is possible to communicate with fsx using that pipe from a custom fsx client not using SimConnect, then I will be releasing a rocking SimConnect variant, thus a new option could enter the arena for developing FSX addons, maybe call it GSXIPC or GIPC
Will work with pipes and post my progress here
First I will just build a standard simconnect app and see if updating ai aircraft positions is smoother
Next I will build a custom app that is not based on simconnect and see if it can communicate with fsx using the named pipe
Then I will finish the construction of my fsx server and client and release them for beta testing
If the pipe concept works i will build and release a custom api using pipes for building addons and interfacing with fsx

Thank you,

Gabriel LePage

[Manuel Ambulo]

Nice Thread, Russell, gggDude, Pete, surely, its very interesting discussion.

What i think is that SimConnect or FSX should allow us to set the velocity data, it would (i think), solve the problem of the latency, because FSX would do the same role as FS9 did for multiplayer, that you send the velocity data to FS and itself would move the plane and do it's own predictions, avoiding problems with sync and others problems. Also avoiding the use of too much CPU time by doing predictions every times per second and just let FS do it's own prediccion. BUT, unfourtanely (sorry by my bad english...), as we know the velocity variables (in SimConnect) as not writtable, that means that we cannt send values of velocity to the AI objects, because FS its doing its own calculations, but it should work if we use AIRelease function, BUT!, unfourtanely, also doesnt works under AIRelease.

The limitation that i see in AIRelease is that most of the animations of the plane are lost, as Russell says, its like a slew state for the AI object, things like lights, flaps, sound of engines, and animation of gears are losts, and from my point of view, that is not good, hehehe.

Hope ACES could fix this AI smooth issue....:(

Manuel Ambulo

[gggdude]

I agree Manuel, if there was more built in ability to control various aspects of AI aircraft that would be great.
I wonder why the changes implemented in FSX were so drastic when it comes to AI aircraft/multiplayer. I also wonder what built in functions exist for multiplayer abilities that were not exposed in SimConnect, to developers. Flight Simulator has never really made it easy to develop multiplayer servers and clients, there are many aspects of Flight Simulator that are still obfuscated. Maybe the challenge really lies with ACES and company to make FSX a little more developer friendly and open source. I have been involved in several discussions in this forum and with other developers that attempt to overcome limitations put in place by the creators of Flight Simulator, i.e. the current AI control issue, BGL's and extracting nav info, list could go on. Well we will do what we always do and persevere and come up with our own solutions.

I am working on the pipes solution over the next week. I will post my results, but I am going to move the discussion of my project to my forum. I will continue to participate with this and other threads on this forum, but will not post about my projects here.

Thanks, all who participated in this thread, lets find that solution.

Gabe

[Pete Dowson]

I was very disappointed with the managed SimConnect API, for many reasons, and that also contributed to my choice to develope a SimConnect alternative.

Yes, I can understand the disappointment with Simconnect for non-native C/C++ programming.

In addition, my own API better suited my multi-threading requirements, (the primary reason)

Okay, though I'm no aware of any threading issues. I too use multiple threads, where these are useful. Though because of the way FS works, when you run inside the process, as FSUIPC does, you tend to have to keep many things in the main FS thread for synchronisation purposes.

I have never developed using FSUIPC, does it support AI object creation and manipulation?

No.

If it does not, will it ever have these abilities?

No, I don't really intend to elaborate into new areas not previously covered, except where this is merely an extension of its original purpose. SimConnect is supposed to be the interface for the future and we need to try to force that into doing the job properly.

FSUIPC's interface is there for backward compatibility, not for new applications. I'm surprised is has been so popular, but I put that down to the slow appearance of new applications specifically written for FSX

btw found this on an forum talking about FSUIPC (INTERESTING PIPE INFORMATION) web page http://forums.simflight.com/viewtopic.php?f=54&t=68523


Oh, the SimConnect log. Yes. Sorry, I clean forgot about that -- SimConnect always logs the pipe name:

Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64

I suspect there's a parameter you can use in the SimConnect.xml/cfg files too, to set the name. Maybe even instead of the UDP port. I don't know.

Will work with pipes and post my progress here

Okay. I'll be most interested in the results! I hope it helps!

Regards

Pete

[davidt]

this is a great topic of discussion. i've not had a chance to read it all yet, but i'm replying so i'll get email notifications on further replies.

[gggdude]

I have had great success building a client that uses named pipes that DOES NOT use SimConnect, I experimented today with good results. I am exploring this as a potential method to improve AI aircraft smoothness
My full post is at http://gsxlive.net/adminforum/index.php?topic=120.0
I will soon be testing to see how much named pipes improves ai aircraft performance.

Moving my discussions to my forum, sorry for the inconvenience.

[Manuel Ambulo]

Great! gggDude!, im very positive, i really hope that pipes could be the answer or solution for this AI aircraft smoothness problem....

Manuel

[gggdude]

me to!!! we shall see
follow results of testing on my forum if you want

[Manuel Ambulo]

Thanks gggDude, i will follow your progress in your forum's site. :)

Best Regards,

Manuel

[gggdude]

Alright, I only have one day of vacation left. Thanks for being patient. I was out of state for the first week of vacation and back at home for the second week, but doing family stuff.
Starting Tuesday I will dive back into the AI smoothness issue with full vigor.
I have been working with named pipes, and that is where I left off before I went of vacation.
I had really hoped to have some results before I left for vacation, but hey, I decided I needed a break from programming and the whole AI smoothness issue. Perhaps to gain a new perspective on the issue.
I hope to be able to post something here this week.
Thx
I will post on my forum

[Capn_Geoff]

I'm very interested in smooth animation - as I'm currently injecting aircraft in FS9 using FSInn. At one point about two years ago that was smooth as silk, but the latest version of (FSInn) is very jumpy - and increasing updates to smooth out the jerks has been fruitless.

I'm thinking about the future, though, and while my VA (VUSN.org) is not likely to adopt FSX - it may use FSXI and I want to be prepared. I did run an experiment using FSInn and FSX and we were able to land a plane on a moving carrier (the carrier was controlled by my simulation), but the carrier was extremely jerky.

I had thought about using SimConnect for direct connection, but after having read the above info, it doesn't sound like that would work. When you have a carrier moving and a plane landing, they must be updating smoothly together.

I went to gggdude's link, but I get a 404 error. Is there a more current link?

The lure of FSX with movable carriers and smoke effects, and being able to see landing gear movement, etc is fantastic, but I need a simple API/SDK interface so I can simply give the simulation generated platforms position and state as often as necessary, but smoothness is now especially important.

[gggdude]

Response to Capn_Geoff
The link is currently broken, and I apologize for that.
I own an internet server, and host FSHost, TS, webpages, FTP, a bunch of stuff.
I recently upgraded my server to win server 2k8 64 bit, rather I am trialling the os, but I believe that it is the os I will finally go with.
Over the last few weeks I have been working on the server and putting services back online, but the customers got first dibs, over my free stuff, i.e. my personal flight sim material.
So I have not put the forum you are trying to access back online yet.
But I can answer your question here with regards to the material you would have seen.
Unfortunately, I have not found a solution to the AI aircraft smootheness issue. I have made some progress but obviously have not posted it yet.
The fact is that, I have not achieved satisfactory smoothness, even using a named pipe to connect to FSX. There is simply no way to achieve update sync to AI objects.
My best results were achieved using, a named pipe connection, using my own client (my client did NOT use the simconnect libraries or client). Although the results were better than using the simconnect library based clients, and sockets, it is not good enough.
I can share with you what I did achieve with you.
In fact, there was only a marginal improvement useing pipes vs. sockets.
The issue totally lies with being able to sync AI objects, which is something that is missing from simconnect.
No solution exists that I aware of. I have spent COUNTLESS hours working on a solution, as well as some of the others guys posting in this thread.
So this means that I will delay the development of my server and client for the time being, because what I would offer would probably not be an improvment at this time, although there would be a significant improvement in network and connection stability. I will shelve this project for now.
However, I have started work on a navigator/radar/flight planning program for FSX. It will accept both FSX and any user connected to FSHost.
Most recently I have been working with my custom protocol that sits on top of tcp and udp, for communication between my server and clients applications.
So my current project is navigation software for flight sim.
I extracted all the navaids in fsx for this project, so it is well underway.
I would much rather build a client and server software for flight sim however, kind of my dream project!
Questions? Comments? send me a personal message via this forum.
My regular forum on my website will be back online soon, sorry for the incovenience.
G

[Geoff_D]

Maybe it is time to ask Peter Dowson, if he will once again, rise up and help the FS Community work around this problem. :rolleyes:

I know it goes against all what Simconnect was meant to be, but maybe if Simconnect cannot achieve satisfactory "near real time" operation, then some of the direct memory access methods that FSUIPC use to use, may be the answer. :stirthepo

I believe that most of the original FSUIPC functions, now internally use Simconnect.:confused:

Before Simconnect, with direct memory access, the AI smoothness was not a problem.:o

So maybe the current FSUIPC can "add" some additional functions, that are needed for AI control, that use to be Direct Memory access, and make these "alternative FAST functions" to the now converted to Simconnect functions.

Hopefully, there could be dropped at some later time, when & "IF" , Simconnect provides better real time service of the functions needed for AI control.:D

While I realize it is a PITA to seek out these locations, for each version of FSX, it would seem we are stuck with the current versions of FSX (and Simconnect) for some time, so the investment in time & effort to add these alternative "FAST" function might we worth while. ?

Just a thought ... otherwise I don't see much more progress here till FSX1, and even then, nothing there is guaranteed.

[gggdude]

It sure would be nice to have an API to replace the shortcomings of SimConnect. I am not sure that FSUIPC could meet those needs given its capabilites, they seem to target different needs.
FSUIPC is definetly a great piece of work, and SimConnect is not bad, minus several very serious shortcomings.
It would be a monumental piece of work to DMA any software (I have no desire to peek and poke around in memory), including a new version every few years, my hat is off to Dowson for his work on FSUIPC. In the dawning age of 'managed windows' ;) I wonder how long it will be before such software as FS starts relying on managed components, Vista uses managed services etc. Managed code would make it virtually impossible to DMA software, and I would not rely on this method in the future. Personally I love .net/managed code. I know C++/native/win32 and .net/C#, and have programmed both for some time. .Net has come a long way and is VERY powerful, competing with native code in many scenarios now (especially due to optimizations). I use .NET exclusively now, unless I can not get the performance or functionaliy I need and then revert to C++/Native code.
It would be nice if MS finally just did us all justice and opened up the FS franchise, like they said they would in the past.
If there was a comparable consumer sim, with the popularity of MS-FS, then I would be using that flight sim.
I wonder what the plans are for FSXI or whatever it will be called. Will they even use SimConnect? Will the developer API be similar or different? Who knows, makes it kind of difficult to invest resources into developing for MS-FS.
I love MS-FS, and fly it exclusively, I would REALLY like to develop a multiplayer server and client, NOT based on DirectPlay. Hopefully that can happen, maybe ACES will wise up and fix a few of the issues we have, they have got to know about this and other issues.

[Simon853]

If there was a comparable consumer sim, with the popularity of MS-FS, then I would be using that flight sim.
Have you tried X-Plane 9? That is getting extremely good. If I didn't already own FS and have time and money invested in add-ons, I'd probably be using it exclusively. Then I could happily dump Windows too.

Si

[gggdude]

I tried X-Plane way back in the day, around 2000-2001, and was not impressed, has it improved dramatically? If so thats cool.
However, I love Windows (Vista), Windows and I coexist happily on my pc's ;)
I have LOTS of development time invested in FSX, hopefully FSXI will overcome the shortcomings of FSX.
G

[Capn_Geoff]

X-Plane is indeed an excellent sim. I believe that I read that with the new release some of the scenery building functionality is coming back. The graphics are definetly on par - even better than FS9/X IMHO. I was going to check out the x-plane.org yesterday, but their server was down, and I haven't had a chance to look at the latest and greatest yet....

Ok, so I won't beat my head over the update rate/synching problem with FS/MP. At least I won't waste my time in that direction - when I have so much else to do!

[PeetyGreen]

New to FSX..

I've seen a few threads on connecting to FSX via sockets but have been looking for examples on how to do this but come up w/ nothing.

I want my client app to be able to send aircraft updates to FSX a few x a second. Which should create the initial aircraft and update its position (lat/lon/alt).

How do I open up FSX to accept these types of request as well as send updates w/o using SimConnect?

Thanks

[GOZR]

I just did follow this thread, This is a major problem for FSX and not only Ai's plane but any surrounding moving object..
Now this is affect FSX SP2/Accel so what was under FSX "1" that was smooth ? maybe by looking at it we may find a solution because for now it is a complete disaster for FSX accel.
Anyone found a solution yet ? many links on this thread are dead...

Thx

[Pete Dowson]

I believe that most of the original FSUIPC functions, now internally use Simconnect
Yes, almost all. FSUIPC4 is a compatibility layer, to ease the transition to SimConnect. If the take up of FSX had been all that was hoped there'd be many more direct SimConnect add-ons by now, and FSUIPC would be well on its way to being phased out as an interface. This is why I've really been concentrating on the User Facilities.

Before Simconnect, with direct memory access, the AI smoothness was not a problem
You never actually had control of AI by "direct memory access", surely. Are you thinking more of the multiplayer interface, not AI?

FSUIPC did offer direct access to some of the same facilities MS's TrafficToolBox does -- i.e. the ability to send controls to AI aircraft. It used the same interface TrafficToolbox did. I could do it the same way in FSX (it does already for "Zapping" AI aircraft), but I don't see much point. As far as I know these facilities were only ever used by programs such as AI Smooth, and they were never terribly satisfactory.

Regards

Pete

[bojote]

I've been trying for months to get AI planes in my FSHostClient program to move smoothly

I'm surprised no one has mentioned that simconnect (by default) uses the Nagle algorithm for sending packets, so I assume something like this:

<DisableNagle>True</DisableNagle>

in both the simconnect.cfg and simconnect.xml will aliviate (or completely solve) your problem, it DID solve mine with Squackbox and the horrible latency problems I was having.

[russell]

<DisableNagle>True</DisableNagle> in both the simconnect.cfg and simconnect.xml will aliviate (or completely solve) your problem, it DID solve mine with Squackbox and the horrible latency problems I was having.

Hi, and thanks for the reply.

It's an interesting theory, and one that I haven't tried, but I don't think this problem is related to TCP packets. I think it's related to the fact that FSX is updating the local user's plane (or, the local user's view of the outside world as his plane moves forward) and my program is updating the AI plane. Since Simconnect doesn't seem to have a way of syncing those two movements up, I think it's a lost cause.

See my second post in this thread for my thoughts on trying to get the two in sync. One of the things I tried was to update the AI plane each time Simconnect updated the local user's plane (via the VISUAL_FRAME callback), but I believe even that is flawed, since the time between when FSX updates the local user's plane and when FSX calls my callback can vary.

Thanks,
Russell

[B21]

hello my necro buddies - there is a method for smooth AI movement:

another thread in this forum here (http://www.fsdeveloper.com/forum/showthread.php?t=17374)

The trick is to put the AI aircraft into SLEW mode and send it *velocity* updates, instead of trying to warp it from point to point through space by sending it position updates. Makes sense when you think about it, and this method looks totally smooth even if you send the updates once-per-second.

Having said that the starting point for most FSX programmers is to assume the correct method for AI motion is to send position updates, and they find out it seems to kind-of work at slow update rates as the plane warps from place to place and maybe it will smooth out if you can just send the updates fast enough. It's a tough step to accept the problem is with your algorithm not some failing of FSX or the tcp/ip stack or whatever. But the approach is fundamentally flawed.

But adjusting the position by sending velocity updates is more complicated than sending position updates, whereas sending the position values is trivially simple (but it won't be smooth).

It might be the proper way to control motion would be via acceleration updates (that guarantees continuous velocity changes, in the same way that velocity updates guarantees continuous position changes, and position updates ) - but the slew system in FSX doesn't provide any possibility for that.

And there are significant limitations on what you can do with AI objects in slew mode in FSX (e.g. animations go right out the window) but that just means more programming to fix that (e.g. swap out of slew mode while you animate) so FSX provides an endless opportunity to spend your life programming instead of flying...

B21

[Manuel Ambulo]

Hey B21!, nice to see you on this thread...


The trick is to put the AI aircraft into SLEW mode and send it *velocity* updates, instead of trying to warp it from point to point through space by sending it position updates. Makes sense when you think about it, and this method looks totally smooth even if you send the updates once-per-second.


I think it's a very nice technique, and also, think that sending velocities to the AI aircraft is the solution...but also it's important to send position updates in intervals of time, in other words, to reallocate the AI aircraft each interval of time, and between those intervals the SLEW system will "MOVE" the plane...with this it's important to set ROTATION (pitch velocity, bank velocity and heading velocity) and TRANSLATION (in XYZ axes) values to the SLEW system.



It might be the proper way to control motion would be via acceleration updates (that guarantees continuous velocity changes, in the same way that velocity updates guarantees continuous position changes, and position updates ) - but the slew system in FSX doesn't provide any possibility for that.



I think that maybe it would be neccessary to use velocities relative to the plane's body instead of world velocities, since SLEW system's velocities are relative to the plane's position. I realized that maybe body velocities are the same velocities of world velocities, but the difference is that are relative to the plane's body.



And there are significant limitations on what you can do with AI objects in slew mode in FSX (e.g. animations go right out the window) but that just means more programming to fix that (e.g. swap out of slew mode while you animate) so FSX provides an endless opportunity to spend your life programming instead of flying...



Exactly, the bad news of using SLEW is that it doesn't have animations in it...
However, in few experiments i noticed that you can control few things like gears....if you put an AI plane under SLEW and send NOSE GEAR simulation variable with different values...you will see that you can change the position of the landing gear...*EVEN UNDER SLEW*...i think the trick is to send more than one NOSE GEAR values say from 0 (zero) to 100% and you will make your own animation of the landing gears (even under slew mode on an AI)...


Manuel

[bluejoystick]

Hey B21!, nice to see you on this thread...

Exactly, the bad news of using SLEW is that it doesn't have animations in it...
However, in few experiments i noticed that you can control few things like gears....if you put an AI plane under SLEW and send NOSE GEAR simulation variable with different values...you will see that you can change the position of the landing gear...*EVEN UNDER SLEW*...i think the trick is to send more than one NOSE GEAR values say from 0 (zero) to 100% and you will make your own animation of the landing gears (even under slew mode on an AI)...


Manuel



Dear Manuel

What is the meaning of Nose Gear?? I have search it on FSX Event key but im not found..?
Or do you have another mean of it??
I have same problem.. when i use 'slew' the plane is cannot make animation about the gear..

Best Regard

Blu

[Manuel Ambulo]

With "Nose Gear" i meant the "Center Gear"...this "Simulation Variable":


GEAR CENTER POSITION


When you instruct an AI aircraft to go under SLEW MODE, all animations will be disabled...HOWEVER! there still a chance to "move" the gears, by sending positions (0-100%) every certain interval, to make the "ilusion" that the gears are still moving. In other words, send these "Simulation Variables" with a certain interval of milliseconds (maybe?):


GEAR CENTER POSITION
GEAR LEFT POSITION
GEAR RIGHT POSITION

Since if you set for example 75% for "GEAR CENTER POSITION", you will see that the AI Aircraft will have that gear 75% extended...You can do a test and you will see what i mean....if you make your program to create some kind of "counter" from 0-100% you still have the chance to make a custom or improved animation on the gears...it may not be the same as the original animation..but still you have the chance to "move" the gears...


Manuel

[bluejoystick]

With "Nose Gear" i meant the "Center Gear"...this "Simulation Variable":


GEAR CENTER POSITION


When you instruct an AI aircraft to go under SLEW MODE, all animations will be disabled...HOWEVER! there still a chance to "move" the gears, by sending positions (0-100%) every certain interval, to make the "ilusion" that the gears are still moving. In other words, send these "Simulation Variables" with a certain interval of milliseconds (maybe?):


GEAR CENTER POSITION
GEAR LEFT POSITION
GEAR RIGHT POSITION

Since if you set for example 75% for "GEAR CENTER POSITION", you will see that the AI Aircraft will have that gear 75% extended...You can do a test and you will see what i mean....if you make your program to create some kind of "counter" from 0-100% you still have the chance to make a custom or improved animation on the gears...it may not be the same as the original animation..but still you have the chance to "move" the gears...


Manuel

:) Thank you

its works guys
:)