I’ve found some working day/night scripts that work the way I (almost) want them to. I’d like the day/night to sync with Roblox servers and they do that just fine. I’ve set the script to only check every 10 minutes hoping this will reduce load.
The feature I desire most however I cannot figure out. How would I add ambient changes to a script? Ambient makes a h-u-g-e difference in overall lighting quality. Currently I can change ambient settings but they stay the same through the entire cycle.
Thanks! Let me do some testing and try it. I’d like to add it into the day/night script.
Is there a way to call it by time rather than wait? I’ve seen threads swearing wait is bad yet wait seems essential for some functions. Perhaps I could have a day/night that triggered only based on server time?
That would be a much longer script wait is a fine thing it has its bugs but if you use it right its fine but let me see if I can make you a script that runs off of sever time.
Well the work is not your burden but that is quite generous! Even if you were able to post an example line of code showing me a timestamp style code it’d be very helpful.
Ambient itself doesn’t have a property called Color3. Color3.new requires you to specify a number from 0-1 which represent Red, Green and Blue. To make things easier, use the typical RGB values with Color3.fromRGB(r, g, b) which allows you to specify a range from 0-255. You should also realise that Ambient lighting is only really applied to indoor structures, while if you want to have a noticeable effect on the outside you should change the OutdoorAmbient
Correct code for changing the Ambient and OutdoorAmbient:
game.Lighting.Ambient = Color3.fromRGB(r, g, b)
game.Lighting.OutdoorAmbient = Color3.fromRGB(r, g, b)
My fault. I was using the term ambient in a general sense during the question. Your post gives me even more ability to customize though both indoor and outdoor.
This is not a valid index of Ambient. This returns an error, try it yourself. It is simply game.Lighting.Ambient.
Attempting to apply the RGB values 255, 255, 255 to a Color3.new() gave me the values of 65025, 65025, 65025 after I had checked the properties. Hence why I suggest you use Color3.fromRGB to prevent any funny business from going on.
Color3.new() should only be using a number from 0-1, which the source for that can be seen here.
Oh I see what I did wrong my bad. Color3.new() does work perfectly fine however, I forgot that ambient is already stored as a color3 value and doesnt have a separate value for that.
If you don’t want to use wait() (which isn’t necessarily a bad thing), the other option you can take is connecting to a signal.
In this case, assuming you are using DistributedGameTime, you would get the changed signal for that property and create a callback that updates the ambient every time this property changes:
workspace:GetPropertyChangedSignal("DistributedGameTime"):Connect(function()
local newTime = workspace.DistributedGameTime
-- do stuff here
end)
There is a problem with this method, however. This callback will be called at an unnecessarily high rate because DistributedGameTime is meant to be accurate at a level smaller than seconds. So, while this might still be a viable idea, I recommend you set up a system to stop the ambience from actually doing anything most of the times it is called. For example (if you don’t have any conditional statements already):
local lastTime = 0
workspace:GetPropertyChangedSignal("DistributedGameTime"):Connect(function()
local newTime = workspace.DistributedGameTime
-- 1 second cooldown
if newTime - lastTime < 1 then return end
lastTime = newTime
-- do stuff here
end)
It is still much simpler to use wait(). Its inaccuracy isn’t noticeable for us humans.
That does sound counter-productive. My main goal is to have a low resource, fully functioning, real time day/night with ambient and lighting changes. If wait is the best way that is fine. There was some vilifying of the wait function yet so many scripts use wait.
Consider making your ambient system work based on the time system. So if you set Lighting.ClockTime in your day/night code, hook up your signal to that instead of something generic like DistributedGameTime.
(As a bonus, this also means you can set the time however you like – e.g. using admin commands – and other related systems like ambience will work as the only thing they rely on is the time.)
If you don’t use Lighting.ClockTime or something that works similarly, you can create a BindableEvent and connect the ambience to time using that instead.
This approach should reduce the number of times that function is called (unless you are using TweenService or something on the time) and if it doesn’t then you can easily modify the day/time code so that it control that number without a significant performance overhead.
Oops, just realised that this still doesn’t solve the problem of how the time part of your system would work. So this post is kinda pointless. But don’t worry about it too much – what you’re doing shouldn’t be so expensive on performance that you will notice any issues. Do whatever you like
Hah… but this sounds like it would work at least in my mind. What if I had the script check once when player enters server for the current time. This first and only check would set the lighting and ambients… anything after 8pm let’s say would be night. Anything after 6am day. 7:30pm-8pm sunset. 5:30am to 6am sunrise. Of course if the player was on for 4 hours or something you still need the cycle to progress. Really day/night should be built into Studio like terrain tools.
Yup, and perhaps just make a while loop that only runs once every 10 minutes or something with a wait(). It’s not a very intensive task so again you don’t need to worry that much about it unless you need to heavily optimise your game.
