SteveFx

I tried this in native dx10 preview and it seems fine, so I presume that this is side effect of the freeware dx10 shader patches rather than anything to do with Milviz. I can see no issues with the real fixer.

I downloaded the Rick Piper hs748 from the classic British flight sim web site (I chose the fsx version). I can see no issues with the windows with an up to date fixer install. Is that the correct hs748 that you are using? note that I do have the flight one fix for blue windows in vc during rain installed which could be related.

Which version of the fixer are you using? And is the aircraft freeware? have you checked if the glass texture is 8 or 16 bit if so converting it to dxt3 might fix it.

You presumably had my dx10 fixer installed. The manual explains that if you want to move a fsx installation which uses the fixer that you must uninstall the libraries using the dx10 controller before moving the fsx installation and then reinstall the libraries after the move. Not following this process will cause fsx to crash as you describe. The fixer is not working on your laptop, if you want it to work you must install the fixer and then install its libraries.

Fastspring have introduced new charges which make continuing to sell the fixer uneconomic. I therefore intend to remove the product from sale at the end of March (2024).

It’s your windows documents folder. C:\users\{your name}\documents.

I believe that bufferpools has no impact if running dx10.

If it’s isn’t dx10 preview then turn on missing texture alert in fsx.cfg to find out what the issue is. https://www.fsdeveloper.com/forum/threads/missing-textures.7376/

I’m glad that it’s sorted and I am particularly glad that it wasn’t the fixer!

That’s disappointing, there is nothing else that I can suggest. From the ctd forum this problem originated with a windows update. From what I have seen that seems to generate a spurious event that api.dll cannot handle. In my testing switching to ipv4 seems to greatly reduce the incidence ( ie I haven’t seen it since ) but if you have had a further occurrence then the “fix” cannot be 100%.

If it doesn’t work in dx9 then it is an Active sky issue relating to firewall or perhaps a missing texture. All you have to do to test this is press the switch to dx9 button in the fixer controller. If it works in dx9 but doesn’t work in dx10 without the fixer libraries then it clearly isn’t a fixer issue but must be an ASN issue relating to the base dx10 shaders or the different handling of missing texture in dx10 vs dx9. Note that in dx10 without the fixer rain works but looks bad. if it works in dx9, works ( albeit badly) in dx10 and works in dx10 with the fixer libraries installed and the rain shader unticked in controller file->debug then it’s a conflict between active sky shader changes and the fixer. I think that’s unlikely mind. If test 1 or 2 suggests that a missing texture could be the issue then you need to Google fsx.cfg missing texture alert to find instructions eg here for instance. https://www.fsdeveloper.com/wiki/index.php/Missing_textures The most likely explanation is something firewall related, but if you test as I suggest you can narrow it down.

Also read this one

Is this windows 11? I believe that AS16 and ActiveSkyNext don’t work at all on windows 11. I believe that there is a patch for AS16. If it isn’t windows 11 then does it work in dx9 ( your post isn’t clear)? does it work in dx10 with fixer libraries uninstalled? does it work in dx10 with fixer libraries installed but rain fix disabled. is there a missing texture? - enable missing texture alert in fsx.cfg. based on the answers I suspect that your best approach may be to raise a support ticket at hifi simulations but I will look at what you report back.

I have investigated this issue and can report some findings. I believe that the crash requires a SIMconnect client to trigger it. I think that (possibly because of the mentioned Windows Update) something subtle has changed in the behaviour of named pipes causing FSX to get a spurious event that it fails to handle properly. My suggestion of a possible workaround ( I am uncertain how well this will work) is therefore to force the use of IPv4 for SimConnect. With Acceleration or FSX-SE that is as simple as placing the following 3 line simconnect.cfg in your Documents folder. [SimConnect] Protocol=IPv4 Address=127.0.0.1 Do NOT add a "Port=" line. With SP2 you need to follow the SDK manual (which is wrong for FSX-SE and acceleration) and additionally craft a simconnect.xml which goes in the same location as your fsx.cfg file. For SP2 the IPv4 entries in the two files must contain a "Port=" and they must be the same port. The fsx function that crashes at 3afa2 (Acceleration) or 1ddc (Steam) can be identified as a fileiocompletion callback (ie async IO). It appears to be used just for reading commands via SimConnect - although it could have other uses that I have not seen. The callback receives three parameters - an errorcode, the number of bytes read and a pointer to some "context" setup by FSX earlier. In normal operation it is called when a SimConnect command is received with an errorcode of zero, the length of the command and the "context". When a SimConnect client disconnects it is called with an error of 8000014B aka NT_STATUS_PIPE_BROKEN. In the failure case it seems to get an errorcode of zero, zero bytes read, but the real issue is that the "context" pointer is not correct. The function crashes trying to call a object in the context which isn't there.

Can you try creating a simconnect.cfg file in your Documents folder containing the following 3 lines [SimConnect] Protocol=IPv4 Address=127.0.0.1 Ignore the SDK documentation about this file which is slightly wrong for acceleration and FSX_SE. Do not add a "Port=" line as it suggests. That should switch any simconnect users to use IP rather than a named pipe. Let me know if that reduces or eliminates the problem (or makes absolutely no difference)! The location in API.dll where your system is crashing is in an callback function that appears to be exclusively used by SimConnect. I have a theory that the crash occurs if a simconnect user closes the session whilst FSX is trying to send it a message. I know this because I had crashes at the same location and did some investigation on it. I think that the buffering that TCP/IP uses may make the problem less likely than with named pipes. Note: if this does help then ideally we should try and find which simconnect user disconnects during startup and try to switch it to IPv4 rather than switching everyone. I also don’t know if fsx supports IPv4 for DLLs loaded via dll.xml., it may ignore the setting for these as they part of the same process.

Are you using a weather engine, if so which one?

You might do better posting on the aerosoft forums or the main avsim fsx forum rather than a backwater support forum. https://forum.aerosoft.com/index.php?/topic/105600-mega-airport-heathrow-fsx-has-run-out-of-graphics-memory/ if you want to fly with the combination of 1) complex detailed aircraft model 2) very detailed airport then you need to make some compromises with the fsx sliders, dialling down ai traffic and ground traffic to a few percent and setting lod range to default perhaps. When you find something that works then try moving them up a little at a time. if you don’t want to make those compromises then you need to look at a 64 bit simulator such as msfs 2020 or P3D. in choosing Heathrow X you have probably chosen the absolute worst case of the latter. London is a large city surrounded by many airports and thus some care is needed. Try reading some of the reviews for Heathrow X on sim market, you are not alone in having this issue and there is no great solution https://secure.simmarket.com/aerosoft-mega-airport-london-heathrow-xtended-fsxp3dv2-(download).phtml

I can’t help but think that you are posting in the wrong forum.

The two legacy shadow warnings mean that you have chosen to enable shadows for legacy aircraft built with the flight simulator 2000 sdk. If you haven’t downloaded any such old aircraft models then you don’t need these settings and they may cause minor issues shadowing the aircraft that you do have. Ground shadows is a buggy feature in fsx that people didn’t use and most developers didn’t test against and that therefore may cause major graphical issues with add on sceneries eg black triangles on runways. I would disable all 3 settings. texture max load limits the maximum size of texture that get loaded into the GPU. For expensive pay ware aircraft that often means that you aren’t setting the best quality graphics as they typically ship with 2048x2048 textures or bigger. I would increase it based on the recommendations for the aircraft provided you sort out why you have vas issues.

You have posted this in my support forum but your issue is about the memory usage of aerosoft airbus and various sceneries and not about the fixer. The goal of the fixer is to allow fsx users to run fsx in dx10 preview with improved shadows. FSX is a 32 bit program as is thus limited to around 2GB or 4GB memory depending on a setting in fsx.cfg HIGHMEMFIX. The fixer installation tests for the HIGHMEMFIX setting and will warn you if it isn’t set. You can check using the diagnostics button in the fixer controller which will check again. If the setting is set then there is nothing further you can do to increase memory. It has been suggested ( though not by me) that running fsx in dx10 preview ( with or without the fixer) saves a few 100K of memory and that therefore this can help if you are very close to the limit. Using a 64 bit version of windows can free up more memory of the 4GB for use by fsx, with a 32 bit windows fsx gets more like 3GB. From 2010 onwards developers were pushing the envelope of memory usage in addons. Unfortunately there is no magic fix for this, you have to be careful in which addons you run together and be careful to keep LOD radius in fsx to a lowish value. If you Google “fsx oom memory” without quotes you can find some helpful page on this subject - the Avsim FSX setup guide seems to have disappeared.

I was also able to reproduce at Canary Wharf in London.

Thanks! Note that there is a support forum right here on avsim. https://www.avsim.com/forums/forum/644-the-official-dx10-scenery-fixer-support-forum/

The OP seems to have disappeared. if anyone else is interested in testing this fix then let me know.

If you can send me a PM with your email address I have a beta with a possible fix for you.

Ok, I am able to look at it now. The problem is that the fixer uses the alpha channel of the reflection render target for cloud shadows. I think that some buildings (typically skyscrapers) that appear as reflections with water 2.0 max are writing alpha values into the reflection RT. These are therefore treated as cloud shadows by the fixer. The solution is to conditionally distinguish between the general shader being used to display these in the main RT and the reflection RT and to avoid the write to the alpha channel, whilst still applying any alpha blending that is required to draw the buildings correctly. A complication is that the general shader can in some circumstances be used to draw clouds so care is needed to avoid breaking that.