As the update 460 was released I started getting more and more reports of bugs in my game.
The first bug that appeared was that the tools in my custom toolbar was disappearing.
The tools are suppose to disappear when Tool.Enabled = false, but for guns that never happens.
As of 460, something is setting the Tools Enabled to false when you equip them. Not every time, but enough times for the tool to disappear after 5 or 6 equips.
As for what sets the tools enabled to false only the people at roblox could figure out.
Second bug (Has been resolved)
[FIXED] The second bug (has repro) has to do with network ownership.
My throwsystem relies on throwing the tool handle by:
Destroying the equipweld
Setting the handles velocity locally
Moving the handle into workspace
Disclaimer: This is a quadbillion times faster and more accurate than creating fake projectiles on the server-side. I’m not here to discuss efficiency though, I’m just reporting the bugs.
None of the bugs occure when you play alone, but the second someone else joins these bugs starts appearing.
In this new update it would seem the server tries to re-claim ownership of the projectile once its put in workspace. Once it’s claimed the projectile it re-enforce the weld, which was already destroyed, for a breif moment until it realize the weld is actually destroyed.
That is why the chinalake projectile is teleported back towards its orgin and then fall down.
That would explain why grenades have little to no energy once thrown.
Reproduction steps
Here’s the file for the second bug: weld__repro.rbxl (23.4 KB)
How to use:
Spawn 1 Server + two Players.
Use Player1 and click anywhere with mouse.
Notice how the projectile flies sideways.
Use Player2 and click anywhere
Notice how the projectile just drops down.
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