Few bugs/bad features

[NightElfik]

Hello, I've played Simutrans Experimental and posted general feedback with suggestions and bug reposts: http://forum.simutrans.com/index.php?topic=10308.0. Some of bug reposts are not experimental-only (as jamespetts says), I am reposting appropriate ones here.

• The "Fast forward" button in paused game just unpauses the game which is running normal speed but the Fast forward button is pressed. So you have to press it twice to activate fast forward mode.
  
  


• Sometimes when I turn off the Fast forward mode the game is lagging for a while (10-60 sec). I could not figure what is the reason but after long gaming session this happens nearly always.
  
  


• {maybe experimental issue? probably not} Train get totally stuck when placed opposite semaphore (one way) just before it. This happend to me when I was placing some extra one-way semaphores in fast forward mode and just after second click (1st both way, 2nd opposite direction, 3rd correct direction) the train was under the cursor. The trains stopped and can not move whatsoever. I've tried to send it to depot. After few months other trains started to ride through it (it became "immaterial" . Save-load game combo helped me to resole this somehow.
  
  


• After removing Oil rig (on sea) as public service player, orange squares from station coverage do not disappear. They disappear only after hovering them (for example with inspection tool).
  
  


• I noticed that on the vehicle card on the life preview of the vehicle (above the "Follow me" button) the scene is rendered incorrectly. When I am watching the bus riding south-east (on the right side) the building on the south-west neighbor tile is drawn after the bus which causes the bus is "on top of building" which starts "lower" than the bus. This is clearly wrong. This happens only on NW-SE roads. In the game it is rendered correctly.
  

This is probably not bug, but annoying feature:
I play on dual monitor configuration. The secondary monitor is on the left of the primary, where is maximized window of the game. When I try to scroll the map little bit faster (or minimap) by right clicking and dragging to the left, it stops scrolling. This is probably caused by the cursor leaving the game window between frames and game will not return it to original position. When I return the invisible mouse cursor to the game window it starts to scroll the map. Also if I release it (when it is not responding) It appears on the secondary monitor.
This happens more likely if I grab the map closer to the left edge. Like 50px from the edge is not possible to scroll in the direction out of it. This can even be simulated if the window is not maximized (thus there is nothing to stop the mouse cursor to leave the game window).
The game should scroll the map even if the cursor is not in its window or the cursor should be "locked" in the game window while scrolling.

[Ters]

The last bit is probably a restriction in either the operating system and/or SDL. When the mouse leaves the window, it has left the window, and no more mouse events are sent to it. Which OS does this happen on and are you using the SDL version of the game?

[NightElfik]

The last bit is probably a restriction in either the operating system and/or SDL. When the mouse leaves the window, it has left the window, and no more mouse events are sent to it. Which OS does this happen on and are you using the SDL version of the game?

I play Simutans Experimental from here: https://github.com/downloads/jamespetts/simutrans-pak128.britain/Simutrans-Experimental-Complete.zip. OS: Win7 x64

I know that it is hard to catch events while mouse cursor is not in the window but it should be possible to "lock" the mouse in the window using Win API.

[Ters]

I know that it is hard to catch events while mouse cursor is not in the window but it should be possible to "lock" the mouse in the window using Win API.

But if you're using the SDL version, the Win32 API isn't available. (I also don't think you typically lock the mouse in the window, but tell Windows to continue giving you all mouse events until you say you're done. Although repositioning the mouse cursor is possible, it might be bad UI.)

[NightElfik]

But if you're using the SDL version, the Win32 API isn't available. (I also don't think you typically lock the mouse in the window, but tell Windows to continue giving you all mouse events until you say you're done. Although repositioning the mouse cursor is possible, it might be bad UI.)

There are two approaches (I think).

1) Listen mouse globally and count relative position to your window.

2) Prevent mouse leaving your window. There are some messages sent by Win when mouse is about to leave the window and you can prevent it (don't know concrete values). I am .NET programmer and those magic messages can be caught by overriding the WndProc method of Form.

But this would be OS specific. Maybe programs which can lock the cursor to the window are the solution (there is buch of them over the Internet).

[Ters]

Now that I check the docs, there is a ClipCursor function in Win32, but that would only work for the GDI version. I'm not sure if SDL has something like that, nor other platforms.

One thing I don't like about confining the cursor is that it breaks the relationship between the position and movement of the physical mouse and the cursor on the screen. Not so much a problem with maximized, or fullscreen, windows, as the cursor is clipped at the desktop edges anyway, but with multiple monitors, maximized windows aren't that different from non-maximized windows.

[Dwachs]

Thanks for your reports! I could not reproduce the items 1-3 with current standard simutrans.

A fix for 4 is underway.

5 is known, nobody volunteered to fix it.

[prissi]

Issue 2 is related to the fact that for large screen or well developed games the target fps is too high. Thus after fast forward, simutrans must find out what fps it can achieve. This can take up 10 30s und bad circumstances. Same should happen after unpause by the way.

Even the GDI version actually captures the mouse. But windows frees it anyway. Happens also with other programs.

[NightElfik]

Issue 2 is related to the fact that for large screen or well developed games the target fps is too high. Thus after fast forward, simutrans must find out what fps it can achieve. This can take up 10 30s und bad circumstances. Same should happen after unpause by the way.

Interesting, can't be the "computed target FPS" saved when going to fast forward and loaded when leaving? Last target FPS is quite good estimation (it might be little too high if FF was turned on for long time).

[Dwachs]

About issue 5:

• I noticed that on the vehicle card on the life preview of the vehicle (above the "Follow me" button) the scene is rendered incorrectly. When I am watching the bus riding south-east (on the right side) the building on the south-west neighbor tile is drawn after the bus which causes the bus is "on top of building" which starts "lower" than the bus. This is clearly wrong. This happens only on NW-SE roads. In the game it is rendered correctly.
  

I could not reproduce this. Is there a reproducible way to get this wrong behavior? Savegame / Screenshot much appreciated.

[whoami]

The clipping errors in the vehicle window are (e.g. with ST r6162) quite prevalent in Pak128, even with its r1092 (new makeobj, right?). They occur to vehicles (trains) under and on (some) bridges and also in stations with roofs.

[prissi]

Yes, because for these windows the simple redraw routines have to be used.

[Dwachs]

Yes, because for these windows the simple redraw routines have to be used.

No The sophisticated routine was used, but the routine to display an unscaled image was not aware of this. Should be fixed in r6188.