mjt
-
Posts
139 -
Joined
-
Last visited
Content Type
Profiles
News Articles
Tutorials
Forums
Downloads
Everything posted by 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)
-
What line? -
Nice! Change sort to sort additive in the shader for the beam and it will play nice with overlaying transparency and portals Means make a custom shader to be used in the .efx and add this sort value before the shader stages start... gfx/effects/sabers/red_line_custom { cull twosided sort additive { map gfx/effects/sabers/red_line blendFunc GL_ONE GL_ONE rgbGen vertex } }
-
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?
-
Folks who checked this out, beware that I have occasionally updated this topic to include my latest findings with regards to mapping the q3map_ parameters in the shaders to their surfaceparm counterpart...
-
I wonder where I said you should ? Just providing another option here, because I really have grown fond of this tool over Radiant 1.6.6 because of its advanced BobToolZ plugin for Patchmeshes and the new patch primitives. I also like to compile with the version of q3map2 it brings along. Thinking about it, I will now edit the post again to include what I did to get that to work properly. Granted it's a bit of effort but nothing special.
-
Just updated the instructions - shader editing no longer necessary during setup
-
NRC gamepack only has entity definitions and build menu configs. I was suggesting installing the assets from the original JA SDKs for shaders, editor relevant textures and so on. Those are not included in the NRC gamepacks.
-
Download a release from Garux GitHub: https://github.com/Garux/netradiant-custom/releases And the gamepack contents from: https://icculus.org/gtkradiant/downloads/1.5/gamepacks/ja-example-maps-2005-01-16.tar.gz Extract the .tar.gz file using 7Zip for example so that the folder "ja-example-maps-2005-01-16.tar.gz\ja.tar\base\" ends up being your base folder of the environment you want to map for. You may want to use notepad++ - extract the shader files from the base assets or use the ones from the above gamepacks. Check the documentation that comes along with NetRadiant Custom from Garux, you will see what shader instructions can be used with the included build of q3map2 docs/shaderManual/contents.html docs/Complete_list_of_shader_keywords.htm docs/Complete_list_of_command_line_parameters.htm Don't worry. The only relevant part of the documentation is about what instructs q3map2 to modify a surface - don't worry - undocumented stuff that is specific to JKA such as clampAnimMap and oneshotAnimMap do work of course as they are not what you have to look with regards to compatibility here - only instructions that affect how q3map2 modifies the surfaces - not the engine later on. Extract NetRadiant Custom so I has a "netradiant-custom-DATE_OF_RELEASE" folder inside the "netradiant-custom-win64" folder you can place about anywhere you want. I'll share my template adaption of the unverified_gamepacks ja.game package so you can extract this alongside radiant and overwrite the existing files. I've customized the compile options as I didn't feel the need for the original variations anymore with more sophisticated q3map2 features in use. Inside the archive will be my preferences and modified compile commands. The original ones can be found in the unverified gamepacks if you want to see it. However look at my zip file so you know where your files should end up incase you want to build this yourself... The file linked to this post is to be found here: If you are running NRC on Linux, run with the .x86_64 file. You may need to install LibQt5quick: sudo apt-get install libqt5quickcontrols2-5 libqt5multimedia5 libqt5webengine5 libqt5quick5 libqt5qml5 Either right click radiant.x86_64 and click Run, or run from terminal.
-
Yeah, we talked about how CS-Go Battle Royale did VIS blocking. However I never checked out the portal *.prt files so I didn't recognize this was an issue with q3map2 / workflow. Seems you lucked out!
-
@SephFF I summon thee! Do you remember the VIS blocking you did under your terrain? Good for you!
-
The mins and maxs use the model origin as reference - you do not define the bounding box in world coordinates but in offset from the origin of the model. Then it should work.
-
I suggest you modify the init scripts for each map - use DevaheB to decompile your scripts, then use BehavEd to recompile them - or alternatively find some other way to execute your script before the player can take control again. It seems SoFII has direct injection for console commands and cvars - probably allowing you to make a cheat injection script or potentially modifying gravity directly in ICARUS - provided you can somehow extract more headers for BehaveEd to use. Just incase you're curious you could try if JKAs ICARUS command to modify gravity still works, or if IBIZE.exe will refuse a compile of your script and how such a script if sucessfully compiled would behave in game.
-
If the .bsp in question has a brushmodel that has no drawsurfaces, as in only collision but nothing to display AND it has the right shape, you can reuse this in a func_static / func_usable entity via entity modding. Brushmodels being the numbers with the * in front of them. Alternatively misc_model_breakable can display a md3 model AND have autobound key set with mins and maxs keys set to give it bounding box physics - those will never rotate along with the model though and always be on the cardinal axes - a brushmodel collision block CAN be rotated as far as I recall. For misc_model_breakable the angles key can be used to rotate the visible model, but the bounding box will not rotate along.
