Can changes to Lighting’s properties from Scripts replicate across all clients, and changes to Lighting’s properties made from LocalScripts change the own users Lighting settings?
How does filtering enabled not already accomplish this?
1 Like
It would be nice if this was FE independent
The goal of FE is to let the developer have control. The goal of non-FE is to make game creation a lot simpler for beginners.
Mixing the behaviors doesn’t sound like a good idea.
14 Likes
You can write custom scripts to do this.
A LocalLighting service has been highly needed for a long time- especially since they added in fog.
3 Likes
Why only FE? This is stupid and doesn’t make sense considering you are usually more limited with FE.
2 Likes
It isn’t stupid and does make sense. If you’re a beginning developer and you want to learn the basics, FilteringEnabled might be a bit too much. If you have more experience though, it’s a good idea to turn on FilteringEnabled. If you want to control the lighting settings for each player seperately, you’re most likely an experienced developer and thus you use FilteringEnabled most of the time anyways. Adding behavior like OP suggested would only benefit few developers and it would also make the Roblox API more cluttered.
7 Likes
If you want this behaviour, make your game filteringenabled. It’s that simple. I don’t see why things like this should have to be made when it’s the developer’s choice not to make their game filteringenabled.
1 Like
It’s hard to work with FE, even for a lot of the developers on this forum.
Yes I personally have absolutely no problem working with FE, BUT using a core feature as a work around for another core feature is ridiculous if you have no need for FE in the first place.
If I am making a simple game, or prototyping a large game that does not need filtering enabled and would make it a much more complicated development process by enabling filtering enabled, I should be able to use features that have nothing to do with the intent of FE without using FE.
I shouldn’t have to use FE as a workaround for a feature that should be existent for non FE needing games as-well.
So Instead of limiting games that are not FE, empower them with allowing this feature request.
Sorry, but I don’t see a need for a feature. I see a need for proper education / Tutorials. That is something that is for sure 
But creating an small controller shouldn’t be that hard.
I hate to say this, but I don’t wish to have more services that actually aren’t fixing the real problem
4 Likes
As i said before. You can also do this with non FE games. Juts use local scripts and create some controller for it. Like i did to.
By not using Filtering Enabled, you aren’t helping yourself.
Letting the client make changes to the server is poor practice and insecure… but I’m off-topic…
If it only takes them a short while to add this feature then I’m all for it, but if it would take long to implement then I’m against it because there are many other features that would be much preferred by the mass.
The best way to empower a non-FE game is to check off the “FE” toggle.
Jokes aside, there’s absolutely no reason to skew this consistent behavior. The primary reason to not use FE is because you don’t understand how to. Instead of going entirely backwards and encouraging people to not use filtering, I agree with @Velibor and think more tutorials would be a better way to approach this!
1 Like
Couldn’t you just put lighting changes in RenderStepped function?