Forum Replies Created
-
Posts
-
Good response from @Moloch.
One of the techniques we often use is to create a Custom Element in RAIN for managing the interface between game code and AI code. If you’re interested, there are a bunch of great examples here:
https://www.assetstore.unity3d.com/en/#!/content/23526
Custom Elements are very easy to create. Here’s a template. You can add variables that are exposed through the RAIN editor, plus you can add code at various steps in the AI processing (AIInit, BodyInit, Start, Pre, Think, Act, Post).
using UnityEngine; using System.Collections; using RAIN.Core; using RAIN.Serialization; [RAINSerializableClass, RAINElement("Your element name here")] public class YourCustomElementClass : CustomAIElement { [RAINSerializableField(Visibility = FieldVisibility.Show, ToolTip = "Your tooltip")] private _someVisibleVariable; public override void Act() { base.Act(); //Add some custom code here } }I’m not sure what a locomotion controller is. Are you using a Unity script?
If you are using colliders to keep the AI above the ground, a typical setup is:
1) Capsule collider. Make sure it is centered on the character and that the base of the capsule is right at the base of the feet when standing.
2) Rigid Body. Make sure it is constrained in X/Y/Z rotation and X/Z position (not y). This assumes you are not using root motion animation. If you are using root motion animation, don’t add the constraints.What is in your attack node? Is that a custom action? If so, what value is it returning?
I’m guessing you have a rigid body on your character and you have not constrained it in the X/Z position. Is that possible?
It depends on how the parameter is being used. Triggers don’t need to be repeated, but value type parameters do.
I don’t think there is a specific “right” answer for you. You will probably just have to jump in and start experimenting with different methods until you find something that works.
I would probably start with colliders and add triggers to handle the collision. The triggers will be code, so you will probably deal with damage and other code related issues in the trigger, then set a few state variables to send information back into RAIN to deal with managing fighter state and animation.
How are you determining that your entity is still active? Setting IsActive = false will not change the enabled/disabled status of the component in the Unity hierarchy.
Also, setting the Entity to inactive will not remove variables that have already been set. In other words, if an AI has already detected the Entity, it won’t suddenly forget the detection when you set the Entity to inactive.
I’m currently using this feature in my own code. Seems to be working, so I suspect the issue is something else.
There are multiple ways to solve the problem:
1) Don’t have all the AI move to the same position in space. Usually this is what you really want to do, regardless of whether they are avoiding each other or not.
1a) We often use a “harness” to achieve this. There are examples here on the forums and in our Squad Command package on how to use a harness. Generally, a harness is a component attached to a target that defines and manages “move to” positions around the target that AI can move to.
2) We’re still working on an avoidance solution for AI. It’s one of the trickier problems we’re solving. We expect to have a solution soon, although we won’t release it until we’re pretty confident it works well in almost every situation.
3) People often solve avoidance issues by just noting the position of nearby potential collisions and steering away from them. RAIN does not use steering behaviors, so the issue becomes a little harder. However, you could look for nearby collisions and either pause movement or choose a different move target temporarily. This isn’t easy to get right, but it is possible.
Look for a release of (2) sometime this December.
In what way does it not work? (We use it all the time.)
If you are using Mecanim, then you probably want to activate the run animation using the RAIN MecanimMotor. That will usually be done based on Speed. If you look at the MecanimMotor on your AI, at the bottom of the inspector you can see that you can add parameters that will be sent to the state machine. One of those is Speed. Add that parameter and enter then name of your MecanimParameter. Then just make sure your state machine blends based on Speed.
An alternative approach could be to just use the Set Mecanim Parameter node in your behavior tree.
Finally, it is possible to do this using a MecanimAnimator in RAIN. However, we’re generally moving away from that strategy (we don’t love it and it doesn’t provide the fine control usually necessary.) If you really want to use the MecanimAnimator, post back again and I’ll go into more detail.
Looking into it.
Your code is running in a RAINAction, not in a MonoBehaviour. “this” is not a unity component and so “this.transform” is not valid. You probably want “ai.Body.transform”, but you will have to pass that in to your shoot function.
It’s likely that the Parallel running your Move node is set to “Succeed on All”. You can see that your Detect and Move node have succeeded but your Animate is still playing (and will continue repeating forever as long as you have a looping animation.)
(1) I suspect you don’t really want the Audio Detect in that parallel
(2) You probably want the parallel to succeed on anyNot sure why we didn’t see the first post from @OMGItzGnaR back in July - sorry about that.
I think the original issue was occurring because the same variable is used for eyes and sense, and that variable is an entry condition for aggro. So when either sensor detects, the same result happens. The fix would be to use separate variables and trigger behavior based on which one is activated.
@cycro - I don’t know what your issue might be. Are you saying your Move node is failing, or is there something else happening?
A couple of thoughts for you:
1) you probably don’t need the near sensor to tell when the AI has arrived. Just setting a close enough distance in your Move node and running it until Success should do the trick. Nothing wrong with the near sensor generally, but you may not need it.
2) you probably need something like a second timer or an alternate state for your AI so that it knows when to stop looking. The object it is looking at will still be in the sensor range after your wait timer expires. I would probably
- only run the detect node while you are patrolling
- store the last object detected in a variable
- ignore any detected objects if they are == to the last detected object
- clear the last detected object variable after some amount of time
