• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

smooth AI movement - the old favorite

A bit of newbie-warning on this post, sorry for that.

I've been looking at your ideas and interesting posts, and began to test it myself. I'm working with Beatles SimConnect SDK in C#.net, but I guess that shouldn't make a difference in this case.

Exactly what are you doing every 4 seconds, to make the AI turn or pitch in another direction?

What I did was that I set Slew-mode to On, set the pitch axis, and then turn the slew mode off again. Shouldn't this new pitch value make the AI-aircraft pitch down or up? Am I missing something here?

Thanks!
 
Hey Frazer,

Frazer said:
What I did was that I set Slew-mode to On, set the pitch axis, and then turn the slew mode off again. Shouldn't this new pitch value make the AI-aircraft pitch down or up? Am I missing something here?

Once the AI is created, it's set to SLEW ON, then you should "drive it" using the SLEW values to make it move. It's important that you keep it under SLEW ON...and not set it to OFF....if you set it OFF, it will hand off the control back to the FSX's built in engine, making it difficult to an external program to "drive" the AI.

B21 said:
The basic idea is as described earlier in this thread, but that still left a lot of programming to simply control the AI object by adjusting the slew rates. The basic technique is a "following" AI algorithm as illustrated here. I *predict* where the lead aircraft is going to be FOUR SECONDS AHEAD (the predicted_point), and adjust the slew rates of the AI aircraft to turn towards that point.

All motion of the AI object is by sending the slew AHEAD/HEADING/BANK/PITCH/ALT commands which adjusts the corresponding linear or rotational speed, and in between my per-second updates the AI aircraft continues with the previously set velocities, i.e. if it's turning it will continue to turn. Testing shows the movement has none of the jitter present when doing absolute position updates via simconnect.

Manuel
 
Yup,

I *create* the AI aircraft with some suitable init position - sound like you've got this bit ok

I send the 'SLEW ON' event to the AI object (and never send the SLEW OFF)

I RequestDataOnSimObject for time/lat/long/alt/pitch/bank/heading of the AI object once-per-second

Each time I get this data packet back for the AI object, I calculate where I want the AI aircraft to be four seconds later than the time (zulu time) returned in the data packet.

How you calculate this 'predict point' can vary, depending on your application - maybe it'll help if you explain what you're doing. E.g. you could have an AI object follow the user aircraft - the predict point would at its simplest be a lat/long/alt projection forwards from the user aircraft using its current position, heading, and speed. Or you could do something similar with the position of a user aircraft in multi-player. In *my* application I actually have a GPS-trace file showing the tracklog of a real aircraft, and it's easy for me to walk forwards through the file and pick out the "T+4 seconds" position of the aircraft. This 'predictive' algorithm is very similar to simply continously aiming at the user aircraft (e.g. if you wanted to follow that) but for various stability reasons it's actually a bit smoother if you actually aim to stay four seconds behind a point you're predicting the user aircraft will be in four seconds, if you can get you're head around that concept....

Given the *current* position and orientation of the AI aircraft (returned in the RequestDataOnSimObject data packet) and the *predict point* I want the AI aircraft to reach in 4 seconds, I can compute the SLEW_AXIS.. event values to send to the AI aircraft to have it arrive at that point at the right time. The AI aircraft doesn't necessarily ever arrive exactly at *that* point because I'll be sending more SLEW_AXIS events a second later aiming at a slightly updated predict point, so the AI aircraft behaves as expected, slewing around the sky in a fairly sensible way, with the 'predict point' always being dangled 4 seconds in front of it to aim at...

You can test the SLEW_AXIS.. events using Traffic Tool on the user aircraft (thanks Manuel). If you do this it helps if you update the shift-Z display values to get vertical climb rate and true heading etc.

Then you can hit kind of a milestone having a SLEW_AXIS_ALT_SET(1000) event cause the AI object to descend at a steady 63 feet-per-minute... and have the RequestDataOnSimObject pick up the AI object altitude once-per-second and display it in a console window or something. At this point you have just about everything you need to create a working navigating AI object that you can move around at will.

But as I mentioned in an earlier post, even though the principle is this simple (once you get it), there is still a lot of quality programming to do just to make sure the process actually works in practice. E.g. I had to calibrate the SLEW_AXIS.. values, and the 'turn-and-move-forward' algorithm of moving an object takes a while to get correct - it's certainly harder than the basic 'warping' of the AI object directly to the point in space that you want it. The good news is that each 'degree of freedom' is actually pretty independent, so you can get the code working for moving the aircraft in lat/long at a fixed altitude (this is the only tricky 'aiming' algorithm) and add in altitude changes afterwards. Pitch and bank don't alter the direction of motion of the aircraft so they're easy to program and are cosmetic really.

My particular requirement has location 'samples' that really can be quite a long way apart (eg 10 seconds), so it's necessary for me to smoothly interpolate between them - today I've been working out how to move the aircraft in a smooth 24-second turn when my lat/long/alt fixes might be at 10-second intervals (try it on a piece of paper....). So I'm dealing with some pretty detailed issues as the basic method is working very smoothly...

Another subtlety (as mentioned by Manuel earlier but I forgot about it) is that my source data (real GPS traces) sometimes have an altitude offset such that for an aircraft on the ground I am trying to tell FSX to move it *lower* to the height my GPS trace says (wrongly) it should be at. FSX works well in placing the AI aircraft on the ground (and not below it), and no lower, but my AI 'following' algorithm was going a bit nuts twisting the aircraft to try and reach the lower position. It was an easyish fix to detect SIM ON GROUND from the AI object and tweak the movement algorithm in that case (i.e. force pitch and bank to zero).

Also today I downloaded the tracklogs of 39 real aircraft from a gliding competition in the UK, and replayed them on my PC substituting 747's for the gliders, and had a cloud of 747's circling smoothly over Cambridge... ZERO framerate hit.

B21
 
hehe, not that you want it, but my final update is that the automatic load of 46 standard-format tracklogs (from the 2008 15m World Gliding Competition) worked in AI-playback using the slew method without a hitch and still no detectable impact on frame rate on a 3Ghz Pentium 4:

1r_thermal_close.png


I will include these tracklog files in the package for my FSX module (sim_logger version 2) due out this month (Nov 2009), and have written up a walk-through. Big thanks to Manuel for pointing out Traffic Toolbox that I hadn't thought about using at all...

B21
 
Thanks for the answers, somehow I missed the fact that I should remain in slew-mode.

Works fine now, just some fine-tuning to do.
 
sim_logger version 2, using the AI slew technique, is now finished:

http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_logger/

B21

**update **
The sim_logger homepage now has a link to a version of the source in the 'Development notes' section near the bottom of the page.

sim_logger is written as a single Visual C++ program of over 4000 lines, divided into the main sections:
  • Program startup and ini file handling.
  • FSX simconnect message handling, in particular recognising file loads of FLT, PLN, WX files and receiving the position updates from the user aircraft and the replaying AI objects
  • Writing the IGC file for the user aircraft. The checksum formula has been removed to keep it secure.
  • Reading the IGC files associated with the loaded flight, adding interpolated points if the sample rate is a bit low, and estimating values for pitch, bank and heading (these are not in the log).
  • The AI movement algorithm, updating the slew rates of the AI objects once-per-second.
  • The menu system using the FSX SimConnect_Text call

In particular the AI following algorithms, the IGC file 'interpolation' algorithm that injects extra trackpoints if the gap between samples is >5 seconds, and the estimation of pitch and bank from the lat/long/alt tracklog sample values are non-trivial.

Other significant parts of the simconnect module are more engineering than computer science, may help any developers of simconnect modules, e.g. finding and parsing the FLT file when the user loads one or simply subscribing to and processing position updates from the user aircraft or AI objects. Also processing an 'ini' file for the module, and using the 'SimConnect_Text' call to create a menu system.
 
Last edited:
Hi guys,

I've been quietly following this thread for some time - primarily because I am doing something slightly different: I am turning off (FREEZE) the USER flight model, and writing my own. Can I then assume I can do away with all this stuff above and assign my own values to the AI object, as some kind of an offset to user aircraft?

Or more specifically, I have an aircraft that has a custom flight model (so, FSX's flight model is completely disabled using FREEZE command) and this aircraft has a droppable object (droppable fuel tank):

Is the only way to have a droppable fuel tank to design and declare it as an AI object, and have it ride along the user aircraft, until dropped (and then assign to it its own flight model (or in this case, "fall model")?
 
there are two issues - one is how the drop tank flies in formation with the user aircraft, and the other is how it falls.

If you're controlling the lat/long/alt/pitch/bank/heading of the user aircraft on a per-frame basis, then you could do the same with the drop tanks as AI objects at an offset from the aircraft. At least this is much easier to do than if you were *not* controlling the position of the user aircraft. I'm not sure how the latency beween the aircraft and drop tank updates would affect you though.

Alternatively, if you've modelled the aircraft you could make drop tanks part of the model and just change the visibility of that part when you drop them, and create the AI at 'drop time'.

There's no 'jitter' issue with drop tanks falling through the sky (the issue of flying in formation with another aircraft that is having its *position* updated by a simconnect client) so you could simply update the position of the AI object in the same way as you do for the user aircraft.

Given the way drop tanks tumble, I wondered if creating a drop tank as an *effect* had any potential. It's possibly worth thinking about, because there's no way anybody is flying around a 3d model of the falling drop tank and a sequence of images might just work...

effects sdk here

B21
 
Thanks, "B21"... (bat-21? :) ) Yes, I am controlling the lat/long/alt/pitch/bank/heading of the user aircraft on a per-frame basis... Ok, I thought I asked before I start experimenting. I hope there IS no latency issue if AI object is told to "ride along, and then disconnect". Unfortunately, the "part-of-model-and-hide" is not an option for various other considerations.

Thanks again, I'll report on my findings.

Misho
 
Last edited:
good luck with it - my suggestion is kick off another thread and other lurkers can watch your pain for a couple of months and learn from it...

B21 (as in my real glider competition id, aka "Bravo! two-one. Good finish.")
 
FYI everyone, as per my question and follow up 4 posts above, it works like a charm, no latency issues!

Misho
 
well done Misho - sounds like a good result. I guess it actually worked for you *because* you're not using the FSX flight model, so the AI drop-tanks can be coordinated with your movement of the user aircraft...

B21
 
well done Misho - sounds like a good result. I guess it actually worked for you *because* you're not using the FSX flight model, so the AI drop-tanks can be coordinated with your movement of the user aircraft...

B21

Thanks - I'm encouraged but there are still a few more wrinkles to iron out. You are right, I am not using a FSX flight model - I call "freeze" on every object I create and create my own positioning algorhitm. If all objects are following the same algorhitm, they can be precisely controlled.
 
Back
Top