mjt

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.

On 5/6/2023 at 6:22 PM, ancanar said:

 BTW - I guess this effect was absent in Jedi Outcast, right?

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?

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.

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

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

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

Only using one stage to depthWrite and alphaFunc GE128 and the following with depthFunc equal which will only write on the alpha mask of the previous stage... that would then be static and the depthFunc equal stage would be scrolling. However the variant with terrain blending seems to be the better choice - using it on top of the suggested method and having the alpha mask around 128 in average brightness and some grainyness in between. Similar to this: 

as the alphamask first stage

Forwarding you this from Discord by @Raz0r :

Quote

sounds like https://github.com/kugelrund/Speed-Academy with g_vrgi 0
i originally tweaked that in OpenJK-Speed, which made its way into JKEnhanced. but i'd say Speed-Academy is the most polished 

On 10/12/2022 at 4:40 PM, undeadslayer said:

That file on github does not work with Jedi Academy or Jedi Outcast, these two games are not even on their radar as games that uses the quake engine. The method that NumberWan mentioned will work, but the problem is that user's instructions are as clear as mud so I will re-explain it in better detail.

bsp sekai was supposed as a suggested tool to convert quake live bsp files to regular q3 bsps which then can be properly decompiled with the method NumberWan mentioned. It was just a reply to the comment above, not the initial question. Just left it here incase 5m1le71ger sees it by chance.

@DarthDrako

• MP Movement • Not identical to MP but close. Allows for bunny hopping and less "slide" effect when moving. g_bunnyhopping 1. Also in the menu.

Could that already be enough? I suppose it's not the same but maybe it is - give it a try and report back your findings

Remember the random mission generator from SoF2? You'll find parts of that still in the code in JKA I think, but it's not in a usable state. For all I know neither GTK Radiant nor NetRadiant Custom provide any phython hooks. Your best bet for that would probably be blender, combined with q3map2, the io_map_export plugin - that way you can do level geometry instancing from assets, and export it all to brushwork for collisions and use .fbx as a modelformat for your actual drawsurfaces - could set up things in python or geometry nodes to procedurally assemble the assets to a level then.

I'm looking to do the same for a remake of a KotoR level right now.

I'll leave you a few links wrt level generation / modification that I frequently use for this:

https://github.com/c-d-a/io_export_qmap / https://github.com/andyp123/blender_vhacd / https://github.com/kmammou/v-hacd

https://github.com/SomaZ/Blender_BSP_Importer/tree/FAKK_EF2_Support (Has a more up to date WIP build floating around Discord)

https://garux.github.io/NRC/ / https://github.com/Garux/netradiant-custom/releases

36 minutes ago, SimonP said:

I need to understand how scripting refers to the objects/entities even if I expect to initially just copy the logic from existing scripts in the game levels/SDK.

Entities like trigger_* target_scriptrunner, NPCs, NPC_Spawner / NPC_Vehicle and all the func_entities (bare func_group), potentially the normal point based entities like target_ as well, can have a spawnscript / usescript setup on the entity in Radiant - this script runs on spawn/use on the entitiy itself (exception being target_scriptrunner which can run it on the entity that triggered it)

From that scope you have access to the parm1 to parm16 fields of the entity and can control it with all the ICARUS commands supported by this entity. Some commands however will not execute without an affect block directing them. In that case you should check out here: https://jediacademy.fandom.com/wiki/Icarus_Scripting:_basics#script_targetname

You can use this script_targetname / targetname stuff to affect other entities and run scripts on them from another script. I am not sure if defined variables in scripts are inherited down anything that is started from its scope or if it's accessible from two different running scripts. Something to test eventually.

2 hours ago, SimonP said:

In this section (https://github.com/JACoders/OpenJK/wiki/ICARUS-Scripting#brush-manipulation-commands) it says "This code will put the affected entity on a constant motion between (0,0,0) and (0,0,100), each move taking 2 seconds, with 3 second stops.", however it looks like it actually has 5s (5000ms stops). The same is true for the example code above and below the quoted text.

All commands are send off immediately one after the other - wait commands make the script wait.

So if you instruct a brush to move for 2 seconds, and have a 5 sec wait command after it, the brush starts moving as soon as the wait starts counting. So the wait arrives at 2s when the brush reaches final position, leaving you off with 3 more seconds of wait till the next brush movement is send off with another wait.

Try to figure out what actually is executed at which point and scope. For example if you define tasks in an affect scope that include waits, the scope in the affect block will regard them, but any command executed after the affect block on the same level of hierarchy will just immediately fire off, as soon as the affect block before has been sent off as instructions. If you need for the script to wait, you'll either have to carefully time everything using wait commands in the correct scopes, or you use if blocks and parms / variables to check for completion or check out the signal / waitsignal mechanic.

On a sidenote, if you want to move entities in a linear fashion with ICARUS, instead of smoothed out / accellerated / decellerated - you have to give them a key/value combination on the enitiy in Radiant/BSP:

linear
1

This is not sth you can set with ICARUS, it has to be compiled into the map / changed via entity modding / patching.

To understand when wait does actually wait:

//(BHVD)

affect ( "some_mover_entity", /*@AFFECT_TYPE*/ FLUSH )
{

	task ( "DEFAULT" )
	{
		move ( < 0.000 0.000 128.000 >, < 0.000 0.000 45.000 >, 4000.000 );
	}

	dowait ( "DEFAULT" );
	sound ( /*@CHANNELS*/ CHAN_AUTO, "sound/movers/sec_panel_pass.wav" );
}

The sound will play as soon as the mover starts moving - the task does not include a wait command and will report as completed to the "dowait" as soon as the move command is send off and the brush starts moving.

If you wanted the task to take as long as the brush moves, you must include a wait inside the task:

 

//(BHVD)
rem ( "comment" );

affect ( "some_mover_entity", /*@AFFECT_TYPE*/ FLUSH )
{

	task ( "DEFAULT" )
	{
		move ( < 0.000 0.000 128.000 >, < 0.000 0.000 45.000 >, 4000.000 );
		wait ( 4000.000 );
	}

	dowait ( "DEFAULT" );
	sound ( /*@CHANNELS*/ CHAN_AUTO, "sound/movers/sec_panel_pass.wav" );
}

On the other example - the one about tasks and loops - this really looks like a mistake to me. I think what they intended to convey was to define a task that uses parms exclusively outside the loop once, and call it inside the loop as dowait or do instruction.

Using parms / variables can help you write better universal scripts that can be reused on many entites throughout a level. But for basic stuff it's not really relevant too much.

What are you cooking up though?

On 10/9/2022 at 6:33 PM, 5m1le71ger said:

1.  If map makers put the map file into PK3, there will be no such problems, provided the author has an open mind.

2. One problem with Q3MAP2 is that it can't convert the quake live BSP file, which will prompt for version 47, not 46. So, what tools can convert a version 47 BSP file?

https://github.com/zturtleman/bsp-sekai might do the trick...

On 9/23/2022 at 8:29 PM, Vermillion said:

Is there any way to apply this hardcoded effect on a custom model? 

Well you can check out the saboteur NPC and assign a different model to it, see if the stealth still works on it - from there on out you could make any kind of NPC as long as the class is what makes it cloak...