Lumber Tycoon PGS Physics Instabilities and Networking Issues

Bug Reports Engine Bugs
#1

I’m a huge fan of physics games, and that’s why I made Lumber Tycoon how it is. What I’ve tried is probably a bit more than what Roblox can handle, but if nobody is trying to make games like these, there aren’t going to be any good benchmarks that can be used to improve Roblox physics. If you want to fix something, you’ve got to see how it breaks. I made this game and this thread with hopes that it would be insightful to the wonderful engineers at the HQ. I also hope it will be insightful to other developers who are trying to tackle similar problems.

A solid ~70% of the bug reports I’ve received are physics related. My expertise is limited, but I’ll try to speculate about what’s going on, and hopefully this will be helpful.

Hinges flip out sometimes

This is a tricky one because sometimes it never happens, sometimes it happens occasionally, and sometimes it happens consistently. It’s a huge issue for vehicles. Here, it was happening consistently to my roommate whenever he hopped out of a vehicle, but it wasn’t happening to anyone else in the same server. Eventually, after 20 minutes or so, it stopped happening to him for the most part.

Since it was only him, I suspect it was a hiccup in transferring network ownership from his client back to the server when he hopped out. He’s on a mac, but users have reported this on all platforms.

The network ownership transfer explanation makes the most sense to me, but this also sometimes happens as soon as a vehicle is spawned, without the need for a person to sit in it first. However, when it spawns, network ownership hasn’t been explicitly set yet, so the client could still be taking auto ownership and causing these issues.

Here’s a pretty hilarious example of the same issue, in which the car ends up embedded in the wall of the store:

Character movements aren’t replicated

This was my roommate in the same server as the above videos. He had gotten out of a vehicle and his character fell over, and at that point his character stopped updating the server with where it was. Animations were still replicating, and the logs he is cutting through RemoteEvents and dragging clientside with network ownership are still replicating. This only happened for a few minutes. This wasn’t gamebreaking, but might be insightful to the kind of connection problems he was having that could have been helping to cause the above bug. Other players confirmed that they could also not see his character.

Clients sometimes incorrectly perceives the physics of parts

This can be observed here:

At 1:10, I see the logs in the truck sliding back and starting to fall out. At 1:25, they jump back to where they were before they slid. This happens in a few instances throughout the video in more subtle ways, but that part seems to be the most obvious case in the video.

It looks to me like my client is making incorrect assumptions about what’s going with the physics on the server, perhaps during brief connection drops, and when the server finally assures the client of what’s really going on, the client corrects everything.

I’ve seen this happen it much more dramatic ways as well. People would be driving and their entire train of trailers would flip over and their wood would fly everywhere, and then everything’s back as it was a moment later.

It’s very jarring, but usually not game-breaking. It can be breaking in cases where the client takes ownership of an item while this is happening, and it adopts its incorrect assumptions as an initial condition instead of what is really happening. I’ve seen this cause big issues.

If I am correct, this looks like more evidence of underlying networking issues.

Grabbed parts are unstable because of high BodyGyro D

When a part with a BodyGyro is welded to the end of a long, slender member, a high dampening value will make it unstable. I’ve reduced the D on updated servers, but this makes items that players carry wiggle a lot more, and it’s a bit harder to carry things. I’d like to be able to use a higher dampening.

Repro: Dropbox - Error - Simplify your life

1 Like
#2

This still happens occasionally, but I’ve largely been able to rectify this issue by identifying a bug the transfer of network ownership, which is just what I was suspecting was the problem.

The issue was that the ownership for all the parts was not necessarily being changed from client back to server all at the same time. I found that the client fired the ownership request remote individually for each part the client wanted. The client was firing the remote for every part all at once, but the server was not necessarily receiving those signals all at once, and so network ownership was not necessarily picked up and dropped for every part synchronously. That effect is just a result of my particular execution. I’ve found that when multiple loose parts that have different network owners are trying to interact, especially when in an arrangement like a bucket of loose parts, big issues will happen. That’s what was happening here.

This bug is consistent with my original observation that clients with poor network connection were particularly affected. If connection is poor, then it is most likely that the server will not receive all of the remote triggers synchronously.

The solution was to have the client first assemble all the parts it wanted to request network ownership for, put those in a table, and then fire the request only once for all the parts. This ensures everything is received at the same time, and we’re on one server thread for all of the parts instead of spreading it out.

#3

I didn’t realize ownership could be called by a player even in FE. Isn’t that a security risk? Would it not be better for the server to say, “here, you take these parts” instead of the client saying “I want these paets?”

#4

You can’t call the ownership function from the client. In my particular execution, ownership is set by a server script at the request of the client through a remote. I.e., the when the client initiates a part drag, it fires a remote to the server to request network ownership of the part. That’s what I’m describing.

#5

You can’t call the ownership function from the client. In my particular execution, ownership is set by a server script at the request of the client through a remote. I.e., the when the client initiates a part drag, it fires a remote to the server to request network ownership of the part. That’s what I’m describing.[/quote]

I’m now confused: you mention that two parts in the same mechanism (the car) had different owners at the same time, which is why the cars flip out. I thought you only needed to set the ownership of a single part in a mechanism for the whole mechanisms ownership to be set. Is this not the case?

#6

You can’t call the ownership function from the client. In my particular execution, ownership is set by a server script at the request of the client through a remote. I.e., the when the client initiates a part drag, it fires a remote to the server to request network ownership of the part. That’s what I’m describing.[/quote]

I’m now confused: you mention that two parts in the same mechanism (the car) had different owners at the same time, which is why the cars flip out. I thought you only needed to set the ownership of a single part in a mechanism for the whole mechanisms ownership to be set. Is this not the case?[/quote]

No, you’re correct that two parts in the same assembly cannot have different owners. I’m talking about a case in which you have a bunch of free parts, not in an assembly, that are in the back of the truck and have different owners. All of the loose parts are resting on each other and trying to keep an equilibrium state, which is really hard to do when everyone is fighting over physics.