After this update I noticed something similarly wrong in my game that’s too suspicious to be entirely unrelated. When there is another user in the server, if you join and equip a tool, the gui for the tool appears briefly and then disappears again. If you equip the tool again a second time, it works correctly.
I have not troubleshooted in Studio exactly what happens yet since I just now found out another player is the trigger for it. Will check tomorrow.
My tools create the gui by reparenting an existing screengui under the tool hierarchy to playergui on Equipped, and back to the tool on Unequipped. Nothing else fancy happens.
I have the same problem as you. I finally figured a work around by adding a .5 second delay before enabling the GUI.
My GUI stays in the tool I Enable and change the adornee to the player on tool Equip. Printing debug info from the localscript during the error state shows the GUI exists, is Enabled but alas, it has vanished!
Same as you guys, no problem with single player (private server).
It looks like if you join a server with other players already there, the tool GUI is reparented back to the tool as though the Unequipped event had been fired, but a print in the unequipped listener does not fire. If I remove the unequipped listener, the issue still happens. If I print what happens on Tool.Changed, there are no clues - the tool is not disabled like what OP mentioned happened to them.
A repro for this specific issue is here: ToolGuiBug.rbxl (23,5 KB), join two players with a local server and equip the tool.
This issue is most likely related to the problems OP is seeing since it also started happening after 460 and only happens when you join a populated server.
Your post helped bring to light an issue with a recently enabled feature, so we disabled it yesterday, so thank you We will make sure weld__repro.rbxl works correctly when we fix and enable the feature again. Sorry for any inconvenience
Is the backpack issue still occuring? I am having trouble reproducing with the provided repro file in studio with several players. I can equip/unequip the tool on each client several times and the ui seems to appear correctly.
The weld_repro.rbxl was just for the second bug.
The toolbar (first bug) had no repro file. But it seems to be resolved in new servers. I can ping you if it comes back?
I could not reproduce the tool gui issue with my repro file anymore. It was happening still in some old servers in my game but those seem to have cycled out now. Appears resolved?
We rolled back the flag that was causing this issue. We will address this issue and make sure we have a test in place before rolling this flag out again. Thanks for the report and sorry for the inconvenience!
Hi. I’m a bit late to the party. First I had to find a post related to my issue since I still haven’t been promoted to Regular and can’t post in engine bugs :/.
I’m not sure if it was 460 or 461 that broke it, but for Mac players in my game the weld for Melee weapons seems to be broken and what’s worse is that we have ships that rely on Body Postion and Body Gyro, also for some unfortunate Mac users when they get ownership of the physics, the ship falls off the map. Seems like the default water ignores the object completely, either that or the client somehow overpowers the water physics.
This happens 100% of the time for a few users. I’ll be probably ditching the old ship physics anyway, but thought that you should know about this issue. I can try and provide more detail if needed.
It seems what we (Sea of Pirates) and Pilfering Pirates have in common is that both games give Network Ownership to the driver. As I know it happens on some Macs (reported OS being High Sierra). I hope this info helps isolate the problem.
. Sadly not the case