Search

To stop wandering NPCs during the interaction, you need to somehow stop the wandering mechanic. When using the NPC as a combatant with move AI solution, you can just block the move AI (either globally or for specific game objects).
For other solutions you'll need to handle this differently. E.g. schematics handling this would need to be based on some conditions, e.g. a game state or variable on the game object being set. For custom scripts, you could e.g. call a function on the script via Call Function node to let it know to stop or resume movement.
The 2D and 3D quickstart tutorials use such 'teleport' battles, i.e. encountering an enemy remembers the position at the start of the battle and load the battle scene. After battle, the game returns to the remembered position and scene.
There are also separate schematic tutorials for such a setup, see here for battle start and here for battle end.
As for fighting multiple NPCs, that depends on how you start the battle.
General, there are the Auto Join Settings found in Battles > Battle System > General Settings that allow enemies around a starting battle to automatically join at the start of a battle, or even join an already running battle when coming in range.

1) Did you take a look at the tutorials using Mecanim animation?
If you're doing a 3D game, check the 3D Action RPG animation setup, or for 2D the 2D Quickstart RPG animation setup.
Generally, the setup in ORK depends on your animator controller's setup, e.g. based on if you're using transitions (based on parameters) or play the animations directly.
If find it easier to play directly and have an exit time in your animations - i.e. you just play the attack animation and it transitions back to your idle/starting animation when it's done. No parameters needed to set here.
Overall, you'd just set up your animation types (Base/Control > Animation Types), hook up animations (Base/Control > Animations) and use that animation setup in your combatant's settings.
Playing the animations is done using the Combatant Animation node in your schematics, playing them by the animation type.
2) Might just be a display issue - where and how are you displaying the variable?

@lonewolf_cat the scroll is handled in the UI Box there is a component Scroll Rect in the object Scroll View that you can set the horizontal scrollbar in, but you need a bar to set there since the one it has now is vertical.
Probably faster to just make a new box. Make sure you have UI Canvas to make it on like this https://orkframework.com/guide/tutorials/ui-setups/unity-ui-initial-setup/#2-toc-title
Then just right click the canvas object, go to Makinom -> UI Box -> UI Box Scroll Horiztontal
Or the one that only says UI Box Scroll comes with vertical and horizontal bars.
Then drag the box to a folder to make a prefab, and create a UI Box in Makinom-> UI->UI Boxes for it and assign it to the menu. If you replace the existing UI Box then it would change it for other menus too...

The battle menu has User Highlight settings for this. When not using a battle menu, you can use the turn start/end schematics of combatants to implement a custom system, e.g. spawning a prefab there.
As for highlighting combatants with the raycasts affect range, that's currently not available out of the box. You can e.g. use cursor prefab components on your raycast cursor prefab. The affect range scale component combined with trigger machines on the prefab to spawn/destroy prefabs to highlight combatants within the trigger of the cursor could do the trick.

Yeah, there's not much correct here ... you try to create a new bestiary entry with a static property that doesn't exist, bestiary settings is never initialized, etc.
You can access the game's bestiary via ORK.Game.Bestiary - e.g. to check if a combatant is known or get entries for a combatant. I'd recommend to create a dummy combatant instance for each of your buttons, see this documentation for details on creating combatants via script.
That way you can check if the combatant is known and change the button text based on that (you can get the name of the combatant from the combatant directly).
So, in your Start function create the combatant (with default start level, etc., see the linked documentation for details on creating one with other setup):
Combatant combatant = ORK.Access.Combatant.CreateInstance(ORK.Game.Combatants.Get(index), new Group(), false, false);
In the button update, just check if the combatant is known:
if(ORK.Game.Bestiary.IsKnown(combatant))
And use the combatant's name instead of bestiary entry.

There is language export/import functionality available.
Basically just export all your texts as CSV files, add language texts to it and import it back.

Even for smaller games with not so much text it's probably better to use language export/import. It gives you all the content to edit in one place and does the adding of texts for you.
Btw, loved the recent video updates, looking better and better :)

Hi @gateguard
These can be handled many different ways, much of it depends how You want the mechanics to work. I'll toss out some guesses at different ways to do it, but we probably need to know more specifically how you intend the mechanic to work.
I would recommend doing the Status System tutorial + 3D RPG playground if you'd like more depth in to various systems of the framework.
-
I think you're talking about the miss schematic in an ability, it is the schematic that runs when the Hit Chance fails(misses). There is also an Evade Animation here: https://orkframework.com/guide/editor/battles/damage-types/
You could do something simple like a Status Value for Evade and all it does is subtract from the end of the Hit Chance formulas for abilities. https://orkframework.com/guide/tutorials/status-system-setup/05-formulas/
In that tutorial the hit chance is (User.DEX / Target.AGI) * 100. At the end of the formula if you subtracted your Status Value for Evade, it would be reducing the % chance to hit by the Status Value amount. ((User.DEX / Target.AGI) * 100) - EVA
If you want to do something more like a separate % chance to evade that is not using the Hit Chance %, that is more complicated, essentially the built in Block mechanic.
-
Threat is most likely going to be handled in Battle AI. https://orkframework.com/guide/documentation/battles/battle-ai/
Lots of ways to go about it though.
If what you want is preferred class order my first thought is use Check Status to see if the target is a Combatant Type Tank or Class Tank, success -> move/ability, Fail-> check the next biggest threat type, repeat. Put in a chance node on the successes so there's a chance it will not use the top threat and skip to the next one, and or put a chance node before any of that so maybe it skips the class checks altogether and choses random target (still going through other checks like distance etc)
There are also nodes related to amount of damage done that could choose target based on raw damage.
If you want to do a value based system where certain abilities add a specific threat amount, that is more complicated.
Take a look at this Taunt/Provoke schematic, it is sort of in the same vein of thought that you are checking for something in the Battle AI (in this case a status effect) to give priority to a target.
https://orkframework.com/guide/tutorials/status-system-setup/16-battle-ais/#21-toc-title
https://orkframework.com/guide/non-knowledgebase/2d-grid-battle-rpg/10-battle-ai/
-
Protect I haven't actually created one yet so I'm not sure if the newer Status Effect settings make it easier now, or using Status Value change schematics (when HP changes a schematic runs and checks for the Protected status effect(s))
There was a tutorial in Ork2 about using Linked combatants nodes to do it, which the node still exists in Ork3
https://orkframework.com/ork-2/tutorial/gameplay/protecting-allies/

Sure, that shouldn't be an issue.
You can also let Makinom know about those custom controls and have it automatically enable/disable the control component based on the player or camera control state in Makinom. This can be set up in Base/Control > Game Controls in the Player Settings > Control Behaviours.
There's more details in this ORK documentation about custom controls, but the setup is part of Makinom, so it's also valid for Makinom only use cases.

IndieGuy said: Are there any limitations or special considerations I should be aware of when attempting this integration?

Not really. Though, if you're using interactions (e.g. Interaction Machines), you still need an interaction controller setup.

Might be coming from the battle AI selecting an action and telling the move AI to move toward the target (due to being out of range).
You can set up the battle AI to only use targets detected by the move AI - e.g. check out this part of the 3D action RPG tutorials.

https://imgur.com/a/7bQrmwt
Using solution #2, The Thorn Damage trigger on my player group, but not the attacker. Switch user/target doesn't do anything.

Yeah, you're using just an empty combatant that's not initialized to anything, that'll cause errors. Check out the documentation on combatant scripting for details on how to create a new instance.
A different approach for this kind of information would be using ability variables. They can either be just for display or also used as part of your damage calculations.

You need to register your custom controls with ORK/Makinom.
Whenever player or camera controls are blocked, the system will disable those components and enable them again when controls are unblocked.
If some special setup is needed when they get disabled or enabled, you can either put that into an OnDisable and OnEnable function in those control components, or use a wrapper component to work between ORK and your custom controls (see the linked documentation above).

Make sure your animation setup is correct, e.g. here for the attack animation. Sounds like the stop parameter changes are not correct.

I can't explain every detail of how I created the battle system since there's way too much information I'd have to write down but I'll give you an overview.
The battle system is active turn based using the grid system. The turn order is calculated using a status value using the Multi Turn option.
The grid is set up to a fixed 6x3 size. I store all of the grid objects into selected data so I can reference the position when ever I need to place combatants at specific locations.
The entire battle is just a series of spawning prefabs in the form of particle effects while flashing damage numbers, sound effects, screen shaking and blinking the selected combatant/position.(either red for damage or green for healing or white for everything else)
The actual combatants are the character portraits (2d sprite prefabs) you see in the video. The UI that displays the name and health are HUDs I have attached to each combatant. The background they're on is just a series of sprites. The actual grid is invisible. Everything else is either a HUD or the battle UI.
The top section of the screen displays 3 HUDs elements for the turn order. The very first portrait is a HUD with a blue color for the background. This has been filtered to only show the current combatant's turn. The next HUD shows up to 8 turns, excluding the current combatant. The next HUD on the right displays the total turn count. Lastly, you have sprite as the background.
To the left of the screen you have a HUD that displays custom "goals" and rewards. The reward is just the normal battle reward of turn based combat. Based on the result of the goals, I have bools set up that may add additional loot to the battle rewards once the battle ends.
To the right is a HUD that displays defeated combatants in battle.
At the bottom is a HUD that displays the current active combatant, as well as the turn based battle UI.
The difficulty of setting up a similar system is understanding the UI system of Unity and understanding how Ork handles displaying data. I recommend you follow the tutorials GIL have posted. I've been working with Ork3 since it first went into beta so I learned everything blind. lol
Once you understand how to display any data, handle variables, and organize systems, you should be able to replicate what I've done easily.
If you have any specific questions I'll try to help as much as I can.

No, spawn points are only used for spawning, i.e. afterwards the combatant has no connection to the spawn point.
You could use the spawn point's rotation for that kind of information.
E.g. the 2D tutorials have a setup where the root object of the combatant rotates and the sprite is on a child object, always facing the camera. That way, the rotation information is used as directional information for the animator controller. More details on this kind of setup here.
Another way would be to get the nearest game object with your custom component and check the information on it in a schematic. E.g. the Search Objects node can find a game object with a defined component on it within a defined range, using a Check Fields node to check that heading setting on it.
Use the schematic in an Auto Machine on the player (e.g. start type Start) and it'd be used when the player is spawned.

See the scripting documentation on creating a combatant and initializing it.
What you're doing is changing the settings (for all combatants), not actually the instance of the new combatant.

There is currently no built-in player/camera control for that - I'd recommend using custom controls for that.

You can download the completed HUD prefabs at the top of the tutorial. The used project is the one from the 3D RPG Playground tutorials.
All you'd need to do is import the HUD prefabs into the project and follow the setup steps from the tutorial to add the prefabs to the project.

Yes, that's possible - since you handle whatever should happen when an ability/item is used via schematics, you'd simply have to do that in the schematic.
E.g. moving the game object of the target into the air or adding force to the rigidbody.
Based on the video, using damage dealers/zones for damage calculation seems a good fit, i.e. only damaging when something actually hits.
Alternatively, you can check if something is on the ground using a Check On Ground node (uses character controller or raycasting) or other check nodes (e.g. Y-axis position checks, raycast nodes, etc.).