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.
A decompiled map will then use this value on the resulting .map but it will differ from the originally defined one - you should find those on worldspawn still as these keys are not cleared on compilation / decompilation - adjust them to match the ones you might find in the maps accompanying shaders and set up the original lightrig.

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

Edited March 24, 2023 by mjt
information about decompiled styles added

[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.

[Seto]

Hi there.

It's a somewhat old thread, I know, but I happened to stumble across this and was extremely curious about it, so much so that I couldn't resist coming back to JKA modding to examine it.  I would love to know if a solution was found, but I am sure if one was found it was probably different from the workaround I am about to describe, so I am going to continue to post anyway.

First I replicated your problem by simply extracting the entities and doing the onlyents recompile on q3map2, making NO changes.  The problem you describe happens as described.  Since no changes were made, this can only be caused by q3map2 doing something strange (also you can tell that the light entities are properly linked and it is just the surfaces not lighting properly).  Or perhaps we can say that some data related to lighting is somehow being disrupted within the bsp format when q3map2 recompiles the entities and changes the size and memory positions of other things within the bsp.

Now, there may be some combination of switches to adjust the compiler which will resolve this issue, but I felt this would take a long time to figure out, plus my memory of how q3map2 works isn't what it used to be.  So instead, I used a hex editor to directly modify the entities block of the bsp, which is possible since entities are stored as plain text, and this method should remove all the possible reasons for why this lighting issue occurs from the equation.  Now, normally this is not the best way to edit entities because you are essentially limited to only overwriting what is there already and cannot readily change the actual size of the bsp in this way or it will break other things.  However, as I recall, all light entities that are not specifically linked to other entities (i.e., lights without targetnames) are only used during the lighting stage of the compile, and after the lighting is already compiled, the entity itself no longer serves any purpose.  Since we are already dealing with a compiled bsp, this means we can just find some existing lights (they must not have targetnames!) and simply overwrite them with the hex editor to insert a couple new entities to achieve the desired result.

Below is an example of the change I made (I used HxD as my hex editor of choice).  I just did a search until I found a grouping of a few unlinked lights and started overwriting them, being careful to preserve syntax and not touch any other entities.  Do note that the characters that appear as dots (.) are infact hex 0A (line separator) and should be inserted in the left side this way; the rest can be typed normally on the right side where plain text is displayed.

I purposely made it a little bit more complicated than necessary (using target_relay) just to provide some margin for space where you might want to customize the specific behavior or conditions by which this triggers (this is also what the "emptyfield" keys are accomplishing, and taking up space so that we reach where the next ent begins seamlessly).  Also, I only downloaded part1 and not part2 of this map for testing, so I had the levelchange point to another SP map just so I could confirm that it worked.  The end result is that the lighting in the section in question works exactly as it should, and upon killing the AT-ST at the end, the level immediately changed (based on the "cin1" targetname which I figured out from browsing the map entities).  For full disclosure, I will say that for testing this workaround, I did noclip through the map to get to those sections and didn't play through the whole thing.  Also, I tested on openjk, although I would expect this kind of change to work perfectly fine on base jasp.exe too.

[KyleFan]

Hi @Seto!

I can't really say I've found a solution as of now. Life's been quite busy lately so I couldn't find the time to work on this issue. But thank you the help, I'll definitely try it out when I can get back to it, hopefully during the summer. 

[KyleFan]

Okay, so SomaZ wrote this little tool which he uploaded recently: 

I tried it out, it didn't even took me a minute, and the lighting change finally works perfectly!

 

I can't thank you enough, @SomaZ!

The Force is strong with this one.