Alright this is pretty good work around can’t believe I did not think of it.
Thank you!
1 Like
I have been getting this error when using a custom camera as well.
Same for me. Out of nowhere these spam error messages keep popping up and lagging my whole entire game. I think what I should do is Do a Disabled = true or Destroy() script for this.
1 Like
@iamtryingtofindname @Aeventy Unless your camera script is in ReplicatedFirst, these are pointless suggestions. game:IsLoaded() is true when your localscripts outside of ReplicatedFirst run. Read the devhub article on this.
Also @iamtryingtofindname your solution is similarly bad to wait(), you are still yielding once on Heartbeat for no apparent reason. There should be no reason to yield there.
PS: this doesn’t seem related to the bug report at all, let’s stay on topic please and not derail the thread further.
1 Like
What I did was set the camera to scriptable and then to custom. Weirdly it does nothing else but stop the output spam. I can share the code later today.
1 Like
The error seemed to appear for me if I tried to set the CameraType to scriptable before the CameraSubject was chosen.
The following code got rid of the error for me:
local RunService = game:GetService("RunService")
if camera.CameraSubject == nil then
repeat RunService.RenderStepped:Wait() until camera.CameraSubject ~= nil
end
4 Likes
Try adding a wait() before switching the camera type
for example
wait()
workspace.CurrentCamera.CameraType = Enum.CameraType.Scriptable
Annoying error still happens, I use it to show the lobby to the players at my start screen. But for some reason its purely random. Also tried yielding to heartbeat to no avail
1 Like
I remember I had done that, and even then, not using a wait() would not throw a warning. However, I remember I was able to solve the issue, I don’t remember how though.
I can confirm that this is still happening. It is very annoying when you’re making a weapon aiming system which switches out of Scriptable and Default.
1 Like
Any luck sir. I am doing a game soon and i want NO console warnings/Errors.
yeah this is an issue with roblox that happens whenever you want the CameraType to change too soon after the game starts. I don’t know why Roblox hasn’t fixed this issue. To fix this I would recommend just placing a “wait()” right before you change the CameraType. This sadly may not work 100% of the time, but it’s still a pretty good fix.
Something a little like this:
wait()
game.Workspace.CurrentCamera.CameraType = CameraTypeIf you wait about four frames it shouldn’t warn in 99.9% of cases, at least that’s what worked for me.
1 Like
I had right now the same problem and i just used Codename_Planet way:
just put at the top of script “wait()”
like
wait()
local camera = game[“Workspace”][“CurrentCamera”]
camera.CameraType = Enum[“CameraType”][“Scriptable”]
Currently, I manage to remove this error by just setting the CameraType to Custom it still works perfectly fine for me especially I do have first-person cutscenes that lock the player camera to the player head when animation is played.
The reason why this is is because the default playerscript needs to load the module so you can easily bypass this warning by simply waiting a couple of seconds.
1 Like
This warn is still lingering but ofc its avoidable and it surely does make sense
1 Like
I’ve had the same issue when making a camera system, I wasn’t sure how I could be able to avoid this, so I just got the PlayerModule ModuleScript from my player’s PlayerScripts while in-game and in the CameraModule ModuleScript, I turned the line of code (335 for me) which warned me about this issue into a comment (–). I’m not sure if any of this will cause problems with future updates, but I don’t mind just grabbing that ModuleScript again and doing my edits like I did. It’s working perfectly fine for me as of now.
1 Like
Just use the “wait()”, example:
LocalScript on StaterGui
local cam = workspace.CurrentCamera
wait()
cam.CameraType = Enum.CameraType.Scriptable
cam.CFrame = CFrame.new(workspace.Cameras.Cam1.Position)
Your Welcome
1 Like
Just a little PSA.
This is not a proper solution, its a bandaid fix, and its bad practice. You should avoid using waits (wait, task.wait, etc) for anything other than actual timing, at all costs.
The reason is because waiting unnecessarily slows down your code (on top of the performance impacts of plain wait which task.wait addresses). It doesn’t have a big effect in most cases, but, it is absolutely bad practice, and, when relying on asynchronous stuff like this creates a race condition. If the wait call happens to be initiated earlier compared to a separate piece of code (in this case, the camera controller) the warning (or error) would be produced. This might mean that people with faster hardware than you could encounter an error, or your game breaking because Roblox upgrades their servers, or the order of which script runs first changes (or Adopt Me releases an update and takes out the NASA super computer)
This is probably the most common example of race conditions on Roblox, and its extremely common. It causes probably one of the hardest to fix bugs because it is virtually impossible to debug due to the issue entirely being based on time. You’d have to potentially consider every location where you yield in your code.
The most common place you’ll experience the effects of a bug like this is in any game which seems to just sometimes break at random, for example, a lot of older games like Daxter33’s paintball had experienced issues where rounds or maps would fail to load, or maps would load after players had spawned (and died). Because its timing based, its basically completely random whether or not the race condition will cause an issue, and said issue might only happen 5% of the time, but that’s still a lot more than 0%.
Commonly you will see wait(1) placed at the top of scripts but this is still not a proper fix, its a pretty hacky fix, and its a bandaid. Even if it is statistically impossible that there will be a conflict caused by the race condition, you shouldn’t be doing this to avoid problems (its literally the equivalent of making your code procrastinate on its homework).
Any time issues like this come up, Roblox provides events, or functions which allow you to avoid the issues and have your code executing immediately, rather than 0.1 seconds in the future or something.
In a case like this where they don’t provide a way, or at least, not one which can feasibly be worked out by people, its absolutely a bug, and/or deserves addressal. I would even argue in this case that this warning is improper, because it explicitly requires and implies user code must work around Roblox code, whereas what should be occurring is that Roblox code works around user code (the issue is addressed by a warning, but instead it should be addressed by accounting for any potential problems that’d be caused, and if there are no problems, there should be no warning)
5 Likes