Mage,
Thanks for the info.
OK, I now have HT's Twotter and BN2 and all FP's are IFR so they do the fake ILS approach. Neither the Twotter or Islander will clear the hill yet. Both are still porpoising on final and both take a dive into the hill and don't come out. The data tags show them as being on the surface somewhere in the hill.
Note that my FP has both flying at 4k from TNCM, although they never get that high before beginning a loooong descent to TFFJ.
Any other thoughts appreciated.
Cheers,
Mike
AI A/C at St. Barths question
- carib_flyer
- Posts: 10
- carib_flyer
- Posts: 10
A little later in the day...
Can I ask a few questions about setting up approaches without having to read the SDK?
I took a look at the barths_approach.bgl file and although there's a lot of data there, I could see where Jim set up the approaches. Looking at the ILS 10 approach and comparing it with the ILS28 approach I see a difference.
In the ILS 10 app, the Runway leg shows a distance of 4816', but no altitude. The ILS 28 approach for the Rwy leg shows 926' distance and 50' altitude. Why is there no altitude for the ILS 10 approach at the runway leg?
Just curious as I would think that therein would lie the distance/alt numbers that might be responsible for the angle of descent to the runway. But heck, I've been know to have been wrong before...
Cheers,
Mike
Can I ask a few questions about setting up approaches without having to read the SDK?
I took a look at the barths_approach.bgl file and although there's a lot of data there, I could see where Jim set up the approaches. Looking at the ILS 10 approach and comparing it with the ILS28 approach I see a difference.
In the ILS 10 app, the Runway leg shows a distance of 4816', but no altitude. The ILS 28 approach for the Rwy leg shows 926' distance and 50' altitude. Why is there no altitude for the ILS 10 approach at the runway leg?
Just curious as I would think that therein would lie the distance/alt numbers that might be responsible for the angle of descent to the runway. But heck, I've been know to have been wrong before...
Cheers,
Mike
Mike
It is not really that simple but I wished it was.
Those numbers you are looking at have no effect on AI landing behavior.
I was not very precise in the code that is not used for anything because those are fake ILS to begin with.
Those numbers are only for display when using the GPS receivers data list during LOAD and ACTIVATE.
Many element tags in the approach code have no meaning but are needed for the compiler to work. Approach codes are actually written for the User Airplanes GPS receiver then the ATC dll files pull out what is needed for the AI approach.
There is a balance point between how the approach code is written in certain element tag areas vs what the dll's use for AI Planes. All of this stems on the fact of how the FD's are written for each model.
There is no standard amoung all the model designers out there. Most just tweak their model to fly based on a visual of the plane taking off and landing.
Based on your post it still appears that you are having problems that some of us do not see using the same models. When adding the HTAI models you need to make sure that the Model.mdl, .air file and the aircraft.cfg all match correctly and are for the model you downloaded. Do not mix and match any of these 3 files with other models.
It is not really that simple but I wished it was.
Those numbers you are looking at have no effect on AI landing behavior.
I was not very precise in the code that is not used for anything because those are fake ILS to begin with.
Those numbers are only for display when using the GPS receivers data list during LOAD and ACTIVATE.
Many element tags in the approach code have no meaning but are needed for the compiler to work. Approach codes are actually written for the User Airplanes GPS receiver then the ATC dll files pull out what is needed for the AI approach.
There is a balance point between how the approach code is written in certain element tag areas vs what the dll's use for AI Planes. All of this stems on the fact of how the FD's are written for each model.
There is no standard amoung all the model designers out there. Most just tweak their model to fly based on a visual of the plane taking off and landing.
Based on your post it still appears that you are having problems that some of us do not see using the same models. When adding the HTAI models you need to make sure that the Model.mdl, .air file and the aircraft.cfg all match correctly and are for the model you downloaded. Do not mix and match any of these 3 files with other models.
- carib_flyer
- Posts: 10
Jim,
Awww.....here I thought I was getting the handle on this stuff. Guess I'll have to break down and read the SDK. But thanks...I do understand what you explained about the ATC etc. now.
As for the AI aircraft, I used HT's Twotter just as it came out of the box except for replacing his "blank" texture file with a new one. I'm going to try one more change to the AI FP and see what happens.
Thanks for all your help, it's been very enlightening.
Cheers,
Mike
Awww.....here I thought I was getting the handle on this stuff. Guess I'll have to break down and read the SDK. But thanks...I do understand what you explained about the ATC etc. now.
As for the AI aircraft, I used HT's Twotter just as it came out of the box except for replacing his "blank" texture file with a new one. I'm going to try one more change to the AI FP and see what happens.
Thanks for all your help, it's been very enlightening.
Cheers,
Mike
I looked on PAI for some information - there were lots of discussions there a while back about exactly this sort of thing. I already use a curved approach written by one of the guys there, for Washington Reagan (it emulates the river visual). This is based on Jim's work. The same guy wrote an approach for an airport in Canada and there were some more explanations there.
The author tries to explain the process, after a fashion, and it is obviously fairly complex to get right because the AI don't concern themselves with all the finer points of a carefully-written approach unless they follow something more complex like a GPS approach. The trouble is that to make planes approach a certain specialized way in good weather requires an ILS, and as Jim said in another post here, a GPS approach cuts in for flights only when the vis drops below 3 miles. In the Caribbean you get that sort of visibility only really in torrential rain. A fairly typical hazy day there puts the vis about 12-15 miles, so a GPS approach will almost never get used in that region in FS, but an ILS will. If there's and approach coded (even without an ILS at the airport) AI flying under IFR will use it. The "gotcha" is that AI will not follow the full procedure, they get vectored to the final approach track and they then take over the descent to the runway for themselves. All Jim's or this other guys approaches could do was put the plane into a position where it can reach the runway in a particular way. The AI blindly follows the ILS path down to where it thinks the runway is, and if the author of the approach has angled that track to the runway, the AI spots this and makes a final turn off the ILS track and to the runway. I think I have that right.
Since the AI flies in okay for most of us, I can only echo Jim's sentiments and look hard at the aircraft CFGs (they're hard enough, but simpler than the approaches). The fact that the aircraft are oscillating down their final approach path sounds like some drag or power value needs adjustment, my default HTAI Islanders and Twotters motor down final approach with those things obviously in balance.
http://www.htaimodels.com/downloads.html has the original models as you're probably well aware.
The author tries to explain the process, after a fashion, and it is obviously fairly complex to get right because the AI don't concern themselves with all the finer points of a carefully-written approach unless they follow something more complex like a GPS approach. The trouble is that to make planes approach a certain specialized way in good weather requires an ILS, and as Jim said in another post here, a GPS approach cuts in for flights only when the vis drops below 3 miles. In the Caribbean you get that sort of visibility only really in torrential rain. A fairly typical hazy day there puts the vis about 12-15 miles, so a GPS approach will almost never get used in that region in FS, but an ILS will. If there's and approach coded (even without an ILS at the airport) AI flying under IFR will use it. The "gotcha" is that AI will not follow the full procedure, they get vectored to the final approach track and they then take over the descent to the runway for themselves. All Jim's or this other guys approaches could do was put the plane into a position where it can reach the runway in a particular way. The AI blindly follows the ILS path down to where it thinks the runway is, and if the author of the approach has angled that track to the runway, the AI spots this and makes a final turn off the ILS track and to the runway. I think I have that right.
Since the AI flies in okay for most of us, I can only echo Jim's sentiments and look hard at the aircraft CFGs (they're hard enough, but simpler than the approaches). The fact that the aircraft are oscillating down their final approach path sounds like some drag or power value needs adjustment, my default HTAI Islanders and Twotters motor down final approach with those things obviously in balance.
http://www.htaimodels.com/downloads.html has the original models as you're probably well aware.
- carib_flyer
- Posts: 10
Mage,
Even though your response isn't solving my problem, it is really interesting reading about AI ops. Something I never really understood, but have a better handle on now since you guys have been responding. Thanks again.
Another question about the ILS approaches.
You mention that once the AI a/c is on the supposed glidepath, it will then follow what it thinks is the correct angle of descent to put it on the runway. Does it get this runway end location from the designed approach or does it get it from FS, like in the AFCAD? If it gets it from designed approach, would it be possible to change that location to further down the runway and perhaps adjust the braking effect in the a/c cfg file?
Cheers,
Mike
Even though your response isn't solving my problem, it is really interesting reading about AI ops. Something I never really understood, but have a better handle on now since you guys have been responding. Thanks again.
Another question about the ILS approaches.
You mention that once the AI a/c is on the supposed glidepath, it will then follow what it thinks is the correct angle of descent to put it on the runway. Does it get this runway end location from the designed approach or does it get it from FS, like in the AFCAD? If it gets it from designed approach, would it be possible to change that location to further down the runway and perhaps adjust the braking effect in the a/c cfg file?
Cheers,
Mike
Mike
Each runway end has a hard code that the AI Plane targets for touchdown. It is normally the aiming point bars if that box is checked in runway markings using AFCAD.
When designing the approach code I turn the aiming bars on to get a visual of the target touchdown point. Even if the bars are off or not on a runway the dll file still targets this point on the runway.
TFFJ also has a displaced threshold which also is used for clearing the hill. At this point I move the runway toward the water and tweak the displaced threshold to give me a good touchdown point. However that was not enough with TFFJ so I had to evaluate the seperation points for the turn to final.
The object is to hold the AI Plane high until inside the SUCRE waypoint before allowing the dll to command a descent. This will cause a steeper descent then normal and hopfully the AI Plane will clear the hill. However that also depends on how the FD's are written by the modler. Some models that are not written for short field landings have a flatter descent profile and cannot maintain a high altitude close in to the runway. Some FD's do have the ability to hold 1200 ft inside SUCRE before starting a 1500 FPM descent like the DO228.
Approach speed also plays a part based on reaction time of when the descent starts. This is seen as the desired vs the actual when using Traffic Toolbox which is by the way the tool I use for writting the approach. The faster the approach speed the slower the reation time which is what gives the DO228 the edge over the other AI Planes that Approach at a slower speed.
So yes you can move a runway but I already did that and you can tweak the displaced threshold to move the target touchdown point further away from the hill. Have some good brakes but that is not the requirment for turbo props. Turbo Props must be in full beta prop pitch before the brakes are applied. This again is up to the FD modler to tweak so the AI Plane has the ability to stop very quickly.
The point we don't have control of the AI Plane in writting approach code is when the AI Plane starts the descent and the profile it uses on the descent. As previously said we can hold the AI Plane high and target the touchdown point but it once again relies on a true set of FD's for the type plane making the approach.
One other area to check is the FPS of FS9 when the AI plane is on the approach. If your FPS (Shift+Z) is down low the AI studders on the descent and causes a less then smooth profile.
Each runway end has a hard code that the AI Plane targets for touchdown. It is normally the aiming point bars if that box is checked in runway markings using AFCAD.
When designing the approach code I turn the aiming bars on to get a visual of the target touchdown point. Even if the bars are off or not on a runway the dll file still targets this point on the runway.
TFFJ also has a displaced threshold which also is used for clearing the hill. At this point I move the runway toward the water and tweak the displaced threshold to give me a good touchdown point. However that was not enough with TFFJ so I had to evaluate the seperation points for the turn to final.
The object is to hold the AI Plane high until inside the SUCRE waypoint before allowing the dll to command a descent. This will cause a steeper descent then normal and hopfully the AI Plane will clear the hill. However that also depends on how the FD's are written by the modler. Some models that are not written for short field landings have a flatter descent profile and cannot maintain a high altitude close in to the runway. Some FD's do have the ability to hold 1200 ft inside SUCRE before starting a 1500 FPM descent like the DO228.
Approach speed also plays a part based on reaction time of when the descent starts. This is seen as the desired vs the actual when using Traffic Toolbox which is by the way the tool I use for writting the approach. The faster the approach speed the slower the reation time which is what gives the DO228 the edge over the other AI Planes that Approach at a slower speed.
So yes you can move a runway but I already did that and you can tweak the displaced threshold to move the target touchdown point further away from the hill. Have some good brakes but that is not the requirment for turbo props. Turbo Props must be in full beta prop pitch before the brakes are applied. This again is up to the FD modler to tweak so the AI Plane has the ability to stop very quickly.
The point we don't have control of the AI Plane in writting approach code is when the AI Plane starts the descent and the profile it uses on the descent. As previously said we can hold the AI Plane high and target the touchdown point but it once again relies on a true set of FD's for the type plane making the approach.
One other area to check is the FPS of FS9 when the AI plane is on the approach. If your FPS (Shift+Z) is down low the AI studders on the descent and causes a less then smooth profile.
I believe the turning radius is a value listed in the contact point settings. Those are in the aircraft.cfg.
Open one of FS default planes and it will give you a listing of what contact does what. The SDk also gives a list.
Some of the large planes have main gear turning contacts also besides the front steering gear.
Open one of FS default planes and it will give you a listing of what contact does what. The SDk also gives a list.
Some of the large planes have main gear turning contacts also besides the front steering gear.
I will look through the .air but I never remember seeing it there. I have a feeling it is in the model.mdl.
The one in the .cfg must be User only.
The good news is I have the BN2 clearing the hill and coming to a stop before the end of the runway by tweaking the FD's.
The biggest effect is to just increase the cruise speed by 20 or 30 knots. I used the DHC6 speeds as a test. Also changed the flap settings based on the DO228. I am going to post what few things everyone can change that makes the difference.
After landing they make a wide right turn which is probably what you are trying to stop.
The one in the .cfg must be User only.
The good news is I have the BN2 clearing the hill and coming to a stop before the end of the runway by tweaking the FD's.
The biggest effect is to just increase the cruise speed by 20 or 30 knots. I used the DHC6 speeds as a test. Also changed the flap settings based on the DO228. I am going to post what few things everyone can change that makes the difference.
After landing they make a wide right turn which is probably what you are trying to stop.
