him225

Also they really need to remove the moon illusion effect, size variation of sun and moon and nearing horizons becomes huge, makes it feel like in a fantasy role playing game. The dawn/dusk light amount and change rate also needs to be fixed, while the sun sets/rises at the correct times, the light quantity drop/increase from sun hiding behind horizon is pretty fast kind of like a light bulb turning on/off making day light shorter by about 30 minutes in both. In real world and also in FSX - p3dv4 some light is present when the sun is just below horizon.

Putting 0,1,2 also gave improvement here. Seems the other two working threads also need to be away from interference of terrain loading cores and rather be shares on single core as the terrain loaders are quite aggressive and fluctuating in their xpu demand. The default value 2 and 4 has them share one core each with the terrain jobs, but LM did not give entry to core distribitution of terrain jobs for complete control leaving users to achieve above indirectly that much reduces the optimum AM possibilities.

I agree getting off runway tarmac should be the best check for runway vacation for both arriving and departing AI, but sometimes AI making a U turn also trigger the same which would also need addressing. That criteria is true for smaller airports or in normal density operations yes, but at larger busier airports it is now not uncommon to have next takeoffs being cleared earlier or on lift off, at EGLL for instance. The option may be specifically enable for busy airports.

Not a good idea as it is highly variable how much time a landed AI will stroll on the runway before vacating depending on the model and taxiway layout, if this takes too long then the lined up AI will cause go around to an incoming landing due to just sitting and not leaving the runway before the landing AI comes near. The current method of triggering a fast rolling takeoff just after landing runway vacation along with the check for minimum distance of incoming landing is more reliable. Better way to make takeoffs clear faster instead and take better advantage of fast rolling takeoff feature would be to force next takeoff clearance as soon as preceding departure lifts off the runway, as currently the AI still wait lined up till preceding departure reaches a certain height causing a delay and greatly limiting the instances where benefit of the fast takeoff ability is possible.

The assigning of parallel runways exclusively for take off and landing can be done via editing the afcad to solve the mentioned KJFK problem I think. But it would be interesting if the tool can allow for assigning of specific landing runways based on parking codes, parking types etc when multiple landing runways are available, since default atc assigns landing rwy based on position of descending aircraft, depending on geographic location of certain airports that can lead to crowding of one runway while the other doesnt get many landings assigned to it. This can also be useful where airlines use certain terminals close to certain runways in real life thus avoiding many taxiing conflicts, and where traffic density exceeds single landing runway capacity.

In using multiple runways, how about distribution based on parking types and codes?

Does the thrust work with mouse wheel too or does it always require a hardware throttle like the AS A320 does?

No I meant updated model as in AI model from a different developer for the same aircraft. For UT2 would only require reassignment of repaint on existing addon schedule if everything work normal. But didn't go well when I changed existing repaint assignments to the new AI model.

I recalled why the problem with 787s happened. I had initially assigned them to camsim model after I created the schedule, then I decided to change all 789s to new fspainter model and reassigned them in UT2. So both problems happened after I updated the aircraft model. Probably not reliable to change repaint assignments then on an existing schedule.

I am using mix of default and new models/repaints some of which I added when last I created the addon schedule. I too was doing update of VIR and BAW for their 787s, rest all aircraft were already existing. The BAW 787 although appeared at heathrow did not appear at an airport until I removed and reassigned it in UT2. I also updated cathay cargo 744f to the faib models from aia in an existing addon schedule. The faib PW variant had two liveries, although I added both set to unlimited after removing the aia one, only one of them appeared until I removed and reassigned the missing one again to the list after which it began to show up.

Could anyone explain how they replace an old addon schedule with a new one for an airline in UT2? Until now I just removed the old db file before I finalize the new one in power pack. After that opening in UT2 most repaints from the previous set are still recognized and I just add the missing ones. But I realized that aircraft of some liveries and some legs fail to appear after this, if I remove and add them again in UT2 they work again. If it is the correct way then it would seem to have all repaints and legs work properly after replacing a schedule every aircraft in the list must be removed and added again.

or to google the current local time of the startup location is how I presently workaround it. The startup screen seem broke with the time thing. It does not change to the time offset of a new selected location either as seen by toggling the GMT checkbox.

ok, unticking that checkbox at the bottom of change location window got it back to normal. Easy to miss that setting. Is there a similar setting for startup screen aswell?

More than not I use the sim in sync with current GMT which ever part of the globe I may. Except for the time zone inaccuracies which were corrected by some free fixes, I liked the way FSX handled timezones - it preserved the GMT when changing location, whether it be at startup screen or in sim change of location. I had a local airport flight set in as default with fsx set to take system time and didn't need to touch the time setting after that. But I am confused about how LM intends the user to use the time setting in p3d - at first the startup screen would preserve the local time which I found quiet unsettling and thought was a bug, then they did this in sim too. How is fixing local time more useful or better than fixing GMT? Now I am having to doubly load scenery if I decide to change location when in sim - first to move location then second after correcting time. I think preserving GMT was a more appropriate way and should have been kept as an option at least, or have I missed it?

The answer to this is very obvious and simple - like any other game we need settings available that affect the performance most to be able to run reasonably on wide range of hardware and situations. The developer is to know best, unless they just look to superficialy rehash an old program based on existing user feedback not interested in diving to its core to improve by making significant changes (in which case older performance settings will not necessarily apply or need to be asked). That is why I think it is being taken in negative way.