GUI element functionality to filter/sort by localised name

[sparr]

This idea is meant to address viewtopic.php?f=28&t=32611 and related concerns. I currently find myself wanting to filter a list of technologies based on some user-entered search parameters, including name. I can't filter on localised name, for all the reasons already discussed in that thread.

What I propose is that the container GUI elements could accept some parameters that control the visibility or order of their children, executed at display time and not otherwise represented in game state.

Old way, statefully sorts on prototype name:

Code: Select all

-- make parent container
local flow = player.gui.top.add{type = "flow"}
-- get list of item names
local names = {}
local n=0
for name,_ in pairs(pairs(game.item_protytpes)) do
  n=n+1
  names[n]=name
end
names = table.sort(names)
-- add item buttons to parent in sorted order
for name in names do
  flow.add{type="button",caption=game.item_protytpes[name].localised_name}
end

Proposed way, locally/ephemerally sorts on localised name:

Code: Select all

-- make parent container, tell it how to sort children
local flow = player.gui.top.add{type = "flow", child_sort_attribute = "caption"}
-- add item buttons to parent
for _, prototype in pairs(game.item_protytpes) do
  flow.add{type="button",caption=prototype.localised_name}
end

Old way, statefully filters out some items based on prototype name:

Code: Select all

-- make parent container
local flow = player.gui.top.add{type = "flow"}
-- conditionally add item buttons to parent
for name, prototype in pairs(game.item_protytpes) do
  if string.find(name, "basic", 1, true) then
    flow.add{type="button",caption=prototype.localised_name}
  end
end

Proposed way, locally/ephemerally filters out some items based on localised name:

Code: Select all

-- make parent container, tell it which children to show
local flow = player.gui.top.add{type = "flow", child_filter_attribute = "caption", child_filter_regex = "basic"}
-- add item buttons to parent
for _, prototype in pairs(game.item_protytpes) do
  flow.add{type="button",caption=prototype.localised_name}
end

[sparr]

The filter and sort criteria could be callback functions instead of a few hard-coded options in the engine. That would require exposing the lookup functions that the devs have denied us in the past, but maybe it could be done in such a way that calling them outside of this specific context would still be an error, but they could be called in this context.

[eradicator]

The problem is not the filter function. The problem is that the "container" gui is part of the game state. And as such can not have a state that is locale-dependant because locales are currently only known to the instance (player) that runs them. So this does not solve the problem.

Here's a more recent thread: viewtopic.php?f=28&t=57945

[sparr]

What I am proposing is that the stored state of the GUI would be the entire list of *possible* child elements, in some order, just like the stored state of a caption is a LocalisedString table. Then the rendering engine itself would perform the filtering at display time, without changing game state, instead of currently us having to change game state by deleting/moving gui elements ourselves.

[mickael9]

I agree with sparr, this should be possible. Also see my older proposal here: viewtopic.php?f=28&t=48164
Callbacks might be possible if you pass them as string instead of function object so they can run in their own context.

[sparr]

A callback could also work if the devs give us a "localize_string()" function like previous requests have asked for, BUT that function throws an error if it's called from anywhere except from a callback passed to a gui element, and those callbacks throw an error if they try to affect global state in any way.

[eradicator]

I'm certainly not disagreeing that i want sortable gui elements. But implementing it via callbacks seems...unrealistic? As of now factorio has no callback functionality anywhere and trying to build bulkheads against all the things that mods could do wrong is a lot of error-prone work. And in the end you get a sort function that only works on gui elements. I think the "simple" approach of forcing all locales to be deterministic is much more realistic. And works for all of the mod-state, not just gui elements.

[sparr]

The devs have already repeatedly rejected the "simple" approach. Good luck with that :/

[eradicator]

The devs have already repeatedly rejected the "simple" approach. Good luck with that :/

Sounds like you didn't read the thread i initially linked to. Also in that case it would be rather strange if they instead chose to implement an even more complex mechanism :P.

[sparr]

The devs haven't rejected previous suggestions because of complexity. They have rejected them because they want to keep support for un-synced locale files.

[eradicator]

viewtopic.php?p=344301#p344301

[sparr]

viewtopic.php?p=344301#p344803

Same thread, a few posts down, where the same dev explains why that idea is rejected

[eradicator]

viewtopic.php?p=344301#p344803
Same thread, a few posts down, where the same dev explains why that idea is rejected

Except that's not a rejection. That's just an explanation of the main hurdle. If you read closely you'll notice it doesn't even contain the usual determinism argument. Not sure what you're trying to argument over. I already said i'm not against any improvement on that front.

[sparr]

Them not doing it for years is the rejection. Everything else is explanation of that implicit rejection.