Any Dialog Box/Textbox UI widgets

[GamerSg]

Im trying to achieve the following scenario

Based on a defined condition/trigger
-Pause the Game
-Ask the player a qsn through a dialog box
-Allow the user to answer that question by typing in his results

I believe the condition/trigger and pausing should be trivial to do through Lua. I just wanted to know if Spring has any built in UI components accessible via Lua or if anyone had made some widgets already.

[Niobium]

Afaik there aren't any, processing keyboard input isn't a trivial task (think of handling backspace / arrow keys / etc).

One thing you could do is use springs standard chat box with some sort of command like '/answer <their answer goes here>', which your widget would then trap.

[zwzsg]

I've coded widgets for yes/no questions. I don't know of any widget, or any Spring Lua UI framework (chili/red/etc...) that implements a textbox. Probably because a proper text box would be a rather complicated component to code. However, you're not the only one to need textbox in a widget, so I'm sure that if you wrote this component, it would be reused. That, or, if you wait enough, someone else will eventually make one.

[hoijui]

the problem is, you can not make one text-box to be reused everywhere, cause there are so many UI frameworks. of course you could make that, but it would not fit with other UI stuff, and mod devs would hate it for that, and not integrate it. this is also a problem for AIs, and i guess widget devs in general. removing all UI frameworks except one, or unifying them with some sort of abstract interface description language is... i guess practically not possible. to make a new framework, where "all" mod-devs have a say in the design, and which of course had to be very flexible, could solve the problem, but that is also impossible in practice, as most mod devs do not see a problem with what we have now, as they have a framework that works for them, so why should they do this big effort. maybe extending one of the current frameworks till everyone is happy with it? i heard that chilli is the most advanced, but is also not independent of CA stuff that other mod devs would likely not want to use.

[Licho]

Well chili is used in S44 and Evo RTS and Cursed too. There was even attempt at input box by lurker.
Afaik never finished.

[Masure]

Dig into IceUI (an extensible gui framework). This thread mentioned a textbox input field. Not the same goal as yours but deserves a look.

[Argh]

For a textbox, you could just record all local keys to an array, then when input happens, use the contents of the array to spit it back out as output. Same goes for showing it in the UI context; unpack the array each renderframe locally, and voila, you've got your string to render.

Why do you want a textbox, though? Planning on killing a grue with Spring?

[GamerSg]

My background is in writing game engines and i guess i could agree with hoijui that implementing certain types of UI widgets cleanly requires core engine support for things like current mouse/keyboard focus. However i am very new to the Spring Engine and do not have much knowledge of it's inner workings, which is why i posted this question.

If the engine does not support redirection of mouse/keyboard input to selective handlers, it will have to be implemented in a very hackish way, probably how Argh is suggesting. Otherwise we could have the problem of shortcut keys for gameplay/other widgets being activated while typing into the textbox.

But if you think of it, the current chat activated by pressing Enter seems to be able to achieve all this. When you hit Enter, all keyboard input is directed to the chatbox and does not affect other widgets/UIs. I suppose this functionality is coded in C++ in the engine itself and is only available for the chatbox?

As to why i need this, im actually trying to use Spring at work where we aim to use it as a game to aid in analysing how different people think and react in various situations encountered during the game. However my timeframe is rather tight and i would prefer not to engage in writing such functionality myself especially given my very limited knowledge of the engine.

[lurker]

input box

More of a full text editor box, and it works fine on the version I made it with. Let me grab a recent chili this weekend and see what it takes to update.

[zwzsg]

You make a good point, Hoijui. So in reality, it would probably go differently: One framework would implement a text box. The other framework would be jealous of that new feature, and quickly port or rewrite it. The frameworks who don't would be showing sign of being unmainted and featurelacking, so would slowly get disfavored then forgotten.

If the engine does not support redirection of mouse/keyboard input to selective handlers

Hmm, there sorta is. Basically, the first widget to "return true" to a keypress "eat it", making it unavailable for all other widget. I mean, it goes like that:
- You press a key
- Spring tells every widget one by one that this key was pressed
- Every widget in turn says "yes I'm handling it" or "no pass it along"
- Whenever a widget says he's handling it, then Spring stop passing it to other widget down the widget list
- You can choose the order widgets are ordered with the "layer" field in their GetInfo.

[aegis]

however the UI framework in general should probably handle which widget is focused, not the widget itself...

[zwzsg]

engine != default widget handler in /base/ != custom UI framework inside a mod != widget

I like that the default widget handler does not force me to have only one widget focused at the time, make it possible to have shortcuts. I'd hate if my commands were trapped by a windows that doesn't even understand them just because that window had been focused.

But if you think it would be good to have focus management inside your own UI framework, sure, why not. Eh, come to think of it, my own pseudo framework, the one that I use in my SP menus, does manage focus.

But Spring is mainly a Real Time Stratey engine, not a form engine. So what we have by default, the IsAbove callin and the return true/false in KeyPress/MousePress/MouseWheel, is better suited than focus. And anyway, if you want to display "forms" with multiple "controls", or even a simple menu, you already need to write or borrow your own mod-side UI framework, which I'm sure will come with focus.

[aegis]

focusing might be all well and good with per-widget implementation, but things like *removing* focus could be a problem if the widgets weren't working together.

[Argh]

Lol, btw, derailing isn't helping this guy one bit.

As to why i need this, im actually trying to use Spring at work where we aim to use it as a game to aid in analysing how different people think and react in various situations encountered during the game. However my timeframe is rather tight and i would prefer not to engage in writing such functionality myself especially given my very limited knowledge of the engine.

OK.

Probably the best way to implement that "on the cheap" is to intercept standard messages.

AddConsoleLine() Grabs the current line in the console window, i.e., when people hit Enter to talk to one another. If you need to capture special messages people type, just have them put a special character at the start, like "&", and then store the string in a variable. Then in some further action you can just check the string via string.find(specialString, "&") to then perform further processing. If you're not going to write any serious UI, then that could be in function widget:Update(), like this:

Code: Select all

local specialString

function widget:AddConsoleLine(msg,priority)
  if string.find(msg, "&") then
    specialString = msg
  end
end

function widget:Update()
  if string.find(specialString, "some special command we're using") then
    --> Do Stuff
  specialString = nil --Clear the specialString so it won't happen 100 times a second
  end
end

That chat is stored in the Infolog btw, also (if you need it for anything beyond in-game work).

This is a very rough-and-ready solution, but it would be very fast, implementation-wise

[GamerSg]

Thanks for the replies everyone, ill try to go with the solution Argh has suggested.