Reading GUI button captions

[JasonC]

So I have these top buttons from various mods on my screen:



I did a little test to try and read their captions, and found that their captions weren't strings. So I grabbed them with:

Code: Select all

function print_top_button_captions (player) 

	local message = ""
	
	for _,name in pairs(player.gui.top.children_names) do	
		local child = player.gui.top[name]
		message = message .. serpent.dump(child.caption) .. "\n"
	end
	
	game.write_file("mod-panel/test.txt", message)

end

And it produced:

Code: Select all

do local _={[1]="main-button"};return _;end
do local _="function: 0000000037D10730";return _;end
do local _={[1]="toy-box-button-collapsed-text"};return _;end
do local _="Mod Panel";return _;end

So there's 2 localization ID arrays, a non-localized string, and a function.

Now the documentation for caption makes the following "promise":

caption : string [Read-Write]: The text displayed on the element. ... For other elements, like buttons or labels, this is the content.

How can I resolve those returned items to the caption strings or otherwise get the text displayed on the element?

[Choumiko]

How can I resolve those returned items to the caption strings or otherwise get the text displayed on the element?

If the caption is localised the best you can get are the localiisation tables. As for Trains+ it's a flow element at the top, which contains the Trains+ button (and sometimes the "Player" button.

Getting the displayed text (for localized captions) is not possible since it would/could break determinism depending on what you do with it

[JasonC]

Getting the displayed text (for localized captions) is not possible since it would/could break determinism depending on what you do with it

Well, it's not possible because it's not in the API (presumably, although my question is still open).

If by "determism" you mean "assumptions that mods make about the captions of their own buttons", reading a value would never break that. Only writing it would carry that risk. And captions can currently be modified, despite potential breaking of assumptions - so that's not a reason for things not being possible. It's just a reason you shouldn't do certain things with things that are possible.

If you are referring to "assumptions that mods make about the captions of other mods buttons", those would be incorrect assumptions to make, and it doesn't really have much to do with whether getting the captions should / shouldn't be possible -- that risk is present with just about everything. That's not really a reason for not providing a way to get displayed text, that's just a reason to fix that bug in a module. Any problems caused by mod A reading the caption of mod B's button is a logic error with mod A.

As far as writing captions of other mods goes, I would argue that a mod with a properly implemented GUI shouldn't be reading the captions of its buttons to track its own state, especially if that property is documented as writable by other mods (speaking of determinism). There is always a way to track state that is a more concrete and accurate reflection of what actions you're going to take on that state. Any problems caused by mod A writing the caption of mod B's button is more of a design issue with mod B.

In both cases, the possibility of these problems existing isn't a case for not providing the capability (if everything in the API that had this potential were removed there'd be nothing left). Anyways, I'm only asking about reading.

And more specifically, either the documentation is inaccurate or the observed behavior is incorrect. The result of reading caption is neither a "string" (even the train button flow, while the docs don't promise any meaningful text, they still promise a string, not a function) nor "the text displayed on the element".

[ratchetfreak]

Getting the displayed text (for localized captions) is not possible since it would/could break determinism depending on what you do with it

Well, it's not possible because it's not in the API (presumably, although my question is still open).

If by "determism" you mean "assumptions that mods make about the captions of their own buttons", reading a value would never break that. Only writing it would carry that risk. And captions can currently be modified, despite potential breaking of assumptions - so that's not a reason for things not being possible. It's just a reason you shouldn't do certain things with things that are possible.

If you are referring to "assumptions that mods make about the captions of other mods buttons", those would be incorrect assumptions to make, and it doesn't really have much to do with whether getting the captions should / shouldn't be possible -- that risk is present with just about everything. That's not really a reason for not providing a way to get displayed text, that's just a reason to fix that bug in a module. Any problems caused by mod A reading the caption of mod B's button is a logic error with mod A.

As far as writing captions of other mods goes, I would argue that a mod with a properly implemented GUI shouldn't be reading the captions of its buttons to track its own state, especially if that property is documented as writable by other mods (speaking of determinism). There is always a way to track state that is a more concrete and accurate reflection of what actions you're going to take on that state. Any problems caused by mod A writing the caption of mod B's button is more of a design issue with mod B.

In both cases, the possibility of these problems existing isn't a case for not providing the capability (if everything in the API that had this potential were removed there'd be nothing left). Anyways, I'm only asking about reading.

And more specifically, either the documentation is inaccurate or the observed behavior is incorrect. The result of reading caption is neither a "string" (even the train button flow, while the docs don't promise any meaningful text, they still promise a string, not a function) nor "the text displayed on the element".

Determinism is about in a multiplayer setting where each peer is making assumptions about what each player sees.

All mod code runs on all peers for all players and any difference between them is an immediate desync.

[slindenau]

A better question is why. What are you trying to do?
Check which mods have buttons on the top?

The API is perfectly clear; "For other elements, like buttons or labels, this is the content."
You're getting the content of the button. What that is depends on the mod that created the button, as you can see from your output.