SU4 Beta - Random circuits trigger on and off

[MSFS 2024] Bug Reports Aircraft
, ,
1

Version: SU4 Beta

Frequency: Consistently

Severity: Blocker

Marketplace package name: sws-aircraft-pc12

Context: Community

Similar MSFS 2020 issue: Not applicable

Bug description: Users report that various circuits randomly trigger on and off with the 2020 SWS PC-12 (backwards compatibility). This has been consustent throughout SU4 betas. No such issue exists in SU3.

2 Likes
2

A user also had this behaviour before I switched everything to lvars.

3

Following.. this explain why our 2024 native planes avionics go random on / off sometimes.. is the circuits firing like this and back..

R.

1 Like
4

Hello @SWS-AlexVletsas

Can you elaborate?
Do you replicate the issue yourself?
What circuits are affected?
You say this is consistent, so just spawning your aircraft is enough to demonstrate the issue, or is there anything else required?

I have spawned your aircraft on the runway, and I’m checking both your breakers and the electrical debug, but cannot see anything similar so far.

Regards,
Sylvain

5

There are random circuit disconnects reported by customers, the situation varies. They can happen in the air or on the ground at random points. I.e. they may fly fine for 30’, then the AP resets, then good another 20’.

This is a video from a customer showing the GPS circuit flickering. We are working to replicate this.

1 Like
6

I seen this with my 2024 native plane, the GPS circuit doing exactly this, is a G3000 avionic and happens very random indeed, I haven’t found a pattern yet.

R.

1 Like
7

Ok, I’ll try to replicate this.
Let me know if you find anything likely to increase the occurrence.

Regards,
Sylvain

8

Are you using version 1 of the electrical system as well?

9

I am using the modern new version of the electrical system, with circuits names and everything.

R.

1 Like
11

@flyingraccoon
Three videos from us, we tried reproducing the problem including different avionics configurations:

Note that the PC-12 uses bus switches, there are no circuit switches in the aircraft. If the entire avionics 1 or avionics 2 bus disconnected, then we would see EFIS screens also flickering.

Thanks,
Alex

1 Like
12

I do have a repro on 1.6.29.0 with the PC12.
Not consistently, but enough to be able to trace what’s going on.

I’ll update this thread when I have more information about what’s going wrong.

Regards,
Sylvain

2 Likes
13

Sylvain, I noticed a weird console error that may cause this. It had the CIRCUIT_BREAKER_TOGGLE K:Event misnamed and said it couldn’t recognise it.

I will check again for accuracy, but from memory it said ``Unrecognised event “TOGGLE_CIRCUIT_BREAKER”```. My code uses the correct event from FS2020, but I’m putting it here as a note.

14

Hello @SWS-AlexVletsas

I am not sure this is related.
We think we have identified the root cause of this. This would more likely be caused by concurrent access to the BUS LOOKUP INDEX simvar.
In SU4 we’ve made changes which meant that if you aircraft had calls to the BUS LOOKUP INDEX simvar in multiple different XML files, these calls could be running in parallel and potentially conflict with one another, causing some of the simvars called to have invalid indices and trigger some unexpected changes to the electrical system.
This is what’s happening in your case, as you end up writing electrical simvars based on a lookup index that was modified elsewhere.

There is a fix candidates in the pipes, which will make this lookup index local for each xml file.
But I don’t know yet when it will be available.

Another important thing to know if you have a native 2024 version of the package, is that the new way to provide multiple parameters to a simvar, introduced with MSFS 2024 (
Simulation Variables) allows to avoid the issue, as you are providing indices directly, rather than through a lookup index.
Edit: this was in fact already present in MSFS 2020.

I will update this topic as soon as I have some news about the fix availability.

Regards,
Sylvain

1 Like
15

I like the idea of doing the XML code in a modular fashion, as it helps with maintenance. For new FS2024 native planes, the new method is the way to go. But for FS2020 planes this can break backwards compatibility.

I’ll see if I can push an update on my side, but considering that the PC-12 and Airvan are 2020 planes running in ‘24, there is a risk I will break the 2020 aircraft.

16

@FlyingRaccoon Sylvain, I’m looking through my code in case I can issue a patch, but I need some clarifications.

Using the PC-12 as an example, the bus lookup is used in:

  • PC12_Templates.xml: This is the central library of the PC-12. The Bus Lookup is used 109 times, 88 in an update and the remaining in tooltips and some switches & InputEvents.
  • PC12LG_Cockpit.xml: used in an by the Autopilot and in the emissives of some bus switches.

I assume the problem lies with the parts, which are called on two files:

  • SWS_PC12LG_Cockpit.xml which contains cockpit-specific items and
  • SWS_PC12_exterior.xml which contains systems calculations through the template “SWS_PC12LG_Systems”

I will try moving everything into PC12LG_Cockpit.xml and see if this fixes the issue.

The reason I moved these in the exterior is -and I may remember wrong- that in FS20 the cockpit code stops executing after the LOD drops below a certain size. As these XML systems are important for flying the aircraft (custom autopilot, failures, aging etc), I want them to run all the time even if the user is in drone mode taking screenshots.

My questions are:

FS2020:

  • is it safe to move this code to the interior.xml file? Will the interior code keep running even if the cockpit stops being drawn?

FS2024 -for our conversion process:

  • Same question as above
  • In a native aircraft, if I use the “always_execute” option in attached_objects.cfg, does that mean the code will run all the time?

Thanks,
Alex

17

Hello @SWS-AlexVletsas

My apologies, the “A:1” syntax is in fact already possible in MSFS 2020. Si this is probably the better way for you to address the issue.

Regarding your questions:

  • In MSFS 2020, if a LOD is not displayed, the associated xml code will no longer be executed.
  • In MSFS 2024, the behavior is the same by default.
    That is why introduced always_execute but this can only be used in the context of a ModularSimObject attachment.

Regards,
Sylvain

1 Like
18

I am one of the users who experienced this random triggering event in the PC-12, I fly VR and I always start on the runway ready for takeoff. There are times when I click Ready to Fly that I find I am in an external view behind the aircraft. I just toggle to an internal view, and I’m away to the races. I am not sure why the sim starts me in an external view, but I’m guessing this might have an impact on initialization code that is expecting instruments to be visible at the start. If the instruments become visible after the initialization code has run, would this cause these code issues?

I was chatting with another user, and apologies if this should be discussed in a separate thread, about his evidence that his VRAM was disappearing. I recommended he fly the test flight without changing views at all. He reported that the issue did not appear if he stayed in the cockpit the entire flight. Given that the xml does not execute if the object is not visible, would this be a source of memory leakage when the user is bouncing in and out of views? And is there general guidance in the SDK to avoid this issue?

I hope helps.

19

I can confirm that this fixes our problem on the PC-12 and Airvan, after testing the 2020 planes in 2024.

1 Like