You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main reason this one is trickier to implement properly is because the screen doesn't actually maintain its own list of manager orders - they are only stored in world.manager_orders. The screen just maintains its cursor position, mode, etc.
There are some other search implementations that search over global data that isn't part of the current screen (e.g. the k search, aka look_menu_search), so it's possible, but tricky to do right in this case because the data persists well beyond the lifetime of the screen (in contrast, the data used by the k view, while global, is only really valid for a short duration). It's further complicated by the fact that orders can refer to each other, so if you filter out a dependency of another order and open it with Enter, you would get something that looks like this:
There should be an order name above "must". There might be other cases where DF crashes due to entries being removed (even temporarily) from world.manager_orders to enable searching.
Short version: it might be possible, but it's more complicated to do safely.
At a minimum, you'd have to ensure to not remove any order that is dependent on the orders that match the search.
Also, you'd have to restore the full list when you go into the detail screen because the user might choose to create an order dependency while in the detail screen, and that needs the full list available. This may cause problems since the detail screen uses an index into the global order list. I suppose you could restore the full list only if the user asks to create a order dependency, but... ugh.
an alternative might be to just highlight orders that match a search, and provide a hotkey (or override the behavior of the arrow keys) to jump the cursor to the next highlighted match. this would be a different look-and-feel from the other search interfaces, but it would avoid all the rather scary pitfalls of dynamically modifying the global list. the new behavior won't be completely foreign, though, since almost all text searches work this way in other applications.
widgets:
search text
index of current selected match and total number of matches, e.g. "3 / 15"
hotkey labels: <key>: next match <key>: prev match
we might want to keep the standard behavior for the arrow keys and pgup/pgdn so players can still interact with unmatched orders. maybe next/prev match could be shift up/shift down or left/right.
Activity
lethosor commentedon Jul 26, 2021
The main reason this one is trickier to implement properly is because the screen doesn't actually maintain its own list of manager orders - they are only stored in
world.manager_orders. The screen just maintains its cursor position, mode, etc.There are some other search implementations that search over global data that isn't part of the current screen (e.g. the
ksearch, akalook_menu_search), so it's possible, but tricky to do right in this case because the data persists well beyond the lifetime of the screen (in contrast, the data used by thekview, while global, is only really valid for a short duration). It's further complicated by the fact that orders can refer to each other, so if you filter out a dependency of another order and open it withEnter, you would get something that looks like this:There should be an order name above "must". There might be other cases where DF crashes due to entries being removed (even temporarily) from
world.manager_ordersto enable searching.Short version: it might be possible, but it's more complicated to do safely.
ab9rf commentedon Aug 11, 2021
At a minimum, you'd have to ensure to not remove any order that is dependent on the orders that match the search.
Also, you'd have to restore the full list when you go into the detail screen because the user might choose to create an order dependency while in the detail screen, and that needs the full list available. This may cause problems since the detail screen uses an index into the global order list. I suppose you could restore the full list only if the user asks to create a order dependency, but... ugh.
myk002 commentedon Sep 22, 2021
an alternative might be to just highlight orders that match a search, and provide a hotkey (or override the behavior of the arrow keys) to jump the cursor to the next highlighted match. this would be a different look-and-feel from the other search interfaces, but it would avoid all the rather scary pitfalls of dynamically modifying the global list. the new behavior won't be completely foreign, though, since almost all text searches work this way in other applications.
widgets:
<key>: next match<key>: prev matchwe might want to keep the standard behavior for the arrow keys and pgup/pgdn so players can still interact with unmatched orders. maybe next/prev match could be shift up/shift down or left/right.
ab9rf commentedon Sep 22, 2026
closed in #5677