November 27, 201312 yr Bug Fix: Ver 1.2P crashing about 10 minutes after starting. The quick fix can be found here: http://www.mediafire.com/download/ahe4c1ceewzzpfx/AISIDSTAR12P2.zip Please, ignore my last post, I found the correct instructions here http://forum.avsim.net/topic/408490-ai-aircraft-sid-and-star-controller/page-5#entry2704441 However, aiconv crashes in the first airport that he finds. Feel free to email me the problem airport file to my support email and I'll take a look. So I am new to this program and was wondering if this would make ai approach as real real aircraft do at MHTG ( Toncotin ) ? Generally speaking, it doesn't do the final approach. However, it will do the STAR portion of the arrival if there is one.
November 27, 201312 yr Roland, it´s fixed, the problem was the format of the airports file that was not accept by aiconv. Now, I have sidstars for Brazil, Uruguay and Argentina. Thank you so much for your great program!
November 28, 201312 yr Commercial Member I've not set up my P3D2 AI yet (so many things to do!), but in exchanging notes with Roland today he's testing it and things look promising. (Each product functions in a fully-functional trial mode for interested users.)
November 28, 201312 yr Does this utility work with PR3D v2? Yes, it does work with Prepar3D V2. Install the V2 SDK at http://www.prepar3d.com/support/sdk/ (not sure you even need to install this, but might as well). If you're trying to run AISIDSTAR on a networked, client machine, that works too. Assuming you already have FSX configured for SimConnect networking: 1. Copy SimConnect.cfg and SimConnect.ini files from \My Documents\Flight Simulator X Files to \My Documents\Prepar3D v2 Files 2. Copy the SimConnect.xml from \AppData\Roaming\MicroSoft\FSX to \AppData\Roaming\Lockheed Martin\Prepar3D v2. 3. Install the V2 SDK on the network client machine (not sure this is necessary either). -Roland PS: link to latest version: http://www.mediafire.com/download/ahe4c1ceewzzpfx/AISIDSTAR12P2.zip
November 29, 201312 yr Thanx indeed, I haven't bought V2 yet mainly because of some odd reports on traffic AI. If you run an AI pack, have you noticed any FPS bad hit running AI and your SIDSTAR routine? Riccardo Viecca
November 30, 201312 yr New version: http://www.mediafire.com/download/jnqkwt19948sqnu/AISIDSTAR12P3.zip Fixed: Landing rates too slow when using holding options. I accidentally disabled the target landing rate feature, which measures actual landing rates at each monitored airport and loosens the reigns accordingly. If anyone was noticing the AI were slow to get released from hold onto final, this should fix the problem. Thanks Ronald for the tip, this bug was probably present in old version 1.2N as well. I'm putting out very incremental updates to Ver. 1.2P because I aiming for this version to be the final 1.2 version for FSX. When I stop receiving bug reports, revision "P" is getting uploaded to the library. As I mentioned earlier, Ver. 1.2P is compatible with Prepar3D V2. I'll probably release a specific version for P3D V2 later though because V2 has additional SimConnect features that may prove useful. -Roland
November 30, 201312 yr Just for curiosity sake, people who still use FS9 are crazy for AI traffic since it handles better than FSX. Is there any change to have a version for FS9?
November 30, 201312 yr Just for curiosity sake, people who still use FS9 are crazy for AI traffic since it handles better than FSX. Is there any change to have a version for FS9? I'm a big fan of FS9 and only hesitantly switched to FSX. Unfortunately though, FS9 doesn't have the standard programming interfaces (simconnect) I rely upon in FSX/P3D. -Roland
December 5, 201312 yr Update: I mentioned earlier that I was aiming for 1.2P to be the final 1.x version for FSX. However, I've changed my mind. I'm working on a version 1.2Q. The reason -- my AI control algorithm (with some tweaking) has enough precision to land the AI and taxi them to the gate (even when using an undemanding 1-second sampling rate). Thus, I'm looking into allowing the STAR files to include final approach data, such as for airports with unusual final approach procedures (e.g., DCA river visual approach). Also, FSX sometimes fails to assign AI a landing runway in a timely fashion. In the present version, I have no choice but to let these "runwayless" AI circle the airport. In the new version, I can land these AI immediately. Finally, controlling the AI on final approach provides me more control over spacing, so I'll research into whether the program can better achieve the "string of pearls" effect for high AI densities at busy airports. -Roland
December 5, 201312 yr Roland, Thanks for bringing such a fantastic product to your fellow simmers! Your work is greatly appreciated! I love the idea of allowing the program to control AI all the way to the approach phase, and even allowing them to fly customized approaches such as the river visual into dca as well as the expressway visual into lga. Keep up the great work, and I'm looking forward to seeing the future updates!
December 7, 201312 yr Update: I mentioned earlier that I was aiming for 1.2P to be the final 1.x version for FSX. However, I've changed my mind. I'm working on a version 1.2Q. The reason -- my AI control algorithm (with some tweaking) has enough precision to land the AI and taxi them to the gate (even when using an undemanding 1-second sampling rate). Thus, I'm looking into allowing the STAR files to include final approach data, such as for airports with unusual final approach procedures (e.g., DCA river visual approach). Also, FSX sometimes fails to assign AI a landing runway in a timely fashion. In the present version, I have no choice but to let these "runwayless" AI circle the airport. In the new version, I can land these AI immediately. Finally, controlling the AI on final approach provides me more control over spacing, so I'll research into whether the program can better achieve the "string of pearls" effect for high AI densities at busy airports. -Roland Thanks so much for this. Looking forward to the update.
December 21, 201312 yr Could I have some clarification about how the program chooses SIDs? I'm experimenting with getting this running again, and started with EDDM. Just for tests, I did all the 08L SIDs, and each aircraft uses the exact same SID, even if the destination airport is 180 degrees from the terminal fix. The way I have it set up, every SID file is tied to one and only one runway. So for each sid, there are four files, one for each runway. All the SIDs from a particular runway have the same initial fix, as close to the airport as possible. This is because I don't want the program to consider which SID has the closest entry point (they all take off from the same runway, so they have the same entry point). I only want the program to consider which has the closest terminal fix to the destination. Since they all keep getting vectored on the same SID, something is obviously wrong with this approach. I'm trying to put the initial point as close to the airport as I can- currently it's at 3.5 nm from the geographic center of the airport, but the departing AI keep skipping it and going for the second waypoint in the pattern, and thus probably default to the SID with the closest second waypoint, which seems to be the case. How far away does the first waypoint of the SID need to be from the airport to be valid? Is there a different way to do this runway-by-runway approach? I don't understand why the program even considers which SID has the closest entry, because the ability to assign a file to one and only one runway makes this redundant. thanks
December 22, 201312 yr This is because I don't want the program to consider which SID has the closest entry point (they all take off from the same runway, so they have the same entry point). I only want the program to consider which has the closest terminal fix to the destination. Since they all keep getting vectored on the same SID, something is obviously wrong with this approach. Yes, that seems right (how it is supposed to work) except the entry point for runway specific SIDs should be close to the end of the runway, but still "ahead" of the AI when the AI is obtains about 1000 ft AGL on climbout. but the departing AI keep skipping it and going for the second waypoint in the pattern, and thus probably default to the SID with the closest second waypoint, which seems to be the case. How far away does the first waypoint of the SID need to be from the airport to be valid? That's probably what is happening. The AI won't start looking for a SID until it obtains about 1000 ft AGL. The program places a significant "turn" penalty for any entry points that are behind the AI when it starts looking (essentially, it won't pick any waypoints that are behind it when it starts looking). If there are five SID entry points ahead of it at the same location, it will pick the SID with the exit waypoint closest to the destination airport. Is there a different way to do this runway-by-runway approach? I don't understand why the program even considers which SID has the closest entry, because the ability to assign a file to one and only one runway makes this redundant. I think you're taking the right approach, the problem is with the initial waypoint placement. Take a look at the custom SID files I included for KJFK, where I setup runway specific SIDs for the various noise abatement climbs. The "runways" field is only read for STARs, not SIDs. I kept the runways field in the SID files just to maintain the same format. Before you get too far along, you might want to wait for my Q revision, which I'm almost done with. It lets the user set a lower altitude on climbout to look for a SID. There was also a bug I found that might have affected SID selection. The latest revision also supports final approaches as well. -Roland
Create an account or sign in to comment