So… scrap it and re implement it with the following ideas behind it - which may evolve over time or with more ideas.
- all lights are contained in some other BP.
- the manager keeps track of all lights with get all actors of class.
- gameplay tags exist. Could be used to flag on/off state.
- each light implements an interface.
- the manager makes interface calls to turn stuff on/off alacarte.
Additional ideas:
Direct line of sight option - turn a light off or on based on linetrace between player camera forward vector and position of the light (with proper math to determine it being within the FOV.
Illumination calculation - the manager has a built in function that determines how many lights are visible from a specific point (same line trace as before just used differently).
Btw, generally speaking loops are frowned upon. So even with get all actors of class i wouldnt go looping all the lights to do things with - thats where your overlap should come in.
Have a child BP that you can add to any actor which controls the overlap and detection - for that, you can indeed use loop so long as you do it peopelry and check numbers before the loop starts (avoid loops over 100). Should also use an interface because the manager gets to call on it.
Some other random thing:
Variable naming - go with something like I_counter for Integer, f_counter for float, s_counter for string etc.
Look up common ways to do it right and start using that proper naming so you have easier time later on when you move to code.
Another worthy point.
Add an actor variable - leave it empty. Check if empty. If empty and an overlap had occurred, set the var to the overlapped actor. Easy peasy. You dealt with the overlap and have the actor flagged to do whatever else sans needing to loop. (Does implement interface? Yes? Call “light up”) for instance…