Or put a brighter texture behind it so it stands out more against the background. Almost black on almost black is evidently no good for visibility. 

Create a huge fullbright red arrow pointing on this weapon. Add func_train on it, so it's going up and down. Additionally huge trigger covering half of your map, announcing every 2 sec, that there will be a very important weapon to pick up soon.

Utilizing this techniques, you posses all the knowledge needed for professional LD in 2017. 

Tone down the blue lights - they cast a lot of light but the actual light source is dim. Are you using delay 0 on them?

Then, when the area gains contrast and shadows, put a torch next to the nailgun. Nothing extraordinary, just something to provide extra light and stand out from the blue. 

Sort out your Quake resolution, it looks like you resized your screenshot in MSPaint. 

How about a pulsing (rather than flickering) light, placed exactly where the weapon is -- so that that emanates a pulsing glow? Then you kill the light as the weapon is picked up (that's possible in standard Quake, right?).

Another solution (which I suspect you would not want) would be to just move the gun so that it lies unavoidably in the path of the player...

PS: The map looks beautiful, judging by this and other screenshots (in the Screenshots & Betas thread). 

Lol, khreathor. So true.

I think it has made for some very dumb players also. 

A compromise

I tried a few suggestions, but I ended up just moving the gun so that it's in a slightly different area. Hopefully this works better for players, they'll probably at least see the health which should help draw them to the NG. Flashing lights seem too severe for this, and besides, they can't be toggled in vanilla quake as far as I know.

otp: I'm not really sure what happened to that screenshot. Ericw sent it to me, and the version he sent me is a much higher resolution. No idea how it got all mangled like that when I reuploaded, oh well. I tried your advice on relighting the area, but there just wasn't any way to get the NG to stand out against the rock of the background, and changing the brushes too much in this area is a really big pain since it was the first rockwork/trisoup I ever did and it's a mess. Ended up moving the gun, like I said. 

Maybe I should make a recording of me chanting "Nail Gun... Nail Gun..." and load it as a custom sound in the map to play next to the pickup. Or I could teleport the player to the nailgun if they try and leave it behind. Maybe I'll write some custom QC to make the nailgun follow the player until they pick it up.

Maybe I should just let people fuck up \o/ 

Maybe put a spotlight texture under the gun? 

Is it possible to use trigger_once to kill a light entity?

I tried testing what I proposed in #17126 above and made a small test map with a nailgun, a light and a trigger_once. I gave the trigger_once a killtarget value "lightkill", and gave the light the targetname "lightkill".

When I tried to compile this map, I got a "Segmentation fault" error message. I thought this was unrelated to the entities in the map, but when I turned the trigger_once back into a world brush, the map compiled fine ... so it would seem that I did something wrong when trying to kill a light with a trigger_once.

Can someone explain what I did wrong? 

Like so?
I think that actually looks nice, and helps a little bit more too. Good idea :)

On a rather off-topic note, does anyone know a good tool to quickly convert from tga to jpg or png? It's annoying to have to open GIMP before I can upload a screenshot. 

 

total_newbie: As far as I know you can't kill a light. I think light entities are removed from the map at compile time unless they're supposed to be interacted with in some way, perhaps if they have a style... Not sure. In any case, the only way I know to turn a light off is to target it, not killtarget it.

onetruepurple: IrfanView! I used to have it on my system, it went away with the Win10 upgrade as M$ borked my PC and I had to reinstall things. Works a charm, thanks! 

the only way I know to turn a light off is to target it

How does that work? I guess it's not just a matter of giving the light a targetname and having something else target it, right?

I just tried that with a trigger_once and got the same result as before (i.e. compiler gave me a segmentation fault error message -- which I'm still not sure is not the result of something else, but so far it seems to correlate with my trying to get entities to do things they can't do). 

https://dl.dropboxusercontent.com/s/df4rh3g7v439jtl/lighttest.map

Not sure what your map looks like, I just whipped this up though. Feel free to take a look or compile it yourself (make sure to replace the wad with a path to the original quake wad on your own computer)

Just a simple button that targets a single light. The only keys i've changed are the target/targetname. 

Yeah, that compiles fine on my end and works as intended. When I try the same thing with a trigger_once instead of a button, though, I get the segfault error when I try to compile.

Also: when I change the light style in your map to slow pulse, the button no longer has any effect in-game; the light just stays on. It still compiles, though. So I guess one can only switch standard, non-pulsing and non-flickering lights on and off?

Does anyone know why I can't switch off a light with a trigger_once? 

"Maybe I'll write some custom QC to make the nailgun follow the player until they pick it up."

That would be hilarious! "Pick me, pick me, ooh, ooh, please pick me!" And make it hop behind the player with cartoony boing-boing sounds. 

I'm pretty sure you can't turn a light off or on if it has any style other than the default. I remember trying that once before.

You should be able use a trigger_once though. The light needs a targetname and it will toggle off/on every time it's triggered. I have definitely done it with a trigger_relay activated by a trigger_once. 

Thanks guys. Problem solved.

I should centralize the level anyway.

ACHTUNG!

1- QuakeSpasm 0.90.1 doesn't have 999 as a protocol. Update your QS;

2- The +sv_protocol switch must come before +map on command line. 

I should centralize the level anyway.

If you haven't done this yet, I'd say that should be first priority. Requiring protocol 999 (or bsp2, for that matter) when it isn't actually necessary seems like a very messy solution...

(I mean, technically one could make even e1m1 require protocol 999 by moving the entire map to the +/-4096 boundary.) 

That would be neat prank actually. 

That was hard to spot. 

You could place the nailgun over a hole, put a really bright light in the bottom of the hole, then hide the hole by filling it with a func_wall. If too much light escapes the hole, make it a spotlight. 

What light tool / version are you using? I can't reproduce that in my tool.

Generally segfaults are always bugs in the compile tool, rather than the mapper's fault.

So I guess one can only switch standard, non-pulsing and non-flickering lights on and off? Right. It's just a limitation of the vanilla progs.dat though, this could be done with modified QC. 

Generally segfaults are always bugs in the compile tool, rather than the mapper's fault.

Ah, ok, thanks for clearing that up.

I'm using your tools, but I have v0.15.4.

If you want, I'll upgrade and see if I can reproduce the issue.

What I really should/want to do, though, is get all of my tools up to date, but my primary tool, namely TB2, I don't know how to update short of a fresh OS install (which I'm reluctant to do at the moment) -- see my query in the TB thread.