Is there a use case for searching ungenerated areas? If the generated map looks like a donut, then entity search has to go through entire search area. If a chunk does not exist the search quickly sweeps to the end of line but because entity searches are always scanning surface row by row (advanced ...

This sounds like 83579

Thanks for the report however i will require a reproduction on this because i was unable to reproduce it myself and its first time i am seeing this assert catching anything and it suggests a heavy abuse of the lua metatables by the scripting: it can be either reattaching metatable to non-table, reat...

Thanks for the report. There is exactly one "iron-ore" resource entity that has a position which is corrupted: that entity reports as having a position MapPosition(-322.5, 4161536) while it is being loaded by a chunk at a ChunkPosition(-11, 1). The x coordinate is well within the limits (b...

Thanks for the report. In 1.1.78 the InserterPrototype::stack_size_bonus will only accept values from 0 to 255.

SInce stacktrace has no useful details here and you are not providing any extra details about when the crash happened, if you can reproduce this or anything, i am moving this to pending.

I am trying to reproduce the crash in 1.1.76 or 1.1.78 (not yet released) and whatever i do the save file loads fine up to loading this save file with no mods enabled. Moving to pending unless you can still reproduce the crash in 1.1.76 or later.

Well, my conclusion here is that this save file is corrupted. Corruption here is around stack inserter on nauvis near position {677.5, 894.5} which tries to pickup item from express-transport-belt at {676.5, 894.5}. That inserter during update tries to use a transportLineIndex of 90 when the only po...

Thanks for the report. Issue is now fixed for 1.1.78.

This log does not contain any useful informations and as such there is no well defined condition when this bug report would be considered fixed or not a bug. Since there is also 105527 it could be a duplicate as well. Moving to duplicates until proven otherwise.

Thanks for the report. This is not a bug. Flamethrower turret shooting speed is limited by the value of FluidTurret::ending_attack_speed which means a fluid turret is only able to shoot every 4 ticks (since ending_attack_speed=0.2, 3 ticks will be required only to increase the progress, and in 4th t...

Thanks for the report. Fix is to not do that. It was never designed to handle those cases so its not a bug if it does not work. This is an intersection of 3 complex systems, electric poles drag building, smart belt building and player input source. Smart belt building uses belt building locked to a ...

Thanks for the report however this is not a bug. Smart belt building logic for reverse drag that creates underground belts is implemented as 2 stages: first it builds undergrounds in a way they would connect correctly and then it adjusts their direction if they happened to be pointing wrong way. The...

Thanks for the report and primarily for the save file. The issue here is tightly related to loader ghosts making a connection to an entity of different force which it was not supposed to do. The issue is now fixed for 1.1.78 and the provided save file will load fine.

Hm.. this is really interesting. The issue is with the belt to the left of the selected loader, the belt on the left should be only connected to the left loader as the ghost on the right is of different force and should not be affecting shape of a belt, same as the belt below.

Thanks for the report. This is not a bug. If a vertical wires would be required to be rendered as wider, there should be a modding interface request for a separate wire sprite used when rendering vertical cables. If an existing sprite of a wire (that includes the bending due to gravity) would be ren...

Thanks for the report. This is not a bug. There is a threshold of 0.5 chart zoom below which the spider path does not render.

For 1.1.78 i moved that constant to utility constants under "chart.zoom_threshold_to_draw_spider_path" with a default value of 0.5.

Thanks for the report. I see the issue happening in 1.1.77 but it was already fixed for 1.2.0 so i am moving this to "fixed for 1.2"

Fluids are implemented using floating point numbers, there are roundings happening in various places. If during fluid flow there was some fluid amount lost then its gone. I am not going to round those numbers up because it could happen that there is 49.99999 fluid in the assembling machine that woul...

Thanks for the report. Issue is now fixed for 1.1.78.