�Select entity you want to add light to (Any entity!).
�Add key|value pair of light|200
�Compile

(Note that these lights don't move, so while you can add light to a monster or door, the light won't go with it when it moves (for that use an effect)) 

Why on earth would you add light properties to some arbitrary entity when you can just make a light entity in the place where you need the light (which makes what's going on clearer in the editor)...?

Is there any trick/benefit here that I'm missing? 

(assuming tyrutils-ericw used) you can add the "_minlight" key to a brush model to give the model a uniform base light level, but adding the "light" key just makes it act like a regular light (right?) and because that light will be emitted from the model origin, it is unlikely to light the brush model in a way that you'd like. 

To powerups and weapons can make it easier to light instead of having a hard-to-select light on top of the item.

Otherwise, ya put in a normal light. 

I'm sure that once upon a time light tools would only look at the lighting keys from entities whose classname began with "light". Has that changed?

I'd be glad if it has changed, as it's really helpful for mapobjects in two ways: firstly you can create a custom torch model etc and have it emit light just like a normal torch. I was considering adding a classname "light_mapobject_custom" to Quoth to work around it.

Secondly: for mapobjects which aren't obviously lights, a tight spotlight pointing straight down can be used to finely control the light levels of the model (perhaps with negative light if it's too bright). Adding the keys directly to the mapobject entity would make this trick a bit simpler and more robust. 

A good post. 

A well put posted post. 

I got the idea for lights on weapons from id, e4m6 or 7 I think.

I thought all compilers supported this? 

can water brushes be a door, platform or train? How about changing water levels like in OoT? The only design flaws were the obviously broken boot-change mechanic and the sometimes not so obvious hints to a puzzle, otherwise it stands as one of the best dungeons of the game. 

 

Making my first Quake map I somehow managed to assign a light value to an enforcer. It took me a while to figure out why that monster closet was so bright.

I don't remember what the actual compiling tools were. That was 1996/97 so probably whatever came with the original Worldcraft. 

I hope it will work :) 

#18478: take a look at http://quake.chaoticbox.com/downloads/extras_r4.zip mod. It has the best usage of changing water levels that I've found so far.

Also, AD supports puddles that drain with the trigger_touchsound which oddly is more of a func_ since it is visible. 

Complete noob to mapping here, been experimenting with it and have been trying to figure out a kind of odd scenario- is there a way to prevent an entity from appearing until the player has done something else in the map, i.e. pressing a button or killing a certain enemy? I know monsters can be teleported in, but I mean things like a pickup or message trigger not existing until it's called. Something like the episode gates that only appear if you have the rune, but within a single map (and without runes).

I'd imagine it's possible to kludge something together for item pickups (hide them in the roof/walls/floor and raise them when triggered), but what about entities that can't be pushed around like that? 

It depends on the MOD you use.
With vanilla quake you only have the ability to have monsters spawned in from closets. (Think of rooms not connected to the map layout. Put a trigger_teleport around the monster, and a teleport_destination where you want to spawn that monster. All you have to do is now to target the trigger_teleport when desired. (Button pressed or trigger_counter fired or or...)

With MODs like Quoth or AD this is even easier, just give the monster a spawnflag (iirc 32 in quoth, 96 in AD) and target the monster via your setup. (Monster needs a targetname set for this to work.) 

One (complicated) option I've considered using but haven't yet was having an exact copy of the section of your map with the revised entities.

So you have section A of the map and an alternate version that's unreachable outside the play area. Let's call it A-2. Your player moves through A and kills monsters etc. Moves forward to section B (make sure and separate A from B with a "gate" of some kind - a door, teleporter, elevator.) The player moves thru B to hit a button or solve a puzzle required to move ahead back in section A. By teleporting the player back or finding some other way to route them back to the copy A-2 you could have all kinds of things going on. The dead monsters would be missing but I can't think of any other downside other than that interconnected areas would not work with this method. 

@18488
I know about teleporting monsters, I was hoping for something similar for entities that can't be teleported (which monsters can be) and can't be pushed by func_doors (which health/armor/weapons/pickups can be).

@18489
That's actually a damn clever idea, and the dead monsters could be handled by adding static dead-monster models in the second version of the map- they wouldn't be in the exact spots they died in the original, but not many players would be that attentive anyway. Only thing is depending on the size of the map section, that could be a *lot* of brushes and entities to double up on (and if the branching point is at the very start of the map, pretty much out of the question), and would require some smart design to not make the transition too obvious. 

https://tomeofpreach.wordpress.com/2017/03/14/further-logic-gates-for-2017/

I think you are looking for logic gates?

In vanilla quake you can setup up logic gate map hacks to get things like triggers activating AFTER you do something else in the map. 

Check out the entity state system in Arcane Dimensions. It generalizes the idea of starting "off" (invisible, like it's not spawned), "disabled" (visible but no interactions), or "on" (visible and normal behaviour) to most entities.

You can start an entity in a particular state, and switch entities to a new state by triggering a "trigger_entitystate_on" or "trigger_entitystate_off" (etc.) that targets the entity you want to modify.

It's great for swapping in new gameplay to the same area of a map.