Stress testing -> In an instance of 17 tables (Some pool cues become non-interactable and break)

[Greedboy-55]

So, currently making a world for pool tournaments. World is currently going through stress testing. This world has 17 pool tables, split between two rooms. Each room has 8 (9) tables, and the tables in the opposing room(s) are culled.

The tables work very well, but about an hour into the instance (with around 60 people) the pool cue (seemed to always be the nonbreaking pool cue) on some tables breaks, and makes the game unplayable. Logs don't report anything. Attached a screenshot below. 3 out of the 17 tables have done this. Is there a limit that we're running into here?

Next test i'm going to be removing 4 out of the 17 tables to see if that helps resolve the issue.

[Greedboy-55]

You can see that the pool cue on the end of the table is misplaced, and stays in that position on game reset. This happened when people were playing mid-game, and when the pool cue was released.

[Greedboy-55]

[FairlySadPanda]

That's really strange; I'd almost be tempted to blame VRChat for a load problem. This is one of the reasons we're doing a rewrite. The problem here is the conditions: a soak of an hour in a loaded instance with an unusually large number of tables is going to be nearly impossible to replicate reliably.

Given this is for an event I'm happy to eyeball this code and make a guess, but the number of variables is really high and it might require a drastic rework of the cue controllers, something that could take a while (and would be work we cannot bring forward into VRCBCE 2.0)

[FairlySadPanda]

What I can do is do a "help, the table is broken" reset button that will try and reset the cues and print out a reason if they can't. This will be a hotfix patch - keep an eye out.

[Greedboy-55]

Sounds great. Appreciate the input! I'll look out for the hotfix.

[FairlySadPanda]

Hey there;

I've managed to scrape together some time to work on 1.6.0 again; this has allowed me to do a bit of cleanup to the area of code that might be causing this, and I've also significantly improved our reset functionality.

This code has been pushed to main branch. @Metamaniac , who covers VRCBCE releases these days, will be massaging it into something that can be released. However, as a TLDR (and a very short-term workaround), I've basically improved the _ForceReset custom event on the Pool State Manager code (so that's the script on the Core Table Code object inside the prefabs) so that it should be usable to do a forced table reset in the instance where this break occurs.

At a minimum, rigging up a button in your world to call that function should allow for a broken table to be attempted to be reset, via specifically telling both cues to reset. This will end the game in process. I've set it so that the Instance Owner or a player can use the function. Let me know if you want Master to also be able to reset the table.

This may cause unforseen consequences: I've had limited testing time and I'm hoping @Metamaniac, who has some free time coming up, can double-check this feature does not break horribly in VR.

This looks like a rare bug under load and soak time: as one dev there's unfortunately a limit to what I can do with this sort of bug. We're hoping to do a full rewrite in the near future which will make catching these issues easier.

[FairlySadPanda]

@Metamaniac has done some cleanup since I made this patch and I think we may have resolved this issue. Marking as closed. If the latest code on this Github (not in releases, but the master branch itself) doesn't resolve this, please let us know.

[Greedboy-55]

Thank you all for your hard work! I'll let you know how it goes!