[Totte]

Thanks so much for you swung away the rain in the tunnels! I now run with X2133. ;)

[cjakeman]

Hi Carlo,

James Ross, on 31 March 2014 - 12:40 PM, said:

Csantucci, on 31 March 2014 - 12:38 PM, said:

I've seen that you haven't introduced the change on the cameras file to correctly initialize viewing direction of the passenger view. I put that because there are cases where intializing to viewing direction 0 instead of to the value present in the .wag or .eng file you look at non-existent walls where you see rain dropping.

Yeah, that's a completely different issue and I don't really want to add it back without Chris commenting on why he removed it. :bigboss:

I've taken a look at the changes I made for v1322 and especially Cameras.cs - PassengerCamera.SetCameraCar().

I was trying to preserve the camera direction (e.g. looking out of the window) when the player uses Alt-PageUp/Down to switch from car to car. Previously, it was reset to the initial direction on pressing Alt-PageUp/Down. However I was a bit clumsy.

I've committed a new version which sets the initial direction only on first use of the passenger camera and not when Alt-PageUp/Down is used.

Please tell me if that fixes your problems.

[Csantucci]

Hi Chris,
thanks for attention.
Unfortunately in my opinion this is not the solution. Every car should have its own initial passenger viewing direction and position, that is the one defined in the .wag file, even if they are different from wagon to wagon (there could be cars where the initial viewing angle shows the left side of the route, other ones where it is the right side, others that view forward, others that view backward; and this is also a nice thing that provides for variation!). If you force the fact that the passenger views of all cars look at the same direction - or at the direction selected by the player for the preceding active passenger view - as I understand it is in release 2138 - you get unwanted effects, like this e.g.:

or even worse, against the seat


Moreover, this direction could be towards a part of the internal shape that is even incomplete (because in MSTS there can be also a restriction on the possible direction angle range through the RotationLimit parameter, that is used to prevent viewing in unwanted directions).
So my proposal is: every passenger view should be directed towards its own defined direction the first time it is selected; what should happen if such passenger view is recalled after having passed through other passenger views?
1) (best, even if I think it's a bit complicated, as a matrix of directions should be saved) the last direction selected by the player for that passenger view should be used
2) (acceptable) the default direction for such car (MSTS does so) should be used

What should happen if such passenger view is recalled after having passed through other cameras?
The last direction selected by the player for that passenger view should be used (MSTS does so).

[cjakeman]

Csantucci, on 04 April 2014 - 12:59 PM, said:

Every car should have its own initial passenger viewing direction and position, that is the one defined in the .wag file, even if they are different from wagon to wagon (there could be cars where the initial viewing angle shows the left side of the route, other ones where it is the right side, others that view forward, others that view backward; and this is also a nice thing that provides for variation!). If you force the fact that the passenger views of all cars look at the same direction - or at the direction selected by the player for the preceding active passenger view - as I understand it is in release 2138 - you get unwanted effects,

You've made your point well. I'll try a bit harder tomorrow.

[cjakeman]

Hi Carlo,

Csantucci, on 04 April 2014 - 12:59 PM, said:

1) the last direction selected by the player for that passenger view should be used

I've done some more work and each WAG file should now have its initial direction respected and the camera direction should be restored when the camera returns to that car.

Please try it out,

[Csantucci]

Hi Chris,
it's true that now the logic is MSTS' one, and this is sufficient to me (while it seems not to be implemented or not working that player modified viewing directions are separately stored and recalled for every wagon).
However there is a problem: a line like this one
StartDirection ( 0 180 0 )
seems to have the same effect as this one
StartDirection ( 0 0 0 )
as for the initial viewing direction.
More generally said, I don't find a relationship between the StartDirection () parameters and the real initial viewing direction. To be more concrete, the first wagon in my test consist, that has
StartDirection ( 0 180 0 )
had a correct initial viewing direction in your preceding version, while in this one it points in direction 0 0 0.

[cjakeman]

Csantucci, on 05 April 2014 - 12:40 PM, said:

It's true that now the logic is MSTS' one, and this is sufficient to me (while it seems not to be implemented or not working that player modified viewing directions are separately stored and recalled for every wagon).

Separately stored and recalled for each type of wagon, but identical wagons share the same camera direction.

Csantucci, on 05 April 2014 - 12:40 PM, said:

To be more concrete, the first wagon in my test consist, that has
StartDirection ( 0 180 0 )
had a correct initial viewing direction in your preceding version, while in this one it points in direction 0 0 0.

Very strange; I'll see if I can find out why. Still, we are making progress and thanks for your testing.

[Csantucci]

...

[Csantucci]

Chris,
this patch
 Passviewpoints.zip (1.13K)
Number of downloads: 367
should solve the problems I found.
The conversion to radians of the initial viewing direction was performed before parsing the direction data and saving of the new viewing direction after player action had to be performed also when player action was performed with mouse instead of keyboard.

[cjakeman]

Csantucci, on 06 April 2014 - 04:24 AM, said:

this patch
Passviewpoints.zip
should solve the problems I found.

It certainly does; so I've committed your patch.

Many thanks.