My test save from .28 loaded into .37 still shows the non-grouping behaviour. The same save loaded in .35 behaves as expected. I haven't looked into it too deeply yet, but will report back if I can reproduce it with a fresh save on .37

Noticed the same change in attack behaviour when I was in sandbox mode testing out some new perimeter wall designs. I can provide a save file as well, but I think this video demonstrates the difference well.

https://youtu.be/yGvET2KhRKc

Discovered this myself today when queuing up a bunch of follower robot count research to stress test my base. 0.18.18.

Ran into this bug tonight on 0.18.18. Temporary workaround is to manually delete every blueprint in the book, which then also deletes the blueprint book. This is obviously quite tedious.

Construction bots temporarily disappear while they are repairing an entity. The glow and sparks remain visible, but the sprite of the robot itself is invisible.

Example video: https://streamable.com/k6es9

Confirmed fixed in 0.18.4 with a few attempts to reproduce a crash with two different save files that had exhibited the behaviour with 0.18.2 and 0.18.3.

Spitters used to have acid attacks that could home in on your location, which frankly didn't make sense and made the game frustrating rather than challenging. Now, they will at least lead the target with their attacks, but if you change direction in the meantime, then obviously the attack won't corr...

28.531 Error Commandable.cpp:320: this->lastDamageDealer->getSubstitute() == *this->lastDamageDealer was not true Logger::writeStacktrace skipped. 28.532 Error CrashHandler.cpp:189: Map tick at moment of crash: 6840745 Seeing the same crash. Removed all mods, still was able to reproduce. I attack a...

Stellar response time by the devs, as usual!

Running through the NPE right now. Compilatron managed to position itself right where I have a crate feeding the assembler that is crafting science packs. Compilatron's selection box completely surrounds the crate's selection , so I cannot drop more items into it. Trivial to work around in this case...

I ran into a similar situation recently, except it was a stack inserter that was seemingly unable to deposit items it had in hand into an empty and waiting chest. https://i.imgur.com/GiXa88j.png Everything indicated that it should have been working. Inserter was oriented the right way, powered up, n...

Wube will be subject to the GDPR. However they decide to implement crash log reporting, if it's good enough for that, it's good enough for me. I looked through some saved crash logs and the only thing that might even be remotely considered PII is my Windows username embedded in some pathnames. Not e...

kovarex wrote:I fixed it for 0.16.11.

I really should be preparing for my New Year's Eve party, so feel free to take a break and leave the bug-fixing for 2018.

Not to mention that this parallels the existing mechanic with fuel type affecting speed and acceleration in vehicles.

This bug has different symptoms than the behaviour described in https://forums.factorio.com/viewtopic.php?f=213&t=50651, but I suspect they share the same root cause, and thus will likely be solved with the 0.16 belt mechanics optimization. I'll leave it to the devs to decide if this can be move...

Just to close this off in case anyone else rediscovers this before 0.16: it appears the actual cause of the delay is a discrepancy in where the initial item of a stack is placed on the belt. Normally, items are placed flush against the edge of the belt (closest to the inserter). However, on subseque...

Thanks for report, but in optimized-belts branch (coming 0.16) this problem is gone :) Hooray for the devs! I discovered what might be the same (or perhaps related) bug, which looks like it will also be fixed with belt optimizations. I'll file a separate bug report and hopefully it can be immediate...

This video demonstrates end-loading vs side-loading on normal and underground express belts. In both cases, the shortest underground belt suffers a slight performance penalty compared to the longer ones. However, when end-loading, only one of the two inserters depositing directly on an express belt ...

Upon further testing, it looks like there is more inconsistency than just the length of the underground belt. I'll try to capture video of each scenario and post here.

A stack inserter end-loading to an underground belt is delayed by one tick on the return swing if the other end of the underground belt is in the adjacent tile. This is with a +12 stack bonus and express belts. Tested with north- and south-facing inserters. I have not tested other configurations yet...