i found a issue that if the sides offset value is higher or equals to two the character stops moving in the direction of the camera/movement, any possible fix for this?
When using Offset for something similar to a shift-lock, using the AlignChar property is highly advised.
If that wasn’t your intent, however, this could be more of an issue with your character rig/animation handling. Is your Humanoid’s AutoRotate property on? Is your movement system custom-made? Examine into those potentially.
Hey! I was testing out your camera service and I saw that when the player is on third person the camera doesnt go through walls and zooms to the character whenever the player gets closer to the wall like it should but thats not the case for shift lock for some reason
When the next upgrade for CameraService releases, I’ll be sure to look into that further. (By the way, can you elaborate on that jittery motion concern you mentioned prior?)
Camera motion for right- and left-arrow keys on keyboard devices!
Adjustments to part clipping.
RotSmoothness!
I’m also happy to say that separating smoothness values for “rotation” and “motion” is now possible in CameraService with the RotSmoothness property!
However, read below to understand how to use it:
RotSmoothness does not override Smoothness: In CameraService, the “motion” of the camera relies on both the position of the host and the rotational information it has on-hand. As such, if you set RotSmoothness to a value lower than Smoothness (i.e. set it to 0), the camera will simply ignore your RotSmoothness, and continue. In other words: Your RotSmoothness property must be set to be higher than the typical Smoothness property. With this, you can allow camera panning to be smooth, while ensuring player movements are accurate frame-by-frame!
RotSmoothness is only used in first-person (MinZoom = 0, MaxZoom = 0) When smoothness values for rotation and motion differ, they’re out of sync, in a sense. Zooming out (crucial for any third-person view) from the character relies on rotational information. The result for third-person views is a ridiculous amount of jittery motion. Attempting to use RotSmoothness otherwise will be ignored.
Example code for the above:
CameraService:Change("RotSmoothness", 1.2) -- smooth rotation
CameraService:Change("Smoothness", 0) -- static/accurate following of player
Just tested this out and it’s really cool. I know this might sound much, but for the next version could you add a smoothness property for the Change(), like for example, CameraService:Change(“Offset”, CFrame.new(), false, 1 – smoothness) or CameraService:Shake(1, 5, 1 – smoothness)
AH sorry i didnt check the replies after i sent this and that my apologies!
I’ll take a look at the updated version and see if it is fixed
and about the jitter I did what you told someone else regarding that and it was to raise up the smoothness and it worked for the most part but too much seems to make it look unnatural so i found a number that seemed somewhat closer to what it was before and it worked fine
the jitter was noticeable when i used any body following camera mode as if the camera was struggling to keep up (mostly walking left and right) but it seems to be fixed with the smoothness thing you suggested as a fix a while ago!
This works great for me so far, but I do have one question. How would I make it so that the rotation of the camera is unaffected by Smoothness in third person? Essentially, I want the position of the camera to be changed smoothly, but the rotation should act like the Roblox default.
Unfortunately, due to the logic for this system, what you’re seeking for a third person camera isn’t currently possible in CameraService, as rotational and positional data are intertwined. Sorry!
Hi all!
v2.3.0 (patches to some of the common issues reported recently) is now available on GitHub! Updates to the Roblox model itself will be here soon
I haven’t tried this new version yet, but I noticed when playing in a live game the player can set the camera to whatever type they want. Is that one of the common issues reported that was fixed in this version?
Basically, in studio it works and shows the camera is set by developer but in a live game it gives them the option to change it.