Jump to content

SteveFx

Commercial Member
  • Posts

    2,533
  • Joined

  • Last visited

  • Donations

    100.00 USD 

Reputation

258 Excellent

2 Followers

Profile Information

  • Gender
    Male
  • Location
    England

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    Other
  • Virtual Airlines
    No

Recent Profile Visitors

9,852 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. It’s your windows documents folder. C:\users\{your name}\documents.
  7. I believe that bufferpools has no impact if running dx10.
  8. 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/
  9. I’m glad that it’s sorted and I am particularly glad that it wasn’t the fixer!
  10. 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%.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
×
×
  • Create New...