quality

[ahicks92]

Probably very easy. We need to announce quality. We may also need to do something about the circuit network but it is unclear how quality is represented there.

[EphDoering]

Quality seems to touch many of the GUIS, and a lot of APIs. Each signal has a quality. The filtering menu will need to be modified so that splitters and inserters can filter by quality.
On the hover panel on the side that lists entity description and stats all the items that are effected by quality get a diamond next to them, letting you know what might be worth getting a higher tier of.

[ahicks92]

This gets worse than that. All inventory operations now return ItemCountWithQuality and do not return key-value pairs. Anywhere we use an inventory needs to be updated from:

for name, count in pairs(whatever) do
...
end

To:

for _, info in pairs(items) do
-- info.name, info.count are what you want
end

[LevFendi]

we are lucky that quality is an independent mod from the rest of space age. We might leave this for a while longer.

[ahicks92]

That is incorrect. It is sort of a mod except for all the places where the API now passes you quality or expects you to pass it quality. We can avoid exposing it, but must at least account for it e.g. when getting crafting machine speeds from prototypes. My understanding is that quality "normal" is always present but I am not sure that's right. A number of (not sure how many) things that used to be attributes are now functions taking quality.

I had to break warnings to get things to launch. Which deserves a ticket. But quality was why. No more simple fetching of crafting speed for instance.

[ahicks92]

Ok, status update here. This is a sort of background thing but it's actually pretty close to done believe it or not.

The API takes prototype.health to prototype.get_health(quality) essentially. This transformation must be performed everywhere. If we do so quality mostly works. To that end I have been careful about this, and always pass the quality. It's an optional param; quality-unaware mods can just pass nil. This is at least 75% of what is needed to support quality and we get it anyway.

Note that quality is always set. When disabled quality is "normal". This is true even with the quality mod disabled. The space age expansion here as far as I am aware is that the space age executable allows declaring qual,ities, but I have not installed non-space-age to test this. Docs do not indicate it is space age only.

The remaining 25% is localisation and handling lists that might include quality, then a followup on circuit network and filters which honestly is still far out.

For localisation, I have been introducing proper helpers in localising.lua which do not rely on cached translations. Of these, the new function localise_item is most relevant. It may be called as:

{
    name="iron-0plate",
    quality = "normal",
    count = 5
}

Or in a few other ways, most notably passing it a stack directly. This function returns a localised string of thye form whatrever x 200 (for normal quality) or whatever legendary x 200 (when it isn't normal quality). That is, we deal with quality by saying that normal quality isn't worth announcing, and this deals with the case of no quality becasue normal quality is wqhat you get with no quality as well.

As for lists: I have introduced a pattern table<string, table<string, number>>, where the mapping is name->quality->count. This is a particularly useful representation not because it is in itself super convenient (for example, one could argue quality should be first), but because we can write helper functions around it, and because when qujality is not involved the inner table is just { normal = 5 }. Table-helpers (impoorted almost universally as TH) has grown a variety of functiojns to help deal with such tables. The naming is not yet super consistent, but I have settled on NQC as the acronym and introduced the type alias fa.NQC as well. For example, TH.nqc_to_sorted_descending converts a NQC to a list sorted in reverse order by count. As has been done in the past, and as we should continue to do in future, that does not have any Factorio specific code in it. Whether or not we will want to eventually split this file is TBD. We probably do, but being able to debug table-helpers without having to funnel the problems through Factorio is a very useful property, and I ask other devs to preserve that.

This leaves UIs. The problem is that we don't have a UI framework and the new APIs have lots of quality-aware places. The good news is that for most of these, we can default quality to any quality for the time being. As part of redoing transport belts I did begin writing us a small UI thing which will eventually meet up with layers and some of the other input tickets, as it is designed so that we may simply make a layer that knows how to wrap the smaller thing. This however is not sufficient for an item chooser, nor will it be in the near future, primarily because there's a lot of other problems and doubling down on it isn't a good use of time as of yet. It may be just barely possible to extend the item chooser code to have quality awareness, but personally I'm going to do it right if I do it, so if someone else wants the hacky way feel free to take this over. The real concern is inserters. We can likely shrug at most other things. In particular logistic requests already require having item in hand, and very few people go nuts with the circuit network. Unfortunately I believe filters are >= <= etc. not just ==, so for example that doesn't work well for a splitter if one wants to make a belt which sends higher quality items somewhere else.