Update 460 broke several key features in my game

Platform Feedback Engine Bugs
#1

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:

  1. Destroying the equipweld
  2. Setting the handles velocity locally
  3. 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.

Evidence
Here’s how it works before anyone else joins:
https://gyazo.com/1183f8c9fd48e446cc3281bfa450f06f
Here’s how it works after another player has joined:
https://gyazo.com/bd18be4b52450ec022971c16ef83107a

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:

  1. Spawn 1 Server + two Players.
  2. Use Player1 and click anywhere with mouse.
    Notice how the projectile flies sideways.
  3. Use Player2 and click anywhere
    Notice how the projectile just drops down.

They both use exactly the same code.

Gamelink: https://www.roblox.com/games/5108997584/Reason-2-Die-1-5-1a

12 Likes
#2

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.

4 Likes
Release Notes for 460
Images become "invisible" when parented to PlayerGui
#3

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).

2 Likes
#4

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.

3 Likes
#5

I have created a post for this specific issue already here

1 Like
#6

Thanks for the report! We’ve filed a ticket to our internal database and we’ll follow up when we have an update for you.

Please note that filling a bug report does not guarantee that it will be fixed once triaged.

6 Likes
#7

Doesn’t seem like 461 fixed this. Same issue, .5 second delay on the GUI makes it work properly though.

1 Like
#8

Not speaking for the other issues discussed, but the second bug posted here (weld__repro.rbxl) seems to be working after 461. Can you confirm?

5 Likes
#9

Second bug is fixed. I’ve tested it in studio and new servers. It works just as before the update.
Thanks a ton! :slight_smile:

#10

Hello,

Your post helped bring to light an issue with a recently enabled feature, so we disabled it yesterday, so thank you :slight_smile: We will make sure weld__repro.rbxl works correctly when we fix and enable the feature again. Sorry for any inconvenience

4 Likes
#11

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.

2 Likes
#12

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?

#13

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?

1 Like
#14

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!

4 Likes
#15

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.

A user posted a quick video of the ship problem:

and a screenshot of the weld issue:

image
image987Ă—868 168 KB

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.

Certain players fall through terrain water when seated
#16

Related: Certain players fall through terrain water when seated

1 Like
#17

We don’t use Seat, nor the Roblox Vehicle and I don’t turn on the “Sit” property on the driver’s Humanoid.

I know I did in the past, but I checked just now. I hoped you were right and I only need to disable the Sit property :smile: . Sadly not the case

image
image1013Ă—546 150 KB

#18

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.