SomaZ

Uhm, okay. Never heard of this before. What version of the addon did you try to install? If you have instructions on how to recreate this issue, I could probably fix it, unless its a bug in the 3.1 release that the addon triggers by accident. Anyways, latest release (v0.9.96-pre) also works in more recent versions of blender like 4.2.

First of all, the exporter you tried using is part of wonkos addon, not mine. This exporter is supposed to export every surface as a patch mesh. Patch meshes are somewhat limited and you should avoid using patches for regular geometry except for curved surfaces. I submitted a patch to fix the exporter, but I assume you actually want to copy a complete map with that approach, which is not recommended and probably also not actually doable.

You definitly don't have the latest version of the addon, because I fixed this already. Get the pre-release I linked above.

Update the bsp importer addon to the latest version. Get it here https://github.com/SomaZ/Blender_BSP_Importer/releases/tag/v0.9.96

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.

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.

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.

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

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:

Hm, I feel like a grate with things beneath it except for dirt is kind of weird architecture. It looks nice, but feels not very grounded in reality. People will walk over it. People will have dirt on their shoes. It will pile up whatever you do. Theres two things I can imagine that could work to make it feel more gounded. Keep a lower level, but make it somewhat accessable in the sense of, someone is able to clean it easily. Like having a second entrance for the base. But what for? Is that a base that keeps dangerous animals in cages and theres this passway to transport them into the base without endangering the transport crew? What is that entrance or way used for? Second idea would be placing the whole construction on posts and let the dirt pile up under the construction. Maybe add more foliage under it so it looks like its less maintained than the surrounding area? Just my two cents about that topic. Love the progress so far. Can't wait to see what you will come up with.

Vertex animations store vertex information per animation frame. Means, you can assign a new position and vertex normal for every vertex at any animation frame. This is pretty nice if you have alot of ununiform movement. This is at the expense of data storage as it has to store alot of data for that. In the raven jedi knight games though, theres no interpolation between animation frames so those animations are looking somewhat laggy. There are some instances in the game where it was used like the switch animation at the beginning of t1_rail, the bombs you have to defuse and I think the water pumps in vjun. Those aren't good examples to use vertex animations in general though. Edit: MD3 vertex animations are SP only, in MP you can only force the game to show one of the animation frames

We had a talk about this over on discord. It boils down to: GtkRadiant wasn't configured correctly and shader file name was not added to the shaderfiles.txt file in the shaders folder under base.

I just had a look with my WIP version of my Bsp editor, which will have some additional features. The problem is that bsp surfaces get one fog assigned. If it isn't it simply won't draw. A global fog would take place. It's also not just the door, but also the rotating fan that doesn't have the correct fog assigned. I'll try finishing some parts of my bsp editor and then we can try fixing the problem with that.