Allow lighting objects to work inside folders in `game.Lighting`

Feature Requests Engine Features
#1

As a developer, it is currently impossible to group lighting objects (such as ColorCorrectionEffect and Sky) inside folders under game.Lighting.

The expected behavior is that lighting objects would function inside folders under game.Lighting. But the actual behavior is they simply don’t run while parented to a folder under game.Lighting.

Please allow lighting objects to function/run while parented to folders under game.Lighting.

Why is this important? What's the use case?

In the case of different 'regions' or areas in a world, the developer may desire to have different lighting configurations in different folders under lighting, to easily manage the lighting effects for each different region.

In “RS Minigames” (currently in dev by @Spathi and I), there are two different ‘regions’ that have their own lighting:

  • The lobby has its own skybox and lighting. We change the lobby with the seasons/holidays, so our lobby is constantly changing atmosphere (color correction effects, skybox, etc).

  • Each minigame has its own lighting setup. When a player enters a minigame, their client needs to disable all of the lobby’s lighting objects, while enabling any lighting objects under the MinigameLighting folder under game.Lighting (Lighting objects are added to this when the minigame’s client is ran). Because lighting objects don’t work inside of folders under game.Lighting, this is currently not possible to implement.

You might ask “why not just have the minigame client iterate through all the lighting objects, and if has “Lobby_” in its name, disable it?”.
This isn’t wanted for a few reasons - 1, it’s dis-organized. If the game were a large RPG, with many different map/world areas, the code would need to constantly pass around and store references to the desired lighting effects. Just like we have folders and models for organizing objects in the workspace/other storage containers (serverscriptservice,serverstorage,replicatedstorage,replicatedfirst,etc), we should allow folders for organizing lighting objects under game.Lighting.
2 - It would be really sloppy to have to pass lighting parameters around to code that doesn’t have anything to do with the lighting. E.g. the lobby client code shouldn’t be messing with minigame lighting, vice versa.

14 Likes
#2

Support solely because folders are for sorting, they shouldn’t effect anything else

6 Likes
#3

Why not keep these folders in i.e. ReplicatedStorage and then, whenever you need to switch effects, destroy the ones already in Lighting and clone over the ones in the target folder?

2 Likes
#4

While that could serve as a temporary work-around until this feature is implemented, lighting should still support folders.

From what I can guess, the engine’s lighting code looks for any lighting objects directly parented to lighting, and ignores any children.

1 Like
#5

There’s a few ways that you could achieve the same effect that you wish. However, more GUI instances are starting to fully support folders, why not include the services? I’m a big ban of organization as it easily increases the workflow of the game, which folders greatly help do.

3 Likes
#6

Great idea, I also thought about having a “Disabled” property on a folder which would disable everything inside the folder that is able to be disabled so you wouldn’t have to loop through each component.

5 Likes
#7

I’m not asking for a Disabled property on folders, I’m simply asking for lighting objects to function inside folders that are parented to game.Lighting.

1 Like
#8

I didn’t say you did, it’s my idea. Might not be a very good one, but it’s a start.

7 Likes