I’ve been having trouble reproducing this issue in stand alone places, but it happens consistently in my game: Rolling Thunder - Roblox
Expected Behavior
I expect all voxel terrain to be collide-able and detectable by raycasts
Actual Behavior
50% of the time when you join the game certain parts of the terrain won’t be collideable. You’ll be able to fall through it regardless of the voxel’s thickness or material. It’s inconsistent which areas suffer from this bug, and sometimes other players can interact with terrain that is broken for you.
Vehicles and other physics object will also phase through the terrain, not just characters.
our builders are also experiencing issues related to terrain in studio, sometimes brushes will just ignore voxels making terrain very difficult to work with:
Workaround
No, it’s not a developer level issue.
Issue Area: Engine Issue Type: Other Impact: Very High Frequency: Constantly Date First Experienced: 2022-11-02 00:11:00 (-04:00) Date Last Experienced: 2022-11-04 00:11:00 (-04:00)
Bad Business is also struggling with this issue currently - our bug reports channel is filled to the brim with videos of players falling through terrain (ex: terrain glitch (bb)).
This is extremely aggravating for players but it’s particularly aggravating to me because this is happening during our Halloween Event - an event which brings in many new players to the game. For the second year in a row, our Halloween Event is being hindered by Roblox-specific problems and limiting our growth potential during a very exciting time.
Reports of this issue started on Wednesday for us as well.
Could you please provide an example placefile where this shows (any of the problems mentioned above)? Delete everything else, except the piece of terrain that is problematic.
Here. This is the only place where the brush doesn’t work properly. If I start a new place and try it there, the brush works fine. terrain brush doesn’t seem to work here.rbxl (46.6 KB)
@CDDevelopment can you please also attach a piece of terrain where you saw your painting problem? I am looking at @Markaaron 's problem and it seems that those are two different things. Seems that yours went away when the flag was turned off, but Markaaron’s didn’t.
Now I can’t reproduce yours based on just trying Rolling Thunder, and we would need to fix it so it doesn’t break again when enable that flag again.
@Markaaron your problem is the terrain having the CollisionGroudId set to 1 instead of 0, so it doesn’t collide with the raycasts used by the editing tools.
For now, just set this number to 0 and editing will work. We will see if we can better protect against things like this happening by accident.
Sorry for the lack of clarification. The flag fixed the in-game issues where users were phasing through terrain, which is probably why you can’t reproduce it in-game anymore.
I have the CollisionGroupId set to 1 because I need it as such for things in my game to function properly. Roblox’s built in path finding algorithms do not work particularly well on terrain. For this reason, I need certain things to ignore it. Either way, the built in terrain tools being affected by what the CollisionGroupId is set too does not make any practical sense (that I know of), and shouldn’t be a thing. Thanks for pointing out what the issue was though.
For the raycast problem, how about configuring the RaycastParams.CollisionGroup when calling the raycast method?
The usage for the new collision group name is in this post.
No change is needed for the existing CollisionGroupId . The default value for the new property is “ Default “. Internally, the engine respects the CollisionGroupId if the new property has a “ Default “ value. We encourage you to use the CollisionGroup[string] in the future.
We will improve the messaging on the de-synced CollisionGroupId vs CollisionGroup. Thank you!
No, but if I turn the flag on locally in development version I can’t reproduce it either. I really need to know the specific place in the terrain where this happened to you so we can debug this, as this flag must be turned on. We need it for an upcoming feature, it can’t be just left in the off state forever.
That said, I suspect it was something else (perhaps some other flag was disabled at rhe same time for a different thing?), as this one is unlikely to cause this effect. But I’d like to check before we turn it back on. If it really is that - we will fix it. By can’t do that without a repro.
Unfortunately I can’t get a reliable repro, it seems to occur randomly each session so other people in the team create can edit a problem area just fine, or if you rejoin the team create it can fix it or move the problem area to a different spot.
