"light" entities disabled and grouped styles while merging

[GarompaEstomper]

Entity: "classname" "light"

Bug 1: These ents are off (or sometimes on) at map start and cannot be toggled unless they first are triggered by a trigger_auto or a trigger_relay (multi manager does not work). Sometimes they need to be triggered twice to be able to finally be toggled by triggering them (this can be also tested by using console commands to see how many times you have to trigger the entity for it to start actually triggering).

Bug 2: Huge problem, where it seems the "style" setting of this light entity makes it somehow merge with others. Now this is a bit complex to explain. This "shadow merge" or "shadow grouped" happens to them, and while they are like that, the next rules apply:
A- Even if the targetnames are changed, triggering one of them will trigger all of them
B- Some are not triggered at all, even by using console and their exact targetname, yet they respond together to the targetname of only one of the lights in the shadow group
C- Changing the "style" variable does nothing, other times it seems they ungroup differently but I couldn't find a way to test thoroughly, but mostly does nothing except making the lights toggleable or not. I have no documentation on how these styles work, since all info out there tells another thing and the FGD as well. There seems to be a lot of missing styles, since every doc I can find says there is up to roughly number 12, yet I've seen most maps using 32 and above even up to 38. Maybe this works by addition like spawnflags settings, but I do not know. Makes no sense. Documentation also says there is a limit to how many light styles are touching a face, other docs say targetname counts as an additional style, and others say it doesn't.

Anyway to have some sense of all this style thing an example ended up like this:
targetname light1, toggled a light on another of the merged maps with a different targetname

This makes maps where you need to turn on or off certain lights, be turning off lights that shouldn't, even when those lights sometimes don't even have targetnames.

[wootguy]

Bug 1:
Sounds like a problem with creating lights after the map has started. I've seen weird behavior like this with func_trains and multi_managers. The solution was to only spawn those during MapInit() in the bspguy scripts, or via the entity data in the bsp. If you're not spawning lights late, then it's probably a side effect of bug 2.

Bug 2:
The RAD compiler manipulates the style keyvalue in order to link that light to a group of faces in the map. If I use the "Normal" value in Hammer (1), then check the style keyvalue after compiling, it changes to 33. The faces that the light affects will also have 33 saved into their data structures. This way the game knows which faces to update when toggling the "33" light. The problem is that every map will start counting from that same style number. So, activating style 33 in one map will activate it across all others.

This isn't fixable in the editor. The light and face style values need to be offset so that they don't overlap. It looks like the BSP format supports ~254 styles per map (independently toggled lights), but I don't know if the engine actually supports that many.

Good find btw. I don't think I would have ever noticed this bug. The style limit should be included with the other limits like clipnodes/vertices/etc. Too many lights and the maps can't be merged.

Since I'm not interested or actively working on bspguy anymore, it'll probably be a long time before I fix this (months or never ever). As a workaround, you could try setting up the bspguy scripts and having level changes be non-seamless. Or, you could run the merged map through a RAD compiler. You'd have to use your best judgement for which RAD options to use, and which texlight values to set.