A couple questions regarding seaplane-capable AFCADs

[Guest Ruahrc]

I have been working on a set of AFCADs for use with my Ultimate Traffic's Kenmore Air flightplans. Some of the seaplane bases are already done in FS (but not AI-capable) and others I had to make from scratch. I have all of them done now and am in the testing stages... I notice that there is one big problem: at some of my airfields my seaplanes will taxi out to the active "runway" and then just stop.Comparing the location of where they stop and what is present in AFCAD it looks like they pull up to the red hold short node and onto the runway- but never throttle up for takeoff. The MS Traffic SDK's traffic explorer lists these aircraft as still in the "taxi-out" phase but they are sitting on the runway at 0% throttle, not moving. I don't think they are getting "stuck" on anything since their throttle is at 0% (as evidenced by the Traffic SDK's map) but for good measure I moved the start locations away from the runway ends. That didn't seem to help. Either the start locations don't have anything to do with it, or I didn't move them far enough out? If you need more detail just ask or I can send you an example AFCAD so you can check it out.These are my first attempts at seaplane AFCADs so I'm still learning as I go. I looked over the material in Holger Sandmann's AI floatplane download, as well as a few other AI seaplane packages to get a start. But perhaps an obscure trick of seaplane-AFCAD is eluding me?P.S. One last question... I have made a repaint for Kenmore Air's cessna 208B- and wish to upload it to avsim so others can download it (I don't see any other Kenmore air caravans out there). It is my first upload to avsim and so I am unsure of the process? If someone could give me a quick outline of what you have to do that would be great!Ruahrc

[Guest Ruahrc]

Okay silly me I figured out why they never transition to the takeoff state... the AI planes sometimes don't follow the routes as I had planned. The problem is that due to the pushback, the aircraft will follow the "lead-in" routes I drew for incoming traffic and they don't always follow the "lead-out" routes I made for outgoing traffic. The problem was that on the "lead-in" routes I did not place hold-short nodes thinking that outgoing traffic would never use those routes. Therefore they reach the runway without ever reaching a hold-short node, and therefore stall. Looks like I'll need to go back and re-think my AFCADs.That problem solved... I have one other one that truly escapes me. I made afcads for the following airfields: W55 (Kenmore Air Harbor-Lake Union) S60 (Kenmore Air Harbor-Kenmore) and 0W0 (Seattle Seaplanes). These 3 seaplane bases are not at sea level, but rather elevated slightly due to them being on inland water or lakes. When making the AFCAD, I checked the water elevation in FS9 and entered in the correct values. Strangely enough, however, when I went to check my AFCADs out in the sim they were sunken below lake level! I double and triple checked the AFCAD elevations and they are still correct but the airports still are sunken (and mysteriously enough, all 3 airports are being drawn at an elevation of 14ft. It gets wierder too... if a plane spawns parked at the SPB upon loading of the sim... it will display at the sunken 14ft. If, however, I monitor the traffic in the sim for a while and a plane lands at one of these airfields, it will land at the proper level as defined in the AFCAD!?!? The result is that it floats above the water when it reaches its parking spot since the airplane is driving along routes at 25ft whereas the dock is being rendered in the sim sunken down to 14ft.I have no idea on what could be causing this problem? To the best of my knowledge I don't have any flattens operating... unless the default FS9 AFCADs for these seaplane bases are forcing them down to 14ft? I do not get any of these problems at my other seaports which are all at 0ft elevation.Thanks for any advice or help you can give!Ruahrc

[Holger 0]

Hi there,nice to see people working on seaplane AFCAD and AI traffic!Jon Patch and I recently spent quite a bit of time testing various AFCAD configurations and, with the help of some of the AFCAD "tweakers" at PAI, we managed to come up with a very reliable method for floatplanes. For example, it uses the "plumbing" approach to provide fully functioning drive-through parking on docks, which means there will be no pushbacks or incorrect direction of parking seaplanes. Further, take-off direction can be controlled independent of wind direction, which helps on water bodies with steep surrounding mountains. Last but not least, we managed to avoid those ugly pile-ups of departing floatplanes at the hold-short points.Our new version of Victoria, B.C. - vicenh05.zip - includes two of those AFCAD files, CYWH and CAP5, which anyone can "study" as examples of this method. Feel free to ask specific questions about them.As for your question regarding the lake AFCADs: I wonder whether maybe some of the other elevation settings are not correct? Each AFCAD has three places that include altitude, and in most cases these need to be the same: the runway(s), the main airport data window, and the individual start locations. Have you checked that all those are at the desired altitude?Cheers, Holger

[Guest Ruahrc]

Ahh it's Holger to my rescue again! You have helped me numerous times in the past, thanks!I will take a look at those AFCADs in the new scenery. I just got it installed yesterday, after spending over 2 hrs downloading it via 56k! :). I am also happy to see that my AFCADs still align with the coastlines of your scenery. After fixing my AFCADs when I discovered the hold-short issue the planes seemed to move along nicely... but every now and then I would still see the same problem. Or I would see other random "hangs" such as planes hanging up getting clearance, or even one plane hung up during pushback. Unknown what was going on there.Re: the elevation issue, I had been very careful to make sure that all 3 (airfield elevation, runway elevation, and start location elevation) were consistent and correct, but I still see the sunken airports. I think I know what is going on now though... the stock airport for the S60 airfield, for example, has an elevation of 14ft. Exaactly the height that my airports are sunk. I believe it is a flattening issue, where the default airport's flatten is still active so the new AFCAD can't display properly? I remember reading what the (lengthy, if I remember correctly) process was somewhere before but it (and its location) has escaped me. I will try a search but if anyone knows what's needed to re-flatten the airport to proper lake level please let me know?Ruahrc

[jonpatch 1]

Hi Ruarhc,You can find the airport elevation "how-to" at http://www.jonpatch.ca/flightsim/readme_ap1514rw.PDFThat from this thread: http://www.flightsimmer.com/forums/showthr...rport+elevationBut it's best to do all the airports in the entire US portion of the 915140 cell if modifying default files, or life will get very messy. That may be a big project, as I think there are around 70, and there may be a number of incorrect airports. I have published at AVSIM corrections for the Canadian portion of that cell. Only two airports needed elevation modification.Jon

[Guest Ruahrc]

thanks for the guidance Jon and Holger-I had a look at the CYWH and CAP5 AFCADs included in the package. I can see what you guys did but am unsure as to some of the reasoning behind it. It seems easy enough to copy the style to my AFCADs but for a more complete understanding (in the hopes that it will stave of further questions :) ), can you explain what the purpose of the following is?-Usage of "taxiways" on the incoming flow routes vs "apron routes" on the outgoing flow routes-Addition of the water runways (for user-aircraft use only?)-various taxiway/apron route widths (some are 0ft, others 5, yet others 20...)-Hold short nodes at every runway intersection. Just good practice in general or there in case an AI plane takes an unintended route to the active runway?-I noticed at CYWH there are 6 ILS hold short nodes "floating" around unconnected to anything. Mistakenly left behind or there for a reason?So my understanding of making a good seaplane AI base:-Concrete runway of 1ft width for AI usage (required for AI function)-Taxiways on all "incoming" flow paths-Apron routes on all "outgoing" flow paths-hold short hodes at all rwy intersectionsRegarding the flatten issues I was having at the lake-based bases- I read those threads regarding moving and re-flattening airports and it looks like I was able to get off easy for the time being. Since the airfields that concerned me were seaplane bases, the flattens were not offending anything. At least that is my understanding. Whether or not it is due to me working with seaplane bases vs. airfields or the fact that the seaplane bases are out on the water where the default (and supposedly still existing?) flatten can't be noticed?What I ended up doing was taking the same approach Holger used in his CRG scenery. I created a small xml file with entries for each of the 3 seaplane bases I needed. I copied the entries from the decompiled (using NewBGLAnalyze) default AP915150.bgl file, and modified the elevations to their correct values. Then I compiled that into a bgl using BGLComp and placed the resulting file in the SceneryBASEScenery folder. The file had no effect when placed in the Addon SceneryScenery folder and from what I understand that is due to the fact that by the time FS has loaded files in the Addon Scenery folder, it has already loaded the (incorrect) Airport headers from AP915150.bgl. This leveled out the lakes for me, and seems to be a workable solution for a project of limited scope such as mine. The default AP and FL files are not messed with, and only 1 bgl needs to be placed in BASEScenery. If the user is running default mesh with default elevations he/she can simply not install this 1 bgl file. Lastly, if someone (due to time constraints I cannot at the moment tackle the re-flattening of all airports in cell 915150) in the future decides to fix all airports within LOD cell 915150, the bgl can simply be removed because it becomes obsolete.Thanks for your help guys, I will go back and re-do the nodal logic on the AFCADs. Luckily I had been following a very similar parking spot nodal logic as the ones you had (I think I was going off of earlier examples from either Holger or Jon) and so for those parts (IMO the most complicated and tedious) some simple reclassification of existing links is all that will be needed.Ruahrc

[jonpatch 1]

Hi Ruarhc,I'm very happy you're updating these SPBs! Here's a summary that will hopefully answer most of your questions. I'll let Holger address the elevation correction issues and one or two other points.- incoming flow uses 0' wide water taxiways- these taxiways tap off the runway fairly frequently to help clear traffic- outgoing flow uses 1' wide water apron routes (Holger can explain more about this, I believe)- these apron routes connect only at the two ends of the runway- all runway intersections must have H/S nodes or AI will not work properly- the odd ILS nodes at CYWH are harmless markers I used as guides, they are unnecessary- the apron route segment just before a H/S node should be 5' wide to avoid pileups. Otherwise planes will tend to sit on top of each other. To fully stop pileups, 20' wide would be better, BUT you will get a large H/S mark on the water. Holger and I agree that the 5' marker is small enough that it's much less distracting than planes sitting on top of each other- nodal placement at parking spots is very important for a smooth in/out movement: ----- on the incoming path, a node is placed just before the parking spot. Another node is placed before that. These nodes help align the plane with the dock. Further you can see that I've often put another node at an angle before these to smooth the curve a bit----- on the outgoing path, a mode is placed after the parking spot----- the incoming and outgoing paths leading to/from these nodes are at 45 degrees to the parking spot to ease turns- AI traffic works MUCH MUCH better if you have a tower frequency rather than a traffic frequency. This is usually only an issue with a higher traffic volume- for high volume bases (such as CYHC which I am designing) parallel runways help the flow- the separate water runway for user traffic is necessary so that users don't bump on the concrete AI runway- the runway is 1' wide and concreteI am doing a bunch of bases for a payware project, so we should coordinate these if possible: CAE5, CAE7, CAJ8, CAM9, CAS4, CAY7, CAX3 and CYHC so that at least our dock locations match.Jon

[Holger 0]

Hi there,just to add to Jon's points:* the funny apron route/taxiway split is the key element of the plumbing system. I can't take any credit for discovering that and don't really know why the two different link designations make the difference they do. There are a few different approaches discussed in this thread - http://www.flightsimmer.com/forums/showthr...hlight=pushback - I used the first one described by Norman in Post #18.* note that both apron route and taxiway can be set to 0' width but only the taxiway needs to be at 0' because otherwise it becomes visible as a blue line.* don't forget to add a 0-foot wide concrete runway link on top of the runway.* looks like you've got the flattening method figured out. BaseScenery works as a home for the new file but so would Worldscenery or the respective regional subdirectory, e.g., NamwScenery. Just make sure that your elevation correction file has a very descriptive name so that someone who notices it floating around on his HD can relate it to the your project.Looking forward to those reworked floatplane bases!Cheers, Holger

[Guest Ruahrc]

Thanks again Jon and Holger that explains the methodology much more clearly now. I will try re-noding some of these AFCADs and report the results. Those ILS holds must have been from shoreline-tracing? ;) I've certainly done a lot of that recently.I have a random question... now that the taxiways and apron routes are classified as "water", will there not be any bumps and sparks anymore when a user floatplane crosses these paths? But for the concrete AI runway, you will still bump, yes? Has anyone ever tried sinking the AI runway below water level slightly (0.5ft or so) and then adding a user water runway over top of it so user aircraft float over the bumps? I have a theory that if this is done then the user aircraft will not experience any bumps on the water regardless of what they are crossing on the AFCAD. I saw a similar idea being developed in a download from avsim (ai_traffic_lakes.zip) in where the author created a full AI AFCAD at 1.5ft below lake surface level, and then "paved" over the top of it all with a second AFCAD containing only a user water runway at true lake level. But since different elevations can be assigned to different runways within the same AFCAD I thought maybe this technique could be applied without the need for duplicate AFCADs? The whole point of this was because I once flew a floatplane Maule into one of these seabases and I must have been lined up just right with the AI runway because when I hit it (shortly after touchdown = high speed) I crashed. I have also managed to crash my Maule by running over too many apron nodes but the water surface should fix that yes?Re: the flattening issue The solution I found seems to work- I had also thought of implementing a second solution... would an A16N flatten bgl work in this situation as well? The advantage of the A16N is that it could to in the Addon SceneryScenery folder and still work (correct?) but it was more tedious to make because you have to define vertex points for the area of the flatten. When Holger's airport header method worked I called it good but maybe I should go back and use the A16N... although I seem to think Holger's method is a little more elegant.Ruahrc

[jonpatch 1]

Yes, the sunken runway proposal is interesting. All the boat AFCADs for FreeFlow Bermuda are -10 feet or so. Never tried it. Let us know what you find out.Jon

[GHD 21]

> ... and don't really know why the two different link> designations make the difference they do.There is no intrinsic reason for having both types of link, it just makes it easier to see the outgoing/incoming routes in Afcad2 due to the different colours.George

[Holger 0]

Hi George,thanks for preventing me from trying to come up with elaborate theories why they would have to be different! Occam's Razor - "one should make no more assumptions than needed" - wins again ;-) Cheers, Holger

[jonpatch 1]

Thanks for that George, a mystery solved. And let me thank you for you contributions, it's been a great help to me.Jon

[Guest Ruahrc]

Ahh- so it must not be the fact that some are taxi and some are apron, but rather that the "incoming" routes do not connect to the ends of the runways! And therefore force the departing aircraft to take the "pull-forward" route in order to gain access to the runway end. At least that is how my current AFCADs are set up. The only change in nodal logic I made (other than prettier routing) was that I had incoming routes attached to the runway ends as well- in case an aircraft used so much runway it had passed the last exiting node. I guess if that happens now the aircraft will continue on to the end of the runway and take the outgoing routes in. The end result should be pretty close to the same, however, as it will basically result in the seaplane parking the wrong way at the dock.Anyhow I have completed updating all the AFCADs. Now I just have to do some final testing. If anyone would like to recieve the AFCADs to test as well (it would be easiest if you had Ultimate Traffic as I don't know of any other flighplans for Kenmore Air) I could send them to you. So far though they seem to be working fine. Soon I will be ready for upload!BTW my Kenmore Air repaint I submitted for upload today... so hopefully it will show up in the library in the next couple of days.Ruahrc

[jonpatch 1]

Send them along, Ruarhc, thanks.Jon