Is overlapping at offset between minimum, and maximum:
An additional condition like overlap at offset, but checks all pixels between two values. Like if you gave it 4, and 8 it would check all the pixels between the hotspot +4, and the hotspot+8. Something like -10, and 10 would basically check both the left, and right for a collision if it were on the x. I realize you can use the los behavior for this, but that can complicate things, like a 45 cone would get just one direction, but if you need multiple directions you must add another behavior. Blah, blah, blah 360 degrees misses corners, etc.
You can use -n & n in the expression field.
Run time editable hot spots:
The origin is where and object can be scaled from. Say for example an object had the origin on the left center, and you scaled the width higher, it would look like the object was growing towards the right. The only way to make it look like its growing in some other direction is by either changing the angle, which may not work in some situations, or add another object that has the hot spot set to the preferred side.
What about "scale" action? Doesn't this one will work from the center? If not, then +1
Origin for los, other than hot spot:
The hot spot isn't always the ideal position for the cone origin, and using a dummy object is overly complicated.
Also: Can't see around square corners, so using "solid" can be an issue with something else that uses solid, say tilemaps.
+1
Object.timescale:
We have object.dt, but using the actual timescale would simplify some things.
+1
Weighted random:
It would be nice to have an expression that that gave us random as a chance, or dice roll, or percent. Like in this thread :https://www.scirra.com/forum/viewtopic.php?t=66495&start=0
There are so many good places to use that, but implementing it for each "roll" is a big hassle. Id say use a function, but then you get the picking issue.
+1
Could I throw in "Disable collision between selected instances" ?