The current RF_TRANSLUCENT etc. does not offer the full range of effects. Expose a per-entity alpha value, full 8 bits.
Advantage:
Any entity could be modified using this additional degree of freedom. Ghosts, translucent light bulbs, holograms, fade in/out effects in combination with a properly defined RF_INVISIBLE invisibility (not RF_VIEWERMODEL, which has other implications) allow for new designs of NPC's and monsters.
Disadvantage:
Depending on the implementation, visual artifacts are possible (sorting order, alpha blending does not commute). Delta compression minimizes bandwidth penalty.
Effort:
Add byte alpha to entitity_state_t for all entities. There seems to be a partial implementation related to RF_TRANSLUCENT. In fact, the current player model looks quite okay when rendered translucent, no artifacts from sorting order seem to be obvious. The ability to render any billboard/sprite or brush/model used for entities translucent might add complexity in those cases where translucency is already present (RGBA sprites, translucent brushes).
Blending operations do not commute, thus sorting might be necessary. As bounding boxes ensure that models/billboards do not intersect, a sorting of visible entities in depth would suffice. This is supposedly already implemented to resolve issues of several force fields/translucent glass windows in a row.
Within each object, triangles could (theoretically) intersect. Designer and/or preprocessing will have to avoid this. The problem that non-convex models need sorthing can only be resolved by BSP-like presorting, adding a lot of complexity here.
In summary, with the exception of the within-model sorting, the sorting and separate back-to-front rendering pass for translucent entities should already be present in Q2.
Alternative:
RGBA skins and images.
Submitted 980416, revised 980428, comments to Bernd Kreimeier.