Behavior selection for brush entities and game mechanics

[HugoBDesigner]

It'd be incredibly useful for modders and puzzle designers if we could carefully pick and choose behaviors and interactions between brush entities and the game's many mechanics. This could be useful for custom fizzlers and fields, exploit prevention, or even unthought of mechanics.

The ability to pick and choose these interactions could be attributed to existing entities such as func_clip_vphysics, trigger_portal_cleanser and trigger_paint_cleanser, or could be implemented in a more generalized fashion towards a main brush entity, or even be its own entity.

Some options for behaviors:

• Accepts gel, for letting gel be placed on the surface of the brush; Lets gel through, to act like a grating and ignore the gel; Blocks gel, to prevent it from crossing the brush.
• Blocks lasers; Blocks funnels; Blocks light bridges.
• Allow/block grabbing physics props through it; Allow/block turrets seeing you through it.
• Holds portals, for being able to place portals on it; Lets portals through it, to act like a grating and let the portal shot just phase through the brush.

Ideally, it'd be possible to select not only from the set of puzzle elements that we have (gels, bridges, lasers, funnels, turrets, etc.), but also to distinguish between them and their behaviors. For example, allowing turrets to see the player, but not allowing bullets to pass through (much like glass does), or letting the player hold onto physics props but also block said physics props and also the player from moving through it (as a simplified version of the multi-brush grating we have today).

Optionally, we could have control over subcategories of puzzle elements too, such as distinguishing orange and blue funnels, player 1 and player 2 in co-op, the many different types of gel, source laser versus redirected laser, and so on.

This feature would be exponentially better if it could interface with the proposed triggers from Issue #42.

[RealityAnomaly]

It would be good to unify all these in a single entity, such as a "func_blocker"... but we need to figure out how to get around the issue of there being way too many keyvalues/flags as a result of that :)

[vrad-exe]

Why is "too many" a problem, is there a limit to how many keyvalues you can have on one entity?