Possible to add brushes without decompiling the .bsp and breaking the map?

[RebornKyle]

Is this possible? I want to add some brushes to a .bsp, but doing the decompile method breaks many other properties of the map. Just wondering if it's possible to add only a few brushes without having to break the map. From what I've gathered in tutorials and forums here, it isn't, but I'm happy to be proven wrong.

[mrwonko]

In theory it's possible, but I don't think we have the necessary tools. SomaZ' Blender BSP plugin gets closest, but it looks like it cannot add new brushes (yet?). Or maybe it could be done using a misc_bsp?

[RebornKyle]

6 hours ago, mrwonko said:

In theory it's possible, but I don't think we have the necessary tools. SomaZ' Blender BSP plugin gets closest, but it looks like it cannot add new brushes (yet?). Or maybe it could be done using a misc_bsp?

SomaZ looks the most promising but yeah it seems to not be able to manipulate brushes yet, though it looks like you can edit the lightmap which I thought was not possible too. For a misc_bsp, how would you go about doing that? I'm not knowledgeable on that.

[SomaZ]

Just use -mergebsp with latest q3map2 version of netradiant-custom. Get it here: https://github.com/Garux/netradiant-custom/releases

So, you simply build the brushes you want to add to a bsp within radiant, add lights so the brushes are lit like in the original map, run a compile, don't worry about leaks or anything related to that.

After that you merge both bsps with q3map2.exe -game ja -mergebsp -world <mainBsp.bsp> <bspToinject.bsp>

mainBsp is your original map in this case. Hope that helps.

 

More info in the commit of Garux adding this feature:

Spoiler

* -mergebsp [options] <mainBsp.bsp> <bspToinject.bsp>: Inject latter …

 

…BSP to former. Tree and vis data of the main one are preserved.

	* -mergebsp -fixnames: Make incoming BSP target/targetname names unique to not collide with existing names
	* -mergebsp -world: Also merge worldspawn model (brushes as if they were detail, no BSP tree is affected) (only merges entities by default)

 

Edited August 22 by SomaZ
Added game flag to command

[RebornKyle]

21 hours ago, SomaZ said:

Just use -mergebsp with latest q3map2 version of netradiant-custom. Get it here: https://github.com/Garux/netradiant-custom/releases

So, you simply build the brushes you want to add to a bsp within radiant, add lights so the brushes are lit like in the original map, run a compile, don't worry about leaks or anything related to that.

After that you merge both bsps with q3map2.exe -mergebsp -world <mainBsp.bsp> <bspToinject.bsp>

mainBsp is your original map in this case. Hope that helps.

 

More info in the commit of Garux adding this feature:

  Reveal hidden contents

* -mergebsp [options] <mainBsp.bsp> <bspToinject.bsp>: Inject latter …

 

…BSP to former. Tree and vis data of the main one are preserved.

	* -mergebsp -fixnames: Make incoming BSP target/targetname names unique to not collide with existing names
	* -mergebsp -world: Also merge worldspawn model (brushes as if they were detail, no BSP tree is affected) (only merges entities by default)

 

Hm, when trying to do this, it complains that its not in IBSP format. I checked both files and they're RBSP with version 1. I also checked a base Jedi Academy map just to confirm, and it also has RBSP v1. What am I doing wrong in this case?

EDIT: NVM, figured out I need to specify the game when merging with -ja -game. Seems like it worked, now I just gotta try and align the brushes properly, I guess?

[SomaZ]

7 minutes ago, RebornKyle said:

Hm, when trying to do this, it complains that its not in IBSP format. I checked both files and they're RBSP with version 1. I also checked a base Jedi Academy map just to confirm, and it also has RBSP v1. What am I doing wrong in this case?

Try:
q3map2.exe -game ja -mergebsp -world <mainBsp.bsp> <bspToinject.bsp>

[RebornKyle]

6 minutes ago, SomaZ said:

Try:
q3map2.exe -game ja -mergebsp -world <mainBsp.bsp> <bspToinject.bsp>

Haha thank you, figured out as soon as I posted it. Now to just align the brushes properly I guess

[SomaZ]

6 hours ago, RebornKyle said:

Haha thank you, figured out as soon as I posted it. Now to just align the brushes properly I guess

I haven't tested it, but for easy use, you could convert the mainbsp to like an .obj and use it as guide via an misc_model entity that you delete again before compile. You can either use my blender addon for that or Noesis, which might be the easier choice.

[RebornKyle]

Ok, so after hours of testing, I got the brushes to appear in netradiant when importing BSP into the editor, I did this by taking the map, decompiling it, adding the brushes to where I wanted, deleted EVERYTHING except those brushes, merged that with main. All to avoid a compile. LOL. However, attempting to select the level in-game brought an immediate crash before the loading screen even appeared. So frankly, I'm at a loss, but I've made significant progress.

To give a broad overview, I'm attempting to fix yavin_swamp from Jedi Academy Outcast mod, so it has proper weatherzones like before and generally looks like it did in Outcast. I have managed to accomplish everything, from fixed shaders to scripting, EXCEPT for the weatherzones, as they are brushes. Not only that, but there are already outside brushes all over yavin_swamp (in strange places I might add imo) that don't have weatherzones.

Long story short, everything is functional, except it rains indoors.

There is ONE exception to this however. Upon first compile and loading of the map, and as long as you don't reload it AT ALL, some of the old weatherzones do work! I don't know why, and perhaps someone with more knowledge can explain this. I've attached the two zones that I found that works when this happens, in addition to the console output upon first compile and load.

The other two images are what the game looks like with fixed water, fog, rain, etc.

EDIT: for reference, I am also using JA Enhanced as a baseline, OpenJK mod

[SomaZ]

8 hours ago, RebornKyle said:

Ok, so after hours of testing, I got the brushes to appear in netradiant when importing BSP into the editor, I did this by taking the map, decompiling it, adding the brushes to where I wanted, deleted EVERYTHING except those brushes, merged that with main. All to avoid a compile. LOL. However, attempting to select the level in-game brought an immediate crash before the loading screen even appeared. So frankly, I'm at a loss, but I've made significant progress.

To give a broad overview, I'm attempting to fix yavin_swamp from Jedi Academy Outcast mod, so it has proper weatherzones like before and generally looks like it did in Outcast. I have managed to accomplish everything, from fixed shaders to scripting, EXCEPT for the weatherzones, as they are brushes. Not only that, but there are already outside brushes all over yavin_swamp (in strange places I might add imo) that don't have weatherzones.

Long story short, everything is functional, except it rains indoors.

There is ONE exception to this however. Upon first compile and loading of the map, and as long as you don't reload it AT ALL, some of the old weatherzones do work! I don't know why, and perhaps someone with more knowledge can explain this. I've attached the two zones that I found that works when this happens, in addition to the console output upon first compile and load.

The other two images are what the game looks like with fixed water, fog, rain, etc.

Ok, so theres some things to concider. Weather zones aren't just brushes but also entities. Depending on how you added those, it might not work like that. Second, weather zones are not mandatory to make inside or outside brushes work correctly. Weather zones are just used to speed up the loading of the inside/outside info. IF you have weather zones, inside or outside brushes that are NOT inside of a weather zone are ignored. Jedi Outcast only had outside brushes, Jedi Academy added inside brushes. Only one type of those brushes are allowed per map. So if you mix inside and outside brushes, the game won't load the map. Reloading a map might break the cached weather info, maybe a bug in JA:Enhanced. This needs some investigation.

[RebornKyle]

5 hours ago, SomaZ said:

Ok, so theres some things to concider. Weather zones aren't just brushes but also entities. Depending on how you added those, it might not work like that. Second, weather zones are not mandatory to make inside or outside brushes work correctly. Weather zones are just used to speed up the loading of the inside/outside info. IF you have weather zones, inside or outside brushes that are NOT inside of a weather zone are ignored. Jedi Outcast only had outside brushes, Jedi Academy added inside brushes. Only one type of those brushes are allowed per map. So if you mix inside and outside brushes, the game won't load the map. Reloading a map might break the cached weather info, maybe a bug in JA:Enhanced. This needs some investigation.

Totally right about the inside and outside brushes, that could've caused the crash. I may have to just add weatherzones, as attempting to delete the outside brushes without decompiling has proved fruitless. The problem with that is they're in very strange spots on the map. I'm talking between caulk, out of bounds, etc., and seem to cover the whole map.

From what I understood from looking at base Jedi Academy maps, weatherzones need to be changed to the misc_weather_zone entity, and made a structural brush. Anything else I'm missing? I wont attempt to add the inside brushes further, but they were also structural, but considered worldspawn brushes

Finally, the weather cache is an interesting one. JAEnhanced generates a separate .weather file into the MyGames/JAEnhanced/maps section.  I didn't even know it was possible to generate one of those, I didn't see any info for that on JKHub.  But regardless, my working theory is that at first load, Jedi Academy attempts to read from a .weather file (found in base maps folder) to reduce load time. If there are none, someone at JAEnhanced figured out to generate a new .weather file for a map so that this isn't an issue in the future, and no error is thrown. Jedi Academy is able to recognize the original outside brushes in Jedi Outcast and utilize them. But every time you reload the map, the .weather file that was generated, couldn't find the nonexistent weatherzones when made, so it rains globally instead.

I'll try later to just add weatherzones to the outside brushes and see if that works. Maybe someone from JAEnhanced is still active and could explain/could be contacted about the generating .weather?

[SomaZ]

31 minutes ago, RebornKyle said:

From what I understood from looking at base Jedi Academy maps, weatherzones need to be changed to the misc_weather_zone entity, and made a structural brush. Anything else I'm missing? I wont attempt to add the inside brushes further, but they were also structural, but considered worldspawn brushes

Finally, the weather cache is an interesting one. JAEnhanced generates a separate .weather file into the MyGames/JAEnhanced/maps section.  I didn't even know it was possible to generate one of those, I didn't see any info for that on JKHub.  But regardless, my working theory is that at first load, Jedi Academy attempts to read from a .weather file (found in base maps folder) to reduce load time. If there are none, someone at JAEnhanced figured out to generate a new .weather file for a map so that this isn't an issue in the future, and no error is thrown. Jedi Academy is able to recognize the original outside brushes in Jedi Outcast and utilize them. But every time you reload the map, the .weather file that was generated, couldn't find the nonexistent weatherzones when made, so it rains globally instead.

I'll try later to just add weatherzones to the outside brushes and see if that works. Maybe someone from JAEnhanced is still active and could explain/could be contacted about the generating .weather?

Also multiple things. A decompile of a .bsp file will always have only structural brushes. Also when they were detail in the original .map file. But I don't think its actually an issue in this case. So don't think brushes were originally structural when looking at a decompiled bsp.

 

Weather files are generated on map load. The original jka game executables do this as well. It's not unique to that mod. And as I said, weather zones are not mandatory to make the inside/outside brushes work correctly. They are intended to speedup generation of the weather cache.

[RebornKyle]

1 hour ago, SomaZ said:

Also multiple things. A decompile of a .bsp file will always have only structural brushes. Also when they were detail in the original .map file. But I don't think its actually an issue in this case. So don't think brushes were originally structural when looking at a decompiled bsp.

 

Weather files are generated on map load. The original jka game executables do this as well. It's not unique to that mod. And as I said, weather zones are not mandatory to make the inside/outside brushes work correctly. They are intended to speedup generation of the weather cache.

On the first thing, should I make the weatherzone brushes detail then, in the future?

For the second paragraph, I see now that the weather is generated in JAEnhanced, I'll see if it generates in base JA if I take out the ones from 2003. I can't explain why the outside brushes (or maybe something else entirely) make the insides work properly on the first run though, and not any subsequent ones.

I'm not an expert by any means, but I will test further in base Jedi Academy instead of JAEnhanced just to see what the differences are, if any.

[RebornKyle]

Ok, tested it in base, it displays the exact same behavior, so I know its not an issue with the mod. I'll attempt a merging of weatherzone entity brushes and see how that goes. @SomaZ thank you for helping me understand this, I could've been chasing the wrong idea multiple times if not for your insight.

[RebornKyle]

Eureka! I successfully merged one large weatherzone entity that covered the entire map, allowing the game to recognize the established weatherzone patterns, AND keep them upon subsequent reloads. With that, yavin_swamp's restoration is complete.

I found that where you place the weatherzones matter for the outside brushes: if there are no weatherzones encompassing an outside brush, it will not rain there. So I could theoretically make the zones even more fine tuned, as there are a couple of spots it shouldn't rain on the map, but it does, and those outside brushes are permanently apart of the map unless someone does a full reconstruction without those outside brushes. But, I'm just gonna keep it as similar to the base as possible. If I find some discrepancies between base Outcast and this version I'll attempt to fix it, but for now I'm happy where it is.