SP1 issues so far

[mvanoverdijk]

I just did a VRAM comparison.
ORBX ESGG (Landvetter, parked right outside the Jet center,GA parking #1)
Stock shaders, Active Sky online wx. 4K monitor, RTX2080ti videocard, 11264 MB VRAM

Scenario 1: Render to transparent surfaces CHECKED. VRAM : 10600 MB
Scenario 2: Render to transparent surfaces UNCHECKED .VRAM : 8800 MB

Clearly something is eating away on our video memory here, which is at least for me, causing stutters in cruise with that option enabled.

Can confirm.

Sitting on 28L at LatinVFR FLL cold and dark I am using 10907Mb of VRAM on my 1080Ti on latest drivers. No other add-on has this issue. There is clearly a VRAM leak with render options enabled.

As a comparison the NGXu is using 6950Mb of VRAM in the same scenario and the FSL A321 is at 7120Mb of VRAM.

[SeanI]

Hi folks,

Thank you for the reports. We have identified an issue in recent builds that has caused VRAM usage to spike as many of you have noticed. We are working on a fix for this ASAP and we will let you know once we have a new build with this remedied.

We are also investigating feasibility of a "lighter" set of textures that some have asked for to better balance VRAM usage. For the 8GB users this might not be necessary depending on what other software you are running. Just a reminder for the 4GB users, our minimum system specs are for a 8GB card. You may be able to have some luck by running P3D at low settings. Nevertheless, this fix should bring things in line with the versions our testers have been working with over the past months.

Thank You,
Sean

[chevelle505]

Is there any way to make the FMS Save nav data with the current conditions option so that should you need to resume a flight you can? The current conditions option has come a long way but still not saving battery master and FMS position. Even if saved with everything on and running (in flight) you loose its position and your effectively "lost" as it has to be sitting still on the ground apparently.

[thecoturnix]

Bumping this one because finally i've been able to fix my issue with the virtualfly TQ6+ throttles and i hope it works for others in the same predicament.

What i did:
-Calibrate axes in MAVS, check "enable hardware mapping"(i guess everyone has done this and still i'm not sure this application works as it should but just to be safe).
-FSUIPC: disable the axes in FSUIPC, leave them blank. For the throttles to work axes must be assigned in Prepar3d.
-Prepar3d: go to options-controls-other
-Input method: select "Direct Input". I had "Raw Input" by default. You will get a message saying that the change can destroy your assignments, accept (all my assignments work as before and haven't noticed anything amiss).
-check "Enable controller(s)" box (last option in that screen)
-assign axes and calibrate them in prepar3d. Check you haven't any spurious axe floating (i had the rudder axe in my TQ6 don't know why)
Now the throttles should work

Still lots of questions here. I have no idea what difference there is between Direct or Raw input and why the throttles only work with Direct (i have never seen any discussion about the merits of either as you do about FSUIPC callibration or lack of thereof). Should i suppose the "enable hardware mapping" checkbox in MAVS is the same as the one in Prepar3d control options?

Anyway, happy to have solved my problem. I hope it works for the others.