Page 1 of 1

[0.17.x] Belt speed missmatch

Posted: Sat Mar 16, 2019 7:00 pm
by bobingabout
The speed of the belt graphics and the speed of the items moving on the belt are not the same speed in certain situations.

Install the entire bobs mods suite from the mod portal. Though technically for this issue you only need Library and logistics.
https://mods.factorio.com/mods/Bobingabout
the belt speed overhaul setting in the logistics mod must be enabled, and the belt speed set to 12.5 items per second. (I think that's the defaults)

Grey and Blue belts move at a miss-matched speed.
https://www.dropbox.com/s/dv9aqwwgvgztv ... 5.mp4?dl=0

I double checked, there's nothing in the data files that should account for the speed mismatch.

Re: [0.17.x] Belt speed missmatch

Posted: Sat Mar 16, 2019 8:05 pm
by darkfrei
For example in 0.16 in the Loader Furnace the crafting_speed was 140/3, and now the crafting_speed is 144/3.
Just update the speed of belt or speed of animation to new one.

In 0.17

Code: Select all

every_belt.animation_speed_coefficient = 32, 
yellow_belt.speed = 0.03125

Re: [0.17.x] Belt speed missmatch

Posted: Sun Mar 17, 2019 3:21 am
by bobingabout
darkfrei wrote:
Sat Mar 16, 2019 8:05 pm
For example in 0.16 in the Loader Furnace the crafting_speed was 140/3, and now the crafting_speed is 144/3.
Just update the speed of belt or speed of animation to new one.

In 0.17

Code: Select all

every_belt.animation_speed_coefficient = 32, 
yellow_belt.speed = 0.03125
uuuhh, Yeah, I know this. the speeds are set to the correct animation speed coefficient, and the belt speed that I'm after, but the animation is out of sync to the item travel anyway.

Re: [0.17.x] Belt speed missmatch

Posted: Mon Apr 15, 2019 1:15 pm
by bobingabout
It seems it could be a bit more of an issue than just the graphics not matching the item movements:
mrvn wrote:
Mon Apr 15, 2019 11:26 am
I love the overhault belts and inserters. The colors and recipes for the tires just fit all over. That said the speed overhaul is pretty broken, which is probably nothing you can do about.

When using the default speed override of 12.5 what you actually get is 11.2 or so. Internaly items seem to move an integer amount of pixels every now and then. With 60 ticks/s there is only a limited number of speeds that works right. I'm not even sure there are other speeds than the 7.5 / 15 / 30 / 45 / 60 sequence that works out nicely internally.

I want at least a speed of 12 because many recipes result in 1, 2, 3, 4 or 6 item/s which are all factors of 12. From testing with come combinators to measure belt speed I tried to find one that's just about 12 items/s and here is what I've got:

Setting speed to 12.5 gives ~11.2 items/s. That remains up to speed 13.1. Setting speed 13.2 (or was it 13.3?) it jumps to a real speed of 13.15 items/s. That seems to be the smallest speed above 12.

Re: [0.17.x] Belt speed missmatch

Posted: Thu Apr 18, 2019 4:59 pm
by Mpmpmpmp
Found same issue (both with bob's and another guy's belt speed mod)

work well at 15 /(2*n) (tested with 3.75)

but every other don't

especially the interesting 12 i/s


thought it may be a problem with bob's but same ith other mod

tested on belt consumed one hour run

Re: [0.17.x] Belt speed missmatch

Posted: Tue Apr 23, 2019 10:53 am
by Klonan
I think this is just a case that when the belt speed is not a integer number of pixels, the animation and item movement won't be exactly the same

Since base game has no problem, I am moving to minor issues

Re: [0.17.x] Belt speed missmatch

Posted: Sun May 05, 2019 1:58 pm
by bobingabout
from what I understand... the belt graphics move with whatever speed you set it to, but the items movement speed is rounded down to the nearest whole "Pixels per tick" value...

actually, it's not pixels per tick, it's tile byte fractions per tick. 1 pixel every 8 ticks still works, as if you divide a tile by 256 instead of 32, it still works, just moves one pixel every 8 ticks.
And although I personally have not tested this speed, I do have a perfectly functional 7.5 items per second, which is half a pixel per tick. and others have tested with 3.765, or a quarter pixel per tick. I'm just speculating that an 8th of a pixel per tick works due to some of the reported working speeds, and my own personal maths that such speeds are increments of 256ths of a tile.