Traces (or raycasts, if you prefer) are line intersection tests which can be performed by every major game engine, and are very useful for getting information about an object's environment. However, detailed line traces are something that Construct 2 has been lacking. I've seen a few attempts at line traces done in events, however, they weren't very pleasant to use.
So, to rectify this, I started on a trace plugin, based in part on the line-of-sight behavior. Just like the line-of-sight behavior, you can filter the trace to either solids or a custom list of object types, and you can tell it whether to use collision cells or not. It currently only does line traces, with hull traces planned later.
The plugin has a couple of actions to manage the custom object type list, and 1 action for performing a line trace. The result data from the line trace is stored in the plugin object, and can be accessed via expressions. This currently includes hit position, the normal angle of the line it hit, and the UID of the object that line belongs to. The trace result persists until the next line trace is performed.
Last updated: 2016-11-25 9:27 PM PST
Preview (Drag the endpoints around, and observe the results.)
The plugin provided here is just the first thing I made that worked well enough for my purposes. No real attempts at optimization have been made, other than copying some design patterns I saw in the construct 2 runtime. Using it in a large project is not recommended at this time.
Now, I have a question for ASHLEY. Why is this not default functionality? Traces are too useful for a game engine to not have.