Bryn

Thanks very much for getting back to me. If this was the case (an external library), then wouldn't it fail for the MSFS 2020 read as well (the log has a successful 2020 read followed by a failed 2024 read).

Hi,I'm getting this error when I load PSXT with MSFS 2024: lf_startUpPSXT: No mapping for the Unicode character exists in the target multi-byte code page. Note that I don't get this error when I load with MSFS 2020, and the FSLTL files are exactly the same (i.e., there is a symbolic link to the 2020 FSLTL files). Here is the log, with both MSFS and MSFS 2024 being tried:

Hi, I just noticed that the 'sim time' setting is not persistent, requiring the box to be checked on every load. Is it possible to make this persistent? Bryn.

But where does it sit in the scheme of A340-300 FS addons? Black box / PSS Feelthere / wilco xworks Is it good enough to switch to MSFS now for A343 flights? (The bar is low, though at least Xworks is free!)

That's wrong. ASN hooks P3D, and when the addresses change (as they do in each version), the hook stops working.

Occasionally, they come up on eBay.

This flight? http://flightaware.com/live/flight/JBU387/history/20160831/1345Z/KFLL/MUSC beaten to it...

Given Holger Sandmann is a contributor in that thread, it wouldn't surprise me! Thanks for the links.

I'm surprised by how big seasons.bgl is. I thought it would be like timezones.bgl, with just a bunch of quadrangles with dates, but it's massive, so must contain some other global matrix of data (like the lc and population density files). Do you know the structure of the file?

I believe they've said before that the cost of indemnity insurance for P3D sales is a lot higher.

Better to recompile nave1b.bgl as a P3Dv2 bgl using ModelConverterX. It's easy, and keeps the buildings in their normal spot. PM me if you want help. Bryn.

nave1b.bgl is the file that moves buildings on to the runway. Remove that from the Madrid Barajas 2008/scenery directory (or take a moment to fix it using ModelConverterX). MAD_RWY.bgl also seems to create problems around some taxiways (placing walls across them) - though this is in the older area of the airport. MAD_RWY.bgl cannot be fixed using ModelConverterX, but removing it does not seem to adversely affect the field. The lights patch from simmershome should sort out the night lighting. Bryn.

Is it awesome?

I wonder how it goes with the infinitus prime...

Missing gauge files? I have a vague recollection that some POSKY aircraft needed to have some gauges loaded for various animations to work.

I write my own add-ons (and some simple freeware as well, like approach code bgls, and a weather radar using the ASN API). Here's an example of a problem I think could be overcome easily with some small additions to the SDK. KSEA has 3 runways, but because most of the traffic areas from the eastern sector, and the terminals are on the east side of the airport, 34R/16L is used for almost all of the AI traffic. To get around this, some AFD designers have used various complicated tricks, but it's still very sub-standard, and you end up with outrageous congestion on the single runway. Centre runways are also never used. If simConnect polled for whether I wanted to set the runway for each aircraft when it came time for DTG-FS to choosing their departure or arrival runway, I could assign a runway using my own algorithm. Everything else could remain exactly the same (ATC, taxi algorithms, etc), and you'd get a pretty good improvement in traffic realism. If you extended that to choosing the approach type, or runway intersection for departure, it would be even better. To me, this does not seem like a complicated proposition. The program is already doing it automatically (I've spent some time trying to nail down exactly where this happens, without much luck) - all I'd want is a check to see if I want make the choice for this aircraft, if null response continue with the stock choosing algorithm. Opening up the ATIS for writing the runways in use would be also handy in this context. Finally, allowing access to ATC commands might also be really handy. Rather than taking over an AI and writing a waypoint for the AI to fly to (as the current simConnect allows), it would be great if we could just issue an ATC command to the aircraft. If you expanded the number of ATC commands available, even better. AI and ATC addons have been few and far between, mainly because the SDK tools have not really been there to do anything particularly impressive. But I think there is considerable interest in these types of addons - many users love just setting up an airport with traffic and watching it. So small modifications in the SDK in this area could make the program considerably more interesting and realistic for them.

AI and ATC access. To me, the most frustrating thing about the FSX (and P3D) SDK is how closed this part of the product is. i think the single most important thing in this respect would be the capacity to 'be asked' which runway should be used for an AI to depart or arrive on. Even if nothing else changed, this would allow a huge improvement in managing AI traffic at busy airports. I write my add-ons in C++.

Fixed in P3D3.2! http://www.prepar3d.com/forum/viewtopic.php?f=6312&t=12618&start=15

I just create my own 2d panel. Takes about 30 minutes. I use 2d because: 1: the VC viewpoint bug means the view moves too much on long-body aircraft, especially near the equator, so the panel doesn't stay in a fixed position, like it should in a study sim; 2: the VC mouse cursor calculations reduce performance too much right when I need it, even on the newer sims; 3: the 2d gauges are clearer, larger, and easier to read; 4: the 2d gauges are easier to manipulate (the cursor doesn't 'slide' off buttons as the plane turns or during turbulence); 5: I can cover my screen in panels that I want to see (Aerowinx PSX style); 6: fixed panel positions are consistent with normal desktop training sims; 7: I'm only interested in flying the well-designed systems, not the VC or aircraft model itself (again, think Aerowinx PSX, though PMDGs seamless integration of its forthcoming 747 with P3D makes it the winner for me). It would be be nice if pmdg put landing lights in the model, though, so cockpit builders and 2d users like me can see the ground at night. Bryn Battersby

On the P3D forum, LM have responded positively, saying a ticket has been raised for the bug. We shall see... I imagine the problem will be even worse in the very long 747-8!

Anyone know if this was fixed in P3D3?

Running FSX as Admin stopped FSX from continuously asking for activation whenever I loaded it. I found that something that I don't quite understand happened to my permissions when I installed Win 10. Running nvidia Inspector as Administrator also allowed my to get my custom antialias to work. And Running AHK as Administrator allowed me to run FSX in borderless mode. So admin mode was a bit of a panacea in my case.

I got nvidia inspector to work by running it as administrator. Now I have my antialias working properly again.

Perhaps the tileproxy.sys driver is the problem, then? I'm not really sure what that driver actually does...

There is a change log at the Steam website. That change log lists improvements in the handling of the mouse cursor in complex virtual cockpits, so they have improved that code. But it looks like its not possible to eradicate the fps slowdown completely. http://steamcommunity.com/app/314160/discussions/1/541906989416450278/