Search Results for 'line of sight'

[SigilKeymaster]

So make sure the Detect is setup properly:

Sensor: "Visual Sensor"
Aspect: "Player"
Form Variable: seen

Sometimes people get caught on the quotes, which usually indicates an object name (like a sensor name, or an aspect name) vs the lack of quotes which indicates a variable (and won’t have spaces).

Other than that, what you have sounds alright. If you select your AI you should be able to visually see the sensor and make sure it looks like it is in range of the player. If you have Line Of Sight on, disable it temporarily to see if that is causing the problem.

Last of all you can change your behavior tree slightly to test. Instead of the Detect node, try this:

sequencer (repeat forever)
   detect (sensor: "Visual Sensor", aspect: "Player", form variable: seen)
   expression (expression: debug("Detected Something"), returns: success)

That should print a line in teh console anytime it detects something successfully.

Hello,

I am currently using RAIN for a project, but I am having troubles using it.

My general goal is to have a “car” driving around on my Navigation Network, finding it’s goals. It should drive on the right side. As I set the waypoints of the network in the middle of the street, I thought of making a Custom Action that simply puts the object a little bit to the right. The driving should still be settled with the Standart Action “move”, because why implementing that again?

Well, I already thought of this function to position my object one meter more to the right:

Vector3 rightSide = Vector3.Normalize(new Vector3(ai.Kinematic.Forward.z, ai.Kinematic.Forward.y, -(ai.Kinematic.Forward.x)));
Vector3 newPos = ai.Kinematic.Position + rightSide;
ai.Kinematic.Position= newPos;

Put this in my Execute()

At first I executed it Parallel to the move knot, returning SUCCESS after doing the calculation once. Everytime it crosses a new waypoint it is set to the right side, but slowly moves towards the line again on its way to the next waypoint. I know why too, because the waypoint is set as a goal, I just changed it’s initial position.

If I execute it several times it’s completely crazy, because it sets itself just more and more right of course.

I rather want it to be more like it does the normal move-Action and then the object will be shown doing it moved a little more to the right. While I don’t interfere with changing the parameter used to calculate the move action.

In standart 3D programming you do this as follows:
while(doThisOverAndOver) {
___Set the object to the left;
___Do your calculation; //rotation, move, whatever
___Set the object to the right;
___Show;
}

I just cannot “embed” the move action like this.
I thought ai.Motor.ApplyMotionTransforms (); maybe does the Trick as in:

ai.Kinematic.Position= newPos; // set right
ai.Motor.ApplyMotionTransforms (); //show?
ai.Kinematic.Position= oldPos; // set back

but that’s not it. The update function of showing your transformation is somewhere I don’t know.
I am actually confused about how the Standart Actions work in General. Is there anywhere were I can see the code? Or an overview of the order and what kind of stuff the AI does. The API description aren’t really helpful and it’s hard to find tutorials.

I hope you understood my problem, it’s hard to explain.
Thank’s in advance

• This topic was modified 5 months, 2 weeks ago by  blustrawberri.

[primeKeymaster]

The BigBattle soldiers purposefully had their line of sight sensors turned off. It causes problems in a big skirmish scene like that one. You should generally use the defender soldier prefabs used in the Patrol level.

[RemielParticipant]

<quote>
Which visual sensor line of sight did you modify? The defender sensors were already set that way. Did you add a new sensor or create your own? If so, did you move it up to eye level or is it still at the AI feet?</quote>

I didn’t add any new sensors. I am talking about prefabs from SquadCommand/Soldier/BigBattle . Should I use those from Standard folder instead? But there isn’t much difference in their setup, other then the standard ones having differently set up visual sensors.

[primeKeymaster]

The Column formation activation happens from code in the TakeCommand action. This is hardcoded for these scenes to that, if you want to, you can have command switch to another soldier at runtime. That soldier just runs TakeCommand and it will automatically set up his Aspect and AttackHarness. You might do that when the main commander dies.

If you aren’t using the TakeCommand action, then you can add the FormationHarness custom element to your AI manually (dropdown in the Editor from the custom elements tab on the AI) and then set which formation you want in the Current Harness field. You can also change it from code by modifying the CurrentHarness property of that custom element.

Which visual sensor line of sight did you modify? The defender sensors were already set that way. Did you add a new sensor or create your own? If so, did you move it up to eye level or is it still at the AI feet?

[RemielParticipant]

Thanks for answering.

The commander has “defcommander” aspect on him from the start, it exists on him at edit time. However, the solders’ “myCommander” variable stays empty. It never ends up pointing to the commander.
For some reason they never find their commander. Why would that happen? Their TeamElement is set up exactly the same.
I repeat, I am using your own prefabs. The only thing I modified is activating Visual Sensor line of sight.

When the scene runs, the commander activates one of the formation harnesses attached to himself.

Which one? How do I specify which one?
Currently it keeps activating Column harness every time.

[SigilKeymaster]

@MikeHunt Just noticed you figured it out, going to leave this up in case someone else comes by and needs it. I had forgotten about max path length altogether, so I will remember that for next time.

Here’s a quick rundown of the expected behavior of pathfinding:

With Allow Off Graph Pathfinding unchecked and Max Path Length set to 0:
If the AI is not on a NavMesh, and his destination is not on a NavMesh, he won’t create a path.
If the AI is not on a NavMesh, but his destination is, he will create a path to it starting from the closest point to himself.
If the AI is on a NavMesh, but his destination is not, he will create a path to the closest point to the destination.
If the AI is on a NavMesh, but his destination is on a different NavMesh, he will create a path to the closest point to the destination.
If the AI is on a NavMesh, and his destination is on the same NavMesh, he will create a path to it.

@VisualTech48 You probably don’t need the Player layer in there if that is what you are detecting, unless you want to account for other players blocking your line of sight. Also, you would want to have the Aspect Mount Point set to the player root node if you want it to ignore the colliders on the player. If you had it set to his waist or head, for instance, a collider on the root node could block your line of sight.

• This reply was modified 6 months, 1 week ago by  Sigil. Reason: Edited to make sense

In a previous version of RAIN with Unity 4, I found that I had to make visual aspects have a somewhat larger radius than the body they were attached to since I had checked “Line of Sight” on the AI’s visual sensors-when I did this, aspects were almost always detected correctly. In the current version of RAIN with Unity 5, the ability to adjust aspect size is removed, and the ability to select ‘Line of Sight’ on sensors seems to be removed as well-now, the only aspects that are correctly detected are the ones whose prefabs I didn’t change since the upgrade. What could be going on here? What important changes have been made to the way that aspects/sensors work between previous versions of RAIN and the current one?
Thank you!

[SigilKeymaster]

A few things to know about Line of Sight (LOS):

• LOS won’t be checked if the aspect doesn’t pass the initial sensor check, so it has to fall within the horizontal and vertical limitations of the sensor to begin with.
• LOS doesn’t test against triggers.
• LOS doesn’t test against any colliders connected to the AI doing the check (connected to its body or child of its body, in specific).
• LOS doesn’t test against the target aspect or any colliders connected to it (connected to its mount point or child of its mount point, in specific).
• And the critical part: LOS mask defines what will block your AI’s line of sight, not what it will see.

Let me know if this is not the behavior you see.

[VisualTech48Participant]

Thanks Sigil, I also did some ground testing when I got my chance, and found out you were right. Charachter Controller motor did the trick, and it works fine now.

The issue actually towards the normal motor is that colliders don’t effect, as (what I understand for the code) as he will find his fastest path towards the target. However since the motor doesn’t do the drawing part (It calculates just the nav mesh), or to be specific to path towards the target it just goes with it, but it won’t follow the target if it goes off the Nav mesh again.

On the other hand I’m having issues currently setting up the “Line of Sight” mask, if I just add one layer it ignores my player, even if I put the player him self only or just let’s say walls, it doesn’t detect him anymore.

[NeyjayParticipant]

Ok I figured it partially out.

I added a visual detect (around 40° horizontal and 180° vertical, with line of sight checked) and entity aspects on each character (AI and player).
Then in a custom action (which runs forever) I check if there are any aspects found. If there are check if they are too near. Then do an avoidance based on the cross vector of the difference vector between both positions (I added some randomness to the direction left or right). Then I move the character with ai.motor.moveto.

This works well except that the AI now ignores the Navmesh during this movement. Trying to figure out how to get that to work now. If anyone knows anything before I can figure it out, I’d appreciate the help.

• This reply was modified 8 months, 2 weeks ago by  Neyjay.

[primeKeymaster]

When the Line of Sight checkbox is checked on a RAIN Sensor, it will use raycasting and would normally not be able to see through walls. Each sensor can define its own visibility layers for raycasting.

The buildings in the Squad Command scenes are marked Ignore Raycast because they have mesh colliders and we didn’t want to allow those into the raycasting (for performance reasons.) However, the buildings all have a separate cube collider that is in the Default layer which does work with raycasting. The buildings should not be see through.

When finding a cover position, the AI uses a cost function to determine the best cover point. By default a simple cost function is used that tries to balance distance from the AI vs distance to the enemy.

//Our cost function gives 50% more weight to points near the enemy
            //But then also adds in the AI distance to the point
            float tCost = 1.5f * Vector3.Distance(tEnemyPosition, tCandidateAspect.Position) + Vector3.Distance(ai.Kinematic.Position, tCandidateAspect.Position);
            if (tCost < bestCost)
            {
                _currentCoverPoint = tObjective;
                tCoverPosition = tCandidateAspect.Position;
                bestCost = tCost;
            }

You can modify this cost function as you like to change how the AI chooses cover positions. For example, you could give a lower cost to cover positions that are in direct line of sight of the enemy, or even more simply add a minimum distance from the enemy so that you choose points that are close, but not too close.

[primeKeymaster]

So here’s the potential issue with vertical angles less than 180. The sensor ends up detecting only within that angle, and when you get close to the sensor it is easy for the detected aspect to be too high or to low.

For example, in the test scene from @incrediclint the sensor is mounted at the center of the AI capsule. If you reduce the “Eyes” sensor to a 50 degree vertical angle, you can see the angle lines coming out of the capsule and heading toward the ground. There is a gap between the leading edge of the sensor and the AI body, and that gap increases as the sensor angle gets smaller. In other words, the AI can’t see things on the ground that are very close to its own body.

Then if you look at the Aspect attached to the player capsule, you will see that it is at the player’s feet (on the ground). When the AI moves close enough to the player, the Aspect gets into that “can’t see, too close” range. The AI is no longer able to see the player so it begins to wander away. Once it wanders for a frame or two, it gets far enough away that it can see the player again. It heads back toward the player, gets too close, and loses sight again. This repeats forever and looks like horrible jitter.

The solution is to add a second sensor that covers just the close range of the AI not covered by the first sensor. You just want something that manages the gap near the feet. In @incrediclint‘s project there is a second sensor called “Close” that looks like it is meant for this purpose. It might work better if that sensor was named the same as the first (“Eyes”), which would allow the sensor system to treat them together as the same sensor in most cases. Also, make sure the smaller inner sensor overlaps the first sensor by a small amount. I tested in the project with values of 50 degree vertical angle and an inner sensor with range of 2.6 - everything worked great.

Hope that all makes sense.

[incrediclintParticipant]

Same exact problem for me. I worked around it by setting the vertical angle to 180, anything higher then 180 in the vertical ends up as a full circle… so vertical doesn’t seem to have the same range as horizontal. The lower I go from 180 the worse the problem gets. For the setup I have the horizontal angle set to 360, vertical angle was 60, line of sight turned off.

Approaching the AI from angled positions from the rear results in the AI turning toward the player but only until there is a 90 degree difference (so the AI is then facing 90 degrees to the left or right of the player. It then continually hops between trying to turn back to head off to the waypoint or turning to move to the player. I too could see it continually losing the player and then reacquiring it.

The setup is the same as in the Getting Started with Rain tutorial except for the changes noted above. I downloaded the “RainStarter” package from the tutorials and tried to reproduce the problem in that but couldn’t… but it’s running on version 2.0 of rain.

[primeKeymaster]

If the aspect you are detecting is inside of a collider you may not be able to detect it when using line of sight (which does collider based raycasting.)

For example, if I’m using a capsule collider or character controller on my player and I tag it with an Entity/Aspect, chances are the new Aspect will be located inside the collider. You would need to move it above the collider or out in front to be detectable by a line of sight sensor.

• This reply was modified 9 months ago by  prime.