Some lighting effects disappear after entity modding; What can I do?

[KyleFan]

Hi everyone!

There are 3 parts to the mod Imperial Outpost made by Eike Legien. After finishing each part, you have to exit the game and change out the files to play the next one. I was trying to merge the 3 parts into one so that they can be played continuously. So I wrote a script and added an entity to each .bsp so at the end of the level it would load the next level. Everything works perfectly fine, except for one room. I’ll explain it in this short video:

 

[NAB622]

I don't know if this is fixable or not. I'm pretty sure what is happening is the portion of the lightmap connected to those lights is becoming separated from the light entities when you are editing the entity list. I'm not sure how I would confirm this theory or address the problem, though.

You have a great voice, by the way!

[SomaZ]

Might be a compiler bug or something like that. I'm not entirely sure how triggering lightstlyes works, but it looks like its using the actual light entities. Those are usually removed on compile in newer versions of q3map2. I guess, you did an ents only compile to add your "level change" entity. You might want to try doing this again, but add a "_keeplights" "1" to your worldspawn before. Else, we could try adding the entity via my blender addon to the bsp and see if the problem still exists.

[NAB622]

Actually...this raises a good point. Does the entity modding you were doing include the lights as part of the entity list, or are they removed by default? Lights with a targetname or a style should always stay, but I could see an entity modding tool/method/guide removing all lights by default.

[KyleFan]

Yes, I did an ents only compile and light entities are included in the entity list. When I did the compile it actually informed me that "147 light entities have been stripped". And indeed if I look through the modified entity list, the light entities are not there anymore. I tried adding in "_keeplights" "1" to the worldspawn. First I thought it worked because it said "0 light entities have been stripped" but nothing changed, even though the light entities are still in the entity list. I also tried to compile with an older version of q3map2, unfortunately it didn't help either.

 

On 2/13/2023 at 10:56 AM, NAB622 said:

You have a great voice, by the way!

Thank you, sir! This means a lot to me! 

[NAB622]

1 hour ago, KyleFan said:

I tried adding in "_keeplights" "1" to the worldspawn. First I thought it worked because it said "0 light entities have been stripped" but nothing changed, even though the light entities are still in the entity list.

Wait.....For some reason I was thinking you used misc_bsp. If all you did was add a target_level_change, where did you add it on the entity list? I think depending on where you put it, it might change which entity is linked to the lightmap, and that would definitely break all switched lights.

[SomaZ]

1 hour ago, NAB622 said:

Wait.....For some reason I was thinking you used misc_bsp. If all you did was add a target_level_change, where did you add it on the entity list? I think depending on where you put it, it might change which entity is linked to the lightmap, and that would definitely break all switched lights.

That is not a thing. Q3map2 assignes lightstyles to surfaces, not entities. The entities are just linked by target and targetName keys in the triggers and target entities. So, as long as theres the keys intact, this shouldn't be a problem at all. Sounds more like q3map2 just clears the lightstyles on the corresponding surfaces.

@KyleFanwould you mind sending me your patched bsp file in a dm? This would make the debugging process much easier.

 

[mjt]

You need to setup the original lightrig - if you decompiled the .bsp into .map and there are no actual light entities decompiled, you will have to rebuild the thing - now there's styled entity lights you can give a targetname, a style, a style_off and a custom lightstyle. Even shaderlights (area lights that are generated during the light compile based off shader settings) can cast styled light, though not style_off light

I suppose that the shaders distributed with the map either not use this, or have it stripped.

You wanna familiarize yourself with how to set a custom lightstyle (worldspawn key)

How to then set this custom one to a light entity and potentially in the emissive shaders - I suggest you experiment with it on a little testmap first.

check out this stuff:

http://q3map2.robotrenegade.com/docs/shader_manual/lightstyles.html This was how it was done for styled lights in Quake 3 - but Ravensoftware has a different BSP format with more advanced features. Custom lightstyles are setup differently on JKA

ls_Xr : override lightstyle X with this pattern for Red.
ls_Xg : green (valid patterns are a-z)
ls_Xb : blue (a is OFF, z is ON)

patternlenght is 25 for switchable styled lights and up to 50 safe for non switchable continuos styled lights (e.g. AAAZDDDASFEFEFESSEFESFEFF)

The following ones DO apply though if you also want shaders to emit styled light:

http://q3map2.robotrenegade.com/docs/shader_manual/q3map-global-directives.html#q3map_lightStyle
http://q3map2.robotrenegade.com/docs/shader_manual/q3map-global-directives.html#q3map_surfaceLight
http://q3map2.robotrenegade.com/docs/shader_manual/q3map-global-directives.html#q3map_lightSubdivide
http://q3map2.robotrenegade.com/docs/shader_manual/q3map-global-directives.html#q3map_lightRGB

When you setup a light with a targetname, after compilation it will have custom style 32 and counting for each light with a different targetname.

Setting up a shader prior to compile and giving it this value for q3map_lightStyle will also make all the lights this shader emits be styled and switchable by the targetnamed light that corresponds to this style. If you do not set style explicitly on the light matching it becomes a matter of enumeration in the .map file, as in which light comes first or sth. like that if I recall correctly - so you should be safe by putting in a proper custom style just to be on the safe side.

The -light phase of compilation needs to be called with those flags enabled (those are tested with Net Radiant Custom q3map2 - not GTK q3map2 or other variants):

-style -nocollapse -nolightmapsearch

[mjt]

@KyleFan I just remembered that decompiling a map with styled lights will put the enumeration back into the .map that the compiler generates for the engine to handle - those differ from the ones needed to be setup to compile into the same numbers again! So that's probably the reason your rig broke. I'll see if I can find my styles test map and tell you how to fix it.

[KyleFan]

@mjt Thanks for the very detailed response. But the thing is, I didn't compile the .bsp into .map; what I did was that I extracted the entity list into an .ent file, modified it, then recompiled it with an -onlyents command. Now, it looks like the .bsp still has the light entities, only this room just refuses to light up. I may have made a mistake though, I'm fairly new to modding.

@SomaZ I'm sending you the modified .bsp file. Thank you for looking into it!

[mjt]

@KyleFanCan you share the light entities in the .ent file? Because there must be some targetted lights being no longer linked properly - the compiled light must still exist and the surface styles applied, just that they are no longer triggered...

 

One more thing, if the original bsp references external lightmaps in shader or uses regular external ones - it's crucial, that the bsp name didn't change or the lightmap folder is adapted accordingly.