Skip to content

extend printout to support per-user presentation preferences, such as using clock times rather than northeast, shortening names, etc. #312

@ahicks92

Description

@ahicks92

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:

  • If it finds a MessageBuilder, it replaces it with the built value, then recurses deeper. This can be checked with getmetatable.
  • If it finds a table { fn, arg, arg, arg } where fn is a function or callable table value, it will call fn({ 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:

function direction_handler(context, dir)
    if dir == defines.directions.north then ... end
    -- So on
end

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 rather ene or something (probably e 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhance existing featureSuggest to improve an existing featureinfo toolsTopic. Regarding tools that have the main goal of giving info.new featureSuggest a new featureui2Large improvements to the UI and input systems for efficiency of long-term players

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions