Reversal of Locomotives
CovertJaguar opened this issue ยท 21 comments
- Linkages pushing on Locomotives can cause reversal
- Turns out this is due to some code in the Locomotive that will switch the direction of Shutdown Locomotives to face the direction of travel.
- The purpose of this code was to allow Dispensing of Locomotives.
- Solution: Move to Control Track.
- Rubber-banding around corners
- This is usually caused by Loaders.
- Solution A: Fix corners.
- Solution B: Remove cause of rubber-banding?
I solved this by moving the relevant code into the Control Track. This way you can still use Control Tracks to set the initial facing of Locomotives when Dispensing them, but this should remove a potential point of flip failure from the majority of use cases. Doesn't mean there aren't still issues, eg. corners.
I have a system with lockdown tracks (not train lockdowns as they weren't triggering in time and the train would pass on through)
The item unloader unloads the diamond chest cart being held by a lockdown track. The locomotive is trying to train itself away and keeps rubber-banding and as such flipping around.
Ah, yes the corner bug! That might be good enough to reproduce.
Though locking tracks lock the entire train (including locomotive, puts it in idle), so it should at most only rubber band once from locomotive force. Though I suppose linking force could keep it going.
The rubber-banding effect was continuous with a diamond chest cart and a lockdown track (not in locomotive lockdown, just lockdown).
Upon the first rubber-band pull back on the loco, it flipped.
I will try and move out the track a bit to ensure no corners when stopped.
Correct, the only tracks on that line are lockdown for the loaders/unloaders- it was in "Running >>"
I can get this to work (read: break) 100% right now. If you care to witness for yourself, let me know
(It flipped as it tried to round the corner, then rubberbands back)
4 other stops have extended egress rails and do not have the issue.
So it appears to happen when you have a trickle loader. Using enderIO conduits, they do 4/tic or 4/sec (whichever it is I don't know) base. As in 4 items moved/cycle.
This causes the immediate mode loaders/unloaders to emit a signal and then quickly stop (due to items in loader) and it turns the rs signal on/off very quickly. This causes the train to try and go/stop thus rubber-banding. If this happens when the loco is on a corner, it often flips.
From what I can tell, this is what's happening in my case at least.
Last thing, I think if the loco makes it around the corner before the rubber-band effect, it flips during that time.
Ah...yep, that could probably cause rubber banding. I could probably prevent the rubber banding without too much effort with some simple modifications to the loader.
The problem appears to be the limits. 100 would likely be better than 170.
This should be fixable by adding my own flip detection.
So that completely buggered the client side flip detection... Seems to have fixed the server side flips though.
Here is the corner bug in action: http://i.imgur.com/7Ti947d.gifv
Interesting thing happened here. When I broke the electric loco with a pickaxe, the carts split into 2 groups (split around the corner) and went shooting off down the track as if being pulled by some imaginary loco (or releasing all the stored up rubber band energy) :)
Edit: I should mention that train is electric loco : batbox : batbox : tank : tank
Somehow one of the tank carts got between the loco and first bat box as seen in the gif
The linkage code can impart a fair bit of energy on the cart. I actually cap it because in some initial tests it was sufficient to launch carts to the horizon.
Alright! I have fixed the Loader and now have a working (flipping) test case.
Somewhere is here it flips:
[01:13:36] [Server thread/INFO] [railcraft]: tick=53,388, reverse=true, yaw=0
[01:13:42] [Server thread/INFO] [railcraft]: tick=53,515, reverse=true, yaw=63.312
[01:13:42] [Server thread/INFO] [railcraft]: tick=53,516, reverse=true, yaw=45
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,517, reverse=true, yaw=63.842
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,518, reverse=true, yaw=265.945
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,519, reverse=true, yaw=199.001
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,520, reverse=true, yaw=225
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,521, reverse=true, yaw=225
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,523, reverse=false, yaw=225
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,524, reverse=false, yaw=-135
I'm not entirely sure where. The reverse Boolean is just used in calculating yaw, yaw is the absolute determinator of facing. This happens on a corner, it starts at yaw=0 on the straight and ends flipped at yaw=-135 on the corner.
This appears to be the where the flip happened:
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,517, reverse=true, yaw=63.842
[01:13:43] [Server thread/INFO] [railcraft]: tick=53,518, reverse=true, yaw=265.945
if (d0 * d0 + d2 * d2 > 0.001D)
{
this.rotationYaw = (float)(MathHelper.atan2(d2, d0) * 180.0D / Math.PI); // rotationYaw=85.945
if (this.isInReverse) // true
{
this.rotationYaw += 180.0F; // rotationYaw=265.945
}
}
// prevRotationYaw=63.842
double d3 = (double)MathHelper.wrapDegrees(this.rotationYaw - this.prevRotationYaw); // d3=-157.897
if (d3 < -170.0D || d3 >= 170.0D)
{
this.rotationYaw += 180.0F;
this.isInReverse = !this.isInReverse;
}
this.setRotation(this.rotationYaw, this.rotationPitch);
What I am seeing in 10.0.0 is that if I issue a /entitydata command to start a freshly created perpetuum loco (the only one I have tested) and the loco is facing south, it will take off to the north. Once I stop the loco, I cannot reproduce the problem again on that loco. I do not have this problem on an east-west track.
I.e,
/entitydata @e[type=railcraft.locomotive_creative] {locoMode:2b}
causes this problem, but only on the first call. After that, the loco takes off in the direction it is facing.