Factorio Forums

Hi. Recently noticed an issue that sometimes certain modded machines' working visualisations will flicker on and off. I thought at first they were not being rendered. It happens less or not at all when you are closely zoomed in (more than factor 2) and most when you are zoomed out as far as you can go. It never seems to happen in certain tile locations at all. So it's place and zoom specific.

I then realised it looked exactly the same as an issue I'd had with modded pipe covers - an assembling machine with an output pipe was having its southbound pipe flicker on and off, with fluid boxes copied from the vanilla Assembler 3 (but no vanilla assembler uses its output pipes to my knowledge, except chemical plants and refineries, which have them fully specified). With fluid boxes, you can specify a secondary_draw_order(s) parameter, per direction or for all directions, because you may want pipes on certain sides to be hidden behind the main sprite, so I tweaked the south facing pipe to a higher value, and it immediately stopped happening forever.

With working visualisations on assembling machines, though, no such render order parameter exists, to my knowledge (working visualisation parameters are not documented on the wiki).

I only realised that it was being drawn behind when I saw one of my glowing visualisations flickering under the edge.

You see here the machine on the right looks like its lights are off when it's still working:



But on closer inspection, the working visualisation (a glow) is poking out from underneath whenever the lights on top disappear. It's subtle, but it's there:



So it's like some kind of "z-fighting" issue.

Requested fix: working visualisations should be drawn on top of the main animation under all circumstances and never underneath.

I figured out what was causing this, or rather, why it was happening with my machines and not vanilla ones. I still think it's a bug but it only manifests in this rare case.

The machines have two layers in the main animation: base and shadow. But unlike all the vanilla machines, I was specifying the shadow first and then the base: vanilla machines all have the first layer as the opaque body of the machine and then the shadow specified second. When I switched it around to match, the issue goes away.

Internally, the working visualisations must be looking at some property of the first layer to determine draw order. Why it's causing quasi-z-fighting issues that differ frame by frame if that first layer is a shadow is a mystery, as well as why it only occurs at certain zoom levels, but at least it can be avoided.

Thanks for the report.
For next release I made it so secondary sorting index for working visualizations are more spaced out to account for multilayered sprite definitions

Thanks posila, you're the best.