mjt

Have you started looking in how the menus are build in JKA and what options can be used? There should be plenty of knowledge floating around the modding teams for Movie Duels and Galactic Legacy, as these mods have altered menus a lot. There is also the good old JK2 HD Menu revamp that could serve as a first glance at how things are done. Though JKA will have some differences for sure. I hope you don't lose motivation for this - it's a big task but one that can make a big difference hopefully.

textures/kejim/grate02_long { qer_editorimage textures/kejim/grate02_long sort 3 cull twosided { map textures/kejim/grate02_long alphaFunc LT128 rgbGen identity depthWrite } { map $lightmap rgbGen identityLighting depthFunc equal } { map textures/kejim/grate02_long blendFunc GL_DST_COLOR GL_ZERO rgbGen identity depthFunc equal } } This should fix the floor grating - if you don't get dynamic lights on the grating - try with sort 4 instead of 3. We should also take a look at these shaders: textures/shuttle/shuttleinside2 textures/nar_hideout/conveyor textures/doomgiver/doormaint textures/bespinnew/gantrycor1 textures/bespinnew/bluecarb The door itself looks fine to me, a bit of overlap into structural but the more worrying thing is that the fogbrush has two of its sides visible instead of just one. Up the shaft and where it ends close to the door to the next section of the map. That might be determining fog direction on compile and could be the cause for the door not being affected by fog. It could also be the doors shaders - so if you could upload / share the snippeds requested above, we can exclude that too. Did you decompile the .bsp with GTKRadiants q3map2 or NetRadiant Custom? What I could imagine is that whoever build the map in the first place, was using a map editor where he didn't use the origin brush as part of func doors to set the origin but he just placed his func_doors, edited in the opening directions but didn't set an origin key on the entity itself. That would mean all his func_doors default to having their origin at 0 0 0 coordinates while the doorbrushes / shaders are offset so they appear correct in the .map. But sadly, for fog, it's crucial that the entities origin lies within the fog too. So you'd have to recompile the map with origin brushes in the center of your doors.

I see the issue clearly now. Would help a lot to take a look at the .map file itself. Also the shaders used on the door and floorgrating - as the latter can certainly be made to play nice with fog. One thing that I still suspect is that there are two "open ends" to the fogbrushes instead of just one.

You must make sure for autoSprite2 shaders - that you DO NOT compile your -bsp phase with -maxarea switch enabled. It WILL destroy the effect.

Are you saying this is a JA++ restriction or JKA MP restriction? Most likely you'd have to scale the actual .glm models instead. Did you see if you can exploit ICARUS to scale them beyond what the NPC files allow?

Any fog that is created by a brush and not globally applied via worldspawnfog (affecting EVERYTHING in the map) can only have one of its faces open to the world, the rest would have to touch a structural plane in the BSP tree. So if you have a corridor with a fogbrush only covering that corridor and it has two open sides that could see each other, it would glitch out. One last hope you have for this is controlling the cull key in the shader (cull none, cull twosided, cull back) and play with q3map_invert on the fogvolume to see if you can cheat your way out of this dilemma. Is the doorbrush itself still contained within the fog volume or does the fogvolume end before the door? Some shaders might have used compile time parameters that weren't included in the shader files released to the world. A mapper could've used q3map_noFog to explicitly exclude surfaces in the BSP tree from being affected by fog. Though I doubt this is the case here.

Maybe this can be tackled with modern q3map2 from NetRadiant Custom: https://github.com/Garux/netradiant-custom/commit/8565682f07375f6e4bba5d29c7f42f003ac8627f My advice... do not mix water and fog into one shader - instead make your water with caulk_water (doesn't matter if multiple brushes) the topsides of which you give a watershader (potentially with q3map_tessSize and q3map_globalTexture) For underwater fog, you should make only one fog-volume / brush covering the entirity. If that's not possible, look at the commit above and see if you can wrap your head around it on how to use this change to your advantage. Also take into consideration that the blue overlay and perspective skewing already is forced through it being a water volume, the extra fog you would add via brush. (linear fog, not like worldspawn fog which would use GL Fog with radial falloff and probably inverse square compared to the linear horizontal fog culling you get with brushfog)

You dropped some weird version of ReShade in there - are you sure that's setup correctly? For all I remember for OpenGL32.dll reading games, that's the .dll name you need to get that to work. That aside - you did NOT follow the suggestion I made, as in that you wouldn't have tried it from the steam directory still... You should install OpenJK elsewhere as instructed, not try to start it from inside the steam directories. @Lancelot Are you sure it's a good idea to install OpenJK into the Steam GameData? I thought this might be what's giving him trouble to begin with...

I think this is down to the permissions in the filesystem inherited from the steamdirectory upon installation and management of steam games. What you can do is install OpenJK into a separate directory that you manually create outside the programs, programs x86 or steam directory - somewhere you know you have full permissions. In that new directory, place your openjk exes, copy over the dlls next to jasp.exe from your steam gamedata to that new folder that holds the openjk .exes and dlls - mostly eaxman and openal32. next to the openjk .exes you'll end up with a folder called openjk - that's the mod folder itself - potentially containing .pk3s You can then add some commands to the startup commandline for OpenJK .exe +set fs_cdpath "fullpathtosteamGameData" +set fs_basepath "fullpathtosteamGameDataBase" +set fs_game "openjk" and it should no longer complain about not being able to write or work from the steam dirs. And furthermore, courtesy of Ensiform - might be wise not to put your OpenJK directory into Onedrive or in general in any sort of file sharing / watched directory. It's bad practise as these tools can interfere with file locking and blocking read / write access during operation.

Correct, but JK2MV reintroduced it for MP - I think OpenJO should also allow to use it.

@RobiWanKen0bi You didn't follow my screenshot, you also have to set spawnflags 1 to set it to solid - use the mins and maxs from my new screenshot, they match the rock more closely - the modelscale and modelscale_vec keys will also scale your mins and maxs so those should always be calculated from the default scale of the model. Of course you can also freely scale your model with the modelscale_vec key but then you might have to use offsets to the mins and maxs usually used. You can also set those to close a gap in your map perfectly if you don't scale the model with modelscale or modelscale_vec - otherwise you have to take those into consideration too and calculate your mins and maxs with this factor per axis. You don't need mass, gravity, the damage stuff or the material - but the material helps when impactsparks are generated. Here's the list of materials: "material" - default is "0 - MAT_METAL" - choose from this list: 0 = MAT_METAL (basic blue-grey scorched-DEFAULT) 1 = MAT_GLASS 2 = MAT_ELECTRICAL (sparks only) 3 = MAT_ELEC_METAL (METAL2 chunks and sparks) 4 = MAT_DRK_STONE (brown stone chunks) 5 = MAT_LT_STONE (tan stone chunks) 6 = MAT_GLASS_METAL (glass and METAL2 chunks) 7 = MAT_METAL2 (electronic type of metal) 8 = MAT_NONE (no chunks) 9 = MAT_GREY_STONE (grey colored stone) 10 = MAT_METAL3 (METAL and METAL2 chunk combo) 11 = MAT_CRATE1 (yellow multi-colored crate chunks) 12 = MAT_GRATE1 (grate chunks--looks horrible right now) 13 = MAT_ROPE (for yavin_trial, no chunks, just wispy bits ) 14 = MAT_CRATE2 (red multi-colored crate chunks) 15 = MAT_WHITE_METAL (white angular chunks for Stu, NS_hideout )

@Linken Excellent and indepth tutorial - it would help if we could jump to certain section but I don't know if it can be setup like that in a post - jumping to specific posts yes, but to a specific point within a post?

@Linken Excellent and indepth tutorial - it would help if we could jump to certain section but I don't know if it can be setup like that in a post - jumping to specific posts yes, but to a specific point within a post?