mjt

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

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

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?

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

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

I've no idea how to separate out q3map2 from NRC folder structure - I just switched to using a batch script for the exe in the NRC directory, instructing it to scan my maps folder for last modified .map and then run its stuff on it. I can curate a list of known changes if you give me some time. Most notable changes are under the hood though performance wise and with regards to how for example meta surfaces are generated. In general NRC q3map2 switched to ASSIMP as a model loader - instead of picomodel and thus now supports a wide variety of model formats. Most notably .fbx with vertex RGBA - with this method you can also bypass some of the brushwork based surface count limitations that q3map2 usually throws. Recent q3map2 from NRC also has some updates to the q3map_skylight command, enabling it to sample colors directly from the skyparms ( 6 skybox images ) and cast hemispheric ambient light. The best documentation of what WORKS though is when opening the help in Radiant and looking at the offline / fixed documentation. I'll get back with a more comprehensive list later.

Looking at how some games came along with bink as video format - it seems that some of the idtech4 source ports for doom3 / quake4 have implemented ffmpeg into the engine to support different video formats and more high resolution content. In principle you'd have to find someone willing to do the same here. Or find a different solution. I think .roq won't hold any of the upsampled data. It's just too limited.

Most notable differences are in the toolkits provided - the gizmos / modifiers are a bit more advanced - the workflow differs in some areas quite substantially and coming from GTK, you'll have to relearn or reconfigure some shortcuts. If you want a tour through the tool - I can help you set things up and show you around. The q3map2 supplied alongside is vastly more modern than the one from GTK - it includes a bunch of custom fixes and enhancements documented on either github or the help documents supplied alongside. If you want to take a look: https://garux.github.io/NRC/

How's the result coming along? Also - how do you intend to increase the quality beyond the maximum .roq resolution supported by the game?

Excellent improvement! The water looks amazing! I am so thrilled to see the actual shader setup later! I like how you hid at least some of the hard POM breaks on the trunks with some grass! This begs the question of mixing decal normal maps onto the normal map below - how do different blended textures with normal maps behave? Does it calculate POM on both and just blend them afterwards? The ball still needs to be NPCified - so it can be force pushed and choked What kind of surface type is the terrain right now? When compiling I mean - it should list what drawsurface end up as which surface type. I am just asking since there is also a surfacesprite that is planar and could be used for little POM rocks to also put on there. Not sure this specific one works in the version of rend2 you currently use. Someone on jkCommunity discord was makign some fixes for the sprites and weathersystem last I checked.

I'm not sure adding more "details" will be worth it since it already exceeds anything out there on that front - but I'm already very impressed at the quick pace this is progressing at. Did you ever find a good way to setup underwaterfog with blending depthbased color falloff from scattering in the water? In CostaDelsol, after it's initial release we experimented with a depth based falloff projected from 0 0 0 world origin with tcGen vector during runtime - the scale had to be adapted to the color falloff below the waterlevel to scale properly. Working with fogs will introduce you to marvellous journey of setting up correct sort oder both in .shader file, as well as in the shader it self using "sort" Do you have some sort of actual reflection now using rend2? If still not, you can also use tcGen environment at least for SP when using fake reflections. There's a transform that allows for the projection to be 1:1 with infinite parallax bound to the player camera.

More islands! Makes you long to get over there though probably a bit farther out? Also to preserve resolution between skybox and islands. How is performance so far? Thought about making actual islands far enough apart? Could make some boat NPCs to ride on the water! Cloudshadows - you could just project them as shader stage from above using tcGen vector. Those cloudshadows ofc would not cast dynamic shadows on the player. Thinking about it - the gl2 version of rend2 for SP supported filtering dynamic lights through alphatested shaders (using alphaFunc) you could use that on the cloudlayer and have it invisible from underside but hard towars the sun and move it with tcMod scroll - would have to experiment with where the sun rendering actually happens - maybe can scale up such a cloudlayer brush in _skybox entity skybox. For EAX I meant this: OpenAL / EAX can be restored using a dll. drop in replacement to route sound through directsound or OpenAL to restore EAX reverb and other effects soundwise. When EAX /s_useOpenAL 1 is set in JKA, you'll lose facial animations on NPCs if you don't provide an .eal file (EAGLE mesh) in the eagle directory with the same name as the bsp. This file has sound zone information and is capable of for example the stuff shown above in the video. I think on rend2 this is still the latest documentation out there: