[0.12.29] [kovarex] Duplicate colors in consumption graph

[JasonC]

0.12.29

Sometimes this happens. Circled ones are the issue:



I think it has something to do with items that are in the top 8 in longer histories but not recently (e.g. items that have non-white graph colors in 10m but not in 5s), because the items in question are an assembler that recently stopped running and lamps that were off in the daytime, but that could be a red herring.

[Klonan]

Thanks for the report

[kovarex]

It is weired, as the 84kW one is not sorted in properly, I never saw this. I can't see any way to reproduce it, do you have any?

[JasonC]

It is weired, as the 84kW one is not sorted in properly, I never saw this. I can't see any way to reproduce it, do you have any?

i wasn't able to reproduce originally, but I will experiment today. It seems random but I'm sure it isn't. Give me some time, I have a feeling this will be tricky.

[JasonC]

I am working in 0.12.32 now.

So I was going to test a hypothesis that it had something to do with things that were in the top 8 list for longer history views but not shorter, but in the middle of my setup before I even tested it I noticed that the problem was happening. So while this is definitely not a minimal example, I've attached a save that at least has the problem occurring.

The sorting problem and the duplicate color problem seem to be two separate issues.

I have found that, in this save, if you perform the following steps:

1. Switch to the 5s or 1m graph.
2. Then, switch to the 1h, 10h, or 50h graph.

You will get duplicate colors in the graph (two purples in this case):



If you switch from 1h to 10h, you won't get the duplicate colors. If you go e.g. 5s -> 1h -> 10h, you'll see the issue then it will go away on the 1h -> 10h switch. Also, you'll have to do this within a couple minutes after loading the save, otherwise as the graph scrolls the window for the issue to occur seems to go away.

The duplicate colors once again involve objects which were turned off and therefore no longer appear in shorter history lists (lamps again in this case). I still do not know if this is a coincidence or not. I am starting to think it is not, but it definitely has something to do with switching between history times.

I will continue trying to come up with a better example, I still have no concrete steps or theories, but in the mean time, here. If at some point you are able to find the cause of the issue before I am able to find actual steps to reproduce, let me know so I stop trying.

Note: The two mods I've included were not present when I observed the original problem and are not the cause. I was using them to construct the test setup. You'll need electric switch for the switches, and toy box for the infinite supply chests and dumpsters. There is a constant combinator on the left side of the setup that can be used to control the switches; in the saved state the lamps are turned off, they can be turned back on by adding small lamp = 1 to the constant combinator output. Also you may see some debug output from toy-box; sorry, it is in the middle of a bunch of changes.

[JasonC]

I still haven't been able to produce a minimal case for duplicate colors. However I have trimmed down the previous post to be on topic, and have split the sort order issue, which I can readily reproduce, into its own new report.

[JasonC]

I still can't confirm any theories. i did notice three things:

• I can actually reproduce this pretty frequently, in all of my games, if I switch around between history times a lot, it inevitably happens.
• It is still present in 0.12.33, so this confirms that it was not connected to the electrical graph value display issue.
• It actually also happens in the item production/consumption graph (not just electrical), same situation: when switching between time windows.

Also I caught this in a game today:



Not only are there duplicate colors, but one of the bottom 8 has a color associated with it.

I have a hypothesis though: If you select a time window where something is in the top 8, then switch to a time window where it isn't, it's like its color is still remembered. If you then switch back to a different time window where it is visible again, it seems to prefer to go back to its old color. But if something is already using that color, it's asking for a duplicate.

That may not have made sense. For example, let's say:

• You're in the 10 minute view. Item A is blue, item B is not in the top 8.
• You switch to the 1 hour view. Item A is no longer in the top 8, item B is now in the top 8 and just happens to be assigned blue.
• You switch to the 1 minute view. Item B is still there and retains blue. But say item A is also now in the top 8 again. In this case item A also seems to prefer to return to blue. And so now A and B are both blue.
• Also, if at this point you switch to another view where both A and B are in the top 8, the issue corrects itself and the colors are reassigned.

That's a hard setup to recreate on purpose, so I haven't really been able to test it yet. It's also just a guess. But maybe take a look through the color assignment code and see if there's any logic that somehow allows previous colors to be used without checking to see if they're already in use.

I definitely know it's associated with switching between time windows, though.

[kovarex]

It is most probably fixed for 0.13 version (as the logic when switching speeds have been altered).