This is so cool! The only problem is the buggy controls, especially in first person mode. If controls could be fixed, it would open a whole new world.
2 Likes
Added a fallTime property and updated the place files.
As for the controls (this applies to @HLVM as well) that mainly has to do with the camera not so much the flipping of the character. If you want to fix that you’ll have to do some heavy camera editing.
4 Likes
Okay, but how do you use the falltime property and what does it do?
1 Like
If your time in the air exceeds the fall time then gravity will reset to the default.
1 Like
An issue arises if the character has already spawned in. Overall, his method is likely the best.
1 Like
local Character = Player.Character or Player.CharacterAdded:Wait()
2 Likes
Why does this not work with terrain? I assume its using multiple rays to get the surface orientation
3 Likes
This is absolutely amazing! I may be able to find a use for it in a project of mine, keep it up man!
3 Likes
Despite changing the fall I still find myself falling off some edges, but for the most part is fixed. Its wierd that its only a few parts. https://i.gyazo.com/36e8c18a9aae26e3c21bf5d9a2f759cf.gif
2 Likes
I really hope someone can make a camera that follows your character upside down, I’m trying to use these for my games.
2 Likes
I tried making such a script. But it doesn’t seem to be possible. When the camera is pointed directly up or down, it does some weird glitches. This is why you can’t look straight down or up in Roblox 
2 Likes
Yes you can look straight up and straight down. The custom cameratype just prevents you.
1 Like
Yeah, it prevents you for a reason. When looking straight up or down with the scriptable cameratype, it does some weird stuff.
2 Likes
Well the reason is because the default CFrame constructor in the form CFrame.new(pos, lookAt) uses code equivalent to:
local cf = {};
function cf.new(pos, lookAt)
local b = -(lookAt - pos).unit;
local dot = b:Dot(Vector3.new(0, 1, 0));
if (math.abs(dot) < 1) then
local r = -b:Cross(Vector3.new(0, 1, 0)).unit;
local u = -r:Cross(b).unit;
return CFrame.fromMatrix(pos, r, u, b);
else
return CFrame.new(pos.x, pos.y, pos.z, 0, 1, 0, 0, 0, dot, dot, 0, 0);
end
end
Basically, since the code assumes that Vector3.new(0, 1, 0) is up it has to pick default values for the right and up vectors in the CFrame. This in turn causes a singular rotation for situations when a uses the above constructor to be set looking up or down.
The only real way to get around this is to have some other axis defined other than back (-lookVector) when creating the rotation matrix. Although I didn’t use it for the camera, iirc in the above placefile I use a similar concept for the controls by using the right axis of the last thing that wasn’t facing directly down.
Probably just made that way more confusing, but that’s the jist of why it does that. 
12 Likes
Well, try copying how meguy1 did it with Gravity Shift.
3 Likes
Mygame43 “cheated” with Gravity Shift in that the “down” lookVector always points toward gravity. So no real change to the camera code.
2 Likes
I’d rather have whatever’s possible that can be done, so I can actually use a dynamic camera for my game.
2 Likes
If you just want to be able to look in all 360 degrees, try setting the downVector to always be 90 degrees below the lookVector. It’s an ugly fix but it will absolutely prevent the camera from stopping when it hits the bottom or top of the possible camera angles.
You should quickly realize why the camera is limited like it is currently, when you do.
7 Likes
And just how would I go about doing that?
2 Likes
This topic should get you started in advanced CFrame math. I’m not willing to dive into the scripting it would take to create a 360DOF camera, especially not for free; there are lots of professionally made games which use such technology.
4 Likes