1.197.168 | REGRESSION | Fix programmable block sprite streaming for clients

Whiplash141 shared this bug 3 years ago
Reported

In update 1.197.168, the attribute [DistanceRadius(32f)] was added to the OnUpdateSpriteCollection() event that is responsible for syncing sprites drawn by programmable blocks.


In less code speak: This means that if you take control of a grid and your screen is more than 32 meters from its center, you will not receive sprite updates. Yes.... 32 meters.


This is very easy to demonstrate: https://gfycat.com/playfuluniquedog


Note how when I hop out of the seat, everything works fine. This is because the game is using my player to check the distance to the screens. However, when I hop in a seat, sprites stop updating. This is because when you take control of the grid, the game uses the center of the grid, not your player, to check the distance to the screens. Clearly any large ship can have seats further than 32 meters from the center...


Please Keen, for the love of all that is sacred, find a better way to reduce network traffic. This implementation cripples the utility of in-game scripts, and is already being noticed by script users.


World is attached:

  1. Start the world in a Dedicated Server
  2. Join as a client
  3. Sit down in the seat and observe that the sprites stop updating. They no longer get synced.
  4. Get out of the seat. Observe that the sprites start updating again.

Replies (5)

photo
3

Image displaying the issue. I attached a debugger to the game, hosted a game and then placed a breakpoint where proximity to the screen is checked, then manually plotted the positions using GPS markers.


You can see that when I sit down, it is using the grid pivot (not the center as I initially posited) to test proximity. That is even worse because the grid pivot can be way outside the geometry of the grid itself.


Unseated:

HfvkN5x


Seated:

SnVIrG8


Seated zoomed (with grid pivot drawn):

HHfo6bT

photo
3

I can confirm this. This is the same bug i reportet two days ago. Thanks for the really good research whiplash.

Edit: Because of your research i found out, that the grid pivot of older grids and blueprints is messed up. In my research about this bug(Sprite Streaming) i noticed the problem only on older grids and blueprints, that were build before the update and i thought this was the problem. But with the debug options you see, that the pivot point isnt in the right place on old grids. Maybe you could take a look in the blueprints i posted to confirm this theory.

LCDs and other Displays with Scripts wont Update on DS | Space Engineers PC Support (keenswh.com)

photo
2

just found out that the pivot point has nothing to do with the rotation lol. why is the first block building location called pivot point. forget my last edit above

photo
2

the grid pivot is the center move it closer to the lcd by merging the grid to the ground with the pivot nearest to the lcd and it fixed it for me

photo
photo
2

Just today, on our private dedicated server, I loaded in and welded up a small mining ship I made this week. It has custom LCD sprite drawing to the left and right LCDs in its cockpit. This is a small grid ship that is barely even the size of 2x3 large grid blocks (so 5x8meters?).

We are having all amounts of random pieces of the LCDs not draw. Sometimes they ALL draw (borders of status bars, the pips inside the borders, energy icon, text labels etc). Once, one LCD didnt draw anything but the ScriptBackgroundColor.

Loading the Creative single player save I built the ship in, the LCDs were perfect no issues. They updated every 10 ticks, they showed all elements. Even during a 15 minute round trip to the moon and back with a load of ice picked up from the moon.

So for me (today):

It wasn't about lcds being too far from the grids pivot point (its a tiny small grid ship!).

it wasn't about the lcds being on an old build or from an old blueprint (I actually built it all just this week from the ground up).

Single-player works fine, while dedicated server its complete wonky.


This topic is the closest report I've seen to describe what I get, so I don't know if its related, or completely unrelated. However something is seriously "fubar" with MySpriteDrawFrame frame.Add(MySprite) and dedicated servers.

photo
1

Most of multicrew ships on PvP servers now are just about unusable state beacause 80% of utility scripts are not being displayed correctly. Some players see changes on the LCD, some players don't. We need a hotfix, Keen.

photo
2

Hello, Engineers!

First of all, thanks all of you for comments and saves/BP. However, I´m still not able to reproduce the issue you are mentioning.

Whipslash141, thanks for save. But the values on the screen are not updating whatsoever on the screen: ERROR1: no ship controllers were found. Same behavior for both - host and client as well.


/67ec3229530ade33224cf813aed6c8b8

Gabriel, you BPs shared in the other thread are not showing the issue as well. Both BP are working the same. Values updating the same on AAA_broken as well as AAA_working.

Can any of you please share a working BP/save where it would be possible to see the issue as it is not working, please?

Sorry for any inconveniencies this might bring to you. Hope you understand and can provide more info so I can hunt it down and reproduce the issue.

Kind Regards

Keen Software House: QA Department

photo
3

Ive tested whiplashs world and the bug works as described.

First i set up a new dedicated server with experimental mode and ingamescripts enabled.

Then i loaded the world and teleportet to the grid.

The Error "No Ship Controllers were found" could be because of ownership. Transfer all the blocks to you and recompile the script. Then it should work.

Now sit down in the seat and observe the stuck LCD, which will only update, if you are not in the seat anymore.

photo
2

That script is pretty simple in setup and is just looking for a ship controller on the grid and a screen named "Horizon". If it says no ship controller is found, that means that either (1) there is no seat on the grid(there is in the world provided) or (2) it can't see it because of ownership like Gabriel mentioned.

photo
4

Gabriel, Whiplash141,

thanks both of you to guiding me the extra step! :) I did not own the whole grid; silly me.

After following your advices the issue was indeed successfully reproduced and I put it into our internal system.

Kind Regards

Keen Software House: QA Department

photo
3

Awesome, thanks!

photo
Leave a Comment
 
Attach a file