[1.192.021] In-game scripts using sprites don't work in MP

Whiplash141 shared this bug 2 years ago
Reported – Awaiting fix

In Single Player or local MP as a host in-game scripted screens display properly:

GXZsA3y


In a Dedicated Server or local MP as a client, in-game scripted screens using sprites look like this:

SNjDKGt


Steps to reproduce:

1. Start a single player game (with in-game scripts enabled)

2. Spawn in the ship attached to this post. The LCDs on the bridge will display properly like the first image.

3. Start a Dedicated Server game (with in-game scripts enabled)

4. Spawn in the ship attached to this post. The LCDs will display the bright default blue background instead.

Best Answer
photo

Adding an empty MySprite() at the beginning of your draw frame periodically will force the game to send all the sprites. It caches them in an array so if you send the same sprites, it will ignore duplicates. Adding one at the front shifts the indicies and makes it draw again.


The issue seems to be with sprite streaming to clients. This often arises when entering sync range. For whatever reason, the client does not get all the sprites, and since the server only sends unique sprites, if one fails to reach the client, it never will unless you force it to be sent again.

Comments (10)

photo
1

Have been playing on a PVP server, half of the time the lcds had this problem

photo
1

so i play on Local MP, im alone atm..does this mean as soon someone joins it, the LCDs will become blue?

photo
2

Hello, Engineer!


Thank you for your feedback! Your topic has been added between considered issues.


Please keep voting for the issue as it will help us to identify the most serious bugs.


We really appreciate your patience.


Kind Regards

Keen Software House: QA Department

photo
1

very funny @KEEN! THEY DONT WORK!!!

photo
4

I was able to reproduce the issue and reported it. I hope we will manage to fix this son, We will update the thread once we have more information.


Thank you, Whiplash.

photo
1

WHIP! ARE YOU A DEV????

photo
4

FYI this is still broken as of 1.192.101 despite the change log listing it as fixed.

Examples:

d3911219d38ff45da61309511ca9302c299f5f8dd48169a491467b1db26ef82f

photo
1

The issue is still present. Is Keen working on it? Or is there a workaround?

photo
1

yup i can confirm, all lcd script using sprites are not working because of this... please fix thing... again...

photo
1

i hope they fix this soon

photo
photo
4

Hi,

i may confirm this in the latest release now. I just finished a LCD script to display oxygen pressure and want to share some interesting points.

It seems to definitely occur as soon as IMyTextSurface.ScriptBackgroundColor or IMyTextSurface.ScriptForegroundColor gets changed by the script.

Workaround: Never touch those 2 values, instead draw a 100% covering SimpleSquare with the desired color in background first.


It also seems to occur in other situations, i just got the behaviour after a server restart.

Workaround: Implement a INIT sequence, setting all your sprites for at least 1 tick to a different color (or maybe change another sprite property). Changed sprites seem to get updated properly. Don't forget to set all sprites back to normal color after initialization.


With these 2 workarounds i feel able to bypass most of all problems... not nice but functional.

photo
2

Here some more infos i got meanwhile:

It also happens as soon as i leave the rendering distance of the script.

Each time i come back from asteroid mining, it's bugged.


What actually happens is, all static sprites which haven't been changed are invisible only dynamically updated sprites in size or color will be displayed.

photo
3

Adding an empty MySprite() at the beginning of your draw frame periodically will force the game to send all the sprites. It caches them in an array so if you send the same sprites, it will ignore duplicates. Adding one at the front shifts the indicies and makes it draw again.


The issue seems to be with sprite streaming to clients. This often arises when entering sync range. For whatever reason, the client does not get all the sprites, and since the server only sends unique sprites, if one fails to reach the client, it never will unless you force it to be sent again.

photo
4

still a thing 11 month after it was posted

photo
3

There is still this problem

photo
photo
1

Oddly, it seems its the scripts I made (and write textures/text with sprites), that get affected. When I use that built-in "Artificial Horizon" script on an LCD display, it is always AOK on our server. Might be because that script itself is doing the 'workaround'??

I will try doing the Whiplash workaround and see if it makes my own LCD's behave better on our server. If i understand it correctly..... which I'm not 100% on, because I thought the act of getting the draw frame and drawing sprites on each Update (10 ticks in this case) was sending/making new sprites because it would remove prior sprites.

Anyhow... will try that... since it seems Keen isn't keen on fixing the problem being how many months ago it was mentioned?

photo
1

After doing the suggested workaround, where I now add 1-3 blank sprites before an update, all our custom made LCD panels that use sprites/textures are working just fine on our DS.

Thank you Whiplash, for that workaround!

photo
1

The reason the built in scripts work is because the code for those runs on the client; there is no sync going on. In-game scripts run on the server, so the sprites it draws need to be synced to your client. The transmission of those synced sprites is clearly not 100% reliable and idk why

photo
1

Yea, InGame scripts are run during the lcd update. Hell the lcd pokes the Run() of the script and keeps track up the updateticks. for it. Ugh spent an hour talking step by step though MyTextPanelComponent. Its not in there. I will say that the UpdateAfterSimulation is being called with isInRange=true. I am also 90% sure the sprites updated from the server to the m_renderLayers. Hell I am fairly sure the offscreen render texture is updated. Best I can figure is that its something to do with the players position as that is used when detecting something is "near" them to render NOT the view camera. All THAT code is in the IMyRender (aka the DX11 renderer) and its 2 am and I am sleeping.

photo
photo
1

I'm still having this issue. I'm running a dedicated server on a LAN and connecting locally.

photo