This topic contains 6 replies, has 2 voices, and was last updated by 
Sigil 5 months, 2 weeks ago.
-
Posts
-
First I want to congratulate, and thank, the developers for such a great product. I love what you are doing with Squad and Sentio and that you are keeping RAIN free. You guys rocks.
My problem:
I’m working on a game in my free time, and I opted to use RAIN because I needed a tool able to make Navigation Meshes at runtime (maps are generated procedurally). I then made my player controlled character use an AI rig to move, by getting its move variable from a raycast hit.
The complications started when I decided to use a Sensor to detect obstacles (ie. a door equipped with an Entity component). The idea is to make the character stop before a door/obstacle, that’s been put dynamically on the NavMesh, and not keep running on its collider. The NavMesh generation filtrates the layer containing the doors, so that once the door collider is removed (ie. the door opened) the character is able to walk in the next room.I thought the BT like this:
*root [parallel]
-detect (on repeat forever) with player’s sensor and door’s aspect
-selector (on repeat forever)
—-constraint on door variable (== null)
——move to raycast hit point
—-constraint on door variable (!= null)
——-move to character to the player gameobject position (aka stop where you sensed the door)If I click in the area in front of the door, the character moves there, and the door variable gets fired correctly (the second move action is never triggered though)
But if I click in the next room, and there’s a closed door in between, the character go hugs this door’s collider while continuing to try and walk past it…I suspect that I’m using RAIN in a unorthodox manner, and not for what it was thought for, but the NavMesh generation at runtime makes RAIN essential to my project. I do plan on using RAIN also for the AIs of the game’s enemies component, and I would like to integrate it with everything else.
Hope you guys can give me some directions.-
This topic was modified 5 months, 3 weeks ago by
klawd.
(Is it normal that I can’t edit the original post anymore?)
I have actually noticed that the detect node never assign the variable… here’s how the node is configured:
Here the door entity, and the AI rig/sensor:
Am I doing something wrong? Shouldn’t the detect node, use the sensor to detect the door entity and set the variable to trigger the constraint nodes?
EDIT2: I noticed the door Entity Rig had no form, so I put the door gameobject in it, but the detect node still doesn’t detect the door.
The form definitely would have caused a problem. So make sure that stays assigned.
Just to test, increase the range on your sensor, and increase the horizontal and vertical angles. The sensors pickup aspects on points and not colliders, so in some cases it can be easy to miss the target.
Aside from the form, all the screen shots look good, so my only thought is that maybe the sensor is just missing the aspect due to sensor range. The aspects look like a sphere on the entity you have it assigned to, and they usually start at the base of most objects (where the transform usually is).
Good morning Sigil,
here are the new AI Rig and Sensor:
Still the form variable in the Detect node is never filled.
-
This reply was modified 5 months, 3 weeks ago by klawd.
Looks like the entity still has an empty form (in your screen shot). If that is empty at runtime the aspects will never be registered with our sensor manager, which will keep it from being detected. Make sure it is assigned before you hit play, as assigning it in the editor after hitting play probably won’t work (need to fix that so it won’t let you).
The aspects look fairly stretched out on the door, but just so you know that won’t affect how the sensors pick up the aspects. The center points of those spheres will have to fall within the sensors range in order for it to pick it up. I’ll likely change that visualization as that is confusing.
So if your AI is literally on top of those doors, and the aspects fall within the sensors, it still doesn’t pick up the door?
Sorry, I uploaded the wrong screenshots. And yes, it still didn’t pick up the door.
Now I increased the Sensor range from 1 to 1.5, and changed the Detect node to Best Match, and it works. It also works with Any Match, but not with All Matches. I’ll try reducing the Sensor range again to pinpoint the exact problem I was having.EDIT: ok, so, if the range is under 1.2, the Sensor doesn’t pick up the door’s Aspect. I guess it has to do with the Aspect size/position, as you mentioned. Also, I can’t find the documentation regarding Best/Any/All Matches, could you please explain me the difference?
EDIT2: so increasing an Aspect’s size doesn’t have any impact on its real size?
Sorry for the late reply:
Unfortunately you are running into some bugs that haven’t been fixed in the current RAIN yet. Best/Any are currently both the same, Best is supposed to return the closest, but right now they both return the first one they check that passes. All matches will only work for the aspect variable option on the detect node (it won’t set entities or forms), and you’d need a custom action to use the values (it sets a list in memory, and most things in the behavior tree need a single value).
I posted a custom sensor that fixes the best option here.
You could also contact me and I can get you a development version that fixes all of those things. It does come with its own risks though (beta like risks).
-
This topic was modified 5 months, 3 weeks ago by
You must be logged in to reply to this topic.