Hot off the press https://www.x-plane.com/kb/x-plane-12-4-0-release-notes/:

Public Beta 12.4.0-B3
Aircraft

• Fixed an error where the landing gear indicator lights were broken on fixed tailwheel planes (XPD-17687)
• Fixed an issue where the flight plan route was not shown correctly on EFIS Maps (XPD-17691)

Airbus A330-300

• Various smaller improvements and fixes
• Fixed an issue where the “Managed Dot” on the altitude indicator did not extinguish when reaching cruise altitude (XPD-17391)

Graphics

• Fixed an issue where the sky wasn’t drawn correctly (XPD-17690)

User Interface & Controls

• Fixed a crash when the user slewed an aircraft on the map with chocks set (XPD-17680)
• Fixed an issue where the camera position wasn’t populated correctly to the corresponding datarefs (XPD-17694)
• Fixed an issue where popping out an avionics screen to Operating System level could cause a FPS reduction (XPD-16890)

VR

• Fixed an issue where the radial menu was hanging sometimes (XPD-17686)

SDK

• Improved error handling in case of unexpected behavior of plugins
• Improved stability of SDK in case of plugin errors (XPD-17697 & XPD-17689)
• Fixed an issue where mouse cursor callbacks didn’t work anymore when using 3D Custom Avionics panels (XPD-17702)

Edited January 19Jan 19 by Malaromane

Yup and I exit the simulator and plugin didn't crash with B3. 

Edited January 19Jan 19 by Sims Smith

0:07:50.227 I/SIM: Exiting the sim without confirmation
0:07:50.227 D/STM: Transitioning from state state_Normal to state_ShuttingDown
0:08:01.678 G64:  core: Run: [OnBeforeXPSavePrefs]
0:08:01.698 G64:  core: Run: [OnBeforeXPSavePrefs]
AutoDGS: airport.cpp:482: Airport 'KSEA' destructed
0:07:50.227 FSCharter V2 DEBUG XP_Main.cpp:254/XPluginDisable: Disabling...
0:07:50.227 FSCharter V2 DEBUG FSC_API.cpp:1690/APIDisable: Waiting for threads to finish...
0:07:50.227 FSCharter V2 DEBUG FSC_API.cpp:1697/APIDisable: Threads finished.
0:07:50.227 FSCharter V2 WARN  FSC_API.cpp:925/DebugLogRawClose: DEBUG Stopped logging raw network data
0:07:50.227 FSCharter V2: FSCharter disabled
FlyWithLua Info: Load exit file.
FlyWithLua Info: ** Aircraft closed. Exiting Saitek script for L.R. C172. Logitech 'XPlane Plugin.1.2.6.0' not found via Signature. Logitech Saitek plugin is not installed so nothing to reenable.
FlyWithLua Info: Exit file loaded.
FlyWithLua Info:  deinitFmodSupport() FmodSounds.size =  0
FlyWithLua Info: deinitFmodSupport()  Should be 0 now FmodSounds.size =  0
FlyWithLua Info: FlyWithLua plugin disabled.
0:08:01.882 G64:  core: Plugin Disabled.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
[SPAD.neXt X-Plane Connector]: Dataref is illegal and cannot be unregistered.
92552000 SPAD::INFO XPLMInterface: XPluginDisable
92552000 SPAD::INFO ServiceWorker: Stop Flightloop
92552000 SPAD::INFO Internal.BackgroundWorker: Stopsignal to all workerthreads
92552000 SPAD::INFO Internal.BackgroundWorker: Stopping all workerthreads
15:37:15.635660 StableApproach [DEBUG] XPluginDisable_begin
15:37:15.635660 StableApproach [DEBUG] Deconstruct StableApproach.class START
15:37:15.635660 StableApproach [ERROR] Exception in EarthNav.class: AptLoader: invalid argument: invalid argument
15:37:15.635660 StableApproach [ERROR] Exception in EarthNav.class: NavLoader: invalid argument: invalid argument
15:37:15.666394 StableApproach [DEBUG] Deconstructed StableApproach.class END
15:37:15.667920 StableApproach [DEBUG] XPluginDisable_end
WebFMC: Plugin disabled
Threading violation calling XPLMRegisterFlightLoopCallback (C:\Users\Administrator\builds\eiafPmXpN\0\x-plane\design\SDK\COMMON\xplanesdk\Src\XPLM\XPLMProcessing.cpp:44)
Violation by SPAD.neXt X-Plane Connector (SPAD.neXt.XPLane10.Connecter - C:\X-Plane 12\Resources\plugins\SPAD.neXt\64\win.xpl)

Still showing some error 

32 minutes ago, Malaromane said:

Graphics

• Fixed an issue where the sky wasn’t drawn correctly (XPD-17690)

User Interface & Controls

• Fixed an issue where popping out an avionics screen to Operating System level could cause a FPS reduction (XPD-16890)

Oh good, I hit these two, glad they got addressed.

I see they added a disclaimer during startup for for those of us running re-shade. Are that many people having issues with re-shade? Been using it for years now without issue on multiple computers.

29 minutes ago, Mike_CFII_MEL said:

Been using it for years now without issue on multiple computers.

You think so - and yet you seem to write a post with this or that problem every few days 😆.

14 minutes ago, Litjan said:

You think so - and yet you seem to write a post with this or that problem every few days 😆.

Any issues I have don't have anything to do with re-shade. Matter of fact the last two were for MSFS2024, first one was hitting an invisible object and the last was the tug refusing to let go... aircraft unable to move. Only complaint in xp12 right now is zibomod now feels like a fighter jet, that heavy feel is gone.

Matter of fact... I can't remember when I posted about an issue I had with re-shade and XPlane.

Edited January 19Jan 19 by Mike_CFII_MEL

2 minutes ago, Mike_CFII_MEL said:

Matter of fact... I can't remember when I posted about an issue I had with re-shade and XPlane.

This is exactly why Laminar wants to get rid of tools like reshade and others that mess with private datarefs, and will likely further escalate on that pushback. Users don´t KNOW that its reshade that is causing their problems...and then have a bad time in X-Plane and/or clog up the support system because of it.

15 minutes ago, Litjan said:

This is exactly why Laminar wants to get rid of tools like reshade and others that mess with private datarefs, and will likely further escalate on that pushback. Users don´t KNOW that its reshade that is causing their problems...and then have a bad time in X-Plane and/or clog up the support system because of it.

If it were re-shade the problem would still exist, as I use re-shade 24/7/365 while using X-Plane 12. The issues were, are, and will more than likely continue to pop up as a result of beta releases from L/R as they work out programming irregularities. Since they now have a disclaimer during startup, I doubt they will be blocking the use of re-shade, if so... why go thought all the trouble of created the disclaimer after years of re-shade being available, why now?

As far as clogging up the system. Log files are required during bug reports, one quick search for re-shade and the issue is disregarded. Not so clogged.

Edited January 19Jan 19 by Mike_CFII_MEL

30 minutes ago, Litjan said:

This is exactly why Laminar wants to get rid of tools like reshade and others that mess with private datarefs, and will likely further escalate on that pushback.

Well, there would be no need to mess with private datarefs if there was an official way to adjust the associated settings in the first place.

Curious, the only reason I can think of to use reshade in the current version of XP12, would be to improve AA which would incur a performance penalty (especially at night with a lot of lights present).  Reshade can cause issues with the depth buffer and increase input lag.  

But replacing core DLLs that a game/app was built on with alternate version (aka Reshade) so they get loaded instead of the DLLs the project was compiled with, IS going to be a source of instability.  And this is why LR put in a disclaimer.

What it means from a bug reporting perspective is that you’ll have to remove the Reshade DLLs and put the original one’s LR distribute back and then test the same scenario again to see if the bug is repeatable.  LR could detect and block its usage or they can detect and log its usage.  But either way, you reduce you bug reporting significance if you include Reshade.

I’ve used it in the past but it would be better to have access to the shader code (for Vulkan that is SPIR-V compiled from GLSL and HLSL) and work from there rather than replacing DLLs.

 

50 minutes ago, Bjoern said:

Well, there would be no need to mess with private datarefs if there was an official way to adjust the associated settings in the first place.

Its because, as Laminar put it, most people dont have a clue, change things break things than blame laminar. 

2 hours ago, Litjan said:

This is exactly why Laminar wants to get rid of tools like reshade and others that mess with private datarefs, and will likely further escalate on that pushback. Users don´t KNOW that its reshade that is causing their problems...and then have a bad time in X-Plane and/or clog up the support system because of it.

I had this chat with Mike Discord-side already. Get rid is maybe... a bit strong of a word. We don't have any plans to kill off reshade. But it does interfere with our rendering, hence all the Looney Tunes signposts that say "Big Hole here!" and "Are you sure you want to hit yourself with the hammer?"

I do actually think there should be default "abilities" to tinker with this one day. I had this argument with LR the other day that "tinkerers are gonna rummage through our stuff if we don't give it to them."

So post-processing settings is not a far-fetched idea. But our priorities are solely next-gen scenery. So for now... that's a no!

 

13 hours ago, Bjoern said:

Well, there would be no need to mess with private datarefs if there was an official way to adjust the associated settings in the first place.

If changing those datarefs did not constitute a code hazard with unforeseeable consequences, don´t you think that Laminar would gladly allow it? Do you think they made those datarefs off-limits just to p*** their users off and push them into the criminal world? Don´t you think they are lenient in allowing them getting changed so you CAN make X-Plane look like a Disneyland version of the world if you want to?

So for now I rest in knowing that bug report whose log.txt shows the messing with private datarefs go straight into the big round circular deposit under the desk. 

Experts can mess with them - they know the consequences and have (sometimes) read the disclaimer - but when unknowing users stumble upon these hacks (or even pay money for them) and it crashes their X-Plane and I have to read "X-Plane sucks, it crashes all the time, I am going back to Blue Max!" - it makes me sad.

It´s a bit like substance abuse. Yes, life is drab. Yes, a bottle of wine for breakfast can really brighten your day. But you need to know what you are doing (avoid the cheap Lambrusco)!

Edited January 20Jan 20 by Litjan

I've yet to see a tweak to X-Plane shaders that looked good in some ways and did not have consequences somewhere else. I avoid them like the plague. Default all the way.