Closed twpol closed 11 years ago
Property | Value |
---|---|
Posted by | Peter Gulyas (pzgulyas) |
Date posted | Mon, 25 Feb 2013 11:53:22 GMT |
This bug is a keyboard handling issue, not a notch controller defect. Because of this it affects not only the brake controller, but all smooth controllers: Regulator/Throttle, Dynamic brake, Engine brake.
The problem is the "jump" of percent value at key hitting moment. When the key is held down continuously, the increase/decrease of the percent value is calculated correctly. But at pressing time the value gets a boost, as if it had been pressed many tenth seconds ago.
This bug is uncomfortable especially at controllers set to e.g. 0.1 as smooth "step" as shown at example above, because that means the value should change by 10% in 0.1 second. But in case the value is at lets say 8%, and the user hits the increase key, it jumps immediately to value at about 70%, and starts increasing by 10%/0.1s from that, instead of just simply start increasing by the predefined 10%/0.1s speed.
This is a general timing issue of keyboard handling.
Property | Value |
---|---|
Posted by | Peter Gulyas (pzgulyas) |
Date posted | Tue, 26 Feb 2013 19:22:43 GMT |
Well, after trying to investigate the reason of this bug in source code, I have to revise my previous opinion: it is definitely a notch controller bug. The reason is that the current notch controller implementation doesn't handle controllers very well in case they are partly stepped and partly smooth. This incorrect handling also affects fully smooth controllers too. I am trying to fix it. (I think none of the developers are much interested in fixing it, since there are no active responsible developers for the notch controller currently.)
Property | Value |
---|---|
Posted by | Peter Gulyas (pzgulyas) |
Date posted | Fri, 01 Mar 2013 23:38:28 GMT |
I fixed the wrong operation of notch controller. Now it can handle configurations of partly-notched-partly-smooth controllers. There is no longer problem with initial jumping (the "sensitivity") of the percent value. Also cleaned up the code with partly revising my previous modifications in r1380, 1384, 1387.
I also implemented the functionality of DynamicBrakesDelayTimeBeforeEngaging, as suggested in forum thread http://www.trainsim.com/vbts/showthread.php?313028-Suggestion-Dynamic-brake-operation&p=1793702&highlight=suggestion#post1793702
All in all, I think it works now better than it ever did. So I really kindly ask developers to apply this patch and commit to svn trunk. (I have no write access, so I cannot do it myself.)
Property | Value |
---|---|
Posted by | disc (disc86543) |
Date posted | Mon, 18 Mar 2013 21:22:05 GMT |
Still noone applied this patch to the release? A lot of rolling stock is unuseable, because the brakes can't be handled.
Property | Value |
---|---|
Posted by | cjakeman (cjakeman) |
Date posted | Tue, 19 Mar 2013 07:54:47 GMT |
Hi Kerko,
Not yet, but we'll get there.
Should get some time off at Easter.
Best wishes,
Chris
Imported from https://bugs.launchpad.net/bugs/1120678
Since the Signal update (X1395) i noticed that a lots of rolling stock have way too sensitive trainbrake levers. An example: the brake is at release, i touch the brake apply button (just push for a moment and release), -> LAP, next touch -> ~8% service, next touch -> 70+% service... next, emergency. Even for a little touch it changes about 60%, both up and down, so it's very hard to control.
Here is the brake notching section of one of these locomotives: Brake_Train ( 0 1 0.1 0.4 NumNotches ( 5 Notch ( 0 0 TrainBrakesControllerReleaseStart ) Notch ( 0.1 0 TrainBrakesControllerHoldStart ) Notch ( 0.2 1 TrainBrakesControllerGraduatedSelfLapLimitedHoldingStart ) Notch ( 0.9 0 TrainBrakesControllerContinuousServiceStart ) Notch ( 1.0 0 TrainBrakesControllerEmergencyStart )