[Csantucci]

I already had this suspect, but now I have the proof. I have a tram route with very sharp curves and 0% gradient everywhere. If I stop the tram in the curve and release the brakes, the tram begins moving backwards faster and faster, until curve is terminated (where speed slowly decreases), see picture. I suppose there is something that should be adjusted.

[R H Steele]

Csantucci, on 02 May 2015 - 01:07 PM, said:

I already had this suspect, but now I have the proof. I have a tram route with very sharp curves and 0% gradient everywhere. If I stop the tram in the curve and release the brakes, the tram begins moving backwards faster and faster, until curve is terminated (where speed slowly decreases), see picture. I suppose there is something that should be adjusted.
Curveforce.jpg

Just asking, would that have anything to do with what I mentioned in this thread: http://www.elvastowe...nt-speed-limit/

[steamer_ctn]

Csantucci, on 02 May 2015 - 01:07 PM, said:

I already had this suspect, but now I have the proof. I have a tram route with very sharp curves and 0% gradient everywhere. If I stop the tram in the curve and release the brakes, the tram begins moving backwards faster and faster, until curve is terminated (where speed slowly decreases), see picture. I suppose there is something that should be adjusted.

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

[steamer_ctn]

I have had a quick look at issue i), and it appears that the Curve and Tunnel forces are inserted into the wrong location for TotalForceN. I will patch the code within the next day, once I have done some more checking. The patch will prevent the forces from acting upon the train unless it is moving, in the same manner as the Friction forces do.

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

[Csantucci]

Hi Peter,
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: 188
and here the patched runactivities to test. It seems to me that they work correctly.
 Runactivities.zip (1.3MB)
Number of downloads: 202

If you have time, pls. check it.

[steamer_ctn]

Hi Carlo,

Csantucci, on 03 May 2015 - 01:08 AM, said:

I worked in parallel to you, also on the tunnel force, which is handled the same way.
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

[Csantucci]

That's good that you see things like I do.
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.

[steamer_ctn]

Csantucci, on 03 May 2015 - 05:10 AM, said:

That's good that you see things like I do.

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:

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.

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.

[roeter]

The method physicsPreUpdate in TTTrain.cs was copied from physicsUpdate in Train.cs before the tunnel resistance was added, which is why tunnel resistance is not included here - it was overlooked when tunnel resistance was added.
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.

[Csantucci]

I simply extended the since long time pre-existing logic of the friction force to that of curve force and tunnel force, that are of the same nature. So, as friction force seems to work as it should, I expect that also curve force and tunnel force do. The clamping logic you describe seems to me present in UpdateCarSpeeds, under "start cars moving forward" and "start cars moving backward".
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.

[roeter]

The coupler forces calculation was not included in the preupdate because it's effect is limited and there was a strong need to reduce the total calculation.
Originally, physics were not used in pre-update at all, and this is still the case for pre-update for activities (check AIPreUpdate in AITrain.cs).
For timetables, a closer approximation to 'normal' running was required during pre-update to keep the trains to the booked timings, but as the pre-update may have to calculate the running of AI trains for many hours (depending on selected player train), the full update would take too much time. Hence the reduced version, which does indeed come quite close to normal running.
A deeper look into all these calculations might be a good idea, including a better version of the 'reduced' calculation for pre-update - but post version V1.0.
As mentioned, the problem affecting the player train in curves does not affect AI trains during pre-update, so just set that patch for now and make a note to have a more extended look at all this later.

Regards,
Rob Roeterdink

[steamer_ctn]

Thanks Rob for the feedback, and suggestions.

I agree that whilst friction, curve and tunnel force are all zero unless moving, it was handy to have them appearing in the HUD even when stationary. This makes it easier to check wagon setups, etc, and check calculations, etc.

So as suggested, perhaps if we just fix the immediate problem now in regard to the train performance, and investigate it more fully post version 1. Perhaps as part of the patch some notes can be added to the code as explanation for the future investigation.

[scottb613]

Hi Folks,

One thing I've noticed that may or may not be related - is if I stop with the locomotive in the curve of a switch - sometimes it's impossible to get it moving again... This same consists starts easily if the locomotives are clear of the switch... I can get more specifics if needed...

Regards,
Scott

[steamer_ctn]

scottb613, on 04 May 2015 - 04:23 AM, said:

One thing I've noticed that may or may not be related - is if I stop with the locomotive in the curve of a switch - sometimes it's impossible to get it moving again... This same consists starts easily if the locomotives are clear of the switch... I can get more specifics if needed...

A point has a very tight radius curve, and therefore will depending upon the loco and car wheelbases, etc, possibly represent a large resistance to movement. Whether this resistance in reality is large enough to stop the train from moving at all would need to be looked into further.

Can you post a screenshot of the Forces HUD for the scenario described. Please also advise the type of point and locomotive, etc.

Thanks

[Csantucci]

A bug report has been filed here https://bugs.launchp...or/+bug/1451709 .