[0.13.4] item size change not reflected in LuaTransportLine?

[CmdrKeen]

item size changes to seem to of broken LuaTransportLine::insert_at_back(items)

[Rseding91]

Can you give screenshots and a test save + steps to reproduce what you're thinking is an error?

[CmdrKeen]

sorry about the shortened initial bug report, there was supposed to be more there. (remind me not to bug report when sleepy...)

the changes appear to alter how frequently items can be placed on belts:

expected behavior, seen in 0.13.0:

expected behavior (0.13.0)

13.0.jpg (135.71 KiB) Viewed 1716 times

behavior in 0.13.4:

behavior in 0.13.4

13.4.jpg (138.11 KiB) Viewed 1716 times

save file used:

compoundsplitters2-2.zip

(2.95 MiB) Downloaded 86 times

(turn the c-combinator to on to start test)

[Rseding91]

The change to transport line spacing was *so* incredibly tiny. less than half a pixel per transport belt. Nothing that could possibly have the effect you're seeing in those screenshots.

[Rseding91]

What you're experiencing is due to how you insert: can_insert_at_back returns true if there's sufficient space for the item. The belt only moves so fast so it moves *just* not far enough that it can't fit another item on the belt 1 tick later.

2 ticks later it can but now there's 9/10ths of an item room between them and so you get what you're seeing.

[CmdrKeen]

This actually is a bug stemming from 0.13.3 changes:

Increased the distance between items on the belt from 0.28 to 0.28125. This way the the circuit network pulse for items will be every 9/4.5/3 ticks for normal/fast/express compressed belts. (27686)

I fixed the problem by changing insert_at_back() to insert_at((1-0.00125),cS)

I'm not sure what other api functions in LuaTransportLine are impacted by the change. can_insert_at_back() for one appears unaffected.