I made the repro as close to the real game as possible, using every method and object I use in the other game. Like, making everything rendered client-sided, using the same pin models with welded parts, the same ball size and physical property settings, absolutely everything should be very very close.
I never got it to do the issue once in the repro. But this is definitely still an issue in my other game, and it has nothing to do with welds being made or the pins getting anchored at random points; because in one GIF I had, the ball deflected but then was able to hit the pins again shortly after deflecting and then physics were applied, so this is definitely an issue with the physics solver.
Information
This bug has been occurring ever since I first made my Bowling Simulator, the date of creation at about 4/19/2017, with the link for the game listed above. Sometimes, the ball will deflect off the pins and no physics are calculated. Youâll see in the video, physics start solving again right after the ball bounces off, which is weird and obviously points to a flaw in the physics engine.
The pins are MeshParts which do have other parts welded to it, everything is massless. The other parts are meant to âenhanceâ the physics with the pin. My whole game is rendered client-sided, for the smoothest physics possible. (All models are created on the client directly.)
Iâve also heard reports of this same issue occurring in other bowling games, not just mine.
It might be an easy solution just to include a new property on instance objects called something like âCanSleepâ that when turned off, will always have physics calculations ran on it at all times.
This bug report is a continuation from this topic:
Okay that rules out one potential error. I have not been able to reproduce the issue with the file you shared. Hereâs all I can tell you right now.
I never got it to do the issue once in the repro.
Then itâs not a repro. (Repro is short for reproduce, as in, a file that will reproduce the issue). If you have a simplified place that under no circumstances will reproduce the issue you are describing, then you might as well assume that the issue is caused by something not in your simplified place file.
The pins are MeshParts which do have other parts welded to it, everything is massless.
This may not have the result you are expecting. Its impossible for a whole set of welded parts (an assembly) to be entirely massless. One of those parts will be the assembly root part, and the assemblyâs mass will be equal to that. More info: New BasePart Properties: Massless & RootPriority
It might be an easy solution just to include a new property on instance objects called something like âCanSleepâ that when turned off, will always have physics calculations ran on it at all times.
We have no evidence that this issue is related to sleep. In fact, in the place file you sent, you can turn on sleep visualization and see that the pins are sleeping before the bowling ball hits them, and then wake up just before being hit and physically react properly.
I have no other reports of parts failing to wake upon collision (before or after recent sleep change), which is why my initial assumption is that this is not a sleep issue.
Have you ever been able to reproduce the issue in Studio? Or have you only ever come across it in the live game.
Iâve noticed that both of your clips come from your in-game ârecorderâ feature. Is this bug only happening in the replay feature? Or is this just playing back a record of the partsâ cframes, so it did happen in the actual game first.
Maybe you could try logging more info with your replay system, such as the pinsâ properties and descendants. That could help show if some part is getting into a weird state.
Based on the script in your file, you are adding welds and setting the anchored property in your code during runtime, so its possible something in your game is handling that improperly (like a weld is being removed too late). You could try welding everything in edit and removing any weld instantiation work from your code.
I can confirm that this issue happens in live game, and in Studio testing as well. The replay system saves a number of CFrames each shot of the pins and the ball, so itâs 100% accurate on the shot you just threw.
Although it happens rarely, I believe it does still actively occur. I can take a look at getting rid of runtime welding operations, but if thereâs any other ideas you have Iâm open to trying.
Iâm also not sure if youâre interested, but Iâm willing to send you privately my entire game via messaging, if thatâs at all helpful.
Also just a follow-up, but Iâm really hesitant to agree with you that welding could be the issue. Why? Because if there were welds that were interfering with the ball; then the ball wouldnât be able to travel down the lane, correct?
And the welds are never modified on the pins once done initially, thatâs just to keep them together as they consist of numerous parts.
Out of curiosity, who owns the physics of the ball, and who owns the physics of the pins?
I could see a potential issue where the player owns the ball but the pins are owned by the server, then the server might not get an exact copy of the balls physics when itâs replicated.
As I mentioned in the original post, all the models are rendered client-sided, so there isnât a need to set the network owner of anything; everything belongs to the client.
It was just something to double check about since right now, neither of us know how to make your issue occur, so there arenât any leads as to what causes it. But youâre right, Iâd be surprised if that was the problem, but you need to start somewhere.
Sending the entire game wouldnât help because that would put me in the same position as you, and I donât have time to continually play your game until I see the bug, or scan your code for errors. Thatâs why I suggested logging more info, so that next time the bug does occur, you can investigate more in detail, and maybe get a better idea on the conditions that cause it.
If you have other things you want me to try to implement hit me up. Meanwhile, Iâm gonna try adding a few other things to the repro such as adding in a BodyVelocity with no active velocity on it; as thatâs included in the ball in the main game. Probably has no significance to anything, but it doesnât hurt to try.
Also just to verify, is there any significance to the âIsSleepAllowedâ property in TestService? I realized I actually had that turned off some time ago, and just recently turned it back on, and I donât think Iâve experienced the bug since I changed it. Really doubt itâs significant by any means, but just thought Iâd include this as well.
Additionally, Iâd just like to thank you for working with me on this problem. This is the most progress Iâve had in terms of debugging this. Itâs literally been plaguing my game since I first started working on it
Iâve been seeing physics breaking and freezing for some time in other games too, such as Doomspire Brickbattle. Then, all of a sudden, it snaps back on.
Here are sonme images of physics freezing (no objects moving in the image)
At first guess, this looks like an issue with network ownership, where parts are anchored on the server but not on the client. Please post a new bug report following bug report guidelines if you would like it investigated further, or share on Help and Feedback to get input from the community.
This will not impact anything unless TestService is being used (a script calling TestService API is parented to it, and the âExecuteWithStudioRunâ box is checked), but this toggle will give you the same behavior as the âAllow Sleepâ toggle in File>Settings>Physics. Turning âAllow Sleepâ off will keep all non-anchored parts awake for debugging purposes. So if you do find a way to reproduce the issue consistently, you can disable sleep and see if your issue still happens
As you can see, the pin thatâs spinning around clearly hits the 5-pin (pin in the middle) but that pin appears to be sleepingâŚ
On top of this, I think Iâm noticing additional sleeping issues with ball return physics. The ball use a BodyVelocity to propel them when on the ball return, and when ever I select a ball off the rack, the other balls that should move forward donât for some reason until my next shot when I take another ball off the rack, if that makes sense.
