Thanks for the report. It's now fixed for the next release.

Thanks for the report however: please see the notes on that function https://lua-api.factorio.com/latest/Lua ... able_count

There is no built in speed cap; the game tries to go as fast as it can until it starts dropping packets and then backs off slightly.

Thanks for the report. It's now fixed for the next release.

I believe the fix for this will likely be changing the inserter so it can never sleep if pointed at a furnace that supports fluids. There is no event for fluids flowing into or out of a machine.

The crc calculation is essentially instant. All of the time is spent in the function call to the results of requiring "__testorio__.init" This part: { 'tests.core.Class', 'tests.core.Error', 'tests.core.Helper', 'tests.core.List', 'tests.core.Callback', 'tests.events.EventHandler', 'tests....

You aren't supposed to be that far from the center of the map. By teleporting there you broke your save file; You'll need to load an earlier version of the save.

This is the Lua equivalent of the C++ mining code that runs: local player = game.player local force = player.force local character = player.character local prototype = character.prototype local modifier = (1 + force.manual_mining_speed_modifier) * (1 + character.character_mining_speed_modifier) mini...

I tested it; and when I pressed the key combination (shift + ~) it opened the discord overlay and when closing it the game was no longer responding to any inputs. So maybe it's related to that.

I'm not able to reproduce any crash regardless of what I'm doing. Based off your description of "do something for a few minutes" and where it is crashing (something that runs every frame for every player playing the game) that makes me think system instability and or bad hardware. Have you...

I'm going to make an executive decision and say the operating system(s) are responsible for scheduling things to run on cores and not software (us). You'll need to report the issue(s) to whoever makes your operating system if it schedules things incorrectly. Or disable e-cores.

Do you have any way to reproduce the crash? The stack trace did not symbolize anything useful about the actual code crashing.

The log file does not show any crash. Are you sure you uploaded the correct log file?

Can you post steps I need to do for it to crash? I've had it running for the last 10 minutes watching the enrichment run without issue.

To know the max number, just look up "max 64 bit integer". Depending on if they are using signed or unsigned there, it's either going to be a little more than 9T or 18T, respectively. It depends on which statistics are being used; fluids use 'double' and things like items use an unsigned ...

Given that we don't do anything with freesync or g-sync; this sounds like a bug with either freesync or g-sync or the nvidia drivers. Something that you will need to contact Nvidia, AMD, and or your monitor manufacturer about.

I added LuaControl::get_max_inventory_index() read for the next 1.1 release.

The way the C++ code does it is: loop from 1 to <= max and call get_inventory. If it returns non-nil you have an inventory. If it's nil you skip it and continue to the next index.

Thanks for the report however this is working correctly: cloning just the rocket silo does not clone the rocket. This is because the rocket is its own entity separate from the silo and just happens to be launched through the rocket silo GUI. If you are using the https://lua-api.factorio.com/latest/L...

kilo=k 1'000
mega=M 1'000'000
giga=G 1'000'000
tera=T 1'000'000'000
peta=P 1'000'000'000'000
exa=E 1'000'000'000'000'000
zetta=Z 1'000'000'000'000'000'000
yotta=Y 1'000'000'000'000'000'000'000

Using the same save file:

ZSTD Compression 9: 1.52269 - 84.8 MB

ZSTD Compression 22: 5.46916 - 77.6 MB

Zip compression 9: 3.53715 - 85.9