Airports

Basically, the use of the airfields downloaded from FSCloudPort works if the tsc-file with the airfield code is copied and given the extension .wad.

There are special features to note because the files are only conditionally FS4-compatible:

(1) FS4 does not show positions (parking, takeoff, landing).

(2) For some airfields FS4 already has a better automatic object generation than the airfields of FSCloudPort.

(3) Sometimes the coordinates of FSCloudPort do not match those of FS4 (example: "Amiraute Heliport (LF006)".

(4) Sometimes FS4 does not adopt the orientations of the objects (example: "Ouessant (LFEC)" for the runway).

(5) Sometimes the ICAO codes do not fit (example: "Alternative version of LFEC with more 3D objects (LFEX)").

The above-mentioned special features (4) and (5) show that usually only a few steps are necessary for adaptation:

• If the ICAO designation is correct (see (4)), only the file LFEC.wad has to be supplemented by copying LFEC.tsc and renaming the copy.
• If the ICAO designation is not correct (see (5)), the file LFEX.tsc must first be renamed to LFEC.tsc and then the file LFEC.wad must be added by copying LFEC.tsc and renaming the copy.
• Then only the artificial runway may interfere, the display of which can most easily be done by renaming the file "rap...m..m_rwy.tmb" by adding e.g. "___OFF" - but for that in the log to an error. It is better to deactivate the call of the runway in the file LFEC.tsc by adding "//" at the beginning of the line.

This is how LFEC - formerly LFEX - looks in FS2 and in FS4:

Quote from ApfelFlieger

Basically, the use of the airfields downloaded from FSCloudPort works if the tsc-file with the airfield code is copied and given the extension .wad.

There are special features to note because the files are only conditionally FS4-compatible:

(1) FS4 does not show positions (parking, takeoff, landing).

(2) For some airfields FS4 already has a better automatic object generation than the airfields of FSCloudPort.

(3) Sometimes the coordinates of FSCloudPort do not match those of FS4 (example: "Amiraute Heliport (LF006)".

(4) Sometimes FS4 does not adopt the orientations of the objects (example: "Ouessant (LFEC)" for the runway).

(5) Sometimes the ICAO codes do not fit (example: "Alternative version of LFEC with more 3D objects (LFEX)").

The above-mentioned special features (4) and (5) show that usually only a few steps are necessary for adaptation:

If the ICAO designation is correct (see (4)), only the file LFEC.wad has to be supplemented by copying LFEC.tsc and renaming the copy.
If the ICAO designation is not correct (see (5)), the file LFEX.tsc must first be renamed to LFEC.tsc and then the file LFEC.wad must be added by copying LFEC.tsc and renaming the copy.
Then only the artificial runway may interfere, the display of which can most easily be done by renaming the file "rap...m..m_rwy.tmb" by adding e.g. "___OFF" - but for that in the log to an error. It is better to deactivate the call of the runway in the file LFEC.tsc by adding "//" at the beginning of the line.

This is how LFEC - formerly LFEX - looks in FS2 and in FS4:

Display More

I think these instructions only work for airports that already exist in Aerofly FS 4. I tried this with KUDD which is not in Aerofly FS 2 or Aerofly FS 4 and while the KUDD control tower and building objects appeared in Aerofly FS 4, the actual runway and taxi areas did not.

https://www.fscloudport.com/icao/KUDD.htm

Before (no cloudport KUDD installed)

After (required both KUDD.tsc and KUDD.wad, did not work with just KUDD.wad file defined)

Because the new Aerofly FS 4 airport .toc, .tsc and .wad files are binary format files rather than Aerofly FS 2 toc and tsc which were text format files I am not sure how this is even supposed to work. Also, why did IPACS switch to a binary format which is going to take a special software tool to generate rather than sticking with text format files. This just makes it even less likely to encourage people to bother with making scenery for Aerofly fs 4. Even Laminar Research got smart and switched from binary to text format aircraft definition files during the mid-life point for its X-Plane 10. You want to make it easier for others to make addons for your simulator (both free and commercial payware) if you hope to have a big user base for your game. An if you are going to require a special tool than you should have it ready to go before you even release the game.

Quote from jayeye2011

You want to make it easier for others to make addons for your simulator (both free and commercial payware) if you hope to have a big user base for your game.

Yes, hasn't IPACS said they will give us the tools we need to make airports, etc.? Or is there something I may have misunderstood?

Quote from Hartman

Yes, hasn't IPACS said they will give us the tools we need to make airports, etc.? Or is there something I may have misunderstood?

Yes, Jet-Pack (IPACS) did say that. My point is it should have been ready for release when Aerofly FS 4 version 1.0 was released back in July 4, 2022. 5 Months later (or is it 6) it's still not done and maybe even more critical than the Aircraft SDK was since more people donated free airports for FS 2 than airplanes.

Post

RE: Activate the ICAO airfields already stored in the FS4 database

Empty TSCs can cause all kinds of issues down the road. Then Aerofly doesn't know how to load this "thing" what ever it is. It's neither airport nor building, it's undefined and causes undefined behavior and potentially crashes later on.

The Aerofly FS airport database contains most airports around the world but only the base data such as name, ICAO, IATA codes and up to 4 runways. This database is used to look up the location of an airport so that the airport TSC does not need to be loaded at…

Jet-Pack (IPACS)

Aug 31st 2022

Quote from jayeye2011

I think these instructions only work for airports that already exist in Aerofly FS 4. I tried this with KUDD which is not in Aerofly FS 2 or Aerofly FS 4 and while the KUDD control tower and building objects appeared in Aerofly FS 4, the actual runway and taxi areas did not.

https://www.fscloudport.com/icao/KUDD.htm

Before (no cloudport KUDD installed)

After (required both KUDD.tsc and KUDD.wad, did not work with just KUDD.wad file defined)

Display More

In both FS2 and FS4, data for the KUDD aerodrome is already available in the background.

With FS4, the data for LOCATION and NAVIGATION can be activated with a trick: All that is needed is a folder with the ICAO code for the aerodrome and the two files .tsc and .wad (see example file KUDD__EMPTY.zip). I called them Empty because the code in both files only looks like this:

<[file][][]>

Note:

- These airfields can also be read by FS2, but are then only displayed with "none" due to lack of content.

- IPACS also pointed out in an earlier post of mine that these files can lead to errors if there is an additional folder for the same airfield that contains identically named files. This is true!

Back to the example of KUDD, for which I now show three variants:

(1) This is how it looks to me when FS4 has no additional files to KUDD:

(2) This is what it looks like when I import the KUDD data from FSCloudPort into FS4. Positive for me is the tower (GREEN), neutral I find the two tanks (YELLOW) and negative I find the wrong orientation of the artificial runway (RED):

(3) Since I would like to have the tower and not the artificial runways, I have adapted the KUDD.tsc. Since some object is needed to function, I added a heliport (BLUE) north of the tower. The FSCloudPort download as a basis has now become this zip file "kudd__bermuda_dunes__airport.zip":

I am and remain an optimist and assume that we will be able to bring in even better and more additions from the community in the near future.

In the last few days I've been looking more into the online tool FSCloudPort again and found for me that it is also much better suited for FS4 than I previously thought.

In the beginning, FSCloudPort saved the individual objects (e.g. buildings, equipment, vehicles, stationary aircraft, etc.) for each airfield individually as a file and then displayed them with position and orientation via the tsc file.

At some point there was a change. Since then, apart from the runways, no objects are stored as a file, but a toc file retrieves the objects from IPACS' own xref database and places them in position and orientation. And this works in FS4 exactly the same way as in FS2.

Since I also already preferred to do without the artificial runways for me in the past, I actually don't miss anything in the comparison of FS2 and FS4 when using FSCloudPort files. In the tsc file, in addition to the general information, which has also become less in the meantime, there are actually only the runway data and the call of the toc file.

Therefore I use now FSCloudPort both for FS2 and FS4, because with me FS accesses my FS4 user directory.

Here is an informative aerial photo of KUDD

Source: https://flyingcalifornia.files…m/2012/01/picture-081.jpg

KUDD does not have a control tower and the fuel tanks are near runway 10.

I will hope this airport eventually gets updated for FS4 because I prefer to have a runway object defined because the base terrain mesh irregularities can make for a rough landing.

And that tree on runway 28 is odd, I guess you will need the FS4 Airport SDK to define an exclusion zone .

The tower can be hidden by deleting these lines in the KUDD.toc (after that, the two remaining elements should be changed from "1" to "0" and from "2" to "1".):

    <[xref][element][0]
        <[string8][name][tower00_medium_blue_ds_05_08_08]>
        <[vector3_float64][position][-116.27292663 33.74627794 0]>
        <[float32][direction][0]>
    >

The two tanks at the beginning of runway 10 fit, in my opinion.

Unfortunately I don't have a quick solution regarding the tree on runway 28 and the levelling of the airfield .

Quote from ApfelFlieger

I don't have a quick solution regarding the tree on runway 28 .

Quote from admin

We will soon offer for a limited amount of testers our new Aerofly FS 4 airport creation tool. This greatly simplifies adding airports to FS 4. We will publish details once this tool is available.

For the transitional period, I have a suggestion that may be feasible on the part of IPACS in the very short term.

In my experience, this information leads to the messages ERROR or WARNING in the tm.log:

• In tsc-files in the section "General information":
  - <[string8][type][]>
  - <[float64][size][]>
  - <[float64][tower_height][]>
  => This can be quickly commented out or deleted by hand, or omitted when re-setting.
  
• In tsc-files in the section "list_tmsimulator_scenery_object":
  - <[float64][orientation][]> (for the individual elements)
  - <[list_tmsimulator_view_position][view_positions][]>
  => This can be quickly commented out or deleted by hand, or omitted when re-setting.
  
• As well as in the toc-files:
  - <[list_vegetation_map_exclusion_zone][vegetation_map_exclusion_zone_list][]>
  => This can be quickly commented out or deleted by hand, or omitted when re-setting.

Editing these points by hand is a "klax", as they say in German.

Because of the missing input option for orientations of objects, these must "only" already exist in the correct position in the orientation 0°. This is feasible, as @flying_fs shows with the example of OOSM (Muscat).

What is still missing is the functioning of the

• positions for
  - PARKING and HELIPORTS
  - START
  - LANDING
  => Here it is sufficient (for me) for the first, if IPACS simply announces the text elements necessary in FS4, as this must now be written with a text editor in the tsc files.

Long story short:

Before we wait any longer for the perfect automatic solution with aSDK, a manual solution would suffice here and now, so that things can simply continue for FS4.💡