[0.17] Please post bugs and balance issues here.

[Sopel]

I have a suspicion that belts from overhaul are slower than they claim.
I had a processing line that processes exactly 20/s but the last machine had quite long breaks.
Then I used this https://www.reddit.com/r/factorio/comme ... r_without/ counter to measure the actual thrughput. I modified the output to be /10 so it doesn't show just 1.2k and it shows

tmp123.png (217.06 KiB) Viewed 6384 times

it flickers between 112 and 113, that means ~1125 items per minute, which is ~18,75/s.
The animation of the belt is faster than the items on it, and it seems about right.
Can anyone confirm?

[BlueTemplar]

Factorio, like any other modern software, is discrete at its core.

Tiles are 32 pixels wide (on "normal" Full High Resolution).
In 0.17, each item on the belt takes 8 pixels (down from 9 in 0.16).
So, for a single lane, an item moving at 1 pixel per tick makes for :
1 pixel / tick * 60 ticks / second * 1 item / 8 pixels = 7.5 items / second
Double that to account for 2 lanes, and you get the 0.17 vanilla 15 items / s belt speed.

So items are going to move at best at simple fractions of pixels / tick.
And 18.75 items/s = 1.25 * 15 items/s = 5/4 pixels / tick
While 20 items/s would be = 1.33.. * 15 items/s = 4/3 pixels / tick
But both 32 and 8 are divisible by 4, but not by 3 !

There must be either a preference for rounding down or a divisor of 8 not working, because :
18.75 items/s = 1.25 * 15 items/s = 5/4 pixels / tick = 10/8 pixels / tick
is farther from 20 than
20.625 items/s = 1.375 * 15 items/s = 11/8 pixels /tick

So, some accurate speeds should be in theory :
1/4 pixels / tick = 3.75 items / s
2/4 pixels / tick = 7.5 items / s
3/4 pixels / tick = 11.25 items / s
4/4 pixels / tick = 15 items / s
5/4 pixels / tick = 18.75 items / s
6/4 pixels / tick = 22.5 items / s
7/4 pixels / tick = 26.25 items / s
8/4 pixels / tick = 30 items / s
...

P.S.: See also :
viewtopic.php?p=423163#p423163
EDIT : 3.5/4 pixels / tick = 7/8 pixels / tick = 13.125 items / s, which seems to be close to what mrvn found.
Not sure why 7/8 works, but 20i/s gets rounded down to 10/8px/ti=5/4px/ti, rather than up to 11/8px/ti ??

[bobingabout]

in either case, the default of 12.5/s doesn't work as intended, you should either leave the speed overhaul off where you get 7.5, 15, 30, 45, 60, 75 (which is the same end result of 12.5, 25, 37.5, 50, 62.5, 75, which is why I chose it) or manually change the speed per step to 15 and get 15, 30, 45, 60, 75, 90.

[Sopel]

I will have to change it to 11.25xN, I only noticed it after 50h of playing and need backwards compatibility.
Nevertheless, it should be possible to give at least correct values in the tooltip, as the only problem I have with it is that it's a silent difference that breaks your factory at some point.

[MageKing17]

- Spitters and Worms will now target their spit to a position ahead of you and not home like 0.17 base game spit projectiles.

As far as I can tell, spitter projectiles are still homing; if a titan spitter gets within range of me, I have to be moving pretty fast to get out of its range while it's in flight or I will be getting hit. In fact, I can't find any documentation for the "lead_target_for_projectile_speed" field anywhere, so I'm unclear if this is a bug in Factorio or not.

But the homing projectiles brings me to another point: fire-spit-projectile, titan-spit-projectile, behemoth-spit-projectile, and leviathan-spit-projectile all create a fire-sticker on the target. This sticker lasts for 30 seconds (30*60 ticks) and deals 100 fire damage per second (100/60 per tick). 3000 fire damage for ever getting hit by a spitter projectile from pretty much any high-tier spitter is more than a little annoying, especially if you're in a vehicle that doesn't have 3000 health. I wondered why my shielded chaingunner burned to death from a single spitter projectile until I looked at what those spitter projectiles were actually doing. Turns out I'd need a pair of mk4 vehicle energy shields just to counteract the burning damage from the fire-sticker (or, well, a pair of mk6 shields if the vehicle didn't have any fire resistance; at 50% fire resistance, which the chaingunner has, a pair of mk4 shields will do the trick).

Now, if fire spitters are supposed to be that deadly, then fine; I'll just have to live with needing enough firepower and/or shielding and/or repair power to make them no longer a concern (maybe it's my fault for using a vehicle that "only" has 50% fire resistance and 400 health, even if I do have 18 of them working together). But combined with the fact that their projectiles are still homing, it makes clearing nests (at least once fire spitters/worms start showing up) exceedingly annoying.

[bobingabout]

Factorio, like any other modern software, is discrete at its core.

Tiles are 32 pixels wide (on "normal" Full High Resolution).
In 0.17, each item on the belt takes 8 pixels (down from 9 in 0.16).
So, for a single lane, an item moving at 1 pixel per tick makes for :
1 pixel / tick * 60 ticks / second * 1 item / 8 pixels = 7.5 items / second
Double that to account for 2 lanes, and you get the 0.17 vanilla 15 items / s belt speed.

So items are going to move at best at simple fractions of pixels / tick.
And 18.75 items/s = 1.25 * 15 items/s = 5/4 pixels / tick
While 20 items/s would be = 1.33.. * 15 items/s = 4/3 pixels / tick
But both 32 and 8 are divisible by 4, but not by 3 !

There must be either a preference for rounding down or a divisor of 8 not working, because :
18.75 items/s = 1.25 * 15 items/s = 5/4 pixels / tick = 10/8 pixels / tick
is farther from 20 than
20.625 items/s = 1.375 * 15 items/s = 11/8 pixels /tick

So, some accurate speeds should be in theory :
1/4 pixels / tick = 3.75 items / s
2/4 pixels / tick = 7.5 items / s
3/4 pixels / tick = 11.25 items / s
4/4 pixels / tick = 15 items / s
5/4 pixels / tick = 18.75 items / s
6/4 pixels / tick = 22.5 items / s
7/4 pixels / tick = 26.25 items / s
8/4 pixels / tick = 30 items / s
...

P.S.: See also :
viewtopic.php?p=423163#p423163
EDIT : 3.5/4 pixels / tick = 7/8 pixels / tick = 13.125 items / s, which seems to be close to what mrvn found.
Not sure why 7/8 works, but 20i/s gets rounded down to 10/8px/ti=5/4px/ti, rather than up to 11/8px/ti ??

I think I have an answer (speculation etc) on why it only works in increments of 1/8th of a pixel. (why your 7/8 works for example)
Rseding was saying floating point numbers are a bitch of a slowdown when it comes to maths, so he's been replacing a lot of them with integers, or compound integers in some cases where you need a fraction.
what if the new belt speed optimisations include this type of change, and the fraction is only a byte for belt position?
why does this give us increments of 8ths only? to set a speed of 1 pixel per tick, you actually need to set 1/32 because you tell it speeds in TILES per tick. add in a 1/8 and you have a 1/(32*8) = 1/256, which is a byte for the fraction.
and because of the way this kind of computer maths works, anything being a fraction is just discarded, so everything always rounds down.

so therefore, only speeds of multiples of 1/8 pixels /tick actually work, which is multiples of 1.875.
Try setting it to 20.625 and see if that gives you 11/8 as you expected.

[BlueTemplar]

Oh, right, I even mentioned the potential rounding down (which would be just truncating in binary, more efficient than rounding to closest), not sure why I forgot about it in the end...
So [13.125 ; 15[ i/s would be rounded down to 7/8 px/tk = 13.125 i/s
And [18.75 ; 20.625[ i/s would be rounded down to 10/8 px/tk = 18.75 i/s

[Emprah]

The new update somehow just removed pollution from my game. None of the entities producing pollution anymore, neither the existing, nor the new ones.
https://imgur.com/a/1UqWfSq
The images were made in a 10 seconds time span.

If I start a new game, pollution is being made by entities.

[bobingabout]

The new update somehow just removed pollution from my game. None of the entities producing pollution anymore, neither the existing, nor the new ones.
https://imgur.com/a/1UqWfSq
The images were made in a 10 seconds time span.

If I start a new game, pollution is being made by entities.

Seems kind of unusual. All I did was change the pollution generation method to the new new one added in 0.17.29. in theory there are 3 different pollution generation systems in the game right now.

I did some tests, it seems for really low numbers, it appears like there's no pollution being generated. it's probably just dissipating so fast you can't see it. But for the heavier polluting stuff, it was spewing it out for me.

[kingarthur]

The new update somehow just removed pollution from my game. None of the entities producing pollution anymore, neither the existing, nor the new ones.
https://imgur.com/a/1UqWfSq
The images were made in a 10 seconds time span.

If I start a new game, pollution is being made by entities.

Seems kind of unusual. All I did was change the pollution generation method to the new new one added in 0.17.29. in theory there are 3 different pollution generation systems in the game right now.

I did some tests, it seems for really low numbers, it appears like there's no pollution being generated. it's probably just dissipating so fast you can't see it. But for the heavier polluting stuff, it was spewing it out for me.

Do you have any generator type entity's with emissions. Py mods is have the same issue and when I removed the emissions from the gas turbine and loaded a save from before I updated to the new emissions per minute it didnt cause any weird behavior or save bloating

[Ferlonas]

This sometimes happens when editing inserter pickup/dropoff positions:

Code: Select all

11591.128 Error MainLoop.cpp:1166: Exception at tick 1980569: The mod Bob's Adjustable Inserters mod caused a non-recoverable error.
Please report this error to the mod author.

Error while running event bobinserters::bob-inserter-open-gui (ID 143)
__bobinserters__/control.lua:1185: attempt to index local 'gui' (a nil value)
stack traceback:
        __bobinserters__/control.lua:1185: in function 'open_gui'
        __bobinserters__/control.lua:425: in function <__bobinserters__/control.lua:414>

I can not reproduce it and I can't say when exactly it occurs. It always happened when I was rapidly editing inserter positions and thus opening/closing the GUI fast.

[kingarthur]

The new update somehow just removed pollution from my game. None of the entities producing pollution anymore, neither the existing, nor the new ones.
https://imgur.com/a/1UqWfSq
The images were made in a 10 seconds time span.

If I start a new game, pollution is being made by entities.

Seems kind of unusual. All I did was change the pollution generation method to the new new one added in 0.17.29. in theory there are 3 different pollution generation systems in the game right now.

I did some tests, it seems for really low numbers, it appears like there's no pollution being generated. it's probably just dissipating so fast you can't see it. But for the heavier polluting stuff, it was spewing it out for me.

Do you have any generator type entity's with emissions. Py mods is have the same issue and when I removed the emissions from the gas turbine and loaded a save from before I updated to the new emissions per minute it didnt cause any weird behavior or save bloating

so i guess that is in fact a bug and is supposed to be fixed per viewtopic.php?f=30&t=69879

[bobingabout]

yes, that looks like the issue.

[Ferlonas]

This sometimes happens when editing inserter pickup/dropoff positions:

Code: Select all

11591.128 Error MainLoop.cpp:1166: Exception at tick 1980569: The mod Bob's Adjustable Inserters mod caused a non-recoverable error.
Please report this error to the mod author.

Error while running event bobinserters::bob-inserter-open-gui (ID 143)
__bobinserters__/control.lua:1185: attempt to index local 'gui' (a nil value)
stack traceback:
        __bobinserters__/control.lua:1185: in function 'open_gui'
        __bobinserters__/control.lua:425: in function <__bobinserters__/control.lua:414>

I can not reproduce it and I can't say when exactly it occurs. It always happened when I was rapidly editing inserter positions and thus opening/closing the GUI fast.

Found out how to reproduce it:

1. Click on an inserter. Configuration options and position GUI open
2. Hover over another inserter, press Shift+E to open position GUI
3. The aforementioned error appears

[Emprah]

The new update somehow just removed pollution from my game. None of the entities producing pollution anymore, neither the existing, nor the new ones.
https://imgur.com/a/1UqWfSq
The images were made in a 10 seconds time span.

If I start a new game, pollution is being made by entities.

Seems kind of unusual. All I did was change the pollution generation method to the new new one added in 0.17.29. in theory there are 3 different pollution generation systems in the game right now.

I did some tests, it seems for really low numbers, it appears like there's no pollution being generated. it's probably just dissipating so fast you can't see it. But for the heavier polluting stuff, it was spewing it out for me.

Do you have any generator type entity's with emissions. Py mods is have the same issue and when I removed the emissions from the gas turbine and loaded a save from before I updated to the new emissions per minute it didnt cause any weird behavior or save bloating

so i guess that is in fact a bug and is supposed to be fixed per viewtopic.php?f=30&t=69879

Yay, so I should wait till the next patch/fix

[bobingabout]

This sometimes happens when editing inserter pickup/dropoff positions:

Code: Select all

11591.128 Error MainLoop.cpp:1166: Exception at tick 1980569: The mod Bob's Adjustable Inserters mod caused a non-recoverable error.
Please report this error to the mod author.

Error while running event bobinserters::bob-inserter-open-gui (ID 143)
__bobinserters__/control.lua:1185: attempt to index local 'gui' (a nil value)
stack traceback:
        __bobinserters__/control.lua:1185: in function 'open_gui'
        __bobinserters__/control.lua:425: in function <__bobinserters__/control.lua:414>

I can not reproduce it and I can't say when exactly it occurs. It always happened when I was rapidly editing inserter positions and thus opening/closing the GUI fast.

Found out how to reproduce it:

1. Click on an inserter. Configuration options and position GUI open
2. Hover over another inserter, press Shift+E to open position GUI
3. The aforementioned error appears

The mentioned line (1185) is as follows:

Code: Select all

    player.opened = gui

when it should be as follows

Code: Select all

    player.opened = globtable.gui

EDIT: Actually, although this is an error, that's not the issue. it actually causes more issues when I fix this.

I noticed another error, when you walk away from an inserter with the middle GUI still open, it doesn't close.
This is because the code to do that is still commented out. I'll fix both these issues and update.

[Gladaed]

Not all Stationairy worms are updated to the new fireing mode, leading to a deadly mix of enemies. (bobs enemies mod)

[bobingabout]

Not all Stationairy worms are updated to the new fireing mode, leading to a deadly mix of enemies. (bobs enemies mod)

My tests showed they were, they still use a projectile instead of a stream, but should target a position ahead of you, and not home.

[largpack]

Hello there,

I think I've found a bug in Bobs Tech. I cant use logistic science any more (pink).
Instead of that, the lab shows two times the same sciece pack (the green one).

Please find a screenshot attached.

Could you please check it? That would be awesome!

Nice evening,
largpack

[bobingabout]

Hello there,

I think I've found a bug in Bobs Tech. I cant use logistic science any more (pink).
Instead of that, the lab shows two times the same sciece pack (the green one).

Please find a screenshot attached.

Could you please check it? That would be awesome!

Nice evening,
largpack

1. Those aren't my icons, check to see if it's an issue with another mod.
2. If this is a migrated save from 0.16, the old science pack 2 was renamed to logistic-science-pack internally, the same name as my Logistic science pack, all old Logistic science packs were changed to science pack 2 (The base game performs a migration and merges them before I can do anything to prevent it). You need to remove them from the lab, and you'll see a different pack in the slot. Also, for some reason the science packs have changed order, so you'll probably have to remove the end 4 and put them in the right places before the lab can continue as normal.