Search

A selection indicator as you described is usually handled by spawning a prefab - depending on what kind of target selection you use it's set up somewhere else.
E.g. for the regular target selection (used by the target menu) that's handled by the Target Highlight settings in Battles > Target Settings. Add a Prefab highlight type and select the prefab that should be used.
When using target range None, the ability doesn't target combatants, so they're not highlighted. You can use the Target Raycast Settings to select a target and spawn a targeting cursor prefab. E.g. the 3D action RPG's grenade uses this.
As for the tooltip - might be that something else is in the way and blocking the raycast. This is usually handled by using a good layer setup, e.g. having the HUD raycast only use layers that content is on.

Movement animations are handled by forwarding the speed and rotation of the game object to Mecanim, so make sure this part is set up correct.
Also, make sure your game controls are set up correctly.

Finally another update video. I've reach 75% completion of the game. Oh boy, it's been a wild ride this solo dev journey. But there's still more to come.

What would be the proper way to generate a random shop inventory, with some static items and sometimes random new items to add?
For example:
1. Shop starts with Wood Sword.
2. When player party hits level 3, Shop will now also sell Iron Sword.
3. When player party hits level 5, Shop will now also sell Steel Sword, and then randomly will pick from Nothing, Iron Sword +1 or Iron Sword of Flames.
4. When player party hits level 7, Shop will now also sell a Meteorite Sword.
Ideally, I'd like option #3 to only be determined once per playthrough at that time.

Sounds a bit like you fade out the UI box when showing instead of fading it in, either by using the wrong schematics or having the fade in schematic set up wrong. See the schematic setup here and the UI box setup here.

That worked! Adding HUD to buttons is a super useful feature which I think is a bit under-documented - I had to search a bit to find it in https://orkframework.com/guide/documentation/ui-system/ui-system-overview/#3-toc-title
Also had to write my own condition to check if stack limit is > 1, but that's the easy part :P

In the Target Settings > Target Changes of the ability or item. E.g. see this part of the 2D quickstart tutorial.

Next update will add an option to show the total bonus of a combatant coming from all bonuses on it (equip, effects, etc.).
The HUD Attack Modifier List is used to list the attack modifiers, i.e. the parent/overall modifier which contains it's attributes. It'd need to use a prefab that has the HUD Attack Modifier Attribute List component that lists the individual attributes of the attack modifier.
Or, if you e.g. want to display a specific modifier or only have 1 attack modifier in your project (with it's attributes), you can use the HUD Attack Modifier (Content Provider) to select a specific attack modifier and use a HUD Attack Modifier Attribute List component to list the attributes.
E.g. an example setup is part of the 3D RPG Playground tutorials.
Turning on the new option will simply only show the modifiers/attributes if they are relevant to the current action during target selection.

I still think barriers would be better suited for this, at least if I understood what you want to do correctly - i.e. damaging stamina instead of health under certain conditions.
It'd be easiest to go the access handler route via a custom combatant access handler, which has 4 status value related functions to override (responsible for setting/adding values to the status value or it's base value).

This largely depends on your game's setup - that tutorial is part of a series that needs to be followed step by step. At that part of the series, there's no enemy or battle system added yet, so you can just cause the actions via the control maps as it's set up there.
However, if you add this to an existing project without e.g. having a Real Time Battle Area added to your scene (comes later in this tutorial series), running into an enemy will most likely cause a different battle system to be used (i.e. the Default Battle System that's et up in Battles > Battle System > General Settings).
Ultimately, the used battle system has set up if and which battle menu is used.

Would be great if you can show me your setup for #2 and #3 to see what's going on :)

For #1 you can use a Start Battle node in your Dialogue schematic to start a battle after playing a given dialogue. You'll need to pass in the combatants and/or battle component responsible, but that's the route I would recommend. Another route would be to create a new Battle instance and override the Battle Start schematics for that single battle and input your dialogue there.
For #3 spawning Prefabs through schematics lets you store in Selected Data which you could then use as the object in a Destroy Object node. Another option is to specify the name in the Actor part of the schematic settings, use Find Actor Objects after they've been spawned (this is not needed if they are already part of the scene when the schematic starts), then call Destroy Object on the actor objects.

So for anyone who is making a stoneshard/traditional roguelike game, I managed to get wasd and click movement fully functional with multiple enemy sizes and no game breaking AI problems anymore.
It took quite a bit of trial and error and was far more complex than I thought it would be so if anyone ever needs help setting things up feel free to add me on discord and I can show you whatever you need Buddy#3026
Thanks to gamingislove for walking me through some ideas to set me in the right direction :)

If you're not using Death Immediately in your turn based battle system's setup, the death animations are performed one by one, so while there are still enemies in battle, they're already all dead. Not sure what your custom function checks for, but from ORK's perspective I'd recommend to check for there not being any alive enemies and only 1 dead enemy being there - that'd make this only run for the last dead combatant's death animation.
Regarding #3, that's most likely because there are no free battle spots for those new combatants available. That'd use the Additional Spot setup to create new spots.

Hi there. I posted about this in the tutorial request thread but I figured maybe I could make a general thread about it here.
Are there any super beginner-friendly tutorials out there? I have tried following the tutorials on the website but sooner or later I get completely flustered because I find myself just doing what the tutorial says to do without understanding it.
For instance, right now I'm trying the 2D RPG Quickstart because that seemed like the most basic, simple, beginner-friendly one out there. But right now I'm on 02 Player Settings. It's about when I get to this part https://orkframework.com/guide/tutorials/2d-rpg-quickstart/02-player-setup-2/#3-toc-title
That I'm like.... Okay. I can click the buttons and do what it says, but I don't feel like I'm actually learning because I'm 100% certain that if I were to try and make my own game I would have absolutely no idea that I need to go in and click these settings. Maybe it's just the way my brain works but... it just feels overwhelming and confusing.
When I'm doing a tutorial and I get that "I'm just doing what it says to do because that's what it says to do" feeling that's when I start to tune out and give up because I know I'm not going to be able to do these things on my own.
Anyway, I'm not trying to complain. They've clearly put a lot of work into all of this. I just wanted to know if anyone has any recs for something more beginner-friendly.

I think this would fall under this since it's under the Status tab, but would it be possible (or is it already) to extend Formulas to allow for getting the current ability's Modifiers?
Pokemon for example has the normal elemental type chart which we can easily handle with Attack/Defense modifiers.
However, something else they do, is that if the type of the move is the same type (or one of the same if dual type) as the attacker, is that the move gets a small power boost, known as Same Type Attack Bonus.
So for example you could have these 3 moves that a Fire defense mod combatant is able to use
1. Fireball - 40 Power Fire Atk Mod
2. Frostshard - 40 Power Frost Atk Mod
3. Grassball - 40 Power Grass Atk Mod
#2 and #3 should do the same damage on a neutral opponent, but the fire one would get a small 25% boost.
Since the formula for these moves would otherwise be the exact same, it would be nice to be able to keep the single formula for them, but just have a node that can grab the modifier from the ability and then check it against the combatant without needing an otherwise duplicated formula but instead checking the combatant for every type.

Small input on #3 - ORK 3 has random combatants in groups, but ORK 2 doesn't. However, ORK 3 just has random combatants, no chance or condition settings as would be part of the new ORK 2 feature (and also added to ORK 3).

Hmm interesting on #3, I haven't touched ORK 3 yet so perhaps it is something that's new. What you are showing me is the Editor right? Combatants -> Combatant Groups?
So you can already define multiple combatants within "Combatant 0"? Can you also already define requirements for specifically "Combatant 0" and each random combatant you've assigned? Or is the requirement just for "Combatant 0" in general.
If what I'm assuming is correct then I suppose the changes would be different for ORK 2 and ORK 3.
ORK 2 would have the ability to define randomised combatants within the editor and define requirements for each randomised combatant.
ORK 3 would have the ability to define requirements for each randomised combatant.
I'll probably follow up with GiL on this.

@Bantichai For what it’s worth, I didn’t make the discord, I’m just someone that recently started to talk a lot and answer questions in it haha
Thanks for the breakdown. I understand what you mean now by #1 and I can see that being useful and desired by the players too, especially if the game is as punishing as something like XCOM tries to be.
I’m still not sure I’m understanding #3, but maybe it’s because my project isn’t super big at the moment so I’m just viewing it though the wrong point of view (I'm also on ORK 3 fwiw but I'm not sure if this is one of the differences between versions). I could also just be being dense, that's always a possibility too :)
Using your example group of Bandits, currently we can make a combatant group that has:
Combatant 0 - Random between Bandit Thug, Leader, or Captain combatant
Combatant 1 - Thug
Combatant 2 - Thug
Using my project as an example, I have Combatant 0 that is random between Enemy Polearm, Enemy Axe, and Enemy Sword and Combatants 1 and 2 are always Enemy Polearm:

No worries, appreciate you setting up the unofficial ORK discord channel too!
#1. I believe this was added in XCOM 2 as a heavily user requested feature. An example would be if your combat has "Attacks of Opportunity/Sub Actions" that trigger when a combatant leaves attack range, IE walks by an enemy combatant within 1 tile.
If you have your grid movement set to find the nearest path in most cases you will walk by that enemy and trigger an AOO attack. You could of course, just allow movement as many times as you want and move tile by tile but this feature will essentially allow you to plot "waypoints" so you can navigate obstacles provided you have the Action Points/Movement for it.
Furthermore if you decide to have enemies that have a AOO range of more than 1 tile, say 2 (polearm user) or "traps" from grid cell effects you might want to consider this too, especially if you are using the XCOM 2 action system.
It's a QoL feature, allowing you to adjust the pathfinding for grid movement. When you are clear of enemies you can freely move and find the nearest path, when you want to avoid an enemy/trap you can plot waypoints for an alternative path around the enemy/trap seamlessly without having to move tile by tile.
#3. I suppose to easiest way to explain is that it would be an in editor time saver.
Scenario 1:
For example, let's say you want to define a group of 3 combatants.
Combatant 0: Bandit Thug
Combatant 1: Bandit Thug
Combatant 2: Bandit Thug
Now within the editor, you could "randomise" it by defining variables for Combatant 0 but you would then also need to define a 4th combatant if you wanted to always keep it a group of 3.
Combatant 0: Bandit Thug (Bool Off)
Combatant 4: Bandit Leader (Bool On)
The more combatants you want in your group, the longer your list is gonna be.
With this feature, within the position of Combatant 0: You can define Bandit Thug, Bandit Leader, Bandit Captain, set a chance for it to spawn or a variable requirement, define a fallback combatant (similar to conditional prefabs etc).
Scenario 2:
Combatant Spawners. The difference is you wouldn't need to set up multiple pre-defined groups for achieving the same thing. That is, if your goal was to spawn a group of 3 bandits, with the chance of spawning a bandit leader.
1st Group:
Combatant 0: Bandit Thug
Combatant 1: Bandit Thug
Combatant 2: Bandit Thug
2nd Group:
Combatant 0: Bandit Thug
Combatant 1: Bandit Thug
Combatant 2: Bandit Leader
So rather than enabling "Spawn Random" to select between the two pre-defined groups, or defining variables, all the "randomisation" would be done within the editor.
When done within the editor it would reduce clutter when trying to define all the groups within the combatant spawners, give you more control with variables IE if you want to introduce a specific enemy late game within an easier group etc. Otherwise, as far as I can tell you will have a very long list of combatant groups to sort through.
Scenario 3:
Battle Component. Let's say you handle the combatant groups here. You could define requirements for each group but in my cases, I have "battle maps" were fights with multiple different factions can occur, stronger enemies being introduced depending on difficulty etc, it results in a very long list.
Closing:
It would basically automate all the manual steps you have to do to set up randomising groups and all defined within the editor and reduce the amount of clutter. I think a feature like this would lead to a lot of flexibility.