Hey guys, made a very small but important fix to the CollisionFidelity property. The way it was originally implemented had a few events that could cause it to become “corrupted”, which lead to Server and Player to disagree on what Collision Fidelity they thought parts were!
This meant a lot of weird things.
Server and Client would disagree on which collision shape to use for the object.
Server and Client would disagree on mass of a single object.
You as a developer may have thought you set an object to “Box” fidelity, only to have it collide as “Default”, throwing away more perf.
As of my fix, you should see the property set consistently to what the actual behavior is, and what client and server think should never be out of sync anymore. However, if you had a corrupted object you may now see the property set to a different value than what you expected! Please check your games and make sure that this problem didn’t affect you, and if it did, it should be obvious now!
Additionally, I want to take this opportunity to remind everyone that they can use a Studio setting to visualize what collision geometry for Unions and MeshParts looks like. This is a useful tool to help decide which CollisionFidelity is appropriate for your game. Generally, Box will be the most performant, followed by Hull, and finally Default as the most detailed yet hardest on your CPU. With this view, every different color is a single collision object.
I’m honestly surprised this plugin isn’t a regular feature built into Studio, it’s pretty handy to have this at hand rather than digging in your settings to turn it on and off every time you need to check something real quick.
Well, it’s a debugging setting. There are also other ones that aren’t necessarly used that often.
And if they were to make a more accesible setting for it, they would probably need to do that for other settings as well.
Besides, why waste time on it when it’s already available via a plugin?
Wow this really affected me, around 95% of my 4500+ meshparts have had their CollisionFidelity set from Hull to Default now. I’m pretty much going to have to go through each one now since the CollisionFidelity properties were divided between box and hull and there’s no way to check what fidelity a meshpart or union has with code.
I also found a pretty serious bug with the meshpart collision when testing in studio. At some random point during the test something happens that causes all the meshparts in the vehicles affected by this update get a different collision box.
When this happens almost all the meshparts appear like the 2 meshparts in the image below when decomposition geometry is enabled, like if they had no collision box. But you can collide with them and they have a different collision box than on the server, which I can confirm because the game uses GetTouchingParts on the server to check what BaseParts are touching the wheels, and after this has happened there are mesharts colliding with the wheels on the client that the server didn’t detect. My guess is that the meshparts gets changed back to Hull collision on the client which is what they had before the update while the collision is still set to default on the server.
I haven’t found out how to replicate this yet but it has happened 2 times while studio server testing the game, I’ll update this if I found any more information.
So to clarify. If you are now seeing that things have switched from Hull to Default that is because your data has been corrupted already and the property now reflects the truth.
The problem with the way the old feature worked was that there were 2 pieces of Data for Collision Fidelity. There was the “Collision Geometry” data, and the “Collision Fidelity” property data. Collision Geometry was responsible for HOW your objects were going to collide, and how complicated the collision was. There was one special case with boxes where this isn’t 100% correct, but since you are dealing with Hulls only for your case NOTHING has changed.
Anyway the bug was that the two pieces of data were independent from one another, which meant it was easy for Collision Fidelity to get out of Sync from the Collision Geometry data. Your objects still collided like Collision Geometry suggested, but the Collision Fidelity could have lied to you about what happened.
The change I made was to derive Collision Fidelity FROM the Collision Geometry, and simply use the “Collision Geometry” as a UI element that is user facing. Having 2 interdependent properties is bad coding practice, and that is my fault, but if you are seeing a problem now you’ve always had this issue and now it is just obvious that the issue is there.
You should still be able to select all objects and trigger a mass property change to Collision Fidelity “Hull” to fix this.
Thanks for the clarification, my models have always looked like this in decomposition geometry so it must have just been the property lying to me all along in that case. I’ll investigate if that bug I mentioned is something on my end, but it’s not something I have ever experienced before.
Yes if you find any form of desync between Client and Server’s view of the Collision Geometry please let me know because I would want to fix that ASAP.
It would seem the update actually messed up my collisions too, they were working before this update. I did not make any changes to the collisions(stayed on default before and after the update). Its seems to also be putting walls in places there shouldn’t be.
I can’t seem to get through the hollow spot or door way(cancolide is off) when I turn off cancolide(vice versa for door) I can go through solid parts but not hollow ones?
I’m not following what the issue is. You are colliding with the collision geometry. It is not precise. It is approximate. You cannot rely on small holes you made in Mesh or CSG to be the exact size in collision. You may need to can-collide false and create transparent collision parts.
If this was working prior to the update then there was something even more significant wrong with the data corruption. If you have a large object with small openings and you use Default collision fidelity for those objects, the small openings are very likely to get removed/closed up due to the limited resolution of the decompositions geometry.
I imported this prior to the update, and ended up with random shapes that interfered with my collisions. During this time, I built over with transparent bricks. Post-Update nothing seems to have change after changing to the new default collision fidelity, I even re-imported the building and continue to get the same results with the random shapes.
I do all my work in Blender and I’m having a hard time figuring out what the root of this issue is. I fear I may get to a more complicated shape and have to replicate it again with transparent parts(in the event I get random shapes), and I worry that this method may effect performance since brick count would be so high.
