AI Aircraft SID and STAR Controller

[propkop2k2 1]

 

 

Yes, to the console window. Make sure you are in verbose=0 mode (if you are not already).

Are you running Pro-ATC and/or OpusFSX? I've had two other users report strange AI behavior running these at the same time as my program. To try to address this issue, I just finished a program update that stores its FSX control data in reserved memory space on the FSX server, which allows me to force read access only to other simconnect programs. Theoretically at least there's no way any other simconnect program will be able to interfere with commands sent by AISIDSTAR to FSX, unless they're both trying to control the same AI. The updated program also checks for incompatible (earlier) simconnect versions. I'll get the version posted shortly, I'm doing basic testing of it now.

 

I do have OpusFSX, but I get the same whether it is running or not.

 

I have had a look a second time , unless I am missing something obvious I do not notice any speed values written to the console window.

 

I have also disabled every file that is loaded by FSX. It did not make any difference.

[russianspd 10]

 

 

just added your earlier request (a hold option at the STAR exit point and additional spacing for turbo-props). I'm doing basic testing of it now. I'll take a look at KLAS, I know you've been testing there a bit. I'll assume you developed the STAR files using default options for AIConv.exe (let me know if you did not).
 
-Roland

The SID/STAR files were from the PMDG SID/STAR txt files and yes they were defined to the default options by AIConv.exe. I did change the pattern altitutde to 5000 before being given to FSX. And separation was at 6nm, have since backed down to 5.

[bluemja2002 4]

Can't get the program to run, saying that the program can't start because msvcr100.dll is missing.  I have installed the SDK and installed C++ runtime.  Any ideas?

[propkop2k2 1]

Some more feedback on the wrong speed issue I am having.

 

I tried running your program on a second pc. The speeds were still incorrect. I then sat and watched the console output for about 45 minutes looking for the speed value you mentioned. Unfortunately it never showed up.

 

I did notice one thing though. All planes that are already in the air and are controlled by AIsidstar are showing the wrong speed issue. All planes that takeoff and then get controlled by the program have the correct speeds.

[Clipper Ocean Spray 189]

Rev 1.2G (beta) is available here:

 

http://www.mediafire.com/?4kif0um8b7t3nfz

 

For those having slow AI and user aircraft slewing problems, please give this version a try and report back. Many changes under the hood...  

 

Changes:

 

Version checking:  AISIDSTAR will notify user and exit if it detects an earlier version of SimConnect installed.

 

Read only access by other SimConnect programs:  AISIDSTAR control data sent to FSX is now in a reserved FSX memory area with read only access provided to other SimConnect programs. 

 

File logging:  Verbose = 1 and Debug  = 1 will cause a log file (AISIDSTAR.log) to be written in the same directory as AISIDSTAR.exe.  If you are reporting any problems, please run the program until the error is encountered, then normally exit AISIDSTAR, zip up the log file and email it to my support address with a description of the problem and when (approximately) it occurred.

 

STAR exit waypoint holding - now have the option to hold at STAR entry and/or exit waypoint.

AIholdingallowed = 0 (No holding)

AIholdingallowed = 1 (Holding at STAR entry waypoint if necessary)

AIholdingallowed = 2 (Holding at STAR exit waypoint if necessary)

AIholdingallowed = 3 (Holding at both the entry and exit waypoints if necessary)

 

Additional separation for turboprop  - additional 2 nm added to minium AI seperation (AIseparationdistance) for non-jet  engine aircraft (e.g., turboprops).

 

The SID/STAR files were from the PMDG SID/STAR txt files and yes they were defined to the default options by AIConv.exe. I did change the pattern altitutde to 5000 before being given to FSX. And separation was at 6nm, have since backed down to 5.

 

Thanks, now that Rev. G is out, KLAS is next on my list.  I've started using the Traffic Toolbox "Traffic Map" utility to review what is going on at airports, so I should be able to get a picture of the issue quickly.   

 

Can't get the program to run, saying that the program can't start because msvcr100.dll is missing.  I have installed the SDK and installed C++ runtime.  Any ideas?

 

That's just a visual studio redistributable you're missing.  

 

http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/trying-to-open-computer-management-the-program/5c9d301a-2191-4edb-916e-5e4958558090

 

Consider yourself lucky you didn't get the missing redstributable's evil cousin:  the "side by side" error. :wink:

 

Some more feedback on the wrong speed issue I am having.

 

I tried running your program on a second pc. The speeds were still incorrect. I then sat and watched the console output for about 45 minutes looking for the speed value you mentioned. Unfortunately it never showed up.

 

I did notice one thing though. All planes that are already in the air and are controlled by AIsidstar are showing the wrong speed issue. All planes that takeoff and then get controlled by the program have the correct speeds.

 

Please send me a log file using the new version and I should be able to find it buried in there (or it could be missing, which would be an important clue).  Thanks for looking at it again to find additional characteristics.

 

I think I'm done adding features to version 1.2, so I should be able to get to the bottom of this speed issue some users are encountering.  Maybe we'll get lucky and 1.2 rev G (beta) will help, but if not the logging should prove useful.

 

-Roland

[propkop2k2 1]

 

 

Please send me a log file using the new version and I should be able to find it buried in there (or it could be missing, which would be an important clue).  Thanks for looking at it again to find additional characteristics.

 

Log file has been generated and sent to your email. I did find the speed value in the log file.

 

The wacky speeds are still happening with revision G.

[Clipper Ocean Spray 189]

To any users experiencing their own user aircraft getting slewed, a user just reported to me it may be FIXED in the new version.  Please give Rev. G a try ( http://www.mediafire.com/?4kif0um8b7t3nfz ) , if you see the following information repeating in the console output window (or log) you're probably good to go:

 

"Note: user aircraft detected as ai object (Simconnect bug) -- AISIDSTAR will NOT process user aircraft (status OK)."

 

-Roland.

[bluemja2002 4]

 

 

That's just a visual studio redistributable you're missing.  

 

http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/trying-to-open-computer-management-the-program/5c9d301a-2191-4edb-916e-5e4958558090

 

 

 

Nevermind I got it to work by going to this website

http://www.mpgh.net/forum/186-combat-arms-help/459799-proper-way-fix-msvcr100-dll-msvcr100d-dll-d3dx9_-dll-errors.html

Edited July 4, 2013 by bluemja2002

[russianspd 10]

Thank you very much Roland for taking the time to look into issues and providing support to further enhance your ground breaking program. I will give the new G beta a shot at LAS and let you know my findings.

 

Edit: First test will let the sim run for 40 mins and let everything stabilize. Have it set to hold AI at STAR exit point. If that runs well with making AI all come off the approach in a lined up manner we are in good shape. If not I will try with holding at both the entry and exit points.

[russianspd 10]

Still experiencing problems with AI not being put onto the STAR timely and still having altitude difficulties with AI not descending. Because not enough AI are on the STAR approaches it is hard to read how the holding at the exit point is working out. There are about 20-30 AI in the FS read area headed to LAS but only 1 or 2 at a time are on arrival and that is split between 3 runways at LAS.

 

I'll move to a busier airport, LAX. Will test out the turboprop addition.

[russianspd 10]

Some results from LAX: I'll get clumps of aircraft checking in at 7-9 miles from the runway. Only had one go around from a group of 4 that all checked in almost one after the other. Still dealing with a time issue of when the AI comes into the area and the time it spends on the STAR to getting released onto the final approach.

 

Had an Alaska guy who was released from AISIDSTAR and was 4nm from the airport at 900 ft. That aircraft seemed stuck. Anyone else able to comment on how it has functioned on their systems?

[russianspd 10]

At LAS with both holding AI at entry and exit points I only have departing aircraft being released from slewing, no arrivals at all.

[Clipper Ocean Spray 189]

At LAS with both holding AI at entry and exit points I only have departing aircraft being released from slewing, no arrivals at all.

With some help from propkop2k2, I'm zeroing in on a fix for the random, uncommanded (i.e., not related to distance separation) AI speed changes, so this might help with everything across the board, including holding results.

 

Regarding LAS, I guess you can tell my first priority is to prevent go-arounds. :wink:

 

Regarding STAR exit point holding, I can release them at fixed intervals (e.g., 2 minute separations, more for turboprops) and create more of a string of pearls lined up on final. This will increase go-arounds however because I'm usually dealing with numerous STAR exit points at one airport and each AI flies a slightly different pattern from the exit point to IAP. I can account for all that to some extent, but it is not perfect. Regarding the increased go-arounds in this scenario, I can keep checking for minimum separation even after the AI leaves the exit point and vector offending AI away from the approach and back to the exit point, but it might look sort of strange and it is not a realistic procedure (I don't think). I can also put the offending AI on a SID and get them out of there, but that seems sort of a waste.

 

Do you think this would be a better approach for STAR exit holding? More string of pearls, but more go-arounds unless I re-vector offending AI away after they left the STAR exit waypoint (which might look a bit strange).

 

-Roland

[russianspd 10]

There's this program called FS AI Separation. The logic behind it is the user sets a couple factors, desired separation, minimum separation, reduced separation zone, and no move zone.

Desired separation= the nm value you want AI separated, I use 5 miles
Minimum separation=if AI fall below the 5 mile separation the user can set a # of nm that the conflicting AI will be slewed back, so if it's 2 miles then the AI will be pulled back 2 miles say from a 4.5 mile conflict pulling him back to only 1 mile from the conflict. The higher the value the greater the initial separation from the 5 nm limit (really helps with smaller VS larger aircraft because the speeds slow on the approach)Forgot to mention that the program continually monitors the separation values, it will separate the same AI over and over if it keeps falling under the 5 nm value. Helps with reducing go arounds and odd AI behaviour because it doesn't require anything but moving backwards. No turning or unnecessary vectoring.
Reduced separation zone=distance from the airport monitored/all airports in area that AI will be spaced half the distance of the desired separation. (I have mine set to 10, I am more concerned about the main approach where reduced speeds are a factor)
No move zone=distance from monitored airport/all airports that separation will not occur. (I have that set to 0, separation all the way down)

Using this program alone I have had about 8+ arrivals into LAS without a single go around. It's only concern is keeping all AI 5nm spaced apart.

When I turned on AISIDSTAR I had an Alaska on final who turned around and went up the approach path because the program saw it as a new aircraft and was vectoring it to the star point, which is what you are suggesting, having the aircraft revectored, which could be problematic.

I think what would work best is to focus on maintaining the separation. Keeping the separation after the AI leave the STAR is a crucial point. (Might explain why when at LAX I had 3 AI check in all around one another) The speeds and altitudes in SIDS and STARS are primarily meant to help with traffic flow and keep everyone separated appropriately. Leading to a nice string of pearls.

 

Using FS AI Separation I had a nice set of 3 guys all on approach to parallel runways, but this is at about 10pm at LAS, so traffic is pretty light. Airports like LAX would be slimming down the efficiency just because of the volume of traffic there. But reducing the value to separate from the airport allows for a reduced load.

[Clipper Ocean Spray 189]

Rev 1.2H is available here: http://www.mediafire.com/download/xwwb94a80j6ewpz/AISIDSTAR12H.zip

The random changes in AI speed should be fixed. I don't want to go to a higher sampling period (I'm at a light 4 seconds right now), so I can't reign in the speed changes instantaneously. It may take several seconds to return the AI back to a normal speed, especially if the change was excessive. The program does not spend resources adjusting each AI's speed back to the exact target speed because, realistically, each AI's speed is expected to vary from each other to a small extent.

I also fixed a major bug: speed restrictions entered into the STAR and SIDs as knots were getting errouneously converted to meters/sec (i.e., getting reduced by approximately half). For example, a typical speed restriction of 210 kts would cause the AI would travel at 108 kts. This bug was probably responsible for most of the "slow AI" people were seeing as many STAR and SID files have speed restrictions of 250 kts or less.

During the process of fixing these speed issues however, I've gotten cold feet about having a default minimum separation distance, which causes the AI to change speed in order to maintain the minimums (on the STAR). Please note, I have changed the default to zero (i.e., disabled). I think this option is something the user should intentionally enable so they expect the speed variations associated with it. I personally recommend however enabling minimum separation as well as both of the holding options as I prefer reducing AI go-arounds as much as possible.

BTW, here are the typical reasons why AI will change speed when using the program:

(1) AI target speed is 240 kts below 10,000 ft., 300 kts betw. 10,000 and 16,000, 350 kts. betw. 16,000 and 26,000, and 410 kts. above 26,000 ft.
(2) AIseperationdistance = non-zero. The program will vary the speed of AI (within reason) to obtain this minimum separation. To turn off set to zero.
(3) AI released from STAR or SID exit point, at which point FSX will command speed.
(4) STAR and SIDS often have speed constraints at certain waypoints, which AISIDSTAR will recognize and enforce.
(5) AI is flying through the monitored area, but is not departing from and landing at a monitored airport, thus it is not under control of AISIDSTAR.
(4) Random changes in AI speed caused by FSX, which if excessive may take several seconds for the program to the speed back to a normal range.

Other Fixes/Upgrades:

Fixed AIConv.exe Utility: Fixed bug where automatic STAR entry altitudes were not taking into account the airport elevation. If you fly into airports at high elevations, you might want to convert your SID/STAR files again using the revised utility.

Upgraded Holding: I also revised the holding algorithms, there were some issues preventing timely releases from hold. Please note that STAR exit holding allows AI to depart BELOW minium seperation in cases where it is confirmed the AI are landing on different runways (e.g, 19R and 19L).

Also, all the AI will hold turning clockwise making the holding pens look a little more coherent. If you see any AI circling left (counter-clockwise), it is probably because it missed the waypoint and is circling back in the shortest direction. However, missed waypoint circling has been reduced as well (see below).

STAR exit holding peforms a "quasi" go-around if minimum seperation is violated any time after the AI have exited the STAR, but before the AI descend below 1500 ft AGL (this includes AI on final approach). The offending AI will be vectored back to the STAR exit point for holding (and eventual release) . If you do not like the possibility of the AI going against the general approach direction (IMO still better than the FSX VFR pattern solution), use STAR entry holding only (=1). In any case, FSX detects go-arounds as normal starting at approx. 500 ft. AGL and you still have the option to vector those go-arounds on a SID out of the area or just use the FSX VFR pattern

Holding is now also independent of minimum separation: The user can now turn off minium separation (AISeperation=0), but enable holding (AIholdingallowed=1, 2, or 3) and AISIDSTAR will vector accordingly. The program now actually does a pretty good job holding AI to enforce default separation values (generally 5 nm for jet, 7 nm for turboprop) without using AISeperation (=0), which causes distracting AI speed changes (to some).

Upgraded Hand-off to FSX. After exiting a STAR, the program now points the AI in the direction of the airport before handing off to FSX for final approach vectoring. This has done wonders to prevent hand-off problems (AI flies low and slow in one direction away from the airport). I would go so far as to say handoff issues should now be an exception unless the STAR exit point is extremely close to the airport.

Fixed Repetitive Display of the "User aircraft detected as AI object (SimConnect bug) -- -- AISIDSTAR will NOT process user aircraft (status OK)" message.  Now it will only display 3 times. For those users who were getting this message in 1.2G, PLEASE VERIFY YOU ARE STILL GETTING THIS MESSAGE IN ver. 1.2h, but only for three times max.

Upgraded Missed Waypoint Handling: added code for the AI to bypass waypoints where it can't turn acheive the waypoint using a standard turn and speeds. This is mostly for when FSX spawns AI too close to a waypoint at a high bearing angle and starts circling the waypoint, but never getting into the hit area. However, some of the auto-generated SID/STARS have waypoints that are very close to each other. Also added a last resort timer, which tests to see if AI not commanded to hold is lingering at a waypoint (e.g., circling) for an unusual amount of time. If so, it gets released to the next waypoint

Added More AI position Data for debug=1 output to assist with troubleshooting logs.

Fixed STAR/SID Selection - Program was incorrectly calculating arc-lengths when taking into account the turning distance. I actually thought I had fixed this before, but I noticed the bug was still there. Sorry! In some situations this bug may have cause the program to select an entry point that was at a steep bearing to the AI' aircraft's heading.

Fixed: program misleadingly stated it was loading SID filenames during the STAR load phase that it was not actually loading and vice versa. This has been fixed. For example during the STAR load phase, if the program finds the currently opened file to NOT be a STAR file (patterntype = SID), then it will NOT misleadingly state it is loading this file.

NOTAM: I've sometimes noticed issues with opening second windows (to view AI traffic or maps). The AI start diving, speeding up, banking steeply. It should be OK to view the map or an AI for a moment in a new window, but if you keep the second window on indefinitely, AISIDSTAR may start having problems. I'm still looking into this issue.

-Roland