[SU-14] LIGHT Variables - Are they really optimized or is this a major bug?

Version: SU-14 - 1.35.21.0

Frequency: Consistently

Severity: Blocker

Context: Every Aircraft using Light Indexes in Multiplayer is Broken

Bug description: Lights are no longer 64-bits, therefore only Light States work in Multiplayer

Repro steps: There are multiple 3rd Party Aircraft that use Lights for Multiplayer Animations, test any of those aircraft.

Additional Information from Another Developer:

They optimized away a lot of network data to fix the multiplayer issues. Sending 64 bits for each on/off light variable was probably one of the things they optimized away. I think they might no longer be sending the individual light variables at all, and are ONLY sending “LIGHT STATES”. Light states seem to carry 32 bits, with 9 of them being in use by the normal lights. This would explain why only index:1 works. But it does not explain why there’s a difference between default and addon aircraft. I tested 5 of the default aircraft, including CJ4 and 747. They all update the standard set of index:1 lights. I tested a few addon aircraft (cockspur c510, gotfriends gb R3, the FS Thunderbirds custom f-16), and they all have lights that aren’t updating. They’re different for each plane, but they’re consistent between restarts. For example, the c510 does not update landing lights, but the FSTB F-16 ONLY updates landing lights. The LIGHT STATES still sync in all cases, so the data is getting through.

My thoughts, some simulation variables like the helicopter rotor variables are running at 10k, so if Lights were truly something that needed to be optimized, you would think the server load would benefit from cutting other variables first.

Overall, we just need clarification from Asobo as to what LIGHT Variables are transferred over the network and to what extent they are transmitting their index values.

If this is a permanent fix “by-design” and not a bug, we need to know as 3rd Party Developers because this issue will make many of us re-write entire systems, sub-systems, and model behaviors for our custom animations. Therefore, I have labeled this issue as a “Blocker”. If its a bug, then we do not need to spend weeks re-writing systems. If it is permanent, this will require major overhauls within the 3rd Party Development Community. Clarification is much appreciated and any further detailing by any developers dealing with the same issues is helpful as well.

1 Like

The documentation here: Simulation Variables (flightsimulator.com) lists all light variables which are submitted in Multiplayer. Here: Aircraft System Variables (flightsimulator.com) lists which variable is available in Multiplayer.

Light variables in Multiplayer are transmitted to all aircraft up to a maximum radius of 10,000m, if you have 100+ aircraft in the area in Multiplayer that is a lot of light variables being transmitted every m/s and because of that maybe Asobo had to decrease the light variables to save network performance, temp memory and animation workload.

I too have created a number of aircraft mods that rely heavily on all available light indices and types to control model part visibility, animations, and visual effects in multiplayer. They are all majorly broken after SU14 so I also hope this gets fixed ASAP. Lights were already a workaround for the lack of multiplayer variable support - we need MORE multiplayer variables supported, not fewer.

I have done some testing with a friend and we are seeing more strange behavior that may be tied to this issue. I would like to add our observations to this thread in case it helps uncover the root issue.

  • On the freeware F-86 Sabre, only the left side nav light and left hand landing light show in multiplayer when the aircraft loads from the aircraft selector. All of the lights (including those not working) are index 1. The lights show properly when the aircraft is loaded from the main menu.

  • On the same F-86, it can show tanks, rockets, or bombs based on indices 1, 2, and 3 of the pedestal light. A simple XML gauge turns these lights on/off based on payload weight. Initially none of these parts showed in multiplayer, but then I added dummy entries to the [lights] section of systems.cfg corresponding to pedestal 1-3, and after I did that all three model parts are now shown constantly in multiplayer, overlapping on the pylons. They cannot be toggled, even the tanks that are tied to light index 1 are always on. Adding a dummy entry for logo lights:1 did fix the smoke effect, which now can be toggled on and off normally.

  • On other aircraft with similar light-based loadouts (F-16 and F-18 mods), most but not all of the weapons are showing simultaneously in multiplayer.

  • Aircraft like the DC Designs F-16 and F-14 that have the pilot figure visibility tied to a light no longer show the pilots in multiplayer whether the light is toggled or not.

  • When one player is in an aircraft and a second player spawns into that same livery using the aircraft selector, the second player sees the lights of the first aircraft exactly synced to their own lights. When they turn lights on or off, the other aircraft’s lights go on or off to match. This happens on any aircraft ranging from Asobo defaults to payware to freeware, but only in matching liveries.

1 Like

Here are a few examples of the issue mentioned in SeeRyFly’s fifth bullet point:

1 Like

At the beggining of the day, this issue spawned because we used lights for our folding wings. That way they were multiplayer dependent. Now it’s not trasmitted obviously, but I agree with @SeeRyFly, we need more multiplayer variables, not less. At the minimum, give us a couple 64-bit custom vars that transmit over the server and leave the lights as is. You’ll still get the optimization.

I guess, in conclusion, these variables have been in place since the beginning of MSFS. Throughout the last 2-years many developers have become accustomed to using these extra lights for other means outside of actual lighting. Maybe best not to remove their functionality. Just my opinion, but I fully understand the need for optimization.

The “another developer” from the first post here :slight_smile:
There are three main issues that has happened:
1: It now only syncs index:1.
2: The light simvars are no longer transmitted as 64 bit over MP, but only boolean 1 bit, according to what’s actually received by simvarwatcher.
3: The syncing of light simvars is only working on default aircraft. Addon aircraft does not sync the whole list. It seems to pick a random number of simvars to sync between “0” and “some”, but it’s consistent for each aircraft between reloads.

I wonder if it’s now actually not syncing the individual light simvars at all, but actually only syncs LIGHT STATES and then unpacks that locally after transmission on the FAKESIM multiplayer simobject, which explains issues 1 and 2.

This is a huge loss of bandwidth for making aircraft work better across multiplayer.

(By the way, docs for LIGHT STATES is wrong. It’s missing bit 11 which is pedestal and bit 12 which is glareshield (counting from 1, not 0)

Is my speculation correct?
Is 1 and 2 intentional? If so, can we please have some other synced long range 64 bit vars to compensate for this loss?
3 has to be a bug?

2 Likes

+1 Please !!!

1 Like

Yes I agree.

1 Like

wow +1 … MSFS barely qualifies as a multiplayer game, just passing player locations around is like the first five lines of code and in MSFS even that seems an unplanned afterthought. Is MSFS intended as a multiplayer game? The reality is there’s no actual multiplayer system by any reasonable measure. We’ve been busy trying to multiplex multiplayer features onto the incredibly weak primitives that are available, such as spare bits in the hardcoded external lights support, so it’s disappointing to have Asobo break even that limited support before providing a planned alternative.

Microsoft with all it’s Azure strategic positioning and focus on social networking seems to have not noticed MSFS has the absolute minimum support for multiplayer.

Devs asking for “a couple of 64-bit custom vars” shows how low our expectations are.

4 Likes

WombiiActual

The “another developer” from the first post here :slight_smile:

There are three main issues that has happened:
1: It now only syncs index:1.
2: The light simvars are no longer transmitted as 64 bit over MP, but only boolean 1 bit, according to what’s actually received by simvarwatcher.
3: The syncing of light simvars is only working on default aircraft. Addon aircraft does not sync the whole list. It seems to pick a random number of simvars to sync between “0” and “some”, but it’s consistent for each aircraft between reloads.

  • If so, can we please have some other synced long range 64 bit vars to compensate for this loss?

So after SU14, many developers are struggling with their Plane no longer “syncing” additional features of their planes over MP, and no potential solution till Asobo adds “some other synced long range 64 bit vars to compensate for this loss” which may not come till at least SU15, some months away in 2024.

Ideally, Asobo could add those in in a HOT FIX, or at least in a First early SU15 beta, so that Devs can get to work, getting that lost functionality back.

Would make a welcome “Christmas Present” to all !!

Maybe this is the reason. MSFS is 3+ age certified, but the modding community decided to abuse the light variables index to show/use multiple weapons in multiplayer. Maybe Asobo has been told by Microsoft to block this. Microsoft doesn’t allow weapons in MSFS. Marketplace show this.

@dev,

The modding community in general (not just MSFS) have been manipulating all aspects of base games in order to push boundaries. To say that developers have been “abusing” an element of the game to promote there own advances is outrageous.

This comment is obviously targeting our team because we are the only developer that has added multiplayer weapons to the F4F-4 Wildcat using light variables. I have not mentioned that anywhere in this thread and you have obviously dug into my files to specifically single me out regardless.

Overall, I’m confused at your input here in this thread. Your first response was rather mute as you simply re-directed us to the SDK Documentation. Then you respond by targeting our team and making conspiracy theories about Asobo blocking the use of light variables to lower the expectations of the modding community.

Neither one of these comments are productive and promote negative connotations and make me question your role in the modding community.

1 Like

I’ve never bought any of the products from Got Friends. I do know who you are and how highly rated Got Friends products are. Also really don’t need to dig into files as it’s general comment about the current mods available. Clearing this up :slight_smile:

Maybe just a coincidence then that you are only referring to a form of development that our team has done.

Thank you for clearing that up and I apologize for coming off so stern.

I am passionate about accurate simulation and that includes weapon simulation.

That said, I appreciate your clarity but I’m pretty certain our development practices are not the case as to why Asobo blocked certain parameters.

There are multiple sides of the story to every action taken. I try to find the most common reason why features are removed or disable and most of the time it’s because of abuses. The history of multiplayer in gaming communities is harmful.

My role in the modding community isn’t a full time profession. I do this as a hobby.

I really support the addon community. But, of course, I do question if certain processes are right to continue. To modernised the sim for the future. Many of these features will be supported in MSFS 2024. Careful decisions must be taken. The community is one step that can help Asobo take these decisions forward.

Sorry if I come off as negative, it wasn’t the intention.

I apologize as well.

Hope you have a great holiday season and maybe soon Asobo will respond to this bug report.

Cheers

1 Like

Good, having got past that, maybe a more postitive direction is to directly ask Asobo, for some more details as to what they actually did to increase MP performance. (and why)

This would seem to be a "reasonable’ thing to ask in the SDK Dev Forum, as it has obviously changes areas of MP, that affects current and future products that ideally should be adequately described in the SDK.

What surprises me is that removing features like Multi Index’s for some lights, that is only used for a very small percentage of current aircraft, could possibly make that difference to MP performance for everyone else.

Has the Performance of MP, and its past issue of Players disappearing randomly, really been improved in SU14 ?

Certainly during SU14 beta, the numbers appearing in any MP sessions were dismally small, and could hardly have provided any meaningful test results.

Also, it would seem that Rotorcarft, with more parameter Words being shared over MP, take more than their fair share of the MP bandwidth, at the expense of non-rotorcraft objects.

Is it know what the update rate is of any of these MP parameters,-- are they all the same, or do they vary ?

So many unanswered question – some answers would be most welcome…

How about a more descriptive MP SDK !!

Hello everyone,

This is being investigated.
It seems the problem occurs when the corresponding light is not declared in systems.cfg
We ran some tests with the Wildcat from GotFriends and adding the declaration of a logo light in the [lights] section solves the folded wing issue.

We still need to find what caused this regression and will come back to you as soon as the cause is identified.

Regards,
Sylvain

5 Likes

Thank you for looking into this. I agree that adding a light definition to the systems.cfg fixes some of the issues but it does not fix everything.

The F-86 Sabre has visibility conditions set so that if LIGHT PEDESTRAL:1 is on, fuel tanks will show. LIGHT PEDESTRAL:2 is rockets, and LIGHT PEDESTRAL:3 is bombs. When the light goes off, the corresponding model is hidden so only one type can be shown at a time.

Immediately after SU14, none of them showed up in multiplayer at all. In my testing, I added light definitions for each of the three pedestal lights to systems.cfg as you describe, and now all three models are shown when any of the 3 lights are on. In single player they work as they always have. So it seems there is a deeper issue than just requiring lights to be defined in the .cfg

3 Likes

Thank you so much for the response and I’m sure the entire community thanks you for looking into this issue.

I would like to preface that I know using lights for multiplayer systems is unorthodox, but our team is very grateful for your understanding of the importance they hold.

Prior to SU-14, lights (and their respective indexes) where only required to be in the [ELECTRICAL] section.

Cheers and thank you again.

1 Like