Controls - enhancements/bugs

Talk about the mods or features you'd like to see in Daggerfall Unity. Give mod creators some ideas!
Mike
Posts: 162
Joined: Sun Feb 19, 2017 6:49 pm

Re: [CONTROLS] Control enhancements/bugs

Post by Mike » Thu May 17, 2018 2:01 am

OK, thanks for the feedback! And I'll just make one more plug for that menu toggle feature request from my first post in this topic before I stop spamming the forum for a while.

As I've said many times over the past few months, I'm extremely hyped for the future of DFU (both the base game and mods) - I really appreciate all your work, as well as the work of the other devs and modders.

User avatar
Interkarma
Posts: 3340
Joined: Sun Mar 22, 2015 1:51 am

Re: [CONTROLS] Control enhancements/bugs

Post by Interkarma » Thu May 17, 2018 2:42 am

Thank you for the kind words. :)

I've made a fix for this now that should resolve keybind issue from next round of builds. When you come back to Daggerfall Unity, I'd recommend deleting the old keybinds file and setting up again from UI. This ensures any legacy multi-binds are removed from the settings file.

I will consider adding toggle behaviour for selected UIs. This is a deeper problem than you might realise to be consistent across all interfaces. But I can very likely add to the main interfaces (e.g. character sheet, inventory, rest, log book) without too many troubles. The UIs which end up deeply nested or have multi-level modal popups (e.g. travel map) might be a different story however.

There's no ETA on when I'll get to this, but I'll work through it later when I can.

Mike
Posts: 162
Joined: Sun Feb 19, 2017 6:49 pm

Re: [CONTROLS] Control enhancements/bugs

Post by Mike » Thu May 17, 2018 2:49 am

That was quick - I'll try out the keybinds UI again (after deleting my old files) when the new builds come out. And for the toggles, I understand it's low priority with everything else going on (teleport spell a.k.a. mark/recall = awesome), but I would think the much more frequently used screens that could especially benefit from toggle functionality are the Character Sheet, Inventory, Rest, Logbook, and Automap screens (as opposed to the Transport and Travel Map screens), so maybe it will work out OK when you get to it.

Looking forward to more effects being added - also appreciate the frequent interesting Twitter updates!

User avatar
Nystul
Posts: 1126
Joined: Mon Mar 23, 2015 8:31 am

Re: [CONTROLS] Control enhancements/bugs

Post by Nystul » Thu May 17, 2018 11:08 pm

Interkarma wrote:
Thu May 17, 2018 2:42 am
I will consider adding toggle behaviour for selected UIs. This is a deeper problem than you might realise to be consistent across all interfaces. But I can very likely add to the main interfaces (e.g. character sheet, inventory, rest, log book) without too many troubles. The UIs which end up deeply nested or have multi-level modal popups (e.g. travel map) might be a different story however.
maybe it would be easier to make each ui window responsible to manage "close"-behaviour by itself, like automap does. It just closes on key "m" (I have to make this adapt to current hotkey - but this is a simple fix I think). no need to make a generic solution at ui framework level imho, since not all ui windows need to have this behaviour ;)

if you want me to implement this for a given list of ui windows I will work through the list, just let me know

User avatar
Interkarma
Posts: 3340
Joined: Sun Mar 22, 2015 1:51 am

Re: [CONTROLS] Control enhancements/bugs

Post by Interkarma » Thu May 17, 2018 11:58 pm

That is exactly how I was going to handle it Nystul. Just let each window close when the same keybind used to open it is pressed, and decide when that is and is not appropriate.

But (and this is important) there needs to be some intelligence in there as well. For example, if player has spellbook bound to B key and they start renaming a spell to "Big Kaboom", then pressing the B key should not toggle the window closed.

Likewise for multilayered UIs (like Rest). Should pressing the R key close the UI only the first stage of dialog, or when player has an input message box open to enter a time value? If the latter is decided, then it becomes necessary for the MessageBox class to know which keys will and will not close itself based on which parent dialog has it open. Then you need to handle scraping back variable levels of window stack rather than let each modal window close itself as designed, which can be error-prone.

Like anything, it's much easier to ask for these features than it is to actually implement them. And I have no plans to allow myself to become distracted by it right now. We have much more important things to do. Gameplay features still have top billing right now.

Mike
Posts: 162
Joined: Sun Feb 19, 2017 6:49 pm

Re: [CONTROLS] Control enhancements/bugs

Post by Mike » Fri May 18, 2018 1:08 am

Understood - I'm just in the peanut gallery here throwing out ideas with no expert grasp on the details. But I hope something can get worked out down the road, even if it's a long way down, if there's any interest. As already seen in DFU development, a lot is possible. And again, the menus that I think would most frequently benefit from the toggle functionality (Inventory/Character Sheet/Automap etc.) don't have the issues you've raised in any case, so I'll stay optimistic!

User avatar
Nystul
Posts: 1126
Joined: Mon Mar 23, 2015 8:31 am

Re: [CONTROLS] Control enhancements/bugs

Post by Nystul » Fri May 18, 2018 7:46 am

Interkarma wrote:
Thu May 17, 2018 11:58 pm
But (and this is important) there needs to be some intelligence in there as well. For example, if player has spellbook bound to B key and they start renaming a spell to "Big Kaboom", then pressing the B key should not toggle the window closed.
once more you thought this through much more than me ;)
Interkarma wrote:
Thu May 17, 2018 11:58 pm
Likewise for multilayered UIs (like Rest). Should pressing the R key close the UI only the first stage of dialog, or when player has an input message box open to enter a time value? If the latter is decided, then it becomes necessary for the MessageBox class to know which keys will and will not close itself based on which parent dialog has it open. Then you need to handle scraping back variable levels of window stack rather than let each modal window close itself as designed, which can be error-prone.
I would go for the easiest variant to start with: just close the first ("outer") opening window, have open/close key have no effect on input message boxes,
for world map I would try to make "inner" windows return to previous where there is no key conflict (not when in input message boxes but when in regional maps) ;)

If I find some time I will try and see if it works

User avatar
Interkarma
Posts: 3340
Joined: Sun Mar 22, 2015 1:51 am

Re: [CONTROLS] Control enhancements/bugs

Post by Interkarma » Fri May 18, 2018 7:58 am

Thanks Nystul! If you go for the easier option, it should be simple just to sample for appropriate keybind in the window's Update() loop and CloseWindow() when matching key is inputted. It shouldn't be any different from just hitting Escape at that point. You should also be OK with spellbook in simple approach, as the name edit is a popup window.

User avatar
Nystul
Posts: 1126
Joined: Mon Mar 23, 2015 8:31 am

Re: [CONTROLS] Control enhancements/bugs

Post by Nystul » Fri May 18, 2018 8:40 am

I am already implementing it and yes it is easy to do.

automap, exterior automap, character sheet, log book (quest journal) and travel map done (decided to also close when in regional views)

status info popup can now be proceeded with global status hotkey
this means using status hotkey first messagebox will close and health messagebox will be shown. pressing hotkey again will close,
same for enter and numpad enter key
escape key still immediately closes status info popup

btw, input messages boxes are unaffected - did not have to change anything ;)

Mike
Posts: 162
Joined: Sun Feb 19, 2017 6:49 pm

Re: [CONTROLS] Control enhancements/bugs

Post by Mike » Fri May 18, 2018 12:02 pm

Nystul, thanks for jumping in and taking this on! This will be a great quality-of-life improvement.

Post Reply