Regarding key presses in an action game. #13
-
|
I've been having some trouble with the UI so far, so I have a few questions relating to that.
The scrolling is super fast and imprecise too, which works fine for the options menus, but for the text selection it makes it really easy to skip over text entries entirely if there's more than five or so of them. I can't expect to edit that in options on my end, but it does bear mentioning. I get that this seems designed more for AI auto-translations than it is for humans to tinker with game text directly, but it's a little painful to try to use it for anything manual at the moment, unless I've missed something? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Hello, Sorry for the delay, I'm in vacation since the last week and I just see your message.
Unfortunately no, and it's a Unity limitation rather than something I can easily work around. Most Unity games read inputs through Input.GetKey(), which returns true regardless of which UI element has focus. A mod that "consumes" a key would have to globally patch the game's input system, which would break any game that uses Input.GetKey directly in custom ways (which is most of them).
The panel itself IS resizable — grab the bottom edge or corner of the inspector window and drag. If that doesn't seem to do anything, there's a known constraint: the panel's max height is currently capped by the measured content height, so the scrollable text list doesn't claim that "extra" empty space. I'll fix that — the text list should grow to fill the available space when you enlarge the window. Tracking this as a bug. (I'll add it to my list)
Confirmed bug — if the title bar goes above the screen edge, you lose the drag handle. Two ways to recover right now:
The label is misleading, sorry. It does NOT capture from the Element Inspector — it works automatically as you play. Concretely:
Fair point — the scroll sensitivity is currently hard-coded and tuned for short option lists, which makes long lists overshoot. I'll either lower it for the text list specifically or add a sensitivity setting. Thanks for flagging it.
You're not wrong — the UI was built around the AI/online sync workflow first, and the manual editing path has rough edges. To edit the keys manually you have to do it on the website in the edit translation view (in "my translations") or directly on the translations.json file. I was thinking about adding an editor with captured keys dictionary in the UGT game UI, but the problem with keyboard focus will be the same as you mentioned before. The 3 issues above (resize, stuck panel, scroll precision) are all real and I'll prioritize them since they make the manual workflow much more painful than it needs to be. Keep the feedback coming, this kind of report is exactly what helps me prioritize ! |
Beta Was this translation helpful? Give feedback.
Hello,
Sorry for the delay, I'm in vacation since the last week and I just see your message.
Unfortunately no, and it's a Unity limitation rather than something I can easily work around. Most Unity games read inputs through Input.GetKey(), which returns true regardless of which UI element has focus. A mod that "consumes" a key would have to globally patch the game's input system, which would break any game that uses Input.GetKey directly in custom ways (which is most of them).
The panel itself IS resizable — grab the bottom edge or corner of the inspector window and drag. If that doesn'…