Why does this .cvf move the engine in opposite direction? MSTS does it right
#21
Posted 16 January 2015 - 02:39 AM
I think the problem lies in how OR looks at a cabview and shapefile together. If the shape is made SHF but has normal cvf file with one view shown as LHF the engine will move SHF when in forward motion. If however the CVF is made with a normal and a reversed cabview, then changing cab to reverse view will result in the engine moving LHF.
If the shape is built as LHF then it will move forwards in the LHF direction. If the engine shown in the first picture is actually made LHF then forwards is over the refuelling pad.
If the shape is built as LHF then it will move forwards in the LHF direction. If the engine shown in the first picture is actually made LHF then forwards is over the refuelling pad.
#23
Posted 16 January 2015 - 06:24 AM
OR handles all cabviews in the same way, be they .cvf or _rv.cvf. Forward direction is always the one the train driver is looking at. Such direction coincides with the .s file direction if the second parameter of the first Direction() statement is between -90 and +90.
There could be a problem if both the .cvf and the _rv.cvf look at the same direction.
If the complete .cvf and .eng files of this engine could be provided here maybe it would be easier to progress towards solution. If two .cvf files are available, both should be provided.
There could be a problem if both the .cvf and the _rv.cvf look at the same direction.
If the complete .cvf and .eng files of this engine could be provided here maybe it would be easier to progress towards solution. If two .cvf files are available, both should be provided.
#24
Posted 16 January 2015 - 04:28 PM
Erased.
Attached File(s)
-
NS3193.zip (5.84K)
Number of downloads: 158
#25
Posted 17 January 2015 - 01:17 AM
Thanks Jeffrey,
I was able to reproduce the behavior. That's the first step.
I was able to reproduce the behavior. That's the first step.
#26
Posted 17 January 2015 - 03:19 AM
There is in fact a difference between MSTS and OR: while OR firmly looks at the cab orientation to define what is "forward", MSTS seems to have a bit an awkward rule, at least in the following case (that should also be the case of the NS3193).
Attached you have a pack with 2 consists and an additional trainset, that is a modified Dash9 that has a single cab looking "long hood" (even if the long hood can't be seen because there is no freight animation). This modified Dash9_rev behaves, I suppose, as the NS3193.
Here how MSTS works:
If such Dash9_rev is standalone within the consist (check consist 1xDash9_rev.con), its "forward" is what is "backward" for the eye (if you set the reverser to "forward", your eye will see your engine running backward). Same as the NS3193.
If such Dash9_rev is at the last position (or better said not in the first position) of the consist, and there is an engine also in the first position (check consist Dash9_helper.con), its "forward" is what is "forward" for the eye (if you set the reverser to "forward", your eye will see your engine running backward). So the trainset behaves in two different ways in the two cases. The same should happen to the NS3193: if it is put in the last position of a consist where there is an engine also in the first position, it will move the opposite direction than usually. This can be tested inserting the NS3193 in place of the Dash9_rev in my Dash9_helper.con file.
At a first glance this behavior seems to me questionable and I prefer the more coherent OR approach. Now it has to be studied if there is however a solution under OR to "force" the NS3193 to always have its "forward" movement in the opposite of the viewing direction.
TRAINS.zip (8.5K)
Number of downloads: 163
Attached you have a pack with 2 consists and an additional trainset, that is a modified Dash9 that has a single cab looking "long hood" (even if the long hood can't be seen because there is no freight animation). This modified Dash9_rev behaves, I suppose, as the NS3193.
Here how MSTS works:
If such Dash9_rev is standalone within the consist (check consist 1xDash9_rev.con), its "forward" is what is "backward" for the eye (if you set the reverser to "forward", your eye will see your engine running backward). Same as the NS3193.
If such Dash9_rev is at the last position (or better said not in the first position) of the consist, and there is an engine also in the first position (check consist Dash9_helper.con), its "forward" is what is "forward" for the eye (if you set the reverser to "forward", your eye will see your engine running backward). So the trainset behaves in two different ways in the two cases. The same should happen to the NS3193: if it is put in the last position of a consist where there is an engine also in the first position, it will move the opposite direction than usually. This can be tested inserting the NS3193 in place of the Dash9_rev in my Dash9_helper.con file.
At a first glance this behavior seems to me questionable and I prefer the more coherent OR approach. Now it has to be studied if there is however a solution under OR to "force" the NS3193 to always have its "forward" movement in the opposite of the viewing direction.
TRAINS.zip (8.5K)
Number of downloads: 163
#27
Posted 17 January 2015 - 07:09 AM
This is just an observation. The picture in post #10 shows a locomotive with a big white F next to steps. This is so that anyone looking at the engine will know which hand signals will move the engine in which direction. Forward is always toward the F.Every locomotive has a big F on one end ( doesn't matter which end ) that designates the front of the unit. The controls have to function with with the F end as the front regardless of control stand location or direction of operation.
Steve
Steve
#28
Posted 17 January 2015 - 07:25 AM
Thanks for info.
I don't know if this is an international standard, and wonder if it is true also for symmetrical locos as e.g. the HHP8.
In the meantime I have found a very low cost solution to the problem of the NS3193. Within the CABVIEW folder of the NS3193 just do a plain copy of the cabview of the loco (SD40.cvf) and rename it SD40_rv.cvf. That's all. SD40.cvf should now work as desired. There is only an issue about side of inclination in superelevation, and I foresee to provide a patch for that, but no hurry. In the meantime you should have your loco working as desired.
I don't know if this is an international standard, and wonder if it is true also for symmetrical locos as e.g. the HHP8.
In the meantime I have found a very low cost solution to the problem of the NS3193. Within the CABVIEW folder of the NS3193 just do a plain copy of the cabview of the loco (SD40.cvf) and rename it SD40_rv.cvf. That's all. SD40.cvf should now work as desired. There is only an issue about side of inclination in superelevation, and I foresee to provide a patch for that, but no hurry. In the meantime you should have your loco working as desired.
#29
Posted 17 January 2015 - 07:55 AM
steved, on 17 January 2015 - 07:09 AM, said:
This is just an observation. The picture in post #10 shows a locomotive with a big white F next to steps. This is so that anyone looking at the engine will know which hand signals will move the engine in which direction. Forward is always toward the F.Every locomotive has a big F on one end ( doesn't matter which end ) that designates the front of the unit. The controls have to function with with the F end as the front regardless of control stand location or direction of operation.
Steve
Steve
Csantucci, on 17 January 2015 - 07:25 AM, said:
Thanks for info.
I don't know if this is an international standard, and wonder if it is true also for symmetrical locos as e.g. the HHP8.
I don't know if this is an international standard, and wonder if it is true also for symmetrical locos as e.g. the HHP8.
The answers to Carlo's questions are No and No.
German and Dutch engines, for instance, have a small '1' and '2' near the cab door. And for symmetrical engines, 'forward' is always the direction one is looking at from the cab - so, for instance, 'forward' for cab 1 is the same direction as 'reverse' for cab 2. This is also true for MU's.
Regards,
Rob Roeterdink
#30
Posted 17 January 2015 - 10:31 AM