Proposed helper.get_text_input

[SigurdFireDragon]

I propose that the following would be added after helper.get_user_choice, in the helper.lua file:

Code: Select all

--! Displays a WML text input message box with attributes from table @attr
--! with optional table @options containing optional label, max_length, and text key/value pairs.
--! @returns the entered text.
function helper.get_text_input(attr, options)
	options = options or {}
	local msg = {}
	for k,v in pairs(attr) do
		msg[k] = attr[k]
	end
	local ti = {}
	for k,v in pairs(options) do
		ti[k] = options[k]
	end
	ti["variable"]="LUA_text_input"
	table.insert(msg, { "text_input", ti })
	wesnoth.fire("message", msg)
	local result = wesnoth.get_variable("LUA_text_input")
	wesnoth.set_variable("LUA_text_input")
	return result
end

Any thoughts on the form, syntax, or implementation of the above?

If approved, I can submit a patch & edit the wiki as appropriate.

[Elvish_Hunter]

Any thoughts on the form, syntax, or implementation of the above?

You can try replacing wesnoth.fire with wesnoth.wml_actions.message; you may also need to use wesnoth.synchronize_choice to avoid an out-of-sync in multiplayer.
Other than that, I don't know if this may be useful in core or not, so I'd like to hear the other developers' opinion. In the worst case, I'll add it to the Wesnoth Lua Pack.

[SigurdFireDragon]

You can try replacing wesnoth.fire with wesnoth.wml_actions.message

Thanks, hadn't realized that wesnoth.wml_actions is the best way as opposed to wesnoth.fire which is the older way.

As I based this off of helper.get_user_choice, maybe that means that it should be updated (along with some others in helper that use wesnoth.fire) but the wiki mentions some operational differences between wesnoth.fire and wesnoth.wml_action.

Other than that, I don't know if this may be useful in core or not,

I originally wrote it cause I saw a conceptional need (ie, there's a way to do [message] with [options], why not cover [text_input] as well?)
Is that sufficent reason here?

As for wesnoth.synchronize_choice(function()), maybe I'm reading it wrong but wouldn't it be used like this with helper.get_user_choice?

Code: Select all

local result = wesnoth.synchronize_choice(helper.get_user_choice({speaker="narrator", message=msg }, { "option 1", "option 2" }))

and thus shouldn't be in the code of a helper, and left for the umc author to add?

[Elvish_Hunter]

I originally wrote it cause I saw a conceptional need (ie, there's a way to do [message] with [options], why not cover [text_input] as well?)
Is that sufficent reason here?

The problem is that helper.get_user_choice seems to be almost unused, except in Settlers of Wesnoth. To make things worse, I found this post by silene, that seems to indicate that helper.get_user_choice may cause OOS errors.
At this point, I cannot commit it, sorry. But not everything is lost: it can enter in the Wesnoth Lua Pack without problems.
So, there are two options:

• I or Anonymissimus commit it in the WLP
• you commit it in the WLP by yourself. This will require you to use SVN, and to ask Espreon for commit access on Wesnoth-UMC-Dev (if you already did both things, even better)

What do you prefer?

[SigurdFireDragon]

I'll take option #2, it's time I got an account there.

[Crab]

The OOS that silene was talking about in that post is caused by improper usage - the contents of synchronized block are only calculated on one PC, so if you advance the RNG inside, it would only advance on one client, leading to OOS.

[SigurdFireDragon]

...you commit it in the WLP by yourself...

Committed @ UMC-Dev Repository r11702

The problem is that helper.get_user_choice seems to be almost unused, except in Settlers of Wesnoth.

I was grateful that it was there, it saved me the trouble of figuring out how to write it, and I made heavy use of a slight variation of it when I converted my one add-on to be almost all lua.