Questions from a new user

[SaevaxParticipant]

Does/Will RAIN support navmesh cutting? Threading?

[primeKeymaster]

RAIN already supports threaded navmesh creation. What specifically are you referring to with regard to “cutting”? Do you mean manual editing? Dynamic obstacles that create holes?

We are working on a version that supports real time updates based on dynamic obstacles. We have a version running here internally - just not ready for full release yet. We have manual editing on our roadmap, but haven’t started coding on that yet.

[SaevaxParticipant]

Thank you for the quick response.

Dynamic obstacles that create holes specifically. I’m glad you already have it running and I can’t wait for it’s release.

[SaevaxParticipant]

I have a few more questions if you can spare a few minutes.

What are some valid types of input for a move action? I don’t want all my units, both friendly and hostile, to find a new target every frame so I have them all find a target during a co-routine in a MonoBehavior script and pass that target to the AIRig. The co-routine executes once per second or so, depending on the unit, and it also has a frame check that spreads out the work load over multiple frames. So what kind of type should I pass in that allows the AI to path to that target until I set a new one?

If Entities are required for visual sensors and I want one unit to to detect enemy units with AIRigs do enemies need to have both a AIRig and an Entity?

For units with a visual sensor how do you efficiently sort through targets in that sensor to select an target based on a modifier like nearest, furthest, highest/lowest health value?

Are their any relatively efficient ways to do target selection for units without sensors? For example if I want a unit to find the closest target is there a more efficient to loop through enemies and find a path with GetPathTo() for them if it exists then calculate the distance of it to compare with other paths?

What would be the most efficient way to implement a boids type algorithm in RAIN? Of the top of my head would you, with a preset group of units, save a path to a target then get a move vector factoring in separation, alignment, and cohesion vectors for each enemy unit in the group? In what scripts would you do these calculations and order the move action? CustomAIElements, Separate MonoBehavior?

How would you set up units that can jump over gaps or on top of higher surfaces assuming both sections are on the same, connected, navmesh?

[primeKeymaster]

- It’s easy enough to detect a target every X seconds in the behavior tree without dropping to code. For instance, this thread: http://rivaltheory.com/forums/topic/enemy-searches-for-players-last-seen-area/ covers the topic

- Move nodes can take GameObject, Vector3, NavigationTarget, RAINAspect, Transform, and Kinematic types.

- Yes, it is pretty common to have an AI with an AIRig and an Entity

- Use a Sensor Filter. Create a new SensorFilter class that does what you want, then add it to your Sensor. Here’s an example:

using System;
using System.Collections.Generic;
using RAIN.Core;
using RAIN.Serialization;
using RAIN.Perception;
using RAIN.Perception.Sensors;
using RAIN.Perception.Sensors.Filters;
using RAIN.Entities.Aspects;
[RAINSerializableClass]
public class ClosestObjectFilter : RAINSensorFilter
{
    private bool _preferLastObjectFound = true;
    private RAINAspect _preferredObject = null;
    /// <summary>
    /// Once an object is chosen, should it continue to be returned as the sensed object
    /// until it leaves sensor range?
    /// </summary>
    public virtual bool PreferLastObjectFound
    {
        get { return _preferLastObjectFound; }
        set { _preferLastObjectFound = value; }
    }
    /// <summary>
    /// Get or set the current preferred object
    /// </summary>
    public virtual RAINAspect PreferredObject
    {
        get { return _preferredObject; }
        set { _preferredObject = value; }
    }
    public override void Reset(RAINComponent aComponent)
    {
        PreferredObject = null;
        base.Reset(aComponent);
    }
    /// <summary>
    /// Filter out all but the closest object.  The last object chosen may be returned instead if
    /// prefer last object found is true
    /// </summary>
    /// <param name="aSensor">The sensor being filtered</param>
    /// <param name="aValues">A list of aspects.  This list should be modified to retain only the closest object</param>
    public override void Filter(RAINSensor aSensor, List<RAINAspect> aValues)
    {
        float tBestDistance = float.MaxValue;
        RAINAspect tBestAspect = null;
        for (int i = 0; i < aValues.Count; i++)
        {
            if (PreferLastObjectFound && (PreferredObject != null) && (aValues[i] == PreferredObject))
            {
                tBestAspect = PreferredObject;
                break;
            }
            float tDistance = (aSensor.Position - aValues[i].Position).sqrMagnitude;
            if (tDistance < tBestDistance)
            {
                tBestDistance = tDistance;
                tBestAspect = aValues[i];
            }
        }
        aValues.Clear();
        if (tBestAspect != null)
            aValues.Add(tBestAspect);
    }
}

- In most cases, looping through the enemy list on your own won’t be significantly faster than the sensor system. That’s especially true if you create custom aspects and sensors to keep you from sorting through non-enemies. Calculating a path to each enemy is a pretty expensive operation. I can see why you might want to do it, but you should definitely do a heuristic calculation first to trim down the list to just one or two. All of this can be done in a custom action rather than a sensor filter if you want.

[primeKeymaster]

- It wouldn’t make much sense to use pathfinding with a boids algorithm. To do something like that, I would probably
a) Create a formation harness of some sort attached to the leader of the flock/pack
b) Allow the leader to pathfind/pathfollow, but none of the others
c) Have each other AI attempt to follow their position in the formation harness loosely. They could use pathfinding to do it, or they could just use steering behaviors (you would still need to deal with off-graph avoidance somehow). Steering behaviors could be done with a custom motor.

- We’re currently working on a mesh-link solution similar to Unity’s/Mikko’s for supporting climbing/jumping, etc. Until then, you could manually create link hotspots, set up triggers for your AI when they reach them, and then run some custom code to deal with the movement transition.

[Author]

Posts