View previous topic :: View next topic |
Author |
Message |
molletts Tux's lil' helper
Joined: 16 Feb 2013 Posts: 116
|
Posted: Sun Oct 13, 2019 1:19 pm Post subject: UT2004 controls bug (keyboard 'stops', view snaps 'up') |
|
|
It's been bugging me for a while (probably a year or more) but I've had very little time to attempt to debug the issue (or, indeed to play games much) until the last few days. I'm throwing this out here mainly to see if anyone else has come across the problem (and maybe found a solution).
Every so often (I haven't managed to establish a definite frequency for it yet) I find that the view direction will snap to "straight up" and any motion of the player will stop. Releasing the motion key then re-pressing it will get me moving again, having corrected the direction with the mouse. Not an ideal thing to happen when engaged in battle, obviously...
The simplest condition to duplicate this issue that I've been able to find is to start an Instant Action botmatch on a map with a nice lot of open space then just walk in a straight line by holding down your "forward" key, not touching the mouse at all. Eventually (it typically happens for me within less than a minute of starting the game), you will stop dead. Touching the mouse (one pixel of movement seems to be enough) will cause the view to snap up. It's kind of like the input system is resetting itself somehow.
I think I may have noticed the mouse pointer snapping back to the centre of the screen in the game menu once but I wasn't paying proper attention at the time and I haven't managed to catch it again so far.
I've tested this on three systems; two with the nvidia binary video driver (340.107-r1 on one, 390.129 on the other) and one with the Radeon r600 open-source driver (my first thought was that the nvidia drivers were doing something odd with the kernel, maybe causing some input events to be dropped). I've also tried both evdev and libinput for my input drivers. The mice are all USB-based; two of the keyboards are PS/2 while the other is USB. All have AMD CPUs (although it's just occurred to me that I could try installing it on my Core 2 Duo laptop to kill off that commonality). The only other major thing they all have in common (apart from Gentoo ) is XFCE; I shall try launching ut2004 directly under an X server when I get home, later today or tomorrow, to test this possibility.
Any input, even just "Yeah, I've noticed this too" is welcome! |
|
Back to top |
|
|
molletts Tux's lil' helper
Joined: 16 Feb 2013 Posts: 116
|
Posted: Fri Oct 25, 2019 9:56 am Post subject: |
|
|
OK, just realised that I never posted the promised follow-up with the extra tests:
The problem still happens on the Intel laptop.
It also still happens, but seems to be less frequent, when running the game outside of a desktop environment. Something that XFCE is doing would appear to "provoke" the issue but is not the root cause. |
|
Back to top |
|
|
0azza0 n00b
Joined: 16 Sep 2019 Posts: 15
|
Posted: Sat Jan 11, 2020 4:14 pm Post subject: |
|
|
Ever figure this out? Noticed the old post because that glitch sounds familiar.
Whats your wine --version output?
It is a long shot it being that your wine would be so old, .. like, perhaps vanilla going into mid 2s /or as early as ~1.1 .. but ..
the problem you are having sounds just like one that was patched, but for a long time only in staging, long time ago.
https://bugs.winehq.org/show_bug.cgi?id=6971#c269
.. 4 month old post and ancient patch, yah. but same engine/familiar behavior. i believe other people with mouse-escaping-window problems got some temporary relief entering and exiting fullscreen. one of the many reasons so many people are using steam builds |
|
Back to top |
|
|
molletts Tux's lil' helper
Joined: 16 Feb 2013 Posts: 116
|
Posted: Sat Jan 11, 2020 4:59 pm Post subject: |
|
|
0azza0 wrote: | Ever figure this out? Noticed the old post because that glitch sounds familiar.
Whats your wine --version output?
|
Never did figure it out. If I hadn't been busy doing a training course for several years and had been playing it regularly, I might have had a chance of catching the precise update that caused it but it would be virtually impossible now, short of setting up a test system with a "rewound" Portage from about 2016 or 2017 then stepping it forward a few months at a time, which simply isn't worth the effort.
I did see the mouse pointer jump to the top left corner of the screen when I was in the menus the other day, though, which confirms what I thought I'd seen before.
Currently:
Code: | $ wine --version
wine-4.21 (Staging) |
I'm not using Wine for UT2004, though. I'm running the native Linux 64-bit version of the game. |
|
Back to top |
|
|
0azza0 n00b
Joined: 16 Sep 2019 Posts: 15
|
Posted: Sat Jan 11, 2020 6:15 pm Post subject: |
|
|
huh, cool! had no idea that was available.
i wonder if the burn will crash my setup after a few minutes, the same way my attempt at recreating proton-ge via ebuild does...
i'm gona try it .. stuck here:
Code: |
~/Downloads/UT2004MegaPack/System $ ./ut2004-bin-linux-amd64
./ut2004-bin-linux-amd64: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
~/Downloads/UT2004MegaPack/System $ ldd ./ut2004-bin-linux-amd64
linux-vdso.so.1 (0x00007ffc964ca000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fcfd35ab000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcfd3588000)
./libSDL-1.2.so.0 (0x00007fcfd3546000)
libstdc++.so.5 => not found
libm.so.6 => /lib64/libm.so.6 (0x00007fcfd33fc000)
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libgcc_s.so.1 (0x00007fcfd33e2000)
libc.so.6 => /lib64/libc.so.6 (0x00007fcfd3210000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcfd35e2000)
# equery b libstdc++.so
* Searching for libstdc++.so ...
sys-devel/gcc-8.3.0-r1 (/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libstdc++.so -> libstdc++.so.6.0.25)
sys-devel/gcc-8.3.0-r1 (/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/32/libstdc++.so -> libstdc++.so.6.0.25)
sys-devel/gcc-9.2.0-r2 (/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so -> libstdc++.so.6.0.27)
sys-devel/gcc-9.2.0-r2 (/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/32/libstdc++.so -> libstdc++.so.6.0.27)
|
whuy the fudge not?
Code: |
~/Downloads/UT2004MegaPack/System $ ln -s /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libstdc++.so ./libstdc++.so.5
~/Downloads/UT2004MegaPack/System $ ./ut2004-bin-linux-amd64
./ut2004-bin-linux-amd64: ./libstdc++.so.5: version `GLIBCPP_3.2' not found (required by ./ut2004-bin-linux-amd64)
./ut2004-bin-linux-amd64: ./libstdc++.so.5: version `CXXABI_1.2' not found (required by ./ut2004-bin-linux-amd64)
|
kernel is 5.4.2, emerge --sync yesterday, last full @world was like, maybe october.
i think id have to build an old libstdc++ to go any further, maybe i dont have/cant get the same binary you have? hth. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sat Jan 11, 2020 6:40 pm Post subject: |
|
|
Just use the ut2004 ebuild. It pulls in the right deps automatically. |
|
Back to top |
|
|
0azza0 n00b
Joined: 16 Sep 2019 Posts: 15
|
Posted: Sat Jan 11, 2020 6:47 pm Post subject: |
|
|
same bounce: (er- had seen this before learning of ebuild, left it out of last post, accidentally)
Code: |
# emerge -av ut2004
.
.
.
emerge: there are no ebuilds to satisfy "=sys-libs/libstdc++-v3-bin-3.3*".
(dependency required by "virtual/libstdc++-3.3::gentoo" [ebuild])
(dependency required by "games-fps/ut2004-3369.3-r2::gentoo" [ebuild])
(dependency required by "games-fps/ut2004-data-3186-r5::gentoo" [ebuild])
|
emerge =sys-libs/libstdc++-v3 directly did resolve the linker dependency in the megapack binaries and also, somehow that i didn't realize was a test, resolved the ut2004 ebuild dependency too.
havin gotten her playin'
nothin quirky with the mouse over an hour or two |
|
Back to top |
|
|
titi_ger n00b
Joined: 25 Dec 2020 Posts: 1
|
Posted: Fri Dec 25, 2020 12:37 am Post subject: |
|
|
Is there any soltution for the ut2004 move forward bug ? Yes I am using ubuntu 20.04, but the problem is the same as described.
You can run forward for 5-10 seconds then you stop. you have to release the key and press it down again to continue walking forward.
The same happens for all keys which are pressed down for a longer time while playing. Every key is "released" after 5-10 seocnds also I don't move my fingers. |
|
Back to top |
|
|
madscientist159 n00b
Joined: 20 Mar 2021 Posts: 1
|
Posted: Sat Mar 20, 2021 9:07 am Post subject: |
|
|
Has anyone found a solution for this issue yet?
I tried downgrading from the 64-bit version (ut2004-bin-linux-amd64) and latest SDL to the 32-bit binary (ut2004-bin) and the stock Epic libSDL1.2.so, which helped significantly but did not fully eliminate the bug. Now I'm trying to remember if this bug was always present but on the older software wasn't noticeable enough to complain about (10-20s between key down to stopped input)? |
|
Back to top |
|
|
|