Nory

Heyhey,

I'm trying to implement cosmetic variations of individual Combatants. For Portraits and Prefab, I'm using conditionals driven by variables. But I couldn't find anything comparable for the Icon Sprite.

In other words: Is there a way to have conditional Icons on Combatants?

Acissathar

One way (assuming these are in HUDs) would be to create a Portrait type for each variation and assign those to the combatants.

Then in your HUD, you can create a portrait object for each portrait type (so for example, assume you want to show "Happy" portrait but have 3 skins so you'd have "HappyNinja" "HappyPirate" "HappyTaxAccountant"). Then on each of these portrait parents, put a HUD Condition component using the same conditions as you do the conditional prefabs and it'll automatically turn them on/off for you based on those conditions.

(You can heavily abuse HUD Conditions for other things outside of this too, it'll turn off all child objects, I use this to show different backgrounds, etc. based on a single set of conditions)

Nory

That reads like a super cool solution. There's a semi-related HUD question I have and would love to follow this up with, afterwards.

The Icons themselves are not used in HUDs, but in the image object of buttons for the Battle Menu et al. (bottom right):



For these I'm using the Combatant's Prefab as an Icon Sprite. I'm guessing ORK pulls the image from the prefab thumbnail?

gamingislove

No conditional icons available - since you already use conditional prefabs and portraits, you can just use a portrait instead of the icons and use that in your HUDs.

For buttons, they can also use HUD content to show additional stuff like a portrait. E.g. your battle menu's Content Layout settings can add that via the HUD Type setting. Though, for buttons representing combatants (e.g. in targeting menu), this is handled by the Combatant Choice Layout :)

Nory

Oh, I didn't know you could put HUDs on buttons! That opens a lot of doors for future stuff! It took me a bit, but I got it working now. So thank both of you very much for your help!

Which brings me to my other question:
I have an HUD that displays minimal information about the self target. The HUD itself can be toggled using Input Keys bound to Rewired actions to show extended information including status effects from passive abilities:


Additional information is displayed through a Tooltip HUD, but only for players using the mouse. I'd like for this to also work on controller. As an example, BG3 has a separate "inspect" screen with selectables and corresponding tooltips:



If I wanted to replicate something like this, would this need to be a menu screen with HUD elements (like with the portraits) or is there a way to have for example a list of status effects have selectable elements so they can be navigated through and thus display a tooltip, too?

gamingislove

Well ... depends on what should be available for selection and tooltip display.
The different menu screen parts can be used show all kind of information, either specialized on abilities, inventory, etc. or a combined one via the Multi Content menu part.

An alternative could be using a schematic and displaying them via a Selected Data Choice node (dialogue). You'll first have to store all the content you want to display into selected data, e.g. via Select Ability or Select Equipment nodes.

Nory

Makes sense! I'll try to tinker with menu screens first and see how that goes.

Speaking of those, I've been trying to implement an option menu with submenus both for the field menu and start menu. For the field parts, it works as it should:


But for the Start Menu, I couldn't find a dedicated "Menu Screen" Option Type, so I triggered it through a schematic instead:


Here the Options Overview Menu opens without a problem, too. But once I try to navigate to an option-related submenu, I get the following error:

Could this be because the menu screen is opened via a schematic?

Oh and, bonus questions:
I'd like to call menu screens via keys while in the battle menu and during conversations. But from what I've read here, menu screens can only be called if the player control isn't blocked. Is there a way to get around this?

gamingislove

Menu screens are only intended for in-game use (i.e. having a player, etc.), the start menu has it's own Option type to display options.

You can call menu screens via schematics used by global machines (Base/Control > Global Machines), which can be started via input keys as well :)

Nory

I see! Then I'll stick with the native Option menu for the starting screen. I'm guessing there's no way to turn this one into a menu with submenus? Or alternatively, put something like unselectable separators or at least more distance between specific buttons?

At the moment, I have audio volumes right next to gameplay and debug options (last two entries):


As for calling menu screens: That's great! I'll give Global Machines a shot then and get back if I run into any trouble.

Thank you very much for your help, as always.

gamingislove

No, an alternative would be using a Value Option Dialogue node in a schematic and calling the schematic in start menu and menu screen to open that option dialogue ...

There are plans for better option handling, but no idea when that'll come :)

Nory

Okay, then I'll give that a try and see how far I get.

Last question: I'm using the 2D "Z-Rotation to Animator Parameter" thing to drive combatant animations in a lot of different places. I absolutely love the implementation you did!

Though there's a couple of hiccups with 3rd party stuff here and there, so I wanted to take a deeper look at it. As far as I understand, it's driven by the Simple Move Component and the Combatant Component, right? Is there anything else at play – apart from the Animator Component?

gamingislove

Well, that simply forwards the Z-axis rotation of the combatant as a parameter, so whatever changes that rotation will have an impact on it.

E.g. for the player, the player controls moving and rotating the game object, or movement components doing the same thing for other combatants. Also, schematics using movement/rotation nodes, other scripts changing rotation, physics, etc.