Jump to content

sundog

Maxx-XP
  • Posts

    2,480
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by sundog

  1. Do you have an ATI card?
  2. Weird... do you remember what overcast setting you had selected when you saw this? Also, is this with the latest version of SMP (4.9.6.2?) This looks similar to a known issue that was fixed in 4.9.6. Finally, make sure your graphics drivers are reasonably up to date.
  3. I think you hit the nail on the head there. The issue seems related to when hardware MSAA is in use, which happens if HDR is off and AA is on in X-Plane 11.50+. It affects our ability to copy the framebuffer and modify it. There is a way for us to get around this, at least under Windows - so we'll have to put out an update to MaxxFX to fix this. In the meantime, avoid MSAA (preferably by enabling HDR) when using MaxxFX.
  4. Quite honestly I can't think of any scenario that would result in your entire screen turning blue. The only thing I see in your log is that SkyMaxx Pro is noting that you are almost out of memory. I suppose it's possible that this is getting your video driver into some sort of bad state. Start by deleting the settings.dat file in your resources/plugins/SilverLining folder, which should revert SkyMaxx Pro to its default settings. They may be less memory-intensive than what you had changed them to. Failing that, see if lowering your graphics settings in X-Plane has an effect.
  5. @Cameron have you seen this issue before? I don't know if this might be related to the issues mentioned at https://www.x-plane.com/kb/macos-catalina-x-plane/ where the new security requirements in Catalina are impossible for many plugins to satisfy.
  6. The underlying issue is likely that the traffic global plugin is changing OpenGL's "point size" setting and not restoring it back when it is done. So when we go to draw the stars, they look like circles instead of points. As @rawdmonsaid, a workaround for now would be to set SMP to use X-Plane's default sky. Hopefully the Traffic Global folks can fix that.
  7. Sounds like you are a bit low on resources, but if it's generally running OK then we'll just go with it 15-20 seconds to apply changes is a bit much, but SMP is recreating all of the clouds during that time, so a pause of a few seconds is expected there. I didn't know users were being given a choice for the beta Gizmo. I'll have to ask X-Aviation about that, if it's causing problems.
  8. Well the menu is only using X-Plane's own menu system. If that is causing a slowdown it sounds as though the problem is larger than anything caused by SMP. I would roll back the driver.
  9. Try turning off cloud shadows in the SMP configuration. That's the only thing I can think of that might cause a stutter every 3 seconds or so.
  10. I'm afraid not. X-plane doesn't know about our clouds internally, and can't generate shadows for them on its own. Because we have to completely disable X-Plane's built in clouds to draw our own, X-Plane can't generate shadows for its own clouds in that case either. Remember you can adjust the shadow intensity in the SMP settings. Perhaps just turning it down would make things look OK for you.
  11. Oh hang on, I know what this is. The problem is that you're using both FSGRW and ASXP. If SkyMaxx Pro sees data from FSGRW it will use it first, but of course ASXP is not updating the FSGRW data that was last written. If FSGRW left a fsgrwsmp.rwx file in your X-Plane folder, you'll need to manually delete it before switching to ASXP.
  12. Do you have "never change visible weather" selected in the RWC settings? That might be preventing new weather from being displayed if so. You can also try using the "force weather reload" option in the SkyMaxx Pro menu to see if that picks up the new weather.
  13. As we've said above, you'll probably want to try again when our next update goes out. The fixes I'm talking about haven't been released yet.
  14. OK, those are the same settings I was testing with. Thanks.
  15. FWIW I spent a fair amount of time yesterday flying through clouds in my Vive Pro using our latest internal beta release, and did not see this effect although I was looking closely for it. Cautiously optimistic we've finally found a way to eliminate this. So I can be sure, can you let me know what graphics settings you are using (AA setting, HDR on or off, Vulkan on or off?) These sorts of issues are related to the depth buffer, and X-Plane handles the depth buffer differently in each of those cases.
  16. I'm admittedly at a loss; I just now tested TerraMaxx under OpenGL and it did save and restore its settings successfully here.
  17. We do have some VR fixes slated for our next release, so stay tuned. I'm hopeful it will help, but for some reason I've never had clouds in the cockpit in VR with my own setup, so I'm not 100% sure this particular issue has been fixed.
  18. I really can't think of how Vulkan vs. OpenGL would affect TerraMaxx's ability to write its preferences file. It works exactly the same way in both cases. We haven't heard of this happening from anyone else, so at this point I suspect an issue with your file system. It might be time to re-install X-Plane, and the add-ons you care about, into a new, fresh directory - preferably on a different hard drive if possible.
  19. Getting our own fog effects to work in VR is one of the things I've recently fixed here. Not sure if it's the same issue you're describing, though - you are touching on the larger problem of not having API access to influence X-Plane's fog effects. Instead we must disable them entirely and attempt to recreate them with cloud layers and our own fog post-processing effect.
  20. Really weird; I don't see any clues in your log files. Do you have any anti-virus products installed that might be sporadically interfering with our ability to write our settings file? Or maybe some sort of automatic backup software?
  21. Hm, I just tried it here under X-Plane 11.50 (the released version) and it saved and restored my TerraMaxx setting successfully. If it's not some sort of filesystem issue I'm not sure what it might be. If you could attach your log.txt there's a slim chance it might tell us something. @Cameronhave you ever encountered this with any other customers?
  22. My guess would be that your Resources/plugins/TerraMaxx/settings.dat file has somehow become corrupt, or cannot be written for some reason. Try deleting that file and allow TerraMaxx to recreate it when it starts, and see if that helps.
  23. Thanks for sharing that, @rawdmon. I have been spending the past couple of days addressing various VR issues including a few that you've flagged here, with some success. Stay tuned...
  24. We do have a potential solution to that "flickering" issue in VR, but don't want to make any promises until I've had a chance to really test it. Laminar has actually been really good to work with. Yes, the API sometimes limits us, but it's usually for very good reasons that are often beyond their control.
  25. Yes, that's a fair point - external views in VR aren't commonly used. The technical reason is because in VR the shadows will affect the cockpit when they shouldn't. We do need to test VR again for an upcoming release, so I'll take some time to see if anything within X-Plane has changed that would allow this case to work now.
×
×
  • Create New...