Per Entity Lighting Effects

Lighting control by means of moving entities or runtime intensity changes is an important design option missing from Q2.

Advantage:

This makes lighting effects more flexible. Scripted lights are those that do not move, and having them handled client side automatically cuts down network traffic. Dynamic lights that move contribute to network traffic anyway, because of the movement. Dynamics lights with properly chose position and falloff could be attached to moving trains and plats w/o creating artifacts. Muzzle flashes are essentially a temporary entity made of a zero size sprite and a light level and color.

Disadvantage:

Adds to network traffic, minimal with delta compression in the absence of changes.

Implementation:

Requires rewrite of entity handling with respect to lighting effects on the client. I propose adding to q_shared.h::entity_state_t

a signed lightlevel value, which would allow non-scripted lighting changes by entities, including negative intensity ("black hole" darklight effects).
a byte rgb[3] light color parameter added to the entity data, so that colored lighting is available.
a falloff parameter separately from the intensity. In some cases, you might want a large but pale light, in others, it should be a small but intense one.
a lightstyle index pointing to a CS_LIGHTS string. If present, the lightlevel above will simply add an offset.

For both fixed (scripted) and moving light entities, linear interpolation/extrapolation of (some of) these parameters could be used beween svc_frame updates.

Muzzle flashes are one example of temporary entities as light sources.

Alternatives:

This is complements the "Darklights In Scripting" proposal, which would expose negative intensity to scripting. It incorporates the proposal on extended use of dynamic lighting by Nathan Silvers.

Submitted 980411, revised 980420, revised 980508, comments to bk@gamers.org.