SensorToolkit 2 is now available on the asset store, replacing the old version. I’ve been working on this version in the background for the past two years, and I’m excited to finally share it. There was a lot I wanted to add to v1, but it was a dead-end in terms of extensibility and I couldn’t add new features without blowing out complexity. SensorToolkit 2 is rewritten with a strong foundation that’s more amenable to extensions. Plus it has a ton of new features:
Sensors capture the bounding box of detected objects. For example if an enemy detects the player and wants to shoot at its center of mass, there’s now an easy way to do that.
Ray sensor supports all Physics.Raycast shapes including ‘ray’, ‘sphere’, ‘box’ and ‘capsule’.
Range sensor supports all Physics.Overlap shapes including ‘sphere’, ‘box’ and ‘capsule’.
Trigger sensor no longer hooks into Unity Update methods, making it possible to add thousands of static trigger zones into your level without a performance hit.
Line of Sight is now a separate sensor. It’s been significantly extended including the ability to smooth the visibility scores over multiple frames. It can also scale visibility by distance and view angle. So objects in the peripherals or in the distance are harder to see. It’s no longer necessary to use a FOVColllider.
Steering Sensor replaces the old Steering Rig and is now based on the more advanced ‘Context Based Steering’ method. It should work better than the Steering Rig and be much easier to use.
New arc sensor lets you perform raycasts over a parabola.
New boolean sensor lets you combine the results of multiple other sensors. For example: ‘What are the things that I can hear and also see’.
It’s possible to inject custom code into the sensors detection logic if you have custom filtering needs.
I’ve released an update that adds some finer grain control to the FOVCollider component. This component is used to sense when objects are within field of view. Here’s an example of how you might use it:
I have a big update in the works, including a steering rig for characters and air vehicles, and lots of new example scenes demonstrating all sorts of use cases. The scene below makes extensive use of the sensors, including the new steering rig shown on one of the purple characters.
Top notch asset. Still loving it, super handy. (We communicated a few times early on about playmaker actions by email). I am just starting to write some actions for your asset for behavior designer, another popular visual system. The thread is here on the BD forums (I am just getting started). http://opsive.com/forum/index.php/topic,5455.0.html
I’m super glad you’re finding it useful! I haven’t actually tried behaviour designer before, but I was thinking of taking a look at it down the track. Thanks for making your integration code available.
Indeed, behavior designer is a pretty great tool for behavior trees. My post here has all the actions (with descriptions) as well as a link to the short tutorial I put together for it: http://opsive.com/forum/index.php/topic,5513.0.html
This looks really good. Does this come with scripts for obstacle avoidance in 2D XY plane?
[EDIT]
Documentation doesn’t mention anything 2D related, but I see the package contents seem to have 2D variations for every component so I believe the answer to this is probably yes.
Hi magique… Thats right this package has a 2D and 3D version of each component. All of the docs are relevant to the 2D counterparts as well since they work identically (minus the extra dimension of course).
It’s funny that Behavior Designer was mentioned because I just came here wondering if anything was happening between the two assets. Thanks for making those actions tcmeric, I’ll be sure to give them a shot.
I have an event firing to a BD tree once the player is found with a track sensor, and having a bit of delay between it firing and the BD receiving it. Anyone know if it might be Sensor Toolkit or BD causing the delay? Or is that just how Unity handles events?
EDIT: This miiight be because I’m not firing the ray enough times per second. I upped the interval and things work much smoother.
I have an enemy with a Trigger Sensor and a FoV Collider. It has an Enemy Layer and I want enemies to block the line of sight of other enemies (so players could hide behind other enemies with their backs turned for example). Problem is, if the FoV is inside the enemy, they block their own line of sight. I can put it outside the enemy, but then if the player touches/gets near the enemy, the enemy won’t notice them.
Is there a way to have the Trigger Sensor ignore parent objects or is there a way to add a Range Sensor AND a Trigger sensor on the same object while both sensors send the same information back to the Get Nearest Playmaker Action?
I also think it’d be a nice feature to add an offset to the sensors for easier positioning without having to add more game objects for different sensors (unless different sensors are supposed to be an different objects).
Hi Lightrail, I recommend using two different sensors like you’re suggesting. There isn’t a way to configure the line of sight rays to ignore the parent object. The reason is that this option would make the raycasts less performant. You’ll need to use two Get Nearest actions in your playmaker fsm, one for each sensor.
I also recommend that you do put your sensors onto child game objects and position them that way. This helps to organise the sensors for objects which have multiples of them. Im not planning on adding an offset to the sensors because I think this is a much better way to position and orient them.
I think I might have found a glitch of sorts but can’t find the part of the code so that I might fix it.
For the Range Sensor 2D, if I check “Requires Line of Sight”, my event won’t fire. Even if Nothing is selected in Blocks Line of Sight. The object in question shows that is is being detected as well. I tick the option off and it works again. The feature works no problem for the Trigger sensor.
