Is there currently a way to have requirements check for which abilities are being cast, or to check the status of a target rather than the user to see if an effect should be removed?
  • Status requirements can't check for an ability being cast, they're used mostly for more permanent status checks, e.g. knowing an ability or current equipment.

    Status effect changes in abilities (and items) can check the user or the target.
    If you're enjoying my products, free updates and support, please consider supporting me on patreon.com!
  • Thanks, I might be going about things the wrong way then. My objective was to create a status effect called 'Engaged' that would block all combatants either attacking or being attacked with a melee weapon, and to have it end when all the surrounding combatants were incapacitated (i.e., no longer engaged in melee against the surviving character). It's become a moot point as of yesterday though, because after I replaced the combatant object I've been using with a spawner, combat no longer triggers. Nothing I've tried so far has managed to fix this issue, and I can't remember what I did to get it to work before. Tried working through the tutorials again, but there's either something I'm missing or a setting I'd previously tweaked that's preventing combat from triggering. Here's what's happening:

    -Combatants appear to spawn without an interaction controller (when I pause the game and click their object, I don't see anything. Nor any object variables). I set up the interaction controller (which, correct me if I'm wrong, should automatically include a collider and rigid body) to automatically apply via the tutorial steps, so not sure what prevents it from spawning.

    -Placing a new combatant and using the scene manager to give it a controller no longer works either. When I click on the object, my player moves forward until it butts against and then circles around trying to reach the object's center, where I'd clicked (so maybe there is a collider of some sort there). The spawned combatant and placed combatant remain perfectly still. Also, the spawned combatant is sometimes hanging in mid-air. Only sometimes.

    -AI isn't working, period. Neither the Hunt nor combat AI seem to trigger. The combat AI has been reduced to the simplest possible procedure: it just goes straight to 'none'.

    -I created a new attack, modeled after the tutorial example, and set it as the base attack for both combatants. It doesn't even use formulas, I just set the attack value to 100 and gave it a target status change to 4. Range template is set to 1. Nothing happens.

    -A final note: My battles are set to occur in Real Time using Active Time. I set up the whole field scene as a Real Time area (recent change), then replaced it with a set area like I'd been using, and now it's Real Time again since I'd prefer it that way and the area wasn't working either.
  • The interaction controller is only needed for the player to interact with others (and usually added automatically when set up that way). Other combatants don't use an interaction controller.

    Generally, if no fight starts with your spawned enemy combatants, make sure they're:
    - set to be in a faction that is an enemy to the player
    - the spawned combatants are also set to real time when using a real time area
    If you're enjoying my products, free updates and support, please consider supporting me on patreon.com!
  • Thanks for the response. The battle setting was indeed preventing combat from initializing, but that begs the question of how I should go about overlaying those two systems to work together. And there are some other problems...

    -The spawned combatant hangs in the air and gives a message 'does nothing'. Auto-attack begins on the player end when I manually move into range (it's suppose to move on its own to the target, but apparently I haven't set that feature correctly), but the combatant never does anything except take damage and eventually die.

    -As mentioned, setting the spawner's battle setting to Real Time causes their object to hover immobile above the ground. This would be due to the stop-out phase of the 'Hunt' AI and the fact I've placed their spawner in close proximity to where my player spawns, yet when I pause and check it says they aren't targeting anything. I suppose that means they recognize the player as a target but then forget, although if that were the case I'd expect their Hunt AI to resume, so something else is probably going on. Spawning them with an active time setting causes them to wander around aimlessly, as they should, but of course I can't target them nor vice-versa.

    -This isn't a comment, but a question: how do you recommend that I set up my combat system to overlay Real Time and Active Time? I've read on multiple occasions where you state this is possible through ORK, but how, and which settings will I need to tweak to what values?

    -How and where would you recommend I set up an event so that combatants will automatically move into a specific melee range? It will need to run a check against a stat, variable and/or formula value (covering my bases for now) to determine a proximal distance between the target where it will need to stop. In other words, I need them to check for the greatest attacking range held either by themselves or the target, and then have both combatants stop at that range and attack each other, or one attack the other while they generate random values attempting to move into their own attacking range.
  • What is your enemy combatant's battle AI set up like? If the battle AI doesn't find a useable action (e.g. due to use costs), the combatant will end up doing nothing.
    Also, try using the Spawn On Ground options in the spawner (or component on the combatant's prefab).

    Make sure the move AI is allowed in your real time battle settings (Battle System > Real Time Battles > Move AI Settings).

    Setting up real time and active time as a mix depends on how the result should be. You can either set up active time battles that allow free movement (i.e. have individual battles) or real time battles that use a status value as a replacement for the timebar (i.e. allow scene-wide battle areas), where all actions require the status value to be filled 100 %.

    The last question might be a bit tricky ...
    Generally, the battle ranges (e.g. use range of an ability) can tell the move AI to move into use range (there's an option for that in the range's settings, e.g. when setting up a battle range template).
    You could probably set up a battle event that's used at the end of each action, or set up a game event used by a global event to be run every X seconds to check and move the combatants.
    If you're enjoying my products, free updates and support, please consider supporting me on patreon.com!
  • Hard to tell if I'm making any headway or not. In active or real time, both player and AI combatant flash the message "does nothing," but in the player combatant's case it looks as though he's at least activating the 'Target Changes' portion of his default attack ability. A number periodically displays over the AI combatant's head to indicate a status change, but there's no reciprocation at all. In other words, I'm not sure if I'm really attacking or failing to attack, but I know the enemy isn't attacking me at all. There's currently no use costs or requirements on the ability. There's a simple battle event tied to animation that checks the distance to a target and instructs them to move within 'X' range, but that wasn't working either and I've disabled it. This is what my battle information side panel shows during testing:

    In Battle - True

    Turn - (Varies)

    Turn Value - 0 (don't know what this means)

    Turn State - After Turn

    Finished Choosing - False

    Attack index - 0 (not sure what this means either)

    Dead - False

    Defending - False

    Is Aggressive - True

    Is Leader - True

    Item Stolen - False

    Money Stolen - False

    Battle Actions
    Can Choose - True

    Is Choosing - False

    Action Fired - False

    Action State - Available

    Waiting for Action - False

    Auto Attacking - True

    Time Bar - (Varies)

    Used Time Bar - 0 (not sure what this is)

    ...And that's it. The only difference between my AI and player combatants' info is that the AI shows auto attacking to be false. But, again, both say they're doing nothing, and I can't get either to move.


    P.S. - I'm attempting to use 100% mouse interaction for all of my targeting and move selections using the default ORK settings. Should I be using some form of Navmesh system in tandem with this? Because currently none of my combatant objects have a Navmesh component, and I've just set everything so far to recognize all layers.
  • It might be the use range of your abilities that prevent them from being used. Check the ability's use range (or the default use range if it doesn't override it - set up in Battle System > Battle Settings).

    Regarding movement, can you tell me more details about your move AI's setup? Especially the Move Component Settings.
    If you're enjoying my products, free updates and support, please consider supporting me on patreon.com!
  • My 'Default Use Range' in 'Battle Settings' is set to 'None'. The test ability I'm currently working will sometimes have its 'Range Requirement' 'Range Type' set to 'None', and other times set to various templates. The template currently set to the ability has the following settings:

    -Only AI Controlled: Unchecked

    -Minimum Range: Unchecked

    -Maximum Range: Unchecked

    -Use Raycast: Checked

    -Layer Mask: Everything

    -Use Child (User & Target): Blank

    -Move into Range: Checked

    -Use Stop Angle: Unchecked

    -Check Height Difference: Unchecked


    The Move event linked to animations is very simple. It has one 'Change Position' node followed by a 'Calculate' Node. The 'Change Position' node is set up as follows:

    -Enabled: Checked

    -Override Node Name: Checked

    -Node Name: CHANGE POSITION!!!


    Moving Object

    Object: Actor

    Actor: User

    Child Object: (left blank)

    Time Between (s): 0


    Target Position

    To Object: Check

    Object: Actor

    Child Object: (left blank)

    Use Center: Unchecked

    Local Space: Unchecked

    Offset: XY&Z=0


    Move Settings

    Move: Checked

    Wait: Checked

    Ignore Height Distance: Checked

    Controller Move: Checked

    Apply Gravity: Checked

    Face Direction: Checked

    Stop Distance: 0

    No Combatant Radius: Checked *Which radius does this refer to? is it the object collider radius?*

    Move By Speed: Checked

    Secure Time (s): 0.5

    Stop At Target: Checked

    Speed Type: Sprint

    Speed: 10

    Follow Position: Checked


    The first problem I'd like to address is that the position of my combatant is not truly changed; it merely runs to the target and then returns to its initial position before stopping to face away from the target. The speed is also very slow, almost like it's constantly stopping along the way to check for something. It does do damage upon reaching the target before turning around to head the other way.

    My 'Move AIs' under the combatants tab has only the default at this point, and the "Hunt" AI as described in the tutorials. In each case, the 'Move Component Type' is set up as 'Default, and 'Add Component' is checked.


    As mentioned, I'm also unsure of how to set up the mouse controller so that it understands the difference between clicking on an object and clicking on the ground, because it seems only to recognize the ground at this point. Will it require some form of navmesh/layer information, an event-on-click setting, some combination of the two or another sort of configuration to run a fully point and click RPG?







  • edited June 4
    I think the main issue is the raycast settings of the range template. As is, the raycast checks every layer and probably goes from the feet of the user to the feet of the target, which makes it very likely to hit something on the ground.
    I'd recommend to have only some layers for the sight blocking check (e.g. ground, combatants and other environmental stuff that should block sight) and use child objects to have the raycast go from e.g. the head of the user to the head of the target.

    The combatant radius is a setting in every combatant's settings to set how big a combatant's collider is. This would be subtracted from distance calculations if used.
    Your movement setup could lead to the user keep to running toward the target, due to not being able to reach its position (colliders blocking further movement), since you're using no combatant radius and no stop range.

    On which layers are your combatant's placed? Should be set up in the prefabs you're using for them.
    Post edited by gamingislove on
    If you're enjoying my products, free updates and support, please consider supporting me on patreon.com!
  • "I'd recommend to have only some layers for the sight blocking check (e.g. ground, combatants and other environmental stuff that should block sight) and use child objects to have the raycast go from e.g. the head of the user to the head of the target."

    How is that done? I've noticed the option for setting a child object, and I understand the concept of a child object within a model's hierarchy, but how do I reference it inside of ORK? The way it's set up it looks almost like referencing a variable, but possibly more like a variable on steroids that's just finished binge snorting a kilo of cocaine mixed with meth and Adderall straight off the floor of a fully gassed and loaded Russian T-90 tank (because, it Russia, tank *#$%s you.)


    "The combatant radius is a setting in every combatant's settings to set how big a combatant's collider is. This would be subtracted from distance calculations if used.
    Your movement setup could lead to the user keep to running toward the target, due to not being able to reach its position (colliders blocking further movement), since you're using no combatant radius and no stop range."

    When I set it to recognize colliders, my little guy was stopping well short of any distance where two colliders should have met. Then he would immediately turn back and head the other way. My main questions are: how do I get a combatant to recognize that the point where they cease moving forward is to be considered their new default position (meaning that the little %&$@ers are supposed to stop and not turn around to head back where they were), and why is the AI combatant not doing anything whatsoever?

    What might allow a player controlled combatant to run through their auto attack sequence normally, yet cause AI combatants to stand around like a bunch of useless lumps with thumbs stuck up their virtual butts? Because I never specified for them to do that! Certainly not by default for their not doing anything. I set, everywhere that I could find, for the AI to do the opposite of nothing, and specifically not to put their thumbs up their butts because they're supposed to be using them to help with attacking. It's frustrating. Also, kind of gross, and probably unnecessary even while attempting to illustrate a point. Sorry about that.


    "On which layers are your combatant's placed? Should be set up in the prefabs you're using for them."

    I just assume they're being placed on the ground if they're moving along on the ground. What am I looking to check? I haven't yet bothered to reference any layers apart from 'default' inside the ORK framework, or set up any within my scenes. I was wondering, though, if that was something I would need to focus on to create a complete point-and-click interface.

    If my desire is to click a point on the screen and have ORK recognize that I'm clicking on a chest that a combatant will need to run up and check/open, or a trap they'll need to disarm (hopefully prior to running over), or a person they'll be wanting to talk to or an enemy that hasn't yet initiated combat, will ORK do this purely by my adding certain events to the necessary scene objects and prefabs, or does it need me to add a navmesh component set to a specific layer in order to understand exactly where I'm clicking before triggering said event. There are several rather in-depth tutorials on the forums covering how to go about this, but ORK has been upgraded quite a bit since they were posted and I'm hoping that a solution no longer requires the use of any custom scripts to mediate.
  • Child objects are defined in Unity similar to a folder path, e.g. if your child object structure in the scene hierarchy looks like this:
    Root Object > Spine > Head
    The child object in ORK would be defined like this:
    Spine/Head

    Simple way to stop a combatant from moving back to their battle spot would be to just not tell it to. E.g. the game tutorial set up separate battle events for moving to target and moving to base - in that example, you'd just not use the event moving to base after the attack. This would be set up in the ability/item's battle animation settings.
    To permanently change the battle spot of a combatant, you can change the position of it through the Waypoint actor User Base.

    AI controlled combatants doing nothing is usually caused by either no usable action available or no target available. Both issues could have multiple sources. If you can send me a small Unity test project where this happens I can look into it.

    Layers are an important part when it comes to your overall setup in Unity, as this plays a huge role for stuff like raycasting and physics and is a good way to organize your stuff. Especially when going for point and click style controls you should look into this and e.g. only have the ground, combatants and stuff that could block sight or clicks on checked layers, putting other things on layers that you don't check with raycasts.
    If you're enjoying my products, free updates and support, please consider supporting me on patreon.com!
  • -"Child objects are defined in Unity similar to a folder path, e.g. if your child object structure in the scene hierarchy looks like this:
    Root Object > Spine > Head
    The child object in ORK would be defined like this:
    Spine/Head"


    Is that not case dependent though? Just to clarify, my understanding is that we're talking about an object's full hierarchy here, which includes, but is not limited to its armature and everything attached. An armature can have anywhere from 1 to infinity bones. Does Unity require a standard formatting to govern how those bones are named and grouped? Thus far I've not cluttered my project with any character models additional to the standard ORK eggs (because they're awesome!), but when I get to that point they'll mainly be 3rd party.


    -"Simple way to stop a combatant from moving back to their battle spot would be to just not tell it to. E.g. the game tutorial set up separate battle events for moving to target and moving to base - in that example, you'd just not use the event moving to base after the attack. This would be set up in the ability/item's battle animation settings.
    To permanently change the battle spot of a combatant, you can change the position of it through the Waypoint actor User Base."


    I'm not telling it to move anywhere apart from proximal to a target. My move event has one step and doesn't link to any other move events. I'm thinking that ORK views the command as part of an animation loop rather than an actual movement command, thus it never actually reassigns the combatant a new position from where the event initially launched.


    -"AI controlled combatants doing nothing is usually caused by either no usable action available or no target available. Both issues could have multiple sources. If you can send me a small Unity test project where this happens I can look into it."


    It does have a target, at least according to the Battle Information panel. I haven't set up any behavior or rule slots (not really too sure about those yet), but I've given it one battle AI with a 100% use chance and no requirements. The AI is setup as follows.

    -Settings: ORK_BaseTutorial_Fighter

    -None (Ends the AI): enabled


    That is all. Admittedly, it's not exactly a carbon copy of the event outlined in the tutorial, but it's named as though it were and, anyway, less is more... right?

    -Real Time AI range is not checked.

    -Action settings timeout after 1 second, and 'Own AI Decision Time' is left unchecked.

    -It's setup as AI controlled

    -Autotarget, Nearest Target and Attack Individual Target are selected

    -It's always aggressive. Not really pleasant to be around, despite its apparent apathy.

    -It notifies and reacts to its group, and notifies its faction

    -The faction is hostile to the player

    -It detects by sight (really wish we could create our own detection options and set them to use formulas)

    -Use move detection is checked, range 20, threshold 0.5

    -It auto starts battles, range 10, ignore height

    -Base attack is set to the same ability my player combatant uses

    -Auto attack active is checked

    -use ability is checked, ability is set to the base attack, timeout is 1 second and target options are individual


    -"Layers are an important part when it comes to your overall setup in Unity, as this plays a huge role for stuff like raycasting and physics and is a good way to organize your stuff. Especially when going for point and click style controls you should look into this and e.g. only have the ground, combatants and stuff that could block sight or clicks on checked layers, putting other things on layers that you don't check with raycasts."


    Excellent, that's what I wanted to know. Is it as simple as naming new layers and adding a navmesh component to all of my scene objects with an interaction? How does the navmesh adhere? Does it attach to a mesh, and if so will it need to bake?


  • No, Unity doesn't require a standard formatting, so child objects will be case dependent. I'd recommend having helper objects (like one used for raycasting) directly below the root object and using the same name for all your game objects. Since there's no path to them, you can just use their name to define them in ORK and it works for all objects.

    It might not be your move event doing that, but one of the next events of the ability. Since I don't know your ability's animation setup that's just a guess, though.

    As you describe your AI, it basically tells the combatant to do nothing.

    Navmesh and layers are separate things - while Navmesh also has layers (called areas), they're different from the layers a game object is placed on. I'd recommend you take a look at some Unity tutorials about layers and Navmesh to learn more about this :)
    If you're enjoying my products, free updates and support, please consider supporting me on patreon.com!
  • "No, Unity doesn't require a standard formatting, so child objects will be case dependent. I'd recommend having helper objects (like one used for raycasting) directly below the root object and using the same name for all your game objects. Since there's no path to them, you can just use their name to define them in ORK and it works for all objects."

    -What exactly is meant by "helper object?" Would an empty game object placed under one of the bones in the hierarchy be sufficient? Can you give an example of such an object that would be used specifically for raycasting?


    "It might not be your move event doing that, but one of the next events of the ability. Since I don't know your ability's animation setup that's just a guess, though."

    -I usually strip everything down as much as possible before I test. I ran the move event as the only one attached, with just a node telling the object to move into position. Somehow, it's finding its own way back. Is there a node that will force a combatant to check their current position and redefine it as their new point of origin?


    "As you describe your AI, it basically tells the combatant to do nothing."

    -I was going by this explanation in the tutorials: "Since a combatant always uses it’s base attack if no battle AI found an action, we don’t need to tell this AI to use the base attack (it would be different if you want to use the base attack on special conditionts, like on an enemy with less than 10 % HP)."

    Is this no longer true with ORK's current build?


    "Navmesh and layers are separate things - while Navmesh also has layers (called areas), they're different from the layers a game object is placed on. I'd recommend you take a look at some Unity tutorials about layers and Navmesh to learn more about this :)"

    -Ouch. So, you're telling me that in order to use an engine for building my game, I might actually be forced to learn a thing or two about it? Because I was really hoping just to cheat off of somebody else's test the whole way. This is terrible! When are they coming out with that engine that will just intuitively do everything you want the way you have it pictured in your head before it decides to take over the world? Is that version of Unity coming out later this year?
  • Yep, just an empty game object placed somewhere on your combatant's prefab. Can also just be placed directly under the root object.

    You can use a Change Position node to place the User Base waypoint at the User actors position after the move node.

    Sure, the do nothing advice from the tutorial still holds up - however, you'll also have to have other battle AIs before that one, so that the combatant is able to do something.
    If you only have a do nothing AI added, that's all the combatant does.

    I guess not - but I'll work hard on ORK, so maybe version 10 will have just a text field where you can type in what you want and ORK does it for you ;)
    If you're enjoying my products, free updates and support, please consider supporting me on patreon.com!
Sign In or Register to comment.