Enhancement: Much, much more TraceLine

[HugoBDesigner]

What would this enhancement be for?

Scripting

Describe your enhancement suggestion in more detail

The current TraceLineEx and TracePortalLine functions are fantastic, and already handle most cases where a modder might want to use a tracer. But they're still very limited in scope and flexibility, especially in terms of trace filters. As such, to the extent to which it is feasible, I'd love to see the following implementations – sorted by what I assume is easiest and most relevant:

• TraceLinePlayersExcluded: functions exactly like the existing tracer, but ignores the player. May be ignored if the following is implemented;
• Advanced Filters: be it via entity arrays, in-map filter entities, or something else entirely, I think it should be possible to add more than one entity to the "ent to ignore" parameter. At minimum, I believe we need an option to send an array of entities to ignore – which scripters could populate with their own manual filters, entity classes and so on;
• Surface Material properties: when the tracer hits a surface, CGameTrace should include a material properties list. As a most basic example: a tracer should know if the surface it hit is portalable;
• Sweep Trace Finder: this is probably the most scope-creeped option as well as the least well-defined, but given a trace line, cone, hull or sphere, and given the usual parameters of mask and ents to ignore, trace multiple lines (how many could be adjusted) until it finds a given entity or list of entities, at which point the tracer stops and return the hit position. The point would be for custom mechanic designers to have an option to create mechanics that function on an area of effect and require "line of sight". Some random examples: a camera which outputs when it sees a cube; an energy pellet which fizzles anything within a radius of it (except if it's behind glass/a wall, etc.). Very similar to TraceHull, but notably, doesn't stop at the first thing it hits.

EDIT: whenever possible, these implementations should also work through portals.

[TeamSpen210]

• Game code wise, trace filtering works via a trace filter class, which as listed takes a predicate function. Could be tricky to expose?
• For material properties, the surfaceprop, game material int, surface flags would be good, might also want a way to get gel though?
• For sweep tracing, this might be better done in your own code - do a radius entity search for any candidates, then do an individual raytrace to see if they're visible. To be more rigorous, do multiple traces, potentially randomly. That's generally what the game does - turn on r_visualizetraces, you can see paint bombs for example just spam rays to find surfaces. For portals, just look for those, recurse?