If possible, I think you should setup a thread to see what are the main necessities and constraints developers face when creating animations.
As for an example, in my particular case I find it too difficult to sync native Roblox animations to object interactions, such as picking up and object or making sure your hands are placed correctly in relation to an object you are holding.
Rescheduling changing Default to mean Explicit until after I can ship a fix for an issue with tools dropping when switching tools rapidly.
Reminder that we’re planning to change Default to mean Explicit mode on Monday Update: Postponed. You can still opt out by selecting Legacy a this point but we’re planning to force everyone over to Explicit in mid-November.
We recommend updating your games to Explicit mode now and reporting any issues you run into.
That change was already enabled this week. Let me know if you’re still seeing issues.
I just enabled Explicit on my game and I’m seeing something I have no idea how to even approach fixing. It’s 2:30 am though so troubleshooting this right now is going to have to wait for tomorrow.
https://gfycat.com/SingleVengefulHog
https://gfycat.com/FewCheerfulHog
https://gfycat.com/UglyCalculatingBrahmanbull
Okay apparently this is picking up loose objects as well (note the egg).
Reproducing this was only reliable after around 4 people joined the game, and I can’t seem to make it happen in studio.
This looks like a bug that has existed on Roblox since at least 2010. JointInstances without a Part0 or Part1 will sometimes attach to characters at random. I saw this around 2010 with an old weld script inexplicably attaching players to cars and players to players. I saw it recently with JointInstances in the character that had a nil Part0 or Part1 which caused it to attach to other characters or random parts of the world.
I haven’t submitted a bug report because this bug is hard to reproduce and I can’t get a solid repro down. It’s the sort of bug where the natural response is, “no, that can’t be right, something must be wrong with your code” rather than accepting it as an engine bug. I’ve seen it happen multiple times and did a thorough investigation using new APIs recently and found that parts should not have been connected but were. The only similarity between all cases is JointInstances with nil Part0 or Part, and removing those fixes the issue and disconnects the parts that should not be connected.
Related: There’s another “that’s impossible, it must be your code” bug I’ve found recently where the client DataModel gets desync’d from the server. I plan on reporting it but unfortunately can’t give a very solid repro. It happens in approximately 3/10 tests (or less) and only on large games with operations that happen at the start of the game and only for new players. I’ve seen this twice so far, done a thorough investigation each time, and there’s no way that it’s a bug in our code and not a Roblox engine bug. It happens both in live games and in test servers.
That is bizarre.
I’m using welds to connect the hitbox part to the character when they start an attack. It turns out the welds are left behind missing their Part0 after an attack finishes. This is definitely the same bug you’ve described.
I’ve also managed to reproduce it in studio. I needed to do some attacks before I could get it to happen. In this particular case the effect appears different between clients. It’s worth noting that in none of the client views, nor the server view do the welds have a Part0 set.
Please see this bug thread for repro.
Thanks for putting together a repro for this. I know @Khanovich tried to fix this a couple times before.
We’ll talk about it more Monday morning, but we’ll probably postpone switching to Explicit by default since it does exacerbate this by not removing welds when the part leaves Workspace, and we need to fix this bug.
We are going to keep the behavior of welds no longer self-destructing when parts are removed from Workspace. That behavior causes a number of problems when moving models between containers and causes issues with replication. You should still update your games to make you clean those up more explicitly or by parenting them to the part that will be removed.
I’m currently testing my game with the attack hitboxes that get destroyed having their welds contained within, but it still appears to happen, albeit less often. Destroy() is always and only called on the hitbox part and variables holding the weld instance are out of scope.
My client ends up desynced with the server after a while, also I can’t jump afterwards?
No idea what’s going on. Surprised other people haven’t posted about this issue in this thread since it’s being a pretty big problem for me.
The issues with welds crashing or connecting to other parts randomly should be fixed now, so it should be a good time to try Explicit mode again if you’ve ran into this issue or just haven’t before.
We’ve updated the release schedule, please see the original post.
Starting January 7th we will move forward with Explicit mode being the default for all new and existing places that have not explicitly opted out.
On February 4th all new and existing places will be forced to Explicit mode even if they had opted out before.
Please test and switch your places to Explicit mode now to avoid any interruption. Report any issues you encounter today!
I currently have a script which would change the Surface Type of a part (mainly to stop a wheel from rotating by changing the hinge - using VehicleSeat controller). This has currently stopped working due to this update, was just wondering, would using :MakeJoints() after any change like this fix this issue?
It should. The old property setters included the equivilent of calling BreakJoints before changing the value and MakeJoints after.
Adding these calls yourself, explicitly, should get that same behavior as before. We think it’s better to be explicit about this if it’s what you want.
Thanks for the reply!
I had a few welds inside my part as well as the surface joint, so I was required to delete this joint individually - however, I came to notice that these joints are named differently depending on the surface type, and some surface types use Motor6D instead.
Is there any way to find out what joint inside the child is actually the surface joint? If not, is there a list of the names of each joint with respect to the Surface Type?
The surface type joints always have the default name for their type, their class name.
For joint type / name to SurfaceType in parenthesis:
In default & explicit mode, my cars just fall apart.
I’m not really sure what would be the best option to fix this behavior. The cars are just held together with hinges & welds with surface. It’s very strange in that it’s only affecting cars at places when I’m inserting them in from the ToolBox, but not affecting cars that are already in the place that is set to default.
Is my best option to use Make Joints in a script in each model?
Your models as they are uploaded do not contain the welds necessary to hold them together.
Because the explicit behavior no longer automatically creates welds when a game starts, you will have to either do what you said in your post and run MakeJoints from a script in each car, or manually run MakeJoints on each car model from the command bar in Studio before playing.
I suggest you use the latter, but if you are feeling lazy and don’t have any particular surface breaks, you can run workspace:MakeJoints() in Studio’s command bar to join all the surfaces together before playing.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
