Factorio Forums

Image doesn't fully show what's going on (last setup gives a hint, though), see save game to fully display the issue. Creative Mode mod is required, the others are not.

Side-loading sometimes takes precedence over the items already on a belt that should be fully compressed. I've not been able to reproduce this without using an underground belt, but it's difficult to hit the right spot that triggers this behavior, so I may just have been unlucky.
As the save game displays, three of the setups cause the belt that just goes straight ahead to stutter as items are forced in from the side-loading.

I discovered this first some time ago (expand spoiler about stuttering), but thought it could be related to the circuit setup. Issue recently resurfaced and I managed to reproduce it without both circuits and splitters, but not without underground belt.

That's just due to entity update order. The side belts update before the underground belt and move items onto the belt.

Rseding91 wrote:That's just due to entity update order. The side belts update before the underground belt and move items onto the belt.

Did you notice that the first setup has a belt tile between the underground belt and the belt I'm side-loading onto? The issue propagates down the line, meaning that side-loading onto a belt at any time after an underground belt may display this behavior. I do hope you'll reconsider this issue, the behavior is unfortunate in some setups. One example is overflow splitting, another when you want to prioritize burning wood before coal in boilers. Side-loading is an effective way to prioritize item flow, something that's difficult to achieve otherwise (at least when you want a fully compressed belt).

canidae wrote:

Rseding91 wrote:That's just due to entity update order. The side belts update before the underground belt and move items onto the belt.

Did you notice that the first setup has a belt tile between the underground belt and the belt I'm side-loading onto? The issue propagates down the line, meaning that side-loading onto a belt at any time after an underground belt may display this behavior. I do hope you'll reconsider this issue, the behavior is unfortunate in some setups. One example is overflow splitting, another when you want to prioritize burning wood before coal in boilers. Side-loading is an effective way to prioritize item flow, something that's difficult to achieve otherwise (at least when you want a fully compressed belt).

There's nothing to reconsider. Entities have an order they update and with belts it causes things like this. It's a fundamental part of how the game works and not something that's broken or could be easily changed.

I've tested further, and realized that the issue isn't side-loading, but with the underground belts.
Underground belts don't fully compress the output when items on the output start moving after being backed up. See top setup at following image, where I simply stopped item movement on belt by rotating the item void, before rotating it back to restart item movement. This leaves a gap between items just after the underground belt exit. This does not happen with e.g. splitters or belts, only underground belts. When you then add side-loading it will correctly fill in those gaps, but this cause the underground belt exit to produce new gaps as the item movement temporarily stops and restarts. One more thing. I don't expect everything I report to be fixed, I may very well mistake features for bugs, and I may very well be flat out wrong. If you don't want me to report issues anymore then I'll stop. So far I've reported four issues, my first three have been fixed (although one was generic about multiplayer back in 0.12). Every single time I've spent a fair amount of time to make the issue as reproducible as possible, by supplying save games, images and even made a tiny mod for one issue. I'd like to contribute to the improvement of this game, but I get slightly discouraged when I do spend a fair amount of time on this, just for my efforts to be brushed off.

You're not understanding: the code that moves items on underground belts vs splitters vs normal belts is all identical. There's 1 class and 1 place that does the movement. Any inconsistencies you're seeing are external - the mod that puts items on the belt for instance - or simple entity update order when one belt is side loaded on to another and so on.

It's not that I don't want to fix something if it's broken.

I spent some time and I was able to reproduce the underground belt spacing you mentioned with a straight belt and no side loading. I'll look into that and see what might cause it.

.

self-same-spot wrote:That's a weirdly defensive reaction to a normal bug report. "Nothing to see here, that's how it works internally, it can't possibly be a bug, go away. Oh wait, I've just spent 10 minutes to actually reproduce the issue. Ugh, I guess I'll have to fix it." I may be reading the tone wrong, but if I were the OP I wouldn't feel particularly inspired to report bugs anymore.

Your original bug report looked to be about side loading belts sometimes inserting items which isn't a bug. The other thing you posted later was something else completely which may be a bug but I haven't tried to look into what would cause it yet.

So many people make "bug reports" about game features working as they're programmed to work and it gets old. This one in particular has been "reported" a few times and typing out the full reason about how entities go inactive and active and such is tiring

Rseding91 wrote:

self-same-spot wrote:So many people make "bug reports" about game features working as they're programmed to work and it gets old. This one in particular has been "reported" a few times and typing out the full reason about how entities go inactive and active and such is tiring

Hey Rseding,
Just a reminder that all the players appreciate the hard work and effort that you put into the game everyday. I'm sure nobody means to report something that is considered to be working as programmed but please remember that we have no idea how the game is programmed (or any of the efforts and compromises that worked an idea up to the current implementation). However I would like to raise a point; when does something go from "working as intended" to "working but could use a blog post to explain?"
Sincerely,
Confused player of an awesome game.

Per 50651, from .16 on no longer an issue.