Wrofir

Oh you're right! Forgot that had equipment in it too!
Thanks :D Huge time saver

Wrofir

Hmm okay, what about this one.

A multi input/output node option. Where the input for the top input will cross over to the top output, so that i can use 1 common node that many others use, instead of copy and pasting it over and over.

gamingislove

@Wrofir
Interesting idea ... I'll look into it for Makinom 2/ORK 3, but I don't think that's really doable with the current system.

hellwalker

A dual timer on status effects would be neat.
For example if status effect is added to combatant and it's set to expire in two turns, but battle ends in 1.

For turns to translate into seconds when field mode is activated.

There would need to be also the definition of how many seconds each turn equals.

For example, 1 turn = 10 seconds. And depending on if NPC is in battle or field, the countdown switches between turns and seconds.

Malith

Hi GIL I have few suggestions for ORK 3.

01. A structure system for all different abilities, items, etc.. Current "type" structure system is great for managing but it's still getting messy when project grow larger.
02. Some debugging features. A gizmo system with indicators. Something similar to RustedGames Debugging tool for ORK2.
03. Also hope you will add some features to mecanim animations system.

slisy

Can I customize the help text of the editor?

gamingislove

@slisy
Only if you change them in the gameplay source code (ORKEditorHelp attributes that are added to the settings).

huulong

Not exactly a feature, but suggestions to improve starter workflow, that may involve code changes:

Provide a default setup to start testing battles very quickly, if possible out-of-the-box (esp. UI)

I know we're dealing with a deep, flexible framework, not a ready-made solution. However, I still need to be able to start testing battles very fast because:
- I'm currently doing research to see what tech I should use to make my RPG. I'm skipping the adventure part and diving right into the battle system which is my main concern (base system + flexibility to extend), and what the framework would make me gain a lot of time on. The earlier I can make a battle run, the earlier I can estimate if it's worth continuing with this framework.
- in terms of workflow, I prefer starting with a very basic, working system, then add things little by little.

Currently the setup is very long, or at least, the Game Tutorial series shows many steps without feedback on how our changes affect the gameplay and UI. That means we don't get to press Play we finish the whole setup. But I didn't need all the special abilities at first either, so I thought I'd just start a battle, observe empty menus and then fill them little by little. Instead, I got UI layout errors (generic null reference error not stating what I should fix), or nothing displayed at all.

Note: I was testing with New UI and realized I needed to follow the dedicated new UI tutorial in parallel. I switched to Legacy GUI which still didn't show the battle menu, but I will try again restarting the Battle Menu tutorial steps as some fields may have been cleared after changing mode. I still expect it to work with minimal setup, as it should at least show the default legacy GUI skin.

I totally understand I need a minimum of data like characters and basic commands to start a battle, or I will have nobody on the field and empty battle menus. Maybe there is not much default content because RPGs are very different from every other, some don't have a Defend command, etc. and I'm okay with filling them on the go. The problem is that most of the unset parts are GUI Boxes which apparently are needed to see anything (I'm not talking about extra info), and the error messages (or absence of) don't tell me what I need to setup. While I'd totally be fine with having an ugly UI to start with. Since I'm not sure which important steps I skipped, I have no choice but to go back and do the tutorial properly, step by step. But it also contains many details that seem optional (like precise GUI settings or particular abilities) which I could tune later.

To improve this I see a few ways:
a. The framework starts with a default setup that is very raw, but playable, like a base GUI Box with just an Attack command. Maybe you're avoiding this to avoid directing developers into a particular direction and encourage them to follow all the tutorial steps, which is fine. In which case:
b. Create a separate starter project with the "ugly defaults".
c. Improve error messages on missing references like GUI Layout to explain what's missing in data.

UPDATE: while writing this post I realized I could use the sample project provided on http://orkframework.com/tutorials/game/ as a starter project for (b). I still think it'd be nice to provide basic defaults to be able to test the game (esp. battle) incrementally, and point (c) still stands, but at least I'll be able to do my tech research more quickly.

Maybe you can still apply my suggestions so you can make an alternative, more iterative tutorial, with steps like this:
1. Add a battle trigger. Play and move your character into the trigger. Battle starts! But HUD doesn't appear...
2. Let's add GUI Boxes to the battle scene. First, the command box. Just add Attack for now. Play -> you see the command box with a single command.
etc.

Well, I'm starting to get into it now and I have the sample project, so it's becoming less important, but it may be useful to attract new customers (who are not necessarily beginners, just trying many things in a limited amount of time).

joeee19

I have a request about search.
I would like to have the ability to search the editor items from all tabs.
(Both in ORK3 and ORK2)

I've been using ORK for over five years now, but I still can't remember where I found the item I was looking for.

Every time I create a project, I have to re-read the tutorial from the beginning and search for it.

For example, this time I had to find the "StartEvent" editor setting.
I had a feeling it would be in the BaseSettings tab or Game Settings, but I couldn't find it, so I ended up searching all the tabs.
I don't use ORK's MainMenu screen because I prefer to let DoozyUI do the UI for my recent projects, so having the StartEvent setting in the MainMenu tab was not intuitive for me.

Translated with www.DeepL.com/Translator (free version)

huulong

I agree with @joeee19 but I'd like to focus on the search interface and how results are displayed on a single tab. Even when I know exactly in which tab the field should be, and I'm typing the correct search keywords, I sometimes cannot find an item because:
a - generally speaking, the matching words are not highlighted, whether they are section or field names
b - unrelated sections (and sometimes fields) are still displayed, albeit empty, and take room, making it harder to find the relevant result in the middle.
This is especially problematic when searching for a field in a section deep below. For instance, searching "prefab view settings" (the exact name of the last section) in Menus > Menu Settings will still show you all the other sections, including sub-sections like Default GUI Skins with *all* their settings although unrelated, until finally showing Prefab View Settings at the full bottom. There is an advantage in always showing sections to the user, but they shouldn't take that much space (you need to collapse some manually...) or there should be an ORK preference to completely hide the sections not matching search
c - even when you find the matching field, unless you're typing the actual value, not the field name, the value will be hidden. So you need to erase the search field so the value appears again. Problem is, at this point all the other irrelevant fields will show again, and the view will not auto-focus on the last field you clicked, so the relevant field will be pushed again to the bottom and you need to scroll to find it back. In other words, the search is only useful to identify the section in which the field was, which you must then find manually.

So my suggestions would be to tackle each point:
a - highlight matching strings
b - be more strict with search matching and hide unrelated sections/fields (add a preference to toggle that behavior for retrocompatibility if you want)
c - keep showing field values after search and/or allow user to "lock" view on a search result so they can still center view on it after clearing the search field

huulong

Another suggestion on the ORK Framework panel:
Preserve last view on Play, or restore it on Play end

Currently, when pressing Play in the editor, the ORK Framework panel, the top tab focus is preserved (e.g. Combatants) but group selection always revert to the first group (e.g. Factions even if you were focusing Classes). Finally, inside this group, the content is scrolled back to the top.

It would be nice to preserve the current view: Tab > Group > Scroll position on Play. Or at least restore that view (if it was not modified during Play) after Play ends. This would make iterating on values and playtesting much faster as I wouldn't have to reopen the correct group and scroll to the correct field after every Play.

RunawayDev

In ORK Editor window, it would save me a ton of time scrolling, if there was a button at the top to collapse all tabs. Right now you have to manually collapse each one (easily in the tens) and it doesn't save which you've collapsed if you have to close the editor to run the game.

Additionally, some kind of table of contents whose items I could click to jump to section would serve a similar time saving purpose. So I could just jump to Status Effect Settings instead of scrolling, for example.

I've made an example in red

gamingislove

@RunawayDev
There are the small Open and Close buttons beside the search bar on top of the settings to fold and unfold all at once - I think that's been available since the start of ORK 2 :)

ORK 3's new editor has a lot of new features in that regard.

TextusGames

@gamingislove

Why are where so many unnessary ui elements like emty foldouts shown than you search for variable in editor. They are not needed at all. It takes much time to scroll and search for right variable. The amount of settings is very big and disability to reliably and fast search the right one can potentially push away some new commers.

I would prefer that only sections with variables with matching search term were shown withot ui clutter.

Is it planned to improve search ability in that direction? or is it difficult to implement?

TextusGames

@gamingislove

Thank you for option to move schemantics properties to right or left border of the screen.

Same option however should be presented for formulas too.