228.647 Error CrashHandler.cpp:603: Received SIGSEGV Factorio crashed. Generating symbolized stacktrace, please wait ... Raw stacktrace: 0xb4a8f8, 0xd35b0d, 0xbe457d, 0xbe48ed, 0xbe4949, 0x3bfb0, 0xbcd069, 0xbd3534, 0xbd38e6, 0xbd43e6, 0xa0528f, 0xccf23d, 0xd27684, 0xd27d1c, 0xe8fd53, 0xf681e4, 0x1...

Attachments are not attached.

Either disable mouse LED control within the profile, or Factorio's Logitech LED control if you don't use it at all. In my experience, Factorio doesn't touch the mouse LEDs past init.

"Simple" solutions exist for both blacklisting and whitelisting from a sharable-per-filter-configuration bank of constants, assuming all signals remain positive or zero. To blacklist: The constants should emit -2147483648 for all undesired signals The constants are implicitly added to the ...

If you use the signal priorities, yeah, the simplest solution is two comparisons and one constant, but there is no guarantee that it will continue to work in the future, and might need to be rewired after changing mods or an update. (That said, it's probably as unlikely as possible that it would bre...

Actually, I think I came up with a possible resolution for this issue. For background, Steam Auto-Cloud is the system by which Factorio uses the Steam Cloud, and it is really dumb in how it operates; if a file is newer than the one it knows about (e.g. because the blueprint library was just regenera...

172.962 Include minidump in crash report. 172.962 Error CrashHandler.cpp:462: Exception Code: c000001d, Address: 0x00007ff6b1b7bd57 ModuleBase: 0x00007ff6b19b0000, ImageSize: 0183e000, RelativeAddress: 001cbd57 172.962 Error CrashHandler.cpp:482: Exception Context: rax=0000000000000000, rbx=0000015...

Does this apply with built-in GUIs as well?

There are three kinds of items. The general rule is: If the item is strictly an intermediate product (e.g. electronic circuits), the item won't get damaged anyway and so stacking works "as expected". If the item is used as a fractionally-consumable resource (e.g. science packs, repair pack...

Please take a look at 65184 then, since that thread is a NaB-filed statement that the silo does take power to launch.

That complicates things slightly, since that thread is categorized NaB; it shows intent that the rocket silo should consume power during the launch, and so it follows that an unpowered launch is a bug. But, of course, it's hard to actually interrupt the launch if power does in fact run out (you can'...

Strictly speaking, I'm not sure if this is a bug. The power consumption goes to the assembler part of the silo; the rocket parts are the product, and the rocket is the othewise-free product of 100 rocket parts. The desire can probably be accomplished by using e.g. 10 stack inserters set to stack siz...

Is this/was this a game on a public server? If so, you might want to check `/permissions` to check if the permission was revoked by someone else (or possibly the mod). That's the only thing I can think of aside from bad keybindings.

57.118 Error CrashHandler.cpp:462: Exception Code: c0000005, Address: 0x00007ff6464f1148 ModuleBase: 0x00007ff645f50000, ImageSize: 0183e000, RelativeAddress: 005a1148 57.118 Error CrashHandler.cpp:468: Access Violation: Read at address 0000000000000198 57.118 Error CrashHandler.cpp:482: Exception ...

The spitters have an AoE attack which might instead be aimed at the walls, and hitting the turrets via splash damage.

I believe this is a duplicate, but I'd have to find the thread to be sure.

EDIT: Not technically a dupe, but another missed case related to 68191 and 66419 (both considered resolved).

I might mention, to my knowledge (I don't know if it has been changed) the list of jobs that are waiting for robots is stored in a circular queue, and only so many are checked every tick. If you are within range when an entity creates an "order", it can be "served" immediately; i...

That log does not contain any crash.

Except there's still a bug that the fluid transferred (and energy consumed) is double-counted. A simple fix would be to remove the energy usage and rate accumulation for filling a fluid wagon with the pump's fluidbox (since it still takes energy to fill its fluidbox from the rear fluidbox).

And I just reproduced the issue including the extra power consumption; this suggests the actual throughput is 6400/s. I'm not quite sure why the rear pump is behaving the way it is, though, from a theoretical perspective (but I think this is also a known bug that's marked as won't fix).