Transport Tycoon Forums

supermop wrote:ETA of what? As far as I am aware, OpenTTD has not allocated any staff to this problem because it has no paid staff. OpenTTD does however gladly offer full refunds of your purchase cost of the game if you are unsatisfied with the support at any time.

haha, saw that coming xD
eshield: ** apply some ice ** if you can't be part of the solution, don't make part of the problem! If I don't have the knowledges to solve this, I won't rush the people who has. Like every other free and opensource games/applications, it's all done with the donation of people free time into it. Respect!

Since it appears that Windows fall update is causing the problem - uninstall it. (It created a restore point when it installed)

supermop wrote:ETA of what? As far as I am aware, OpenTTD has not allocated any staff to this problem because it has no paid staff. OpenTTD does however gladly offer full refunds of your purchase cost of the game if you are unsatisfied with the support at any time.

ST2 wrote:eshield: ** apply some ice ** if you can't be part of the solution, don't make part of the problem! If I don't have the knowledges to solve this, I won't rush the people who has. Like every other free and opensource games/applications, it's all done with the donation of people free time into it. Respect!

Pffft, c'mon guys, I'm old enough to understand that nobody in this life owes me anything. I just want to bring an attention of devs onto this issue. Just for your information: OSS is made for you. Without you OSS is dead. I had my sweet time contributing pfSense, so there is no need to tell me about "allocations", "staff", etc. A midnight wet fantasies. Peace.

p.s: Maybe, I could have contributed a re-worked mouse handling for OTTD if it was not in C++.

eshield: you don't need to be worried. As always, some workarounds appear - it doesn't mean are final solutions, because can break other intended stuff on code!
What I know is that this changes made it usable again, with W10 with update 1709 (at least for me, on 2 machines):

That was tomb's workaround I think that this temporary solution applies to all releases or patchpacks, for players that are under W10 and got the 1709 update. Since this happened because a W10 update, maybe SDL change isn't needed... but on the allegro it's set as false by default. And this where my knowledges lack :S

BTPro created a version with the workaround, Vanilla compatible, because some players needed it: link here - (check Readme.txt file BUT please remember that's a workaround)
The 3298's approach, never tried it! The must have "reverse scrolling on" scared me as hell, because it's not the default ^^

If you're able to compile it, changes above will make it playable after the mentioned W10 update: Other locations about this "problem":
- https://bugs.openttd.org/task/6629
- https://www.reddit.com/r/openttd/commen ... _viewport/
- https://www.reddit.com/r/openttd/commen ... ght_click/

I can confirm this problem on two machines running Windows 10 1709, and do not have it on the one machine left on 1703. Also, tomb's/ST's fix works for me on 1709, and does not immediately lead to any strangeness on the 1703 machine.

I've looked at the code, especially the WM_MOUSEMOVE message handling and CursorVars::UpdateCursorPosition, but haven't been able to really understand how the queued mouse event stuff is supposed to work. I did add some printf statements to (the original, unchanged) UpdateCursorPosition whenever fix_at is true to see what's going on; attached are the outputs for Windows 10 1703 and 1709. In both cases, I try to scroll the viewport by right-clicking and moving the mouse to the left (i.e. as I move the mouse, the x coordinate should decrease). Maybe this helps someone who betters understands the OpenTTD mouse code; the behaviour is indeed markedly different on the two Windows versions.

Hi all.

I love this game and am in serious withdrawal since my mouse went full schizo...

I'm happy to hear that there are some smart people working on a solution to this, and that there are some workarounds available in the interim.

I'd love to actually try tomb's workaround, but as a guy that hasn't compiled anything other than 2 wives, 3 kids, and a mortgage since about 1994 I could use some guidance on how to make this workaround a reality... I can't compile, I can only download files.

Would anyone have a file or set of files I could integrate into my installed version of 1.7.1 that will make things work, or is that even possible?

Thanks in advance for anything you can offer. (read: "help!")

Dave

maybe this help ^^

Dave T wrote:I love this game and am in serious withdrawal since my mouse went full schizo...

If Your withdrawal symptoms get too bad there are alternative ways of scrolling the screen.

First, the arrow keys on the keyboard will pan the screen. If you have extra buttons on your mouse or a joystick with hat switches, you could map them to the arrow keys.

Second, zooming. Zooming is centered on the mouse pointer, so zoom all the way out, move your mouse pointer to where you want to be, then zoom back in.

TimeLapse1357 wrote:

Dave T wrote:I love this game and am in serious withdrawal since my mouse went full schizo...

If Your withdrawal symptoms get too bad there are alternative ways of scrolling the screen.

First, the arrow keys on the keyboard will pan the screen. If you have extra buttons on your mouse or a joystick with hat switches, you could map them to the arrow keys.

Second, zooming. Zooming is centered on the mouse pointer, so zoom all the way out, move your mouse pointer to where you want to be, then zoom back in.

TimeLapse1357: do you use the arrow keys to move along the map? or even zoom out / zoom in, as you suggested, to get into the spot you want?
Because if you do... and don't use your left hand for the common left keyboard shortcuts (set on Vanilla), how you split your hands between arrow keys and the left keyboard shortcuts, vanilla setted?

only wondering how TimeLapse1357 does it!!

I updated Windows on Friday, but still played OpenTTD with things like arrow keys and strategic scrolling. I also noticed the click and drag scrolling works better when the game is paused.

ST2 wrote:only wondering how TimeLapse1357 does it!!

since I am using Win7, my mouse works fine

but I did try playing for 5-10 minutes using the arrow keys to scroll, just to see if it was tolerable.
I use my mouse wheel to zoom (that should still work in Win10).
Since I am Left handed / ambidextrous, using my left hand for the arrow keys isn't a big problem.

TimeLapse1357: what I meant was that many players use left hand for the shortcuts: Q, W, E, R, T | A (or CTRL+A), S, D | Z, X, C ...
Most of them have, by default, actions associated. It makes gameplay easier/faster. And that's why moving the hand from there to the arrows isn't confortable.
Ofc, if it's with a player not using shortcuts... won't hurt xD

Just chiming in to say I am also having this issue (its what brought me here), and I am not using a logitech mouse so its not the mouse brand. I don't have setting for gestures or anything like that, so I can't disable that!

It's not ideal but I just used an extra mouse profile to assign the arrow keys to buttons on the mouse and turned on scroll when the mouse is near the edge... hope this gets resolved soon, I have been playing this game since the 90's, it really is my all time favorite go to game.

Hello, same problems here, we wanted to play OpenTTD on lan-party, but the right mouse panning does not work (or works in unusable way) on most (5+) computers, inlcuding PCs with i7 8700K and GTX 1080Ti.

Left mouse panning is fine, but took us like hour to figure that out and at least I am used to right button panning.

Is there any fixed version yet?

TO add to this...

I wasn't thinking last night and updated to FCU. The RMB issue appeared. I also noticed that when I'm using the measurement tool in the Landscaping tools, (JGR Patch), scrolling with that tool has become very choppy. It was nice and smooth before the FCU update. Don't know if that will help anyone digging into the issue, but there it is. Note that that tool is used with the left mouse button depressed.

cmhbob wrote:TO add to this...

I wasn't thinking last night and updated to FCU. The RMB issue appeared. I also noticed that when I'm using the measurement tool in the Landscaping tools, (JGR Patch), scrolling with that tool has become very choppy. It was nice and smooth before the FCU update. Don't know if that will help anyone digging into the issue, but there it is. Note that that tool is used with the left mouse button depressed.

Further research:
Discovered I was still using the stock Windows mouse driver, dated 2006. Upgraded to Logitech Setpoint 6.67. I can now RMB scroll at the zoomed-in settings. It's still a little choppy, and I can't tell yet how consistent it's being. But I've regained some functionality.

EDIT: Seems like at the max zoom settings (128x and 64x), I still can't scroll. But at the rest of the lower zoom settings (basically once the town names come in), I can scroll. In Setpoint settings, I'm using Low Pointer Acceleration, and Enable Smart Move. Under Speed and Acceleration, I'm using SetPoint implementation, and Retain OS Settings. I haven't changed any of the button assignments. This is a Logitech Marathon M705.

So I searched around and I found that there are other games affected by this bug. There is a reddit thread claiming that the newest Windows 10 build (17046) deals with the problem. So I entered the Windows Insider program to get the newest build, installed, but sadly the problem still exists. But I thought I'd still post this here, maybe it works for some of you.
In the meantime, full withdrawal symptoms all over the place here, not getting used to any of the other means of map scrolling

EDIT: https://www.reddit.com/r/GlobalOffensiv ... ate_mouse/

EDIT 2: Reading the reddit thread again, I realize it may not be the exact same problem being discussed. But nevertheless, problems with the mouse. Figured it might lead to something.

Lrd wrote:I can confirm this problem on two machines running Windows 10 1709, and do not have it on the one machine left on 1703. Also, tomb's/ST's fix works for me on 1709, and does not immediately lead to any strangeness on the 1703 machine.

I've looked at the code, especially the WM_MOUSEMOVE message handling and CursorVars::UpdateCursorPosition, but haven't been able to really understand how the queued mouse event stuff is supposed to work. I did add some printf statements to (the original, unchanged) UpdateCursorPosition whenever fix_at is true to see what's going on; attached are the outputs for Windows 10 1703 and 1709. In both cases, I try to scroll the viewport by right-clicking and moving the mouse to the left (i.e. as I move the mouse, the x coordinate should decrease). Maybe this helps someone who betters understands the OpenTTD mouse code; the behaviour is indeed markedly different on the two Windows versions.

What about WM_INPUT? A quite suitable thing for RTS, I think. Register main window with RegisterRawInputDevices to get WM_INPUT messages with nice RAWMOUSE structure within it which has everything we need. Replacing WM_MOUSEMOVE handling with WM_INPUT should do.

I'm not an expert in gaming dev, just a guess.

Trunk now has a commit that fixes the issue, see here also:
viewtopic.php?f=33&t=73469&start=1080

I have the same problem, came here to search for a solution but seems it is too early for it. If I can help ,here are my observations of this issue:
I have two machines (PC and lap) with Win10 installed, after the last windows update the problem with the mouse occurred. In general I play OTTD on my PC and first I thought it was a mouse problem but on the laptop it was the same. On the same PC I have Win7 as virtual machine - put there OTTD and it works like a charm.
My conclusion is that in the last Win10 update something about mouse contril was changed.