TargetPRO [By Path-o-logical Games]

I won't post anything without taking the time to do a full and proper update, testing, etc, at which point a release is not that big of a deal. At this point, without looking at it more closely, I'm not sure how much work it will take to replace the old Editor formatting calls with the new ones. It may be a simple replacement or it may need some refactoring.

Unless a code defect is found in 4.3, which would bump the update priority up, we plan on doing the 4.3 update before the end of February (though I do hope to do it sooner).

 

We just released an update to support Unity 4.3. See the release notes here:
http://forums.support.path-o-logical.com/viewtopic.php?f=13&t=1243

Also, please tell your friends and colleagues our Pool, Target, Constrain Bundle is being featured in the Unity Madness Sale right now!!! (https://www.assetstore.unity3d.com/#/content/3769)

Or get the same discount at our store using this 50% off coupon: CPN51670212185

To use it, go to http://packages.path-o-logical.com and click on the Bundle "Get It Now" link. Enter the quantity you wish to purchase and the coupon and click "Update Cart" to verify you are receiving the discount.

 

The new version is now available in the AssetStore.

 

I consider purchasing TargetPRO, but reading the Docs I'm thinking that the system might be hard to combine with my current weapon/AI setup ... I guess my problem is that in my game I don't have dedicated GameObjects for my weapons or projectile launchers. Projectiles just come out of the spaceship and the AI cycles through a List of Weapon classes to determine what to fire.

Question ... Can I have multiple FireController scrips on the same GameObject? That might help me.

Or do I have to re-structure my code in such a way that when a space ship is spawned, GameObjects are parented to the ship according to it's weapon loadout, for example 2 GameObjects for two guns and 1 GameObject for one turret?

 

TargetPRO is a framework that should be able to plug in to any project. The power is really in the TargetTracker caching and the API. FireControllers, for example, are just one way to automate the usage of targets detected by a TargetTracker. You could create custom components or use the API in existing components quite easily.

I'm honestly not sure how things would function with multiple components of the same type on the same GameObject. It would be confusing to work with in general with the Unity API. For example, what would GetComponent<FireControler>() return?

I think having GameObjects for each "gun" would be a better approach and trivial to setup. You could use a List<FireController> on your main ship parent, for example, and drag and drop them, or find and cache them in Awake(). From a code perspective it shouldn't be all that different from having them on one GameObject except it would be more clear what is doing what, plus you would be able to position them in different places if you end up wanting projectiles to come from specific locations on the ship.

If you have any further questions about setup specifics please post to our forums at http://support.path-o-logical.com/forums

 

hi Rafes.
I use TargetPro with 2D Platform Controller and was getting errors.
you cann't help me?

 

Hi,

My guess is your project has a class "Projectile" which is not namespaces. TargetPRO IS namespaced to help with collisions like this though. The problem here is the example file has 'using Pathological;' at the top, which basically brings everything from that namespace in to the script, just like 'using UnityEngine;' does. While this makes it much easier to work with in most situations, to really use the namespace to protect, put the whole DemoSeeker class inside the Pathological namespace. For example (in pseudo code), Change this:

Code (csharp):

1.  
2. using UnityEngine;
3. using Pathological;
4.  
5. /// <docs>
6. [Requires]
7. public class DemoSeeker: MonoBehavior
8. {
9.     // <Code>
10. }
11.  

...to this, so that the entire class is literally inside the namespace:

Code (csharp):

1.  
2. using UnityEngine;
3.  
4. namespace Pathological
5. {
6. /// <docs>
7. [Requires]
8. public class DemoSeeker: MonoBehavior
9. {
10.     // <Code>
11. }
12. }
13.  

Please post to our forums at http://support.path-o-logical.com/forums for further support on this issue.

I'll update the demo script to be inside the namespace for the next release.

 

Hi,

coming back to this ... Any notes on performance? If I had 30 space ships in my scene with 60 FireControllers, Projectiles flying around etc. Can TargetPro cope with that?

Would you use TargetPRO for basic projectile->spaceship hit detection (trigger->collider), too? Or is it more for target tracking? I wonder if I should put the target component script on my projectiles, too?

Does TargetPRO provide a line-of-sight function? I see there's a is-in-front-of function. Is there a function that checks if the line of fire between two objects is unobstructed? That might be useful for me.

 

Hi,

Yes.

Performance: It should be fine, especially if you team TargetPRO up with PoolManager for the projectiles, effects, etc. The only overhead is when TargetPRO detects a new target and caches everything. After that it is super fast. A few hundred objects really shouldn't be an issue at all, especially since they won't all be detected on the exact same frame at the same time. It will be distributed naturally simply because of the nature of things moving in and out of range.

Hit (Collision) Detection: We recently added this ability to use colliders instead of triggers: http://docs.targetpro.path-o-logical.com/home/collisiontargettracker . It was trickey to make sure it always delivered the events correctly too, so this is definitely a timesaver. There is a simple example scene that shows spheres exploding as they hit a cube.

Line-of-sight (LOS): http://docs.targetpro.path-o-logical.com/home/los ...and there are example scenes for this too. It can work on 2 levels. It can be used for detection, so everything down-stream has no idea a target is in range unless it can be "seen", or it can be used to ignore a target which was "detected". In other words, you can have a gun that only turns toward an object when it is visible, or you can have a gun that always follows an object but won't fire unless the object it visibile. The component makes it easy. It is a "Modifier" that you drop on the same gameObject as a TargetTracker or FireController and it hooks in to events (which you have access to as well, by the way) to filter the targets lists and remove things that aren't in LOS.

That "is-in-front" option you mention is a feature of the FireController. It doesn't factor in obstructions, it just refuses to fire if the object isn't in front of it. It can be used to ensure a turret or trap doesn't trigger until something passes in front of it. You can add the LOS component and get both working together.

 

Yeah, on the topic of range. I am still trying to figure out if TargetPRO fits my project.

The space ships in my game have several weapons, some of them with a potentially very large range (like long range rockets), some of them with a rather short range (like turrets). I understand that each TargetTracker needs a range setting that sets the bounding volume.

In a space game you usually would use some per-ship sensor range for that, but in my game that doesn't exist, all ships pretty much have an infinite activation radius. So, let's take a per-weapon, per-GameObject projectile range value to set the radius, right? But in this case, the range setting for some TargetTrackers will be very large, i.e. for long range rockets.

Depending on the character of the projectile, sometimes a very large sphere-shaped collision geometry might fit best, sometimes a more FOV-like cone might fit. Can TargetPRO work with very large activation radiuses? Is the per-weapon or per-ship activation radius the right metaphor to use?

 

Yes, think of the TargetTrackers as sensors. You can put one on each weapon and use the events to trigger any code you want. You could have a single "Ship" class that registers methods with each weapon's TargetTracker (or FireController) and have all the logic in one place; a brian-limb paradigm. Or put a "Weapon" script on each weapon and let it manage itself (I generally prefer to do this second one and only involve the "Ship" for higher-level logic).

I expect you will also want to know that you can configure a FireController so it only fires when you trigger it, for use with user input.

TargetPRO doesn't have a cone-shaped trigger because Unity doesn't have one. However, you can use a sphere and then add a custom "Modifier" class (it's like a filter) that does a quick test to see if a target is within a certain angle of the ship, and if not, drop it from the Target list. The Line-if-Sight (LOS) component that comes with TargetPRO is a perfect example. You could duplicate the script, delete a few things, add the angle check and you'd have your custom Modifier.

This is why having a framework like TargetPRO is so valuable. It isn't just a fixed set of components, it offers a quicker way to create behaviors without worrying about the back-end.

 

Well my concern is that the activation geometry will often be very large and many of them will overlap during gameplay - isn't that a problem?

What about existing collision geometry? I understand that TargetPRO uses it's own layers - but does it only use it's own exclusive layers?

 

There is no geometry. Only physics triggers.

Regarding layers. TargetPRO doesn't use any specific layers. You can setup layers anyway you want and control them in two ways: The collision matrix in your project can make layers completely ignore other layers which is the best way to tailor for performance since TargetPRO will not even be hit. Then you can choose which layers each component of TargetPRO uses individually (just like you do with cameras). Even then it is a very light test against the Target's layer and if the layer isn't one that should be handled, nothing else is done.

 

OK, but I still don't understand. I am reading the docs, but I don't see how TargetPRO integrates into an existing infrastructure.

From TargetPRO -> Projectile -> Detonation Mode:

The spaceships in my game already have collision geometry. Right now I am using (x) isTrigger on my projectiles, the spaceships use OnTriggerEnter. The projectiles are on the IgnoreRaycast layer, the ships on their Ships layer. I use the collision matrix to only allow Projectile->Ship, but nothing else. Does that mean that the existing per-model collision geometry setups becomes redundant, replaced by TargetPRO?

Let's say I have a rocket that either does damage on direct hit, or, when the life time ends, impacts and damages targets in a certain radius? Now what? I will keep the traditional Unity collison sphere on the rocket, but also use TargetPRO?

Under "Effect On Targets" it shows effects like "Damage" and "Slow". Only reading the docs one would think that these are classes or structs, but from the code snippet in the video on YouTube it becomes clear that these are generic strings, that have to be case/switched by the target event handlers. Isn't that worse than having polymorphic classes?

I see that the Projectile class is abstract and generic. Still, I am sceptical that you can account for every possible game design. In a game, there might be simple projectiles, hit-scan weapons, damage waves, lightning gun types, mines ... Who tells me that one day I won't run into TargetPROs limitations when I design certain weapon types?

 

There is no trick to it. You might be looking for complexity that isn't there. At a minimum, you import TargetPRO in to your game project, drop on a couple of components, set layers as needed, and use the events to trigger code. The depth at which you use the framework is really case-by-case. You can get quite creative and still only worry about the game logic code you want to trigger when stuff happens.

TargetPRO doesn't necessarily replace anything. I don't have your game project, but you should be able to use existing stuff or create new stuff. For example, for ship detection you may only need a little sphere trigger on its own layer. It all depends. It isn't complex though. It is up to you how you setup layers and colliders.

Regarding geometry colliders: in Unity, these can't be triggers, but we do have a collider CollisionTargetTracker you could use, but there is no reason to do so unless your object needs to physically collide (e.g. something has to bounce of something else.) It is very likily that you don't need geometry colliders for a space game unless you are getting very very close to the space ship. Otherwise, just use a sphere shaped trigger (cheapest in performance) or a cube (second-cheapest).

No problem. TargetPRO can handle this easily (I've done this before). You can just have the projectile spawn a detonator when it dies, which explodes immediatly. The projectile can have a small radius and the detonator can have a huge one. As soon as the detonator spawns, it will detect and notify everything in range (or even let it grow over-time, simulating a huge explosion.)

No it works well in practice. We spent a lot of time (way too much) trying more clever ways of allowing users to define hit effects. In the end this is an extremely flexible system. You can name an effect anything and then use it. The HitEffect (which is a struct when used at run-time by the way) parameters can really define anything you might need. We haven't found something it can't define.

Remember, TargetPRO is NOT a weapon designer. It is a very modular framework that efficiently triggers events. So far I haven't found anything I could setup:
- regular guns that don't fire anything visible (direct notification)
- missile launchers that fire projectiles (delegated notification)
- area-effects and 3-target lightening (multiple direct notification)
- simple object pickups (direct notification with self-despawn event)
- expanding explosions (really just expanding the perimeter over time and never notifying a target twice)
- damage over-time (fire rapid pulses or a single pulse with an effect that has a duration).
- a bomb (just a projectile for instant notification or a detonator to notify and grow over time)

...note these are all quite simple behaviors once you have an event framework. You can define just about anything in logical terms ("When this is detected, and this is true, tell it to do this, and then do this"). I would be interested to hear something it can't do.


....and then there are combinations you could put together without any code:
- drop a nuclear bomb from a plane (no TargetTracker, use a projectile that spawns a detonator)
- a trip-wire trap (set a FireController to only hit things in front of it, and don't let it turn)


Again, TargetPRO is a framework (it has an API). You can drop a TargetTracker on something and use the targets list for anything you want. It also has hooks to add Modifiers (filters) to add custom behaviors, like we did for Line-of-Sight without sub-classing or hacking. If you wanted to dig in to the FireController, Projectile and Detonator, you would find these are just combinations or variations of behaviors implemented using the API events....just automation.

 

Well you never really answered my question about very large Perimeters overlapping each other ... But I just purchased it. I'm throwing away a lot of my own code (not that it was good code, but it worked). Let's just pray it works.

 

Oh, I was fixated on the geometry side of hat question. I can't see any reason why the size of a trigger would matter but that is up to Unity's core. I haven't encountered or heard of any issues.

That's great! If you need anything, please post to the forums at http://support.path-o-logical.com/forums and note in the upper right there is a custom search feature that includes both the forums and the docs!

For mobile users or direct linking, the direct forums URL is http://forums.support.path-o-logical.com

 

1)
It seems a FireController requires a TargetTracker on the same GameObject. In my game, there's only one TargetTracker managing multiple FireControllers (on several child GameObjects). I thought this is possible?

2)
Uhm, testing TargetPRO a little I noticed that I can use some UnityConstraints, but not all of them. For example, the Transform and Transform (Smooth) constraints are missing. I thought buying TargetPRO I'd get the full package?

3)
In my game there's no real you/them distinction. There's only equal ships with their TargetTrackers. That's why the targets list in my setup always contains the tracking ship itself. Is there any better way to get rid of this than:

Code (csharp):

1.  
2. void OnPostSort ( TargetList targets ) {
3.  
4.  
5.         targets.Remove ( targets[0] );
6.     }

4)
It seems the Line-of-Sight component is not that valuable to me. It depends on a certain setup, where "natural" obstacles are on their own layer. But in a space game, my game anyway, the only "natural" obstacles are maybe asteroids, which could be put on their own layer. But, the ships are all on the same layer, so when I set the Line-of-Sight component -> TargetTracker Mask to: nothing and the -> Fire Controller Mask to: (My ship layer) ... then the Fire Controller does always fire. My guess is, that the Line-of-Sight is never broken, either because the line always hits it's own host (see 3)) or nothing. Am I doing something wrong?

 

TargetTrackers are the core. You usually want one for each gameObject that should detect and respond to things. However, I like the idea of multiple FireControllers being able to use a single TargetTracker. I'd like to modify the TargetTracker component to have a drag-and-drop field for a TargetTracker (maybe even a list of them). I can keep this backwards compatible by making the FireController look for a TargetTracker on the same GameObject if the field is empty in Awake() (I can also make the inspector auto-fill it so when the component is added it will set the field, which means less code to run when the game starts.)

Unity Constraints is sold seperately or as part of the bundle (http://packages.path-o-logical.com). We included a couple of constraints with TargetPRO because they are really useful and part of the example scene files.

That is interesting. I guess if your ship is both a TargetTracker AND Targetable on the same Layer as "outside" Targetables, then I think you are right. The only way to handle it is to remove itself from the Targets list. I think we can add this as a new modifier component, "IgnoreTargets", which you can drop on to a TargetTracker GameObject and then drop other Transforms on to it to do what you are doing: remove them from the Target list if they are there. This is a pretty rare case so I like the idea of a Modifier, instead of adding more to the TargetTracker itself.

Line-of-sight IS, literally, a test to see if something is obstructed or not. It sounds like you just want to know if something is directly in front of the ship? I'm confused by what you are expecting.


I'll create tickets for the TargetTracker reference on the FireController and the IgnoreTargets modifier component. Thanks for posting. This is how our packages get better1

 

Yeah I like the idea too In my game, I could have 30 space ships in a scene with 6 weapon GameObjects each, so that's 180 FireControllers and TargetTrackers, which are largely redundant.
You mean a drag-and-drop field for TargetTrackers on FireControllers, right? Well, I can't really give advice on how to implement this. I guess a FireController variant is needed that is less "pro-active". If I had giant space ships in my game, where it made sense that
the rear turret of a ship fires on a different target than a front turret, then maybe. But I don't have that.
Instead, both the player and NPC ships pick a target and then fire everything on it.

Well let's leave it at that.

Sounds good. Might not even need a public setting, since the default is *self* anyway. Why is that even an edge case? As soon as you need AI with a bit of sophistication they all need TargetTrackers. If I was cynical I'd say that most users of Unity or TargetPRO use it only for Tower Defense games ...

Right. It depends. I need to know if the first target, that the weapon is pointing at, is actually the target the AI wants.
_ In the case of a fixed gun that an object in front of it.
_ In case of a swivel, semi-mounted gun, that might be a 45 or 90 degree FOV
_ In case of a turret that's similar to the gun, but the turret of course keeps tracl of the target.

Slowly, slowly. Let's first see if I am working against the TargetPRO API, instead of with it.

 

So you just want multiple things to know when your ship fires right? You can do that now; just keep the single TargetTracker and FireController on a gameObject together, set the FireController "Notify Targets" to "Off" (http://docs.targetpro.path-o-logical.com/home/fire-controller) and use the OnFire event directly.

You don't need to use the FireController for the HiteEffects list (Projectiles can ignore them, as an example). You can make a script that lets you define a HitEffect on each "gun" and use that instead. We could even create a simple component that just has the HitEffects list and custom inspector and is "dumb", as in it does nothing. It just exists to be referenced and read.

Again, TargetPRO is a framework and FireControllers are just one way to automate its use. You can use all the pieces directly.

Still, based on your other questions, it sounds like each gun should have its own fireController to decide if it should fire or not on a case-by-case basis, with different weapon parameters and effects.

This would assume the Targetable and the TargetTracker are on the same GameObject, which may not be the case. We generally keep them separate to make setups more modular/flexible.

- Fixed: The FireController has this built in as "Wait for Alignment"
- FOV / Cone: I would add a Modifier to test the angle and if greater than a threshold, remove the target from the list. This was recently discussed on the forums.
- Turret: Same as "fixed" but it rotates...right?

 

+1

 

Hm, how would I go from there? Just so I understand.
I have my parent GameObject, one child is the model and many children are weapons. The weapons all hold TargetTrackers (not because I needed them but because TargetPRO requires one, see above) and FireControllers. A script in the parent would then subscribe to several OnFire delegates in it's children. Then what?

Yeah, I already saw that I can set HitEffects on Projectiles, too. I guess setting the HitEffects on the Projectiles if for guns with slow projectiles or rocket launchers? And HitEffects on the Weapon/FireController is for no-projectile insta-hit weapons, right?

Well I guess that I need differentiation. My actual setup is far more complicated than I explained until now. And I won't go into the details.

But you are right, I maybe need a FireController per weapon, simply because the weapons per ship have different data each: cooldowns, ammo prefabs, tracking behavior (gun/swivel/turret).

It's very possible that I will only use the TargetTracker and the Projectile component - and I will fill up the middle myself. Unless you want to modify TargetPRO.

Right, in my tests I had them separate too. There's a parent GameObject will all the scripts on it and the model of the ship with the collision primitive holds the Targetable.

Right. The gun is 0 degrees movement, the swivel gun x degrees, the turret 360 degrees.

 

Whatever you want. This was just an example. My point is you can subscribe to any event on any component from any other component on any GameObject. I was actually thinking about it the other way around though. At risk of repeating what I typed: A single TargetTracker and FireController and lots of gun components that subscribe to the same FireController to take some action when the ship fires. Again though, I think, based on your other posts, that you want a FireController per gun and a single TargetTracker for them all, which would mean a little change in TargetPRO to allow FireControllers to reference a TargetTracker rather than requiring them to be on the same GameObject. You could do this now if you wanted to hack the components. I think you could get away with removing the [requires(...)] line from the FireController, subclass it and add a public TargetTracker field and override Awake to use this reference instead. Regardless I think this is a cool thing to allow, so I'll keep the ticket to add this to TargetPRO officially.

You missunderstand me. What I mean is, you don't have to use any components at all. You can literally create the struct in code as you want it and use that instead. Or make a simple script with the parameters needed by a HitEffect and at run-time use that to create a HitEffects list. My point is the components are just automation for the API. You can do whatever they do. The depth of TargetPRO is in the backend to the components, but the components themselves are just modular scripts that use the back-end and subscribe to each others events.

This is only an interesting line of thinking if you wanted to share a FireController but, like Projectiles, define the hit effects locally to each event-user. With a FireController on each gun, I think you already have all you need.

Hopefully I addressed this above. I think what you are after is pretty simple once you see the pattern. It sounds like a single TargetTracker with a FireController per gun will solve all your design dilemmas. With this setup, you could even make the guns their own prefabs and use anchor points on the ships to mix and match the weaponry....if your game calls for it.

Don't confuse TargetPRO's tracking with the rotation behavior of your gun. These sound like rotation constraints, but the guns still fire at what's in front of them? If so, they all use "Wait for Alignment". If, however, you have a gun that emits from a point and can hit anything in a cone area without necessarily rotating itseld to directly face that direction, then you'd want to filer the targets for the "cone".

 

Hi,
Is TargetPro compatible with Windows 8 and WP8 build targets?

 

As far as we know it is. We do have Windows8 users. If you have any trouble let us know and we'll sort it out.

 

hi Rafes
you cann't help me add "Sorting Style" by name?
Thank you.

Code (csharp):

1. case SORTING_STYLES.Name:
2.                     return targetB.targetable.name.CompareTo(
3.                                                              targetA.targetable.name);

 

I wouldn't recommend using strings at such a low level. It might really hurt performance. I've honestly never looked in to alpha-sorting. You might dig in to the IComparable interface and list sorting in general to find some clues. Maybe start on StackOverflow.com. The site is awesome. e.g. http://stackoverflow.com/questions/5721889/is-there-a-list-that-is-sorted-automatically-in-net

I would look for an alternative if possible. Like using the Targetable.strength value for sorting:
http://docs.targetpro.path-o-logical.com/code-reference/targetable

float strength
​

The number used to sort this Target when a TargetTracker is set to MostPowerful or LeastPowerful. This can be any arbitrary number for any use. For example, set this higher on a player-selected target to make guns attack it first. Or set this to a target's life to make the TargetTracker hit the most or least healthy target.
​

.
​

This was added so you could use it for any custom sorting you want.

 

Hi,
when I play with TargetPRO it seems the objects are only picked up by the TargetTracker if the target's SphereCollider and the Targetable script reside on the same object, right?

 

Any collider that works with triggers, Yes.

I'm not sure the motivation behind your question but here is a longer answer: For regular TargetTrackers, yes, because Unity's triggers only work with colliders on the same object. Compound colliders (colliders on children that are combined) only work with regular collision physics. We have a CollisionTargetTracker that works with collisions, but this requires actual hits since physical collisions (not triggers) bounce off things, they don't move through or stay in a collision state.

I hope this helps.

 

I am not sure if I understand.
Currently, pre TargetPRO so to speak, my setup for every space ship is:

GameObject "AIType" (components: kinematic Rigidbody) <- [parented to] <- GameObject "Model" (components: SphereCollider)

A rocket or projectile is a GameObject with a kinematic Rigidbody (checked as trigger). Now, when a projectile hits the "Model" GameObject, the "OnTriggerEnter" function on a script on the parent "AIType" GameObject is triggered.

When I put a "Targetable" script on my model a Rigidbody is automatically added. That doesn't fit my setup, since the parent "AiType" GameObject already has one. When I put the "Targetable" script on the parent "AIType" GameObject that fits the Rigidbody, but the TargetPro events aren't fired since the Collider resides on the child "Model" GameObject.

 

Unity doesn't allow you to mix triggers and physical colliders. What you are describing is a compound collider. The Rigidbody combines all children to make a single collision shape. Triggers require the collider to be on the same GameObject.

You may want to create a "sensor" to receive TargetPRO HitEffects information. Create a new child GameObject and add a collider (trigger), rigidbody (kinematic) and Targetable. Now you can use any script on any GameObject to subscribe to the OnHit event and you should be good to go (I suggest a public Targetable field so you can drag and drop the child Targetable to make it easy to access and add the event delegate.)

 

Is it possible to make TargetPro use 2D colliders and rigidbodies?

 

It will be in the next version. We are about 80% done and the core is already working. If you'd like to purchase TargetPRO and email support@path-o-logical.com with your order number we can deliver a beta version to you as soon as it is available.

This will be in TargetPRO 6x

 

Great! Looking forward to it.

 

If there was a Hemisphere Target Perimeter, I would buy right now!

Spoiler: example

 

We are renaming TargetPRO to TriggerEventPRO in version 6 and it really pushes the "modifier" pattern which lets you modify the target list based on events. This means a script can be added on top of an EventFireController to do things like limit distance. This is perfect for modifying the behavior for specific game needs without the need to touch or subclass the main components.

 

Unfortunately, I'm not a programmer, and I find it difficult to understand what is at stake, you can answer simply, I need a perimeter detection targets (circled column orange color in my example), and the purpose behind the player's ship (Enemy 3) is not should be detected, it is possible without any additional programming?

 

Without coding I would recomend using a box collider instead. There is no way in unity to chop a sphere collider.
With programming you could easily ignore targets that are below 0 along a specific axis. There are probably several valid approaches.

 

But Unity has a Mesh Collider and this could be a hemisphere ..
The tunnels in my game has an annular shape (and may even be in the form of eight etc), while the player ship has certain angles of rotation, so that the definition of the axes is very problematic .. World coordinates do not fit as well as local - how count the local distance? In general the ideal solution would be to have a hemispherical Mesh Collider for the perimeter! It is a pity it is not there..

 

Mesh Collider math is going to be a good deal more expensive. Within the TargetPro system you could use the sphere collider and then check the relative angle to the target's aiming/orientation angle.

Code (CSharp):

1. Vector3 directionToTarget = transform.position - enemy.position;
2. float angle = Vector3.Angle(transform.forward, directionToTarget);
3. if (Mathf.Abs(angle) > 90)
4.     Debug.Log("target is behind me");

source

 

Indeed, the solution is quite simple!
But now I test another plugin for target,in him perfectly implemented setting angles searching for targets, but I have not tested the performance on mobile devices ... If there will be problems with it, I'll definitely try TargetPro + your advice!
Thanks a lot!

 

TriggerEventPRO (TargetPRO 6.0, renamed) Has been submitted to the AssetStore!!

This is a MAJOR version. PLEASE READ THE UPGRADE DOCS BEFORE INSTALLING!

See triggerEventPro.path-o-logical.com for more information and the new docs.

Videos and some final doc clean-up are in progress.

If you purchased the "Pool, Target, Constrain Bundle", it is now called "Pool, Trigger, Constrain Bundle" and has also been submitted to the AssetStore and includes the latest PoolManager and UnityConstraints packages as well.

See all release notes at support.path-o-logical.com/forums