[ErickC]

The mouse controls now work, but it seems the click spots are located way out in left field. Think there's any way we could define where they would be? As it is, searching for a little spot way far away from the control you're trying to operate is a bit counter-intuitive.

[jonas]

Csantucci, on 20 September 2017 - 10:45 AM, said:

I've tested it and it works OK to me (consist AT3, using the .zip file with the complete trainset). To catch the control the mouse pointer must appear, therefore, if you don't see the mouse, first move it slowly to see the pointer and then actuate.

Ok. Because it works without problems to you, I suspected that we have different options selected. So I found the problem: It is if "dynamic shadows" is selected. Then you get strange effects (at least I get them on my computer). Hovering over a control make the mouse pointer flashing and after 2 seconds it will disappear every time. Sometimes the shown actuation control info even changes without moving the mouse.
Do you have the same effects when using dynamic shadows, Carlo?

[ErickC]

Can confirm that turning off dynamic shadows cures the random nature of click spots. Odd!

[jonas]

I tried it now without "dynamic shadows" a bit longer...and it works excellent! Good for OR to have this feature now!

[Csantucci]

Jacob,
thank you for having successfully chased it! Yes, I had dynamic shadows disabled. By enabling them, I get the problem too. Now I hope not to need too much time to solve this.

[Csantucci]

I have tested and I am in difficulty. What I am writing here is for someone with good knowledge in XNA, and especially for James. The problem is that the calculation of the FarPoint (called maxPointSource here https://msdn.microso....unproject.aspx ) by ViewPort.Unproject oscillates between a correct value and a wrong value when Dynamic Shadows are enabled, therefore not giving a stable catch (cabview control found) result. I attach a logfile with trace lines showing that. I checked all inputs to the ViewPort.Unproject function, but they are the same when the result is OK and when the result is wrong.
 OpenRailsLog.zip (5.22K)
Number of downloads: 461

P.S.
Checking further shows that the problem disappears avoiding execution of DrawShadows in RenderFrame.cs, or even avoiding only execution of these two lines

            graphicsDevice.SetRenderTarget(0, ShadowMapRenderTarget[shadowMapIndex]);
            graphicsDevice.DepthStencilBuffer = ShadowMapStencilBuffer;

and this line

            ShadowMap[shadowMapIndex] = ShadowMapRenderTarget[shadowMapIndex].GetTexture();

within such method.

[Csantucci]

OK, at last solution seems of having been found. I hope to attach this evening the new patch. The shadow code changes the Viewport, which is used to compute NearPoint and FarPoint. So the default Viewport has to be saved in order to be always used to compute such points.

[Csantucci]

In post #13 I have attached a new release of the patch that solves the problem created by the Dynamic Shadows.

[jonas]

With patch rev#4 it now works fine with dynamic shadows on my pc.

Your last posts sounds as it was a bit tricky to adjust it in the code. Thanks for solving it!

[ErickC]

It works well here, too.