Szico VII

You will need the shader name included in shaderlist.txt to make q3map2 process it properly.

Instead of whiteimage point the glow stage to a duplicate of your base texture, but modify it to highlight where you want the glow areas to be: And yes the first whiteimage line should point to your texture file, because as that shader stands the only thing the actual light texture is being used for is the editor, not ingame render Example (base image on left and glow image on right)

Is it actually on a patch mesh?

I have really been trying to get around to it - as soon as I can, I will Moving water below https://www.youtube.com/watch?v=USoX7SHJZds&list=UUygvLoacwTW2DqhEpgSqFtQ

https://www.youtube.com/watch?v=1i4sF32xMnE&list=UUygvLoacwTW2DqhEpgSqFtQ&index=4 How about this? - Benefit of that is its baseja no mods required

Now we have Noesis utility, you can actually convert an ase to a useable ingame md3 if you need to!

Yes changing the effect will likely change the visual origin of the effect, but I suspect damage is calculated hardcoded based on model tag e.t.c. Especially as there is no dmg or damage code in that .efx

-samples 8 is a bad idea, it will make you quickly run into lightmap bug of death, especially with a global _lightmapscale Importantly, neither of these will improve the contrast of your shadows. Only changing the lighting itself or using -dirty or -gamma x will achieve that.

Best way to create a dynamic light is with an effect file. You can use those infinitely and they are genuinely dynamic compared with the q3map2 light styles method, which is also more limited as you can only use 4 within one area

External lightmap shaders only ever worked on patches for me - used on brushes it causes weird funky effects. If there's particular areas you want to improve the shadows, you can improve in several ways depending on lighting and structure. 1) Use q3map_sunExt for your sun shader, this allows you to define the penumbra and level of blurring applied to shadow edges 2) func_group and THEN use _lightmapscale on the func_group to improve quality without applying to the whole map 3) samples 3 in light compile stage 4) the -dirty switch on light stage will darken shadowed areas compared to lit areas. You could also try -gamma and a value Wouldnt bother with the surfaceradius and other sun fixes for q3map_sun, because q3map_sunext does all of these but better.

Unfortunately, as far as I know, any shader lighting applied to a sky shader will be applied to all sky shaders in your map, even if its a different sky shader. They work cumulatively too, so having a sky light on each sky shader just "adds" together, regardless of whether that particular shader is in a given area.

Sweet. Animmap?

https://jkhub.org/files/file/1976-map-models-pack-01/ Depends what you feel this brewery would need, but there's things like a forklift and a generator model in there.

Lightmapscale of >1 will actually help, as it is values of less than one that will cause this error. However having that on 60% of your brushes will do it regardless, particularly if you're compiling with -samples or -bounce or -filter. You can use it more sparingly or try 2x2, 4x4 instead.

Make sure those grates are detail brushes - that will also solve your problem. AFAIK, surfaceparm trans means that it ignores vis calculations and light will pass through it, whereas nonopaque just means when calculating lighting, this surface will let light through, but for vis calculation purposes you cant see through it.

One thing you could to (to get around it) is to use the remove command to delete the vehicle, then use a static model equivalent at the same time, make it appear visible. Rotate the static vehicle model to the right angle, then again hide it (SET_INVISIBLE) and respawn the vehicle facing the right way. Bit of a workaround if the rotate a vehicle thing doesnt work.

q3map_lightmapsamplesize 1x1 Thats one of the things that can cause such an error, particularly if the shader is used extensively and especially if combined with a worldspawn key like _lightmapscale (0.xx)

-subdivisions only applies when you're using it to convert brushwork into an .ase model (using -convert ase), in which case a lower value will increase the level of detail of the baked patch surfaces into the ase, afaik. If you want to increase the LOD of patches ingame, you want something like r_lodcurveerror (and change it from 250 to 500, or 1000) If you want to change the LOD of the patches in radiant, there's an option called patch subdivsions in the preferences somewhere. However, ingame this always approximates to a subdivisons value of 4-8, unless you change the curveerror as stated above.

Sorry just got back from honeymoon, been away

http://tf3dm.com/download-page.php?url=submarine-28398 Sub Model

Try again now

Send it to me and I'll have a go - usually you should be able to move things fine! Exceptions are if you haven't built to the grid or if you dont click within a brush when moving a section, because then you risk resizing it instead of just moving it. Get me via PM