[Kovarex] [0.16.0] Sideloading works completely different now

[Koub]

You and many others, I don't understand why this wasn't deemed top priority. I really hope something good comes from this (like inserters being able to compress belts natively).

Top priority is usually : "Game crashes", "Game corrupts saves", "Game cannot be played".
First, fix the game breaking bugs. Then, the remaining. And also remember that :
1) the fix is probably not just a flag "Can compress" to be set to 0 or 1, it might need a serious refactor of the belt and/or inserter mechanism : unless you're one of the devs, you can't know how hard it will be, and how much optimization they will have to give up to make it work again.
2) I think you have been a little too spoiled with Factorio's devs. I mean look around and name me just ONE dev team that's so dedicated into delivering continuously the best stuff asap, continuous fixes, ...
3) If you don't want to play "unfixed" game, you can still play with stable 0.15.40

Also, your quote is broken, I have never said anything kept me from playing .

[SunriseEU]

If you don't want to play "unfixed" game, you can still play with stable 0.15.40

Please refrain from these kinds of arguments. I hope you understand why. I want to play with the new terrain, the new production ratios, the new graphics and all that as well. It's the very reason I'm in this thread after all.

Given the reasons Koub layed out, I can understand why this isn't top priority, and honestly I don't think most players care at all. But to me, this made the game very unenjoyable since it feels like I have to go out of my way for something that I've for a long time (even in 0.15) thought should be much easier to achieve.

[Tym]

The Factorio web site says this, explicitly, when downloading experimental releases:

"This is the cutting edge "experimental" version. There might be some nasty bugs. Use on your own risk. Your computer probably won't explode though ."

me again: if you are unhappy with the as-yet finalized features of the 0.16 tree, go back to the 15.40+ -STABLE- release.

We've -all- seen how -responsive- the Factorio developers are to user concerns, far and above almost -any- development team i've -ever- interacted with. (I work for an OS company myself, so i'm -well- acquainted with customers concerns about software.)

so, yes, continue to report problems. please, though, -CEASE- to -whine- about them. Happy New Year.

[SunriseEU]

please, though, -CEASE- to -whine- about them.

If you believe that I'm whining, then I'm sorry I've not been clear enough. The reason I mentioned that I've stopped playing because of this is to emphasize that this is a dealbreaker for me if this behavior stays in the game. Like Koub said before, this is a decision the devs have to make about how things should work, and I'm voicing my opinion on the importance. Telling me to go back to 0.15 doesn't help at all, since if I thought 0.15 was a superior version I wouldn't come to the forums in the first place.

Happy new years to ya'll as well

[o6dukeleto]

+1 for giving this a higher priority.

I too am waiting for this fix before playing 0.16. As for priorities, not sure how this is lower than fixing the size of a tank train car, from my perspective this seems much more "game breaking."" (BTW, I like the tank car fix -- not complaining about it, just seems lower priority from my personal perspective.)

My preference for the fix would be that all types of "belt loading" to automatically compress, including splitters, side loading, inserters and mining. I think belts add enough complexity to the game WITHOUT belt compression micro-management. Robots are so much better than belts that "nerfing" belts with compression issues does not seem useful.

[FrodoOf9Fingers]

I wonder what performance hit we'd get for adding in automatic belt compression.

[mh_]

Please stop saying this problem is game breaking! There are really easy workarounds to this. It's just lazy not to think about new solutions. Imho, it would not even be game breaking removing splitters as a whole. This is such a minor problem.

If you want the new features of 0.16 you either wait until it is stable or get used to the bugs. The devs push out the experimental version to people who want to help with development by testing. If you are not one of those, please go back to stable.

The change of the fluid-wagons is also not game breaking. What are your standards here? This just requires you to have longer trains, so what? It's a pity not to have the split wagons, but game breaking a whole other level of critique.

[SunriseEU]

Could everyone stop telling us to go back to 0.15? If everyone waited for 0.16 stable to complain about this then how would they know we were unhappy with the change? I agree that it's not game breaking by any means, but the compression change were intended by the devs and we want that changed. That's all.

The fluid-wagon discussion is a little off-topic, but that change I agree 100% with the devs with the main argument being simplicity. I apply the same argument for this topic. Achieving compression should be simple and intuitive. Why should achieving compression be complex? I don't get a sense of pride and accomplishment when I've built one of the workarounds.

[mh_]

Could everyone stop telling us to go back to 0.15? If everyone waited for 0.16 stable to complain about this then how would they know we were unhappy with the change? I agree that it's not game breaking by any means, but the compression change were intended by the devs and we want that changed. That's all.

The fluid-wagon discussion is a little off-topic, but that change I agree 100% with the devs with the main argument being simplicity. I apply the same argument for this topic. Achieving compression should be simple and intuitive. Why should achieving compression be complex? I don't get a sense of pride and accomplishment when I've built one of the workarounds.

Simple and intuitive obviously don't mean the same.
I understand (intuitively) that the items just lie on the belt. Intuition would suggest that you could not fit another item on a belt where there is not enough space without moving the items that are already on it. Therefor sideloading can not work, says my intuition.

You have to choose. Either this is a bug (as it is posted in "Bug Reports"), then it is very low priority, probably not a bug.
Or this is a feature gone missing. But then you should go post it in "Ideas and Suggestions".

As this is posted in bug reports I suggested going back to 0.15: These post suggest that is of some kind of importance to get sideloading back. It is not. First priority is a playable game. Crashing game and corrupted safe files are more important for the community than some inconvenient but functional game mechanics. This is what the argument is about.

[SQLek]

Problem with inserting in tight red/blue belt is that, hole to insert can be in invalid position.
So correct tick to insert is **.5 for red or **.3333 and **.6666 for blue.

I'm trying to fix my factory blocks by introducing circuit network to place items exactly at correct tick. Work in progress google sheet.

There are quirks/bugs that can cause holes(9 empty belt slots) to change state to invalid.
- before sideload
- before curve
- before & after path change.
...etc

But what will happen if You trigger two such quirks/bugs?...

regular.png (369.94 KiB) Viewed 8495 times

... they nullify each other.

Bug on Bug sideloader

0eNrVWF1vmzAU/SuVn0OFDfnU9rTXvUx9nCrkwE1iFWxkTLao4r/vGlKaJtAYUm3dSyL8ce695xz8wTNZpyXkWkhDVs9ExEoWZPXzmRRiK3lq28whB7IiwkBGJkTyzD5teGE8o7kscqWNt4bUkGpChEzgN1nRanIVQciNkMIcvHgHxelkVj1OCEgjjIAml/rhEMkyW4NG9BYjg0SUmQcpxEaL2MtVChghVwVOVtLGRkAPJxzwL6xsWmdgrC+hCxj/BWXSDo0KMEbIbWGHaMjUHqIS+1IDGpLIFoxdRpcwIU1rU9Ax4i+lEowTq9KyP8UAmUpsBzdeCrxOomX0sSv7wDl7+gmzD9vsre0Ml8aLVbYWkhulO3QMmxoCrCERGjWv+5jNQRqt0mgNO74XOBcnnGZ8YcW90KbEljaBZoT3zfrwWBF9k34dRDYxa8Ko/dlqAHnqUZEgFThW6LgUpn6si++oftoGTyAWCej3i2f30yHlHzEj7EtEm/RG6MJEQ+lotMFQdGYfs5zrOskV+YJTVGnycjhofohqoqONVlkkJGI0Zqt6uEZPXmG6Xjk6JQlrBZkbDD0Ryz7PewSctZWdLYR9Swc7U64Dc/7KluHxkydkARp93IsZVN36vxTU6n+7/P6Z+F/JLVK95Zj65w3THtYXzqwzZ9aXzpjUGZP6zlLSvy4lDW8Sc34uVt8rQum7J4YLJsJOesMuZDYKOXBADpzdELi7IRx4zvA/00ZNp0OXJXrG8/+xSLn7ejbw4PW55JwPXZr+mZw3LlS4i1zsMz2KLsasJ77DcrIctVANYxwkX6cQJaKw/2S14WkBrzuuBp5EOy4TK43BBFt/nUhWtzdDG0P5Qw69rO+Yy3znV6XZsNmoV6Uz9NCbYpMAHVI3XfbVzZxfsqCt+8ouwoIxXnLYTVk4Bpg6AL/uHC33IEFvD8gHkrHhceeN/XjZCe6nndzOBnoq/DhPzQeGDj4u9GKgo0IHRy0HYgbXMQN/jJnC62YKRp0mL458eEmsP0WtTr59TUjKEQTbHvDanCqeoEx31q5Pd+vD3cOP7/CEg/a4F9cos8Wc+WwW0Nmiqv4A7TiYQQ==

This green wire and belt scan is there only to trigger second bug.

[Twinsen]

Just as a quick update we are actively working on fixing all the belt issues including sideloading and experimenting with compression.
Due to the complexity of belts, because of all the optimizations, this is not easy, so bear with us.

[chrisgbk]

Just as a quick update we are actively working on fixing all the belt issues including sideloading and experimenting with compression.
Due to the complexity of belts, because of all the optimizations, this is not easy, so bear with us.

I did some frame-by-frame analysis of 0.15 vs 0.16; when sideloading onto belts in 0.16, the item starts out slightly farther down the item rail in 0.16 than 0.15 on the first frame it exists on the side-loaded belt, like it's being sideloaded into position 0 in 0.15 but position 1 in 0.16.

[SQLek]

Just as a quick update we are actively working on fixing all the belt issues including sideloading and experimenting with compression.
Due to the complexity of belts, because of all the optimizations, this is not easy, so bear with us.

We know there is lot of stuff on Your plate Is there anything we can do to help?

So far my observation with red belts: if segment where is insertion or sideloading is last in path (segment with arrow), not only it behaves differently, but more sane.
Yellow ones works always. With blues i was unable to do inline compression, but i can live without them.

[killerbees]

Just as a quick update we are actively working on fixing all the belt issues including sideloading and experimenting with compression.
Due to the complexity of belts, because of all the optimizations, this is not easy, so bear with us.

W00t!!
<3

[Gergely]

Just as a quick update we are actively working on fixing all the belt issues including sideloading and experimenting with compression.
Due to the complexity of belts, because of all the optimizations, this is not easy, so bear with us.

W00t!!
<3

Well, I was hoping that unlike SOME serious bugs, this will be AT LEAST fixed when 0.16 becomes stable.

Glad that we can (most likely) say Good Byte to this one.

Seriously though. It does not matter when will 0.16 become stable. What does matter, is that when they eventually declare it stable, it will be worthy for that title.

[Kaiji]

Just as a quick update we are actively working on fixing all the belt issues including sideloading and experimenting with compression.
Due to the complexity of belts, because of all the optimizations, this is not easy, so bear with us.

Really glad to hear this.

Thanks for taking community feedback so seriously. This is one of the many things that makes you stand head and shoulders above other dev teams.

[Nazair]

And I was wondering why my factory lost production capabilities.
Turns out something that was working perfectly before 0.16 now works "ok-ish"

Looking forward to the new update. Keep up the good work!

[mh_]

see on page [1]

... it is connected to viewtopic.php?f=7&t=54693 ...

kovarex is fixing

[mrvn]

I want to mention something that I think is related to this problem:

When you have a compressed yellow belt becoming a red belt then, since red belts are twice the speed, there should be enough space between items to fit another item. But neither side loading or inserters can reliably place items in the gaps. I think they can only place items when the yellow belt isn't 100% compressed but has a 1 pixel hole.

[Zavian]

I want to mention something that I think is related to this problem:

When you have a compressed yellow belt becoming a red belt then, since red belts are twice the speed, there should be enough space between items to fit another item. But neither side loading or inserters can reliably place items in the gaps. I think they can only place items when the yellow belt isn't 100% compressed but has a 1 pixel hole.

When you are trying to do that, you have a red belt with gaps exactly 9 belt units long (exactly the length of one plate), but moving at 2 belt units/tick (where a belt unit is the distance a yellow belt moves in one tick). So the gap might be one belt unit before the inserter one tick, then one belt unit past the inserter the next tick. Hence the inserter might not be able to insert into the gap. Side loading probably has similar restrictions.