Navigation Mesh: Walking Radius problem

[primeKeymaster]

In PLAYER NOT VISIBLE I don’t understand what the Constraints are for. Do you expect those nodes to repeat?

[primeKeymaster]

Generally I haven’t been able to reproduce the problem yet. I think it may be the result of a few things that can be fixed pretty quickly:

1) When the Alien moves to the player, set a close enough distance in your Move node. If you don’t it will use the default Motor close enough, which is 0.1, and the Alien will continuously slam into the player because it can never get close enough. I used 1.0

2) Looks like there may be a couple of logical errors. Plus, when using an Evaluate node, if your Evaluate is doing an assignment (e.g., x = 5) then you usually want to set the return value to SUCCESS. If your Evaluate is doing a comparison (e.g., x == 5) then you usually want to set the return value to Evaluate.

3) You can probably get away with fewer sensors. I can probably make some recommendations after I understand the logic better.

[bookParticipant]

Thank you so much again!

I understand my logic could use a bit of work. But I’ll list out the current states of my alien anyway and let you know what they are doing (or in some cases meant to be doing!).

I wasn’t really sure how to set it up perfectly with Mecanim so I just have a variable that is set to each animation state and I change that variable in the behaviour tree. It seems to work okay.

Alien States
———————

PLAYER NOT VISIBLE
This is activated when the player is NOT in the alien’s EYES sensor.

HEARD OTHER NOISE
This state is used for when the Alien hears an item being thrown by the player. He is supposed to walk over to that item and look around. When the player throws an item, when that item hits the ground; if it is in the Alien’s EARS sensor, the alien will switch to SEARCHING OTHER NOISE state. This state is mentioned below.

The throwable item is a bottle in this scene and it’s called “P3_Throwable_item”.

HEARD PLAYER NOISE STATE
This state is used for when the Alien hears the player. I don’t think I ever got it working properly but it’s not a priority feature.

WANDER STATE
This is just the alien following the waypoints.

SEARCHING STATE
The alien goes to this state after the CHASING STATE (mentioned below) when the player is no longer viewable to the EYES sensor but is still viewable in the “Far Away” sensor. The Far Away sensor does not use line of sight. So the Alien will still move towards the player for a set period of time if the player is still in this sensor. So it isn’t a proper searching state. I didn’t really know how to get the alien to look around the last place the player had been.

ONALERTSTATE
The On alert state comes after the searching state. It’s just an animation of the alien looking around before going back to the WANDER state.
This state is also activated after the SEARCHING OTHER NOISE state when the alien hears a noise and goes to investigate where it happened.

SEARCHING OTHER NOISE
This state is activated after the HEARD NOISE state. The alien goes to investigate what noise it heard and will eventually go to the ONALERTSTATE after a given time.

IDLE STATE
The alien randomly goes into this state while in the WANDER STATE. This is just to give him a bit more realism.

PLAYER VISIBLE
If the player is in the alien’s EYES sensor this state gets activated.

CHASING STATE
If the player is only in the EYES sensor but not in the CLOSE sensor. The alien will keep moving towards the player until the player is in the close sensor(in that case alien switches to ATTACKING STATE) or the player escapes the EYES sensor (Note if the player escapes the EYES sensor but is still in the FAR sensor the alien will go to SEARCHING STATE.

ATTACKING STATE
If the player is in the alien’s CLOSE sensor the alien swipes at the player. I just put a distance variable in one of the alien scripts (KillPlayer script) that makes the player die if he is too close.

• This reply was modified 3 months, 4 weeks ago by  book.
• This reply was modified 3 months, 4 weeks ago by  book.

[bookParticipant]

Hi, did you notice any other logical errors in my AI?

[primeKeymaster]

Sorry - haven’t had a chance to dig in yet. I’ll try to dig into it later this afternoon. Thanks for the reminder.

[primeKeymaster]

Let’s just look at one node.

CONSTRAINT HEARD OTHER NOISE varNoise != null
— SEQUENCER
— — Expression isSearchingOther = true returns Evaluate
— — Expression varNoise == null returns Evaluate

In HEARD OTHER NOISE you have a constraint varNoise != null.
- That’s fine. Certainly the constraint will only run if varNoise has a value, meaning a noise has been heard.
- However, the purpose of a constraint node is to deal with child actions that may run for some time and may need to be interrupted if the top level constraint is ever violated. In your case, it looks like you are just using it as an IF condition for the nodes that go underneath (i.e., an entry condition, not an ongoing constraint).
- Because of that, you would probably be better off with a Sequencer where the first node in the sequencer is an expression that evaluates varNoise != null. The sequencer would fail on that evaluation if a noise isn’t heard, but then run the rest of the behavior if a noise is heard. I think that’s what you want.

Your next node is a Sequencer. Inside of it are two expression nodes.
- The first expression evaluates isSearchingOther = true. The return value is “Evaluate”. In this case you are setting the value of a variable, not evaluating the expression. Your return value should be SUCCESS.
- The second expression is varNoise == null. The return value is “Evaluate”, which is fine because you are actually testing the value of varNoise. However, this node will always fail. The top level constraint already tests that varNoise != null, so we already know the value isn’t null.

That’s all of the logic for the HEARD OTHER NOISE. Is the point of this node simply to set isSearchingOther = true? If so, the logic should look more like (note that the quotes are just for readability. You don’t want them in your expression.)
SELECTOR
— SEQUENCER
— — Expression “varNoise != null” returns Evaluate
— — Expression “isSearchingOther = true” returns Success
— Expression “true” returns Success

This selector will first run the sequencer. The sequencer will test varnoise != null. If that fails, the sequencer fails and the selector moves on to the second expression, which will always return true. We’re doing that because we don’t actually want the selector to fail. If varnoise != null succeeds, then we set isSearchingOther = true.

[Author]

Posts