[Released] Sensor Toolkit

SensorToolkit 2 is released!


​

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.
  
• New Navmesh sensor for analyzing a navmesh.

The documentation page covers it in more detail.

 

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:

 

New update with advanced Line Of Sight implementation. Now you can compute partial visibility of game objects easily.

 

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.

 

New video demonstrating what Sensor Toolkit can do.

 

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

Feel free to change them if you wish to do whatever. (My code is very noob). Ill put them under MIT. New github project started here: https://github.com/dumbgamedev/sensorToolKit-BD

 

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 do have another question though.

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).

Hope this all makes sense.

 

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.

 

Gotcha. Thanks for the advice and responding so fast!

 

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.

 

Sounds like there might be a bug, Ill take a look after work. Thanks for pointing it out!

 

It turns out there was a bug, I've just submitted an update to the asset store.

 

Is this compatible with Unity 2018.1?

 

Yes Sensor Toolkit is supported on all version of Unity after 5.0.0.

 

Thanks for the reply! Sorry, just read it. Can Sensor Toolkit be used even without Navmesh? Also, may I ask how is its performance?

 

Yes Sensor Toolkit has no dependency on navmesh at all. I haven't used navmesh in any of my examples. The steering example is only reacting to local obstacles observed with the ray sensors, there's no path planning.

Sensor toolkit has been optimised and it's performance is good. You have a lot of control over the Sensors so you can easily create a configuration that matches your performance needs.

 

Great asset Adam, i've been using it for a while now

In your next release could you possibly add an action to set the "Ignore List" on a Trigger Sensor when using PlayMaker?

 

Thanks, glad youre finding it useful! Sure thing, Ill add this to the next update.

 

Aces, Adam.

Thanks a lot for always keeping this fine asset updated.

 

Is this asset still active and supported?

 

Absolutely! I use it in every project I make so it will continue to be supported for a long time.

 

Excellent to hear and I really look forward to implementing as well. Already purchased.

 

Hi there. During coding I put down sensor.GetNearest() <-- but nothing came up. Is this still a function? Looking through Sensor and SensorToolkit yields nothing aswell. Is there still a way to use this asset?

Also do you have any more tutorial videos for the rest of the asset?

 

Have you already seen the quickstart guide here:

That function is correct. You'll need to use the SensorToolkit namespace, and also you'll need to have a reference to one of the sensors to call methods on it. The video shows how to do all this.

 

Oh I see, I forgot to declare the RangeSensor.

Thank You. Any chance we'll get a video for Rays?

I get this message: NullReferenceException: Object reference not set to an instance of an object

I set it on an enemy game object [2D] and when it comes into contact with the player it just cycles that over and over. Any ideas?

I should start a blog using this thing. So I had to go to my main script where it said sensor and put in my games enemy pre-fab that had the sensor script on it. [if anyone is wondering].

 

The ray sensor works very similarly to the range sensor so I didnt make a video for it. You can read up about it here: https://micosmo.com/sensortoolkit/#raysensor, I'll be making a video for it eventually.. Once I finish a big update to Sensor Toolkit I'm working on.

NullReferenecException means you have a variable equal to null, but you're accessing it as if its not null. Perhaps you have declared the RangeSensor but not assigned the Range Sensor object to it?

 

yes that was it.

 

Very nice asset. Crouch speed would be cool. Easy enough to add though

 

Hi. Long time purchaser but first time user....
Im interested on using the charactersteering rig. So i drag the prefab to a capsule and set my player as target. But it look like it move to player only once and dont really avoid obstacles. Any video on how to properly set this up? Thanks and im PlayMaker user anyway.

 

Hello. You can check out any of the demo scenes and copy the configurations from there. Make sure youre setting the correct physics layers to be avoided. Also keep in mind that it wont do pathfinding and navigate around large obstacles. It can only avoid small obstacles.

 

Is it possible to use the steering behavior with the navmesh? If so is there any example for it?
Thanks

 

@AdamAlexander hey, I am confused as to how number of rays works, even though I change the amount, when I tick on something that has been found it always shows 4 rays leaving the sensor

 

nevermind, I hadn't noticed that it had a LOSTarget component on it

 

Sorry for the late response. It is possible to use the steering behaviour with navmesh (or any other pathfinding system). I use it with navmesh myself. You want to generate a path and then successively input the positions in the path to the target position of the steering rig. Navmesh is a bit tricky in my experience to generate a path without using its Agent Movement functionality. Ive attached the component I use "AINavigation". Put that on your character and set its `targetPosition` property. This will use navmesh to calculate a path. Each frame read the `nextCorner` property and assign to the `Desination` prop on the Steering Rig. The `nextCorner` is the next position in the path. It will automatically progress through the positions when you reach each one.

 

Thank you very much!
Regards

 

Just tried this out, and it looks very well made but still not bloated or intrusive. I'm also looking at NodeCanvas for the first time with this project, and it has its own "if x is in fov" solutions, however, I'd prefer to use your solutions - any chance you could the same line of "plugins" for NodeCanvas as you've done for Playmaker?

 

I love this asset. It does one thing and it does it very well. Stay focused, stay clean.

There is one thing small thing you can do to help us users. Please add Assembly Definitions to your package. This makes it much easier to reuse your code. Specifically, I need it as I have just published some open source code to create an automated explorer cam / flying NPC pathfinder.

TheWizardsCode/AutomatedExplorer: A Unity package that enables automated exploration of a 3D environment. (github.com)

It is dependent on yours code and distributed via UPM. Which means users currently have to manually add asmdefs to your asset once they have installed it.

Would be super awesome if you simply added one for your runtime and another for your editor code.

By the way, while at it could you put all your runtime code into a single folder, makes managing asmdefs easier.

 

Glad youre finding it useful, I'll have a look into this.

 

I have another request in addition to the above asmdef. Please mark the various update methods in the steering rig as protected virtual, along with any others you think might need to be extended.

My use case is that I have added some functionality that ensures the object stays within a particular height range, regardless of collisions. This requires me to add forces. Since your FixedUpdate is not protected virtual I cannot add this through an extension of your steering rig.

 

ah, thanks for the discount...

dev, thank you for your hard work.

uh hey, is there any integration planned with the following:

https://assetstore.unity.com/packages/tools/ai/a-pathfinding-project-pro-87744

https://assetstore.unity.com/packages/tools/game-toolkits/ability-combat-toolkit-155168

https://assetstore.unity.com/packages/3d/characters/animals/horse-animset-pro-riding-system-79902

?

from what I gather, i just take any system, calculate paths, and then the sensors will enable further raycast logics utilizing a flagging switch case layer tag system (AND/OR NOT)

Do you have a recommended character controller system to use off the asset store with your asset? I'm trying to recoup loss on buying upgraded version right away by making a small project for quick resale.

Is it best to make use of your system to reroll out my own custom character controllers?

Just use hit detection to launch functions for entity component manipulation?

seems like i'll be extended your API a lot to make full use, any tutorials for this, best practice to extend classes or integrate my own controller?

thanks again for your hard work 10/10!

 

SensorToolkit is focused on detecting things but doesn't implement any specific AI logic to react to those detections. The AI logic is something you must provide yourself. The idea is that you can drop some sensors on your gameobjects, configure them, and then integrate them easily with your existing AI components with either C# or visual scripting tool. The design goal of SensorToolkit is to provide building blocks that help you build your own AI solution.

I have plans to make integrations with visual scripting packages such as Bolt, Behaviour Designer, Adventure Creator and so on..
I don't have plans to integrate with the packages you mention. But it should be simple for you to integrate it yourself, and that will also give you the flexibility to integrate it to match exactly the requirements for your game.

To extend the system I recommend writing scripts that reference the sensors instead of changing the sensor code directly. Although the source is provided if you do want to do that.
I have a couple of videos demonstrating how to use the sensors in scripts like this one:

You don't need to reroll your character controller. The sensors are designed to have minimal impact with the other components in your game. You can use sensors for some aspects of your game, and you can use your existing code in others.

 

Hi! Congratulations on making Sensor Toolkit 2. The arc sensor looks interesting for jumps and grenades etc. Do you plan to offer any sort of loyalty discounts to existing customers of Sensor Toolkit 1?

 

Thanks! There is a discount if you own v1. You'll only need to pay the difference.

 

This asset is really useful and well designed. But, I'm spending more time trying to figure out how things work than on actually using it. The short videos were very helpful, but they only cover 2 types of sensors. The written documentation is minimal, though what's there is good. It would be great to have more examples of the other sensors (and support classes, like Locomotion), either written or as short videos.

 

Sorry for the late reply. I haven't been checking this forum too often. There's a discord server for SensorToolkit here: https://discord.gg/WXrsBdyChJ that I check regularly.

I've released an update that cleans up the builtin locomotion parameters and improves its behaviour a bit too. I've removed all the confusing parameters such as 'Spring Force' and 'Constrain Motion'. Hopefully it's now more intuitive now how it works.

I do plan to make some more videos too. There is the 'Fundamentals' scene in the /Examples folder which has a lot more practical demonstrations. If you haven't seen it yet then it's highly recommended to check out.