Hey! Once upon a time I saw on YouTube video hosting how a player went through obby and when he came to the level that I call (Only the right way will save your life) And I think many developers have an idea about this level (you are on a platform among which there are three more bridge and only one you can go) But the disadvantage of such levels was that the parts that are transparent and do not have collision allow the camera to pass through these parts and you can determine which path is correct. Thinking about it, I came up with an idea that I have not seen in any of the popular obby. I made a duplicate of the part without the collision of the part but setting the ForceField texture and white color and enlarging it a bit. I was able to achieve the inability of the camera to pass through the bridge. But when the character touches this bridge, the script does not work exactly as I need and the opportunity to fail is obtained after a while. This is do strange “Swing”
There is the Script:
Looks like you are detecting every single touch, and I see a part touching it and then falling. This causes the weird ‘Swing’ as you call it. If you can, get rid of the part and then show me what it does; it may not be the only thing that is making in that weird.
My lazy go-to fix is to modify the camera’s occlusion behaviour by forking the PlayerModule.
local function canOcclude(part)
-- Occluders must be:
-- 1. Opaque
-- 2. Interactable
-- 3. Not in the same assembly as the subject
return
getTotalTransparency(part) < 0.25 and
part.CanCollide and
subjectRoot ~= (part:GetRootPart() or part) and
not part:IsA("TrussPart")
end
This determines if the camera should pass through an object or not when the DevCameraOcclusionMode is Zoom. I just add an extra condition here that uses tags or attributes to determine if the given part should be occluded or not. Usually said condition overrides the other conditions in case I want a transparent part to classify as an occluder. With that in mind, I can keep the collision of a false path off while not allowing cameras through.
Even lazier fix is that I use kill bricks instead. If my obby is high up then I don’t want players spending a long time falling just to die or falling to a lower stage and then just resetting when they can die earlier.
Hello. I tried to make this part separate from the color part. And my character without “Swing” was able to fall through there. Most likely this is due to the fact that my character is facing two parts at once that do not have collisions. But for some reason, at the beginning, the colision is triggered. I found a solution and did this part without box (Which is a little bit more)
well you can make a block somewhere near the fall block and make it collation off when player touch the detect block (the falling block remains collation on until its triggered)
i suc at spellin
Why don’t you just clone the part and remove it’s collision and then make the original part invisible, so the camera will pass through the part like it can’t collide but the character and other parts can walk on it.
I do not quite understand what you mean. I made a part through which the player could fall but from a trait I know. Parts through which the player can fall. The player will be able to keep the camera through this part. And there is no part that does not have a colision. So I did something like Hitbox but just not colliding when colliding with a player.
The camera goes through invisible parts so having an invisible part that is collidable will allow the player to walk on it while the camera will go through it.
