Curve force accelerates trains instead of braking them
#1
Posted 02 May 2015 - 01:07 PM
#2
Posted 02 May 2015 - 03:18 PM
Csantucci, on 02 May 2015 - 01:07 PM, said:
Curveforce.jpg
Just asking, would that have anything to do with what I mentioned in this thread: http://www.elvastowe...nt-speed-limit/
#3
Posted 02 May 2015 - 11:19 PM
Csantucci, on 02 May 2015 - 01:07 PM, said:
A rail vehicle going around a curve will meet resistance, which will tend to slow it down, so from that perspective it will be a negative force. It will be in the same sense as the friction force.
Your scenario appears to raise two questions:
i) why is the wagon moving on a level section of track? Like the friction force, the curve force should not appear in the Total value.
ii) why is the curve resistance value so large, as I would not expect it to exceed the friction values for the wagon?
Can you please post or PM the ENG file, and I will have a look at it.
Thanks
#4
Posted 03 May 2015 - 12:29 AM
A question for the developer of TTTrains.cs - line 1313 - given that there is no FrictionForceN in the line, should CurveForceN be removed from this line? Alternatively should friction, tunnel, and curve forces be included?
In regards to ii) please advise curve radius, as well.
Thanks
#5
Posted 03 May 2015 - 01:08 AM
I worked in parallel to you, also on the tunnel force, which is handled the same way.
Here is the patch I generated
Train_curveforce.cs.patch.zip (972bytes)
Number of downloads: 148
and here the patched runactivities to test. It seems to me that they work correctly.
Runactivities.zip (1.3MB)
Number of downloads: 161
If you have time, pls. check it.
#6
Posted 03 May 2015 - 02:05 AM
Csantucci, on 03 May 2015 - 01:08 AM, said:
Here is the patch I generated
It appears to be the same patch that I was contemplating.
The only outstanding issue may be the line of code in TTTrains.cs. It either needs CurveForceN deleted, or TunnelForceN added.
Do you want to commit the patch that you have created?
Thanks
#7
Posted 03 May 2015 - 05:10 AM
If you have nothing against that, I would wait some further hours to see if some remarks against the patch arise, and then I would commit the patch.
Referring TTTrains.cs, you're right: the line has to be modified; the how is a bit a problem. The insertion of the curve force and of the tunnel force into the car total force is done in the first lines of ComputeCouplerForce. However this method is not called within the pre-update phase of the AI Timetable trains. So, if tunnel force and curve force are not inserted in line 1313, these forces are not considered at all in the pre-update phase. If they are inserted, we are again in the case of the bug.
The clean solution would be to extract from ComputeCouplerForces the first five lines that add the various forces, to make another method out of it, and to call such simple method also within AIPreUpdate of TTTrain.cs. Let's wait for comments on this.
#8
Posted 03 May 2015 - 12:38 PM
Csantucci, on 03 May 2015 - 05:10 AM, said:
I am happy for you to update when you are comfortable with the status of the patch.
Csantucci, on 03 May 2015 - 05:10 AM, said:
Referring TTTrains.cs, you're right: the line has to be modified; the how is a bit a problem. The insertion of the curve force and of the tunnel force into the car total force is done in the first lines of ComputeCouplerForce. However this method is not called within the pre-update phase of the AI Timetable trains. So, if tunnel force and curve force are not inserted in line 1313, these forces are not considered at all in the pre-update phase. If they are inserted, we are again in the case of the bug.
The clean solution would be to extract from ComputeCouplerForces the first five lines that add the various forces, to make another method out of it, and to call such simple method also within AIPreUpdate of TTTrain.cs. Let's wait for comments on this.
I agree.
FrictionForceN is also not considered here either.
I agree that it would be better to calculate the Total force in one location, thus also eliminating the risk of different results in different locations.
#9
Posted 03 May 2015 - 02:45 PM
As for friction force : that's not included in physicsUpdate in Train.cs either - at least it was not when this method in TTTrain.cs was copied from physicsUpdate.
There is no danger of Timetable trains during pre-update starting to move because of the curve or tunnel forces (if the latter is added), for if Timetable trains are stopped, they always have 100% brake application, and furthermore the speed is 'locked' to zero.
As the name and the comment clearly state, this method is used during pre-update only, and therefor is not used on the player train.
Regards,
Rob Roeterdink
PS. I think the patch is not quite correct.
The total of the additional forces - that is all forces combined in :
(Cars[i].FrictionForceN + Cars[i].BrakeForceN + Cars[i].CurveForceN + Cars[i].TunnelForceN);
can never exceed the total force resulting from power and gravity.
So, before this statement :
Cars[i].TotalForceN -= (Cars[i].FrictionForceN + Cars[i].BrakeForceN + Cars[i].CurveForceN + Cars[i].TunnelForceN);
the value of (Cars[i].FrictionForceN + Cars[i].BrakeForceN + Cars[i].CurveForceN + Cars[i].TunnelForceN) should be clamped to the present value of Cars[i].TotalForceN such that Cars[i].TotalForceN cannot change sign but would have mimimum value of 0.
Same for negative speeds, where TotalForceN has a maximum of 0.
Remember that Friction Force, Curve Force and Tunnel Force are all 0 when the train is stationary.
#10
Posted 03 May 2015 - 10:00 PM
If you go to the force HUD, you will see that the friction force is > 0 also at speed = to 0 (already before addition of my patch and addition of curve and tunnel forces). This, although formally incorrect, has no influence on speed.
So I don't have the intention to modify also the pre-existing logic of friction and braking force. This can eventually be done by the author of such code or someone else, if considered valid.
I think the friction force was already included in the physics update when you generated your own version for timetable mode; it is included (let's better say hidden) in ComputeCouplerForces, that is a method that you didn't use in your simplified version for pre-update.