NAB622

It kind of looks like it's just displaying the lightmap on that brush instead of the shader. If you want to test that, see if a colored light in the room changes the color of the grate. If it is a glitched lightmap.....I'm not even sure why, or where to start. It's fixable, but there's a *lot* of trial and error involved without some kind of q3map2 warning or error being given.

I suppose I should have clarified, the default lighting also counts as a style, so the maximum you can have in that room is 3 styled/triggered lights. You may need to rethink what you're doing. Speaking of, what exactly is your goal there? There might be another approach that works. As far as the spectator shot, I'm not sure what's going on there! Weird stuff.... Are you using patch meshes in the corners perhaps?

Any light with a style key, or a unique targetname, counts as a styled light. Multiple lights with the same targetname are grouped together and will function together as a single style. Color and brightness are irrelevant in all cases. Can you post a few pictures of the current state? Depending on how blocky the result is, there may be several solutions. Assuming nothing is glitched, my immediate thought is to identify the problematic surfaces, make them a func_group, then add a _lightmapscale value of 0.5 or less, and see if it helps.

I doubt the T-Junction error has much to do with the lighting, although it is possible. See if a brush cleanup will help with the T-junction error. There is a limit on light styles per surface, though, and that's likely what's causing the most serious issues here. The best approach to switched lights is to use as few switches (And styles) as possible. If I understand correctly, light entities are grouped together by their targetnames during compile, and there's a limit of four different light styles (Switches included) per surface. It's okay to hit the limit, but surpassing it will screw things up royally. For reference, it is possible to use switched lights to make an RGB system, with a switched red, green and blue light on the same surface. It will hit the limit and throw warnings, but it does not surpass the limit, so it remains functional. However, any other switched/styled lights touching the same surfaces will break it.

My suggestion is..... Make a single, large brush for the underwater effect that covers your entire underwater area, textured on all faces with caulk_water. Then for your water surfaces, either use a separate brush with a shader that does not contain the water property, or use a patch mesh for each one.

I believe the models are inside assets0.pk3. If not there, then assets1.pk3.

Autosprite2 is mostly used for energy beams and effects-style stuff. In the single player campaign, I believe the chains on Korriban use it. I've used it in several of my own creations, too. Taspir Power Complex v3 uses it on the CTF map. There are small vertical energy beams surrounding the flags for each team. Don't know if I ever released the source files for that, though...

That's really strange. I get the feeling something else is at play here. The only way I can try to help further is to see the .map file and the shader file. Sorry I haven't been much help on this one.

Okay, yeah, you'll definitely want to remake that brush. Don't do any vertex edits, make sure there's no chance of the game getting confused. Now..... In my opinion, autosprite2 isn't even a great idea here. The candle is large enough that you should seriously consider creating it out of geometry, with either a 12 sided brush or a patch mesh. Use autosprite2 for the flame at the top. In both cases, if you are using brushes be sure to also mark them as detail (Ctrl + M), that should discourage the geometry splits on each face.

After thinking about it for a bit, what does the wireframe on that brush look like? Maybe it has a bunch of invalid faces. That could certainly cause issues.

We learn by doing, and that goes for me too!

Actually, that's okay to do for most edits. Certain things like lightmaps have to be compiled, so recompile your map and reload the level in-game, and you should see the changes. That's probably why it suddenly started working for you.

Ah, sorry, I misunderstood your issue then. Can you post a screenshot?

Autosprite2 works across the longest axis of a surface . Try making your surface rectangular instead of square.

Here's what I would do..... I would make the candle flames a separate texture on a pure black background, add them as a separate stage to your shader, and use blendFunc GL_ONE GL_ONE on them so they blend properly with the environment. For the candlesticks, remove the blendFunc, and use an alphaFunc to mask them. I haven't written shaders in forever, so I can't write an example, but if memory serves, the landing pad texture at the center of mp/ffa5 is a great example of alphaFunc in action if you need it.

Can you post the image as well? If it's just a flame, forget using alpha and just use blendFunc GL_ONE GL_ONE.

/developer 1 is a CVar that needs manually typed into the in-game console, not added to the script. It will show the execution of the script as it goes, making troubleshooting much easier. It likely won't help me very much, but it could help someone more experienced with single player scripts to determine the problem. If you're using something as a template, I would suggest reverting to that method, since ultimately I'm just shooting from the hip. The suggestion for /developer 1 and the print blocks remains a good idea, though.

I don't work with single player, so this might be wrong, but I believe you can remove the "Affect" block, and check the "runonactivator" flag on the target_scriptrunner. I can verify that it does work that way in multiplayer. To further troubleshoot, I would add a few print blocks to the script, set /developer 1 in-game, and see if the prints show up in the console. That should help you determine exactly where the failure is.

Assuming SoundGroup is not a thing.....a simple script and a series of target_speaker entities is 100% the cleanest way to go. If you want to set up an entity system to play random sounds without a script, use some kind of a trigger (I'll use trigger_once here), target_delay, target_random and target_relay. trigger_once | | v target_delay <--------| | | |-------> target_relay | | v target_random | ------------------------------- | | | v v v target_speaker target_speaker target_speaker Target_delay has a random key, use that to create your randomization. Edit: A side effect of this setup is that the trigger_once will also trigger the target_random, since they'll end up with the same targetname. All it will do is trigger a sound immediately before the delay takes place, so it's not a problem, just something to be aware of.

Target_speaker is buggy as hell. Several of the parameters don't work. I don't think the wait key does anything on them, either. You might be better off using target_delay or a script to fire it every few seconds or whatever. In fact, if you're looking for random sounds, that wouldn't be a bad idea, in my opinion. I've never heard of SoundGroup before....is that even a thing in Jedi Outcast/Academy?? It looks like your Radiant is set up for Voyager: Elite Force, judging by the Borg reference. Try changing it to Jedi Academy and see what happens.

Are you modifying the base game's assets1-4 files? Definitely don't do that. It's just asking for trouble.

For numerous reasons, don't edit a PK3 directly. Use a project folder to contain your mod, and create a new PK3 when you want to test it. Or if you want, you can start the game with sv_pure 0 and it will also load assets directly from the base folder as well, which is great for testing mods. I've never heard of files going missing from a PK3, but due to the nature of how ZIP files work, it is a bad idea to ever edit one. I've seen them bloat for no reason, and I've seen them take forever to do a simple edit. Never seen files go missing, but it wouldn't surprise me.

My recommendation: make the shaft any shape you like, but make the door square. The physics engine in JA will bug out like crazy if you try to rotate a cylindrical door around the player. Believe me, I've tried. It's not worth the effort. If you want to time the movement of the door with the elevator, you may want to look into scripting the movement. Edit: As far as cutting the shaft, you're probably looking for the clipper tool. If the button is missing or you can't find it, press X.

Eh, consider me a "Wannabe" as far as Radiant is concerned. I have my own set of annoyances with it, and yes, it's very slow to edit many things. But since you've used a different editor, I was curious what parts of Radiant specifically bothered you, compared to the other editor.

Noted.