extend printout to support per-user presentation preferences, such as using clock times rather than northeast, shortening names, etc. #312
Labels
enhance existing feature
Suggest to improve an existing feature
info tools
Topic. Regarding tools that have the main goal of giving info.
new feature
Suggest a new feature
ui2
Large improvements to the UI and input systems for efficiency of long-term players
This is something I've been thinking about for a while. We need to somehow support preferences for things like units at some point. There's a very few places where it's worth applying this, but for example direction reporting style or saying 2, 3 instead of 2 south and 3 east are some big ones (consider how bad adjustable inserters would get without that option).
It would be best if we didn't have to funnel the player around to every place that might build a message, though. That stops us from ever writing code that figures out what to say without being "bound" to a player. For example, it becomes impossible to send the same message to more than one player at a time.
As part of the 2.0 work I have also introduced message-builder, which has a currently required build step--it would be nice not to need that, and to be able to just freely mix them with localised strings.
Let's solve all of this in one go. We will augment printout to crawl the table it is passed looking for special values, then replacing them:
MessageBuilder
, it replaces it with the built value, then recurses deeper. This can be checked withgetmetatable
.{ fn, arg, arg, arg }
where fn is a function or callable table value, it will callfn({ pindex = pindex, some, other, context, fields }, ar1, arg2, ...)
and recurse on the value. Context might hold things like pre-resolved settings but in any case it should be a table for future proofing.Then we can:
And then use:
{ direction_handler, defines.direction.north }
.Then things like
fa-utils::direction_lookup
can return this sort of lazy value instead and it gets resolved to the player's perspectiven at printout, thus decoupling the decision.This handles the easy universal cases. For harder less universal ones we'd still have to pass pindex around and check. For languages with non-English-like word order where the fragments themselves need to be reversed or whatever--we already lost that battle, we do too much dynamic message building as it is. I'm fine losing that battle a little bit more perhaps, since we weren't going to ever win it anyway.
I opened this now because in 2.0 we will need to handle things like
east-northeast
. I'd much ratherene
or something (probablye ne
because Espeak is turning ene into like ean but the point stands). But that's obscurity for the sake of terseness. I'd also really like to drop the word transport from transport belts personally, but again, understandability for the sake of terseness. I've also wanted to be able to get coordinates in chunks, e.g.2:15
for chunk 2 15th tile for aligning things a few times, so on.The code for all of this may literally be shorter than this description, which is why I put this more in the "one neat trick" category, but it has enough implications that the longer writeup seemed worthwhile. We can revisit after the 2.0 work. Not sure how to label it because it sounds like "big change" but actually weirdly isn't save perhaps for LuaLS annotations.
The text was updated successfully, but these errors were encountered: