SteveFx

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).

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%.

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?

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/

Yes in the shadows dialog, but read the manual chapter 9, if you boost shadows by more than a small amount you may find that a white aircraft in full sun looks like it has oil painted on it.

Whenever you make a change to settings within fsx it writes out the config. The dvd version always sets texture max load to a maximum of 1024 when it dos so. Fsx steam edition has been updated not to do this. This has annoyed people for years. The reason for the check in the diagnostics is to warn you if this has happened.

It's a missing texture, turn on missing texture alert in fsx.cfg, there is an editor in the controller to do so for you. Then note the name of the missing texture and contact the author. Its very common with Carenado for the uninstallation of one aircraft to remove light textures used by another. Many times reinstalling the aircraft with the issue will fix this. In dx9 missing textures aren't shown but in dx10 the use the default texture.

Hello Alain You have turned on missing texture alert, just turn it off. You can do that either by editing fsx.cfg or by using the fsx.cfg edit screen from the top menu of dx10 controller. If you do the former I think it's in [scenery] If the latter ( which just edits the file for you) there is a tick box for it which you should untick and press ok.

Its a fsx feature called sun glare which works just as you describe. Unfortunately Aces introduced a bug with SP2 and it is turned on and off by the same menu item used for the DX10 preview setting. So in SP2 it is always off in DX9 and always on in DX10 (as Dx10 preview is off in DX9 => sun glare off and on in DX10 -> sun glare on) There is an option in the fixer misc dialog to hide the effect although this will also disable the rather similar G effects.

Can I say I told you so?!

Well you haven't said is if there is any connection to dx10 or the fixer. Does it occur with the fixer libraries uninstalled, does it occur in dx9 ? Does it occur if you disable the fixer rain shader in the debug dialog? It sounds to me as if something is wrong with the connection between the as client and as server and this (probably) has nothing to do with the last thing that you did which was install the fixer. Perhaps some other install has removed or corrupted your dll.xml entry for AS16 between the last time it rained (in fsx) and now? Try uninstalling and reinstalling as16???

Ask HiFi? Historically they have switched textures e.g in ASN which caused black flashes maybe they are dong something else in AS16. Actually google shows that you have to open a port in your firewall... http://www.avsim.com/topic/440512-little-issue-with-rainsnow/

It was mentioned in the TB21 thread that a similar issue with reflections occurred with Lionheart Learjet. Bill Ortis again kindly let me have a copy and yes its exactly the same. So.. WARNING If you aren't confident copying and renaming files don't try this. The instructions are In the directory <fsx dir>\SimObjects\Airplanes\Learjet_24b\texture 1) rename the texture GlobalEnv_AC_Plexi.dds to something else e.g. xGlobalEnv_AC_Plexi.dds (If you have already done the following 2 steps for the TB21 you don't need to repeat it!) In the directory <fsx_dir>\Texture 2) create a copy of the texture GlobalEnv_AC_Chrome.dds 3) rename that copy to be called GlobalEnv_AC_Plexi.dds DO NOT rename the original!!!

I had confused this issue with the Lionheart TB21 as the thread title for the latter didn't originally mention Lionheart! It was reported to me that the sun visors do did not work in the new Just Flight TB10/20 To address this go into the debug dialog in DX10 Scenery Fixer and untick the option DX9 Style Alpha Func This will be properly addressed in the next release of the Fixer.