itch.io

Thanks for your message!

Indeed, it's better to use "transitionaltitude" now. In earlier versions of the game, when variable pressure was not a thing, I choose the name "transitionlevel" (removed) or "transition" (now interpreted as transition altitude). Removing "transitionlevel" was a mistake, I'll add it back for better compatibility with older files.

As for the transition level (or lowest usable level), that's currently calculated the same way for all locations, even though in reality it differs per country. The level is set at least 1000 feet higher than the transition altitude, in steps of 500 feet. This avoids conflicts between altitude/FL.

Also, I recently noted that FAA documents say that already at 18000 feet standard pressure should be used. If I read this correctly, this means "transitionaltitude"=18000 should mean FL180 is the lowest level at high pressures. Perhaps I will adjust this for "usa"=True airports in the future, as well as increasing the step size from 500 to 1000 feet.

The range for 'descent rate' is 300 to 6000 fpm. It determines the maximum rate the plane type can attain during a descent (although it will descend faster when 'expediting'). So a setting of 300 to 500 fpm should work fine; lower values will be constrained to 300.

The 'descentaltitude' is indeed the same for all plane types. The idea is that it avoids conflicts with lower planes, keeping the gameplay more simple. For the default airports, the descentaltitude is set below 10.000 so it's not really an issue there. To work around this game limitation, you could perhaps keep the descentaltitude below 10.000, but also add a (higher) custom altitude to the 'entrypoints'. Light aircraft will still be constained by the descentaltitude, while other aircraft enter higher.

I hope this helps, thanks for the feedback!

Hi! Thanks for sharing your thoughts and suggestions.

The two player mode you described is something I've never considered but it's an interesting idea. But indeed, adding true multiplayer at this stage seems unfeasible.

Regarding streaming a window to player 2 without showing the inputs of player 1, a workaround comes to mind which might already work: player 1 types TIMELAPSE01 to save an image every second into the img/ folder. Player 2 uses IrfanView to automatically view the lastest image in that folder (the option is called Hotfolder). This creates basically a second screen although it requires some extra steps and cleanup afterwards.

The scenario mode could be used to create a game that can be rewinded/restarted with the same planes/callsigns in each run. The event list allows for specifying the callsign and plane type. In this case, self-made flight strips could be used.

Hi. Perhaps writing the planetypes in lower case fixes it. But it's hard to know what causes the issue without seeing the actual file. If you have Discord you could probably get more help from other content creators there. Good luck.

Hi, press the Ctrl key to show the coordinates of the mouse cursor. Deviations can occur if runway heading are given as magnetic instead of true headings. Best practice is to use true headings, and specify a 'magneticvar' which automatically rotates the true headings (and latlong positions).

Thanks for the list. Next update will have a custom speed restriction level, to allow for higher speeds above a certain level. Also looking into adding custom atc naming/frequencies to allow for more realistic handoff readbacks.

Also see the example.txt, which has an [area1] with 'name = SC' property, located around the secondary SC airport. Traffic in/outbound SC can enter that area without incident. Also make sure the [area] section has a unique number.

Yes, because the plane is slightly above the glideslope, it tries to capture the glideslope by increasing its vertical speed, although it makes no sense to do so at this stage of an approach route. Good catch, I will correct it in the next release.

Hello Cesar,

Have you tried giving the area a 'name' similar to the two-letter code of the airport? If the names match, then no conflict should happen (see for example the default EHAM airport, which has an 'RD' area only allowed for planes from/to the 'RD' airport). Let me know if this doesn't solve the issue.

Hi. I noticed this too, but I didn't change the speech rate so I think google broke something when they updated their TTS engine. Uninstalling the google TSS updates in the Play store fixes the issue as a workaround, and hopefully they'll fix it with a new update.

You're welcome. I agree with most points of the list actually, although some are just not a high priority due to added complexity in gameplay or development. Current thoughts:

(2) If an inbound plane has a speed of over 250KT, the speed can be maintained by doubleclicking between the speed +/- buttons. I'll have the check if increasing the speed upper limit has implications on other aspects (like automated speed adjustments) of the game. If the player forgets to reduce speed, planes will go around. (6) I'm not sure what exactly the use is for planes heading for a waypoint just 3 miles or less away, as it will be reached in no-time. (7) I may add specific descendaltitudes per spawn point. Currently all planes descend to the same altitude mainly because it's predictable to the player; lowering planes 1000 feet will clear them of conflict with any other inbound plane near the boundaries. Only recently, specific inbound beacons were added, so perhaps specific altitudes could also be an option. (9) It sounds complicated, especially the 7NM will surprise users. (10) The game is designed with the idea that departures would climb above the entering arrivals, therefore the arrivals enter at or slightly above the descendaltitude and are thus clear of outbound traffic. I also think that creating much larger airspaces than anticipated (default airports extend to only 30 to 40NM) increases the occurance of early levelling off. (16) & (18) Neat but minor details.

Hi! Thanks for creating the airport file. The altitude bug will be fixed in the next update; it was related to the (rather high) elevation of this field has.

Hi! It's not possible to edit the accel and decel separately, but I'll limit the decel rate for airborn planes as a workaround. I will also remove the speed reduction after handoff. Supersonic planes were not taken into consideration when developing the game, but it's a nice idea that, after some adjustments, planes like the Concorde can be simulated.

Thanks for the (huge) suggestion list! While preparing the next update (which will be released soon) I've read through the list and I've already implemented a few points (1, 13, 15, 17). 

Notes on other suggestions: (2) this is possible by overriding planetype properties but, as the game takes place in the vicinity of an aiport, most planes are below FL100 already so 250KT is the default limit; (4) for now I'll add a general 'localizerspeed' item for customization; (6) the distance will be reduced from 6 to 4 miles for more convenient waypoint selection; (11) type 'fail000' to disable emergencies; (12) is possible but only by using keyboard commands.

Some other points seem easy to add, but may add much complexity, whether for the game mechanics itself, the airport developer or the player. It's a tricky balance between: how much time to sink into creating every little detail, versus the simplicity that makes the game easy to learn and most importantly: fun to play. The feedback however is appreciated and I will keep all suggestions in mind for future improvements.

Thanks for the report! I made some adjustments to allow handoffs even if the plane is not yet on the loc (in case  it's on an approach route that intercepts the loc very late). But these adjustments apparently cause crashes, so I'll update it soon.

Thanks for the suggestions. I'll think about it, while keeping in mind that I don't want the game to become (too) complex. The routes are just an extra option besides the usual vectors, therefore I kept the routes in a simplified form like most other features in the sim really. The file format could have been more consistent in hindsight, but it's not worth changing it.

The game can be played with just mouse and keyboard commands; see the manual.pdf for all available commands. The distance from a selected plane to the mouse position is displayed at the bottom of the screen.

Hi ycohui, thanks for your contribution and suggestions.

The HOLD to APP option is a good point, I'll add that to the next update.

I'll also look into reducing the distance/altitude limits for intercepting the ILS from approach routes. It's a slightly more complicated  thing as it requires some changes to handoff, minumum altitude and go-around behavior.

I've just released a new version, which fixes the first part of the issues you described. Thanks for including the examples.
And I'll keep in mind the other suggestions for future updates.

That's right. I just released another small update to fix some issues with the custom airports. When things work as expected, I'll update the android version as well in a few days (updates to the Play store take a bit more time, and too frequent updates may bother users).

Thanks for the report and example! Looking into it, I've found some issues happening when loading certain combinations of departure routes, causing incorrect lists of waypoints. I'll release a new version very soon.

The update is available now, with departure routes, plus some other improvements to make more detailed/complex airspaces.

Hello, sounds good although I'm not a discord user myself. There may have been others creating a server as well (for example here). Multiplayer seems unlikely to be added honestly, but thanks for the input!

Hi Luke,

Yes, departure routes are to be added in the next update. Similar to the already available approach routes, the new SID routes will be runway direction specific. The update is almost ready and I will release it very soon.

And thanks for your airport contribution!

In todays update this issue is fixed. Thanks for the report!

In the latest version, the game shows a message (just after loading the airport; at the top of the screen) if there are undefined plane types in the airlinelist(s).

Path looks correct. Did you change #code = exam line into code = exam, to make the airport appear at the bottom of the airport menu? Also, rename the filename to make sure it isn't overwritten.

Looks good, Adam! Thanks for you work on creating the repository.

Hi!

• The altitudes have to be within a certain range. If the ceiling would be very high, then departures will likely incorrectly 'divert' at the boundary instead of flying through the ceiling. Looks like in your case the ceiling was lowered to FL140 automatically. Perhaps some limits could be adjusted, however more divergent values than those used in built-in airports may skew the game mechanics.
• The 'above' property is just the highest altitude you can select for departures only, being somewhere above the 'ceiling' value. For example at EHAM it is set at FL130. I'll try to improve the sketchy explanations :)

Thank you! Indeed it would be nice if there was a place to easily upload or download custom files. I haven't really looked into ways hosting things myself yet, but I'll gladly post links to community work to give them visiblilty. 

Ok, bad luck I guess; for others it works fine. Could you send me an email?

Thanks. Do you still have this issue?