Inserter facing up/north slower than other directions

[joon]

HI,

So the problem is that the inserter facing north/up is slower, I did some tests with different setups and was able to confirm this
Also this porblem kept existing over different versions so thought make a bug report

Found this problem a little while ago when I had setup a line for battery factories, but don't have that factory setup anymore but I had the same problemwith a steam engine powerback up, as shown below, so I started to pay attention to it. There is at the moment of the screenshot no power shortage so the burner shouldn't be able to pick it, but it still does, multiple times in a time period because the electric inserter that is facing north is to slow to pick it up in time and putting it back in the chest. Also did some tests which are also below


...


So the tests where to compare the inserter with each other in different directions. Btw when I had the battery factoryline I used fast inserter so I think the bug is for all kind of inserters.

First tested the north vs south
Start


Halfway, the top row of the north is already slower


Later on, it's almost 1 item behind


2nd test, north vs west & east
Start


After a bit


Later on


...

It's on a Linux, don't know if that might be factor

[bobingabout]

This is an interesting find.

[SHiRKiT]

I can confirm this behavior. Just finished my testing, and picking from south and placing on north is slower than the reverse. I can confirm this in the following scenarions:
- Regular inserters picking from chests and placing on belts.
- Regular inserters picking from chests and placing on chests (inserter stack size has no impact on this)
- Fast inserters picking from chests and placing on belts
- Fast inserters picking from chests and placing on chests
- Long-handed inserter picking from chests and placing on chests
- Long-handed inserter picking from chests and placing on belts

So probably is some other thing. Turn speed or drop point is the guy to be blamed? Or maybe the math to turn the inserter?

[bobingabout]

So probably is some other thing. Turn speed or drop point is the guy to be blamed? Or maybe the math to turn the inserter?

Sugestion to help you try and identify if it's turn speed, or extend speed causing the issue.
Change the definitions, double the extend speed. if this solves the issue, then obviously it was the extend speed causing the problem, if it doesn't solve the issue, then it's turn speed.

I found while trying to mod in faster inserters that especially for long inserters, the extend speed caused quite a few issues.

[waduk]

Wow,..nice find !

Another confirm using

Item counter

The test : Item counter to move 200 advanced circuit from chest

The result...
Regular North : 485
Regular East : 478
Regular West : 478
Regular South : 478

Fast North : 206
Fast East : 200
Fast West : 200
Fast South : 200

Smart North : 206
Smart East : 200
Smart West : 200
Smart South : 200

Long North : 352
Long East : 345
Long West : 345
Long South : 345

TLDR : Wow, it really took north facing inserter longer to move thing, either it's regular, fast, smart or long handed one.

[slpwnd]

Interesting. I never stop wandering what you guys are able to come up with=) Still, putting this one to minor for now because we are really eager to get the stable ASAP.

[AntiElitz]

While testing some stuff i noticed that inserters that are headed upwards are slower than the others. So i ran a test setup and made a video of it to show you.

https://youtu.be/ATMJFgzaSoo

[Twinsen]

Does this actually cause any gameplay annoyances in some setups?

[joon]

For me yes. Like the backup steam power the setup has to be made different. Also applies to loading and offloading of chests/trains/factories. Like I have to build it so that the inserters are facing most of the time east/west to make sure that it is "balanced", which is a bit lame tbh. And I don't really want to worry about how I going to build my factory because of a bug, while it should be equal speed in the first place.

Edit: it's also now the 4th report on it by people so other people also notice it

[AntiElitz]

The difference is about 5% in some cases. That is way too much to be called minor imo. This causes a problem in one of my red circuits layouts i never understood. I rotated it now and it works ways better. This bug was already found half a year ago and is still not fixed. It should be now.

[Rseding91]

The difference is about 5% in some cases. That is way too much to be called minor imo. This causes a problem in one of my red circuits layouts i never understood. I rotated it now and it works ways better. This bug was already found half a year ago and is still not fixed. It should be now.

There are far more important things to fix: crashes, save corruption, multiplayer desync, and so on.

[Captain Taz]

Oh wow, I didn't even know this was a thing o_o

My natural flow of resources is always south-to-north, as that's how linear i like my factories... It satisfies my OCD and I can find things easily...

I always build my train stations with unloading on the north side...

I also build my main busses north-ward and then break off east or west and load factories northward....

well.... god damn it all ._. Thanks for this enlightening thread.

[JackB1024]

For when you all decide to work on this issue, I managed to find out what appears to be the cause of it.
Inserters that are faced north will place their first item down the tick after they arrive at the target orientation, while all other directions will put the first item down on the tick that they arrive at their target orientation.


Did some recording and looked at it frame by frame in virtual dub, here is the frame before any inserter puts down an item, all inserters are still 1 tick away from their target orientation

(See https://drive.google.com/file/d/0Bx5xYr ... ef=2&pli=1 for a better view)


On the next tick, all the inserters arrive at their target orientation. Those facing any direction but north also put down their first item (you can see the LED on the belts turn green as they detect an item)

(See https://drive.google.com/file/d/0Bx5xYr ... ef=2&pli=1 for a better view)


On the next tick, the fact that non-north facing inserters have put down an item is reflected in the lights. Also north facing inserter puts down its first item (seen by the green LED on the belt).

(See https://drive.google.com/file/d/0Bx5xYr ... ef=2&pli=1 for a better view)


Tested this with normal, fast, long and stack inserters and they all had the same 1 tick delay for north facing.
Also, long handed inserters do not place the item on the same tick as the one in which they get to their target orientation, instead north facing ones will arrive at the target orientation, then on the next tick do nothing, and then on the tick after that place their first item. Those facing other directions do not have the 1 tick where they do nothing.

Everything was tested with placing the items on belts, but as it seems to be a tick delay before placing the first item, I'm sure the same result would be seen when placing in chests / assembly machines.
Tested with build 0.13.19

[can00336]

Has this bug been looked at or fixed?

[Loewchen]

Has this bug been looked at or fixed?

The answer to this question can be found in this thread already.

[JackB1024]

So I managed to find exactly what is causing this bug and fixed it for one inserter in my own little test world (the actual fix would require a code change).

Note: This is going to get kind of technical because I used Visual Studio to modified memory in game to get the fix to work, hopefully the developers should be able to track down the exact locations I am talking about and get the fix out.

So the issue occurs inside the moveHandToInternal<ElectricEnergySource>(Inserter *, ElectricEnergySource &, Vector, RealOrientation) function, there is a check to see if the inserter location is correct

Code: Select all

000000013FCB89A5  ucomiss     xmm0,xmm1

is the opcode in question, xmm0 contains the current orientation, xmm1 contains the desired orientation.
For inserters facing east/south/west xmm1 contains the values 0.25/0.5/0.75 respectively, however for inserters facing in the north direction xmm1 contains 1.39137688e-08.
When inserters are moving north, they will reach 0.0 at the exact same time as inserters facing the other directions, however because 0 != 1.39...e-08 the inserters will not return 1 from this function, which would signifying that they are able to drop their item.

Now to fix this issue, if you move instead to the Inserter::update(void) function just before it calls moveHandToInternal you get a value from the inserter object

Code: Select all

000000013F6DE07F  mov         r9d,dword ptr [rdi+168h]

rdi is the inserter object, r9d is the parameter passed into the function (what I assume to be RealOrientation looking at the function definition, but it may be Vector).
r9d contains the correct values for most inserter directions, however for north facing inserters it has a value of 0x326f0967 which causes xmm1 to be the incorrect value. I found replacing this value with 0x00000000 to correct the 1 tick delay and still result in inserters working as expected.

Below is a youtube video showing that changing the value in [rdi + 168h] does indeed fix the inserter bug, with the northward facing inserter on the left using the new value of 0x0, while the northward facing inserter on the right uses the old value of 0x326f0967.

https://www.youtube.com/watch?v=jFF5M_k ... e=youtu.be

[Zulan]

That's funny, I arrived at the very same conclusion yesterday evening without even knowing the reddit thread by then, but wanted to write it up nicely today. I was going to take a look at it since Rseding said it would be fixed if they knew what caused it and if it was an easy fix.

At first I was a bit sidetracked by the surprisingly odd hand-movements over the turn of an inserter, but then I saw the instruction trace difference via gdb and it makes perfect sense: 0 != 1.39138e-08 is more problematic in terms of rounding than 0.25 != 0.25. As they say, if you try to solve one problem with floating point, you have 1.999999999 problems. There is a good explanation of the issue including how to handle it properly at the C++ FAQ.

[JackB1024]

So after looking into how rotation works with an inserter, I seem to have managed to close in even further on the issue:
Inserter::setupDropoffVector(void) has the following code:

Code: Select all

000000013F6E0476  movsd       xmm1,mmword ptr [rbx+1F0h]  
000000013F6E047E  xorps       xmm1,xmmword ptr [__xmm@80000000000000008000000000000000 (01403C82F0h)]  
000000013F6E0485  movsd       xmm0,mmword ptr [rbx+1E8h]  
000000013F6E048D  call        Math::atan2 (013FAF20C0h)  
000000013F6E0492  mulsd       xmm0,mmword ptr [__real@3fd45f306dc9c883 (01403C6D30h)]  
000000013F6E049A  xorps       xmm1,xmm1  
000000013F6E049D  divsd       xmm0,mmword ptr [__real@4000000000000000 (01403C7120h)]  
000000013F6E04A5  cvtsd2ss    xmm1,xmm0  

The call to Math::atan2 returns a close, but not quite correct value for any rotation (2.7827536898742794e-08,0.50000000379580789,1.0000000000000000,-0.49999998608623181 for North/East/South/West drop offs). This value is then halved by divsd and then converted into a double via cvtsd2ss.
For most values the fact that atan2 returns a not-quite correct value doesn't matter, becuse the rounding for converting it from a double to a float gets rid of the errors, however with North, because the expected value is 0, all that is left is the error and it can convert that quite accurately.

So in C++ the code is probably something like:

Code: Select all

float dropOffVector = static_cast<float>(Math::atan2(a,b) / 2);

Due to the fact the expected values are 0/0.25/0.5/0.75 you could probably just add a rounding around either the atan2 call or the final vector to get rid off this rounding error.

[Twinsen]

I'm not even mad, this is amazing.
I'm fixing it right now.

[Twinsen]

The problem was a bit deeper. The vector given to the atan2 was rotated imprecisely.

Fixed it in Version: 0.15.14.
Modded inserters that change vectors at run-time might still have this problem, but the base game now works properly.

Capture.PNG (368.71 KiB) Viewed 22056 times