Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
UT2004 controls bug (keyboard 'stops', view snaps 'up')
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gamers & Players
View previous topic :: View next topic  
Author Message
molletts
Tux's lil' helper
Tux's lil' helper


Joined: 16 Feb 2013
Posts: 116

PostPosted: Sun Oct 13, 2019 1:19 pm    Post subject: UT2004 controls bug (keyboard 'stops', view snaps 'up') Reply with quote

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
View user's profile Send private message
molletts
Tux's lil' helper
Tux's lil' helper


Joined: 16 Feb 2013
Posts: 116

PostPosted: Fri Oct 25, 2019 9:56 am    Post subject: Reply with quote

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
View user's profile Send private message
0azza0
n00b
n00b


Joined: 16 Sep 2019
Posts: 15

PostPosted: Sat Jan 11, 2020 4:14 pm    Post subject: Reply with quote

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
View user's profile Send private message
molletts
Tux's lil' helper
Tux's lil' helper


Joined: 16 Feb 2013
Posts: 116

PostPosted: Sat Jan 11, 2020 4:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
0azza0
n00b
n00b


Joined: 16 Sep 2019
Posts: 15

PostPosted: Sat Jan 11, 2020 6:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Sat Jan 11, 2020 6:40 pm    Post subject: Reply with quote

Just use the ut2004 ebuild. It pulls in the right deps automatically.
Back to top
View user's profile Send private message
0azza0
n00b
n00b


Joined: 16 Sep 2019
Posts: 15

PostPosted: Sat Jan 11, 2020 6:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
titi_ger
n00b
n00b


Joined: 25 Dec 2020
Posts: 1

PostPosted: Fri Dec 25, 2020 12:37 am    Post subject: Reply with quote

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
View user's profile Send private message
madscientist159
n00b
n00b


Joined: 20 Mar 2021
Posts: 1

PostPosted: Sat Mar 20, 2021 9:07 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gamers & Players All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum