No offence, but I find it a bit disappointing that Roblox as-of-recently has been making more changes with things that we as the developers cannot edit (for example, in this case we can’t edit how mass is calculated, etc.)
Personally I would prefer if Roblox were to instead invest to try and give us (the developers) more control over what these systems do and let us instead contribute fixes etc. through community resources. Not only would this allow for more complex things in-experience to made, but it would also not require a multitude of different settings (or worse, no way to revert to before the update) as developers would be providing any additional settings through their own code.
I’m testing this out with my custom characters, some of them have some custom physics tuning (e.g. those with physically simulated tails and snakes) and not noticing anything too severe.
However I do have a snake character that seems mildly affected, it sometimes has issues with tripping itself and it seems more prone to tripping itself with this property enabled + it has trouble getting back up. Once I turn the property back off it starts getting back up right away.
I tried to fix this by adjusting the rootpart density among other things but it doesn’t seem to help. Either way it’s not too big of an issue and I could probably mitigate it with a gentle bodygyro (I thought I already did this but I was mistaken), but it would be amazing if humanoid forces and settings for things like them being trippable or how long they stay tripped could be clearly exposed; then I wouldn’t need bodymover hacks.
Other creatures (huge, tiny, flying, swimming) are otherwise not affected any appreciable amount. This is probably because these are mostly made of MeshParts.
Because it was not an intended feature for how things were to work. It was a bug. Roblox is giving us plenty of time to shift into this new fix. Since this is ultimately a bug, it needs to be fixed at some point. It does not make sense to always have an option to keep a bug when it is just that: a bug that was not supposed to be there in the first place.
Backwards-compatability was always the word on Roblox’s mind for years, many Roblox developers have learned to use these ‘bugs’ to their advantage and personally I feel that Roblox should embrace that and as a result at least leave the option to keep the ‘bug’. Sure, support will likely be non-existent for those who keep the bug, but if a developers decides to keep it, then it’s on them…
Backward compatibility for previous features, not bugs. A bug is unintended. Backward compatibility preserves older features and the uses of them. A bug is an unintended feature sure, but it is still unintended. That is why you patch them; so that things function how they are supposed to.
This is awesome, and explains so many odd inconsistencies I’ve experienced in the past and never figured out. I’m super excited to see how this effects a lot of my physics code.
Actually, I believe you can disable it! This is a humanoid state, and you can disable them preventing the engine from setting them at all.
Particularly, it’s the first state, Enum.HumanoidStateType.FallingDown. You may also want to disable Enum.HumanoidStateType.Ragdoll, but, the last time I saw this actually trigger (if I understand the mechanic right) was in 2013 or 2014 I believe, I’m not sure that it actually works/is enabled anymore.
One partially related question. Wouldn’t it be better if we could manually set the mass without having to awkwardly fiddle around with the part density? In particular, I had an issue when working on a car where I had to use a giant uncollideable block to preciselly manipulate the car’s center of mass.
Dangit, another change of Mass & Density resulting in changing buoyancy of items in water.
I have a boat game that relies on physics to float boats and make them sink or be unstable. They are mostly made using WedgeParts, Parts, and CornerWedgeParts.
I remember there was a very big change in water physics years ago (I think it was when CustomPhysicalProperties was released) that drastically affected my boats and took me a day or so to figure out. Even after fine-tuning the boats again they never really reacted as nicely as they did before the change.
Can you just allow us to be able to choose whether a feature is on or not for a toggle just for once? It’s happened with animations, almost materials, tostring() and much more, I thought this platform was Powering Imagination?
Will this have any negative performance implications. Boxes and wedges are probably easy for the engine to optimise because they aren’t meshesh but simple geometry, so I hope this doesn’t have any negative performance implications (even minor ones).
No it shouldn’t result in any performance difference, it’s only a correction to the way certain part masses/volume & inertia are calculated.
The point of doing this in the first place is to allow you to adjust your game to the change. If it remained optional, it leaves an enormous amount of surface area in the engine for bugs to happen and it creates a lot of extra code in the engine to maintain. It would mean adding the same new feature twice in two pieces of code.
In this case, it would also mean testing new physics content with the feature on/off and painstakingly tuning it until it works for both, and, well, that’s just not feasible. That would then mean that any new features would either not support the old way, or Roblox would need to make the feature change with the setting, and that too is problematic and adds more code and surface area.
I think it’s pretty safe to say that if there were better options Roblox would take them, but, at least keep in mind they’re inputting effort to allow people to adjust first.
Will this have any negative performance implications?
No - Even though we switched Wedges and CornerWedges to calculate angular inertia in the same way as any other arbitrary mesh, there’s very little noticeable perf impact.
Our angular inertia calculation for meshes is pretty fast.
They could just make it deprecated, where it would still exist somewhere in the engine and when it inevitably breaks it would get removed, no need to maintain it. Roblox’s major issue (and the reason I am moving to a different engine) is that they aren’t making backward-compatible changes. For example, the recent removal of public audios broke a lot of games that were abandoned by their developer (one such example are the old After The Flash games). In Roblox, I don’t have any guarantee that the things I coded today won’t break tomorrow when new unannounced updated releases.
Thank you for the update’ I remember people going nuts cause Roblox’s physics were not that accurate in the past. Funny how people switch up fast after they get what they want. Writing systems is no easy work and to be frank, I can’t imagine why you want a more inaccurate old physics calculation method that is said to be no faster than the new one. I’ll be able to create real time cutscenes maybe more attractive.
Just checked the physics of my carts (a combination of massless imported meshes, blocks, and cylinders) and there was no discernable change in movement. There does seem to be a more reasonable balance to the cart when at rest.
Just to be clear I don’t necessarily need a workaround for my situation if you have better things to be doing, I can likely sort it out myself with a body gyro, but I will still share a file with the affected character for if it is useful for other purposes.
The easiest way to see the difference is to flip yourself and move in a straight line. With it enabled you can go a longer distance upside down before the character will manage to right itself. With it disabled it will usually right itself shortly after starting to move.
Hi! This is great, but it’s going to break my moment of inertia calculations. Can I get a way to compute or query moment of inertia? This would make this sort of change a lot nicer!
Also, this is going to break old boats in my game, which is problematic for gameplay. I think this is going to be ok, but long term back compat would have been nice.