Forum Replies Created
-
Posts
-
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 timeMake sure you come back to the forums and let us know what you think of the package and how we can update and improve it. We’re here to help.
The expression mechanism in RAIN supports dot notation for x,y,z,w (w for quaternions). So this works:
(5,5,3).x - vectorVariable.z
Looks like the current version is not handling complex expressions for vectors though, so
(5,5,x)
is not valid. We’ll look into whether we can add support for that in a near term release.
@luxeayor - thanks for answering that. I think you are right about the quotes.
We know that’s a confusing issue sometimes and have been looking for solutions to make it less confusing. We’d certainly welcome suggestions from everyone.
What version of RAIN? Are you running 2.1.5?
That is correct. Scaling the size of a Visual Aspect does not change its visibility to sensors. Sensors will only see the center of the aspect.
You could certainly create custom sensors that behave differently from that. The VisualSensor has a TestVisibility method that determines whether an Aspect is in range. You could extend the check to include a volumetric calculation.
