Closed jiriks74 closed 1 year ago
Thanks for staying on top of this.
I've accounted for this issue in another (unreleased) project that contains discrete logic for both the Stable and Beta clients, since the way the console works has changed slightly. I could probably port that logic to DZGUI and it should work.
IIRC, the main difference is that the Beta client console only needs to be raised and focused once and will not lose focus after commands complete, while the Stable client tends to lose focus after successful completion, which is why it's important to keep trying to raise it, otherwise it can go out of focus and trigger the dreaded "accidentally spawned the Steam music player" bug because the wrong element is targeted.
The other difference is that the client gets a different name/class now and has some lag in between. In the new logic, I wait for the client to be destroyed (i.e. after the library, store, or other open window despawns) and then wait for it to regenerate (when the console pops up).
I don't strongly recommend using the Beta client right now because it is rife with problems, as attested by the Steam for Linux issue tracker, and has broken more things than it fixed. In my case, I can't even launch the Beta client without it going into an infinite crash-and-respawn loop.
But we should patch this issue just in case people are using the Beta client, which they surely are. It shouldn't be too difficult to fix since I already extended this in my other program, but might need your help testing it if my Beta client keeps crashing.
As for Enter not being sent, can't deduce the cause right now based on reading the report, but it is probably related to the above.
TLDR: quick fixes for now would be using Stable client or disabling automods. Hotfix will come in a few days or so.
I pushed the hotfix. Have a look at the testing
branch. You must have both wmctrl
and xdotool
installed. We don't enforce this check at boot (previously just needed one or the other), but will have to enforce it going forward if the user has automods on.
I haven't tested it on the beta client, just ported the logic I had built elsewhere. It should dynamically change to either the Stable or Beta client logic depending on which one you have. Ideally, you should test with both clients.
Thanks.
Version: 3.3.0-rc.16 Mode: normal Branch: testing Mods: auto
I tried the feature with
Advanced options
Force update local mods
I sometimes get Steam must be running
sometimes it dumps all the commands into the console, not executing them as before.
I now also get the vm.max_map_count
dialogue even though I have set it permanently and run DayZ without any problems.
For me Steam beta works very well so far. The UI looks nice, the HW acceleration is really nice and the settings are way better. I like it quite a lot. Once it's released, I'll probably switch back to stable.
PS: RN I tried to run it again and it opened Steam console but then started dumping the commands in this issue I opened before running it again.
I sometimes get Steam must be running sometimes it dumps all the commands into the console, not executing them as before.
OK, this part is an easy fix. Beta client has a different window class name that must be targeted in a different manner. Just fixed this and should reliably find the client if it's on the same TTY session. The logic we had before was a bit primitive and prone to collisions.
As for other windows with "Steam" in the title getting picked up, it's because the old Stable client just emits the name "Steam", which can cause collisions with other windows, and we were using a fairly generic search method since xdotool does not support regular expressions. I've changed this to something more robust that should hopefully capture only clients actually reporting their name as Steam, rather than windows casually containing the string.
I now also get the vm.max_map_count dialogue even though I have set it permanently and run DayZ without any problems.
This is a regression based on a fix that added a sudo
invocation at boot to properly call the sysctl vm map count check on systems requiring sudo escalation to actually poll this parameter. How are you launching DZGUI? If you're launching it through a shortcut somewhere, it's possible this sudo prompt is getting obscured somewhere, rather than requested in the terminal. It might be better if we move this check to the first-time install script instead of to the launch, but need to think about it. Otherwise, we'll have to have the user enter their sudo password through some popup dialog every time if they aren't launching it from the terminal, which is annoying.
sometimes it dumps all the commands into the console, not executing them as before.
Changed around the logic a bit here, too. It should send Return key events into either client now. Looks like it was trying to issue the commands in the beta client but was looking for a window ID that would only apply to the stable client.
How are you launching DZGUI? I installed the shortcut a long time ago, so I use that.
For the rest I'll test it once I'll be safe in game XD
Sorry, I didn't quite understand the reply. Are you having trouble actually getting into the game?
I don't, I was just playing ATM.
RN the launcher doesn't detect Steam at all, even after manually launching the console and focusing it while the launcher checked for mods, but it still wasn't detected.
I don't, I was just playing ATM.
Oh, haha, good one :D
RN the launcher doesn't detect Steam at all, even after manually launching the console and focusing it while the launcher checked for mods, but it still wasn't detected.
Post the output of this:
#!/bin/bash
source $HOME/.config/dztui/dztuirc
echo =========================
find "$default_steam_path/package/beta"
echo =========================
command -v wmctrl
echo =========================
wmctrl -ilx | grep "Steam"
wmctrl -ilx | grep "Steam.Steam"
wmctrl -ilx | grep "Steam Games List"
That's helpful. Try 3.3.0-rc.19
now and it should stop warning about not finding Steam.
Edit: had to make another change and bumped it to 3.30-rc.20
With 3.30-rc.20
Steam is detected and the commands are pasted and executed. However the Steam window wasn't raised before the commands were pasted. I had this issue opened, executed the force update and it started pasting into Firefox. After alt + tabbing into Steam, everything worked fine.
OK, looks like we are making progress. After opening the console (steam steam://open/console
), what is the result of running wmctrl -l | grep "Steam Games List"
?
Alright, for some reason on my system the window was reporting its title as "Steam Games List", but I guess this is not portable. We'll revert to using the class name as we did in the other fix.
Try this, running the script in the background and then issuing the console command again. It should wait and focus the conosle after it respawns. It will print messages to the window as the Steam client is destroyed and respawns, so keep that window on top, put it on another monitor, or if hidden, refer to it at the end to see the output.
I think this method is reliable enough that it can work on both stable and beta clients, so we can drop the old methods.
#!/bin/bash
echo "ALERT: Waiting on Steam client"
until [[ -z $(wmctrl -ilx | awk 'tolower($3) == "steam.steam"' ) ]]; do
sleep 0.1s
done
echo "ALERT: Steam window destroyed"
until [[ -n $(wmctrl -ilx | awk 'tolower($3) == "steam.steam"' ) ]]; do
sleep 0.1s
done
echo "ALERT: Steam window respawned"
wid=$(wmctrl -ilx | awk 'tolower($3) == "steam.steam" {print $1}')
echo "ALERT: Focusing console ($wid)"
wmctrl -ai $wid
Nothing happens even after I open the console manually:
It must be a race condition. I'll try to think of something else, but we are running out of good options here. Does Steam switch windows instantly when you toggle between console/large mode/small mode, or is there a slight delay where the window despawns?
Can you confirm that on your window manager, when issuing a command to open the console from the terminal, the Steam client does not take focus and come to the top?
Try disabling the sleep interval so that we are checking at smaller intervals than 1ms. This will run in the background and open the console for you:
#!/bin/bash
f(){
echo "ALERT: Waiting on Steam client"
until [[ -z $(wmctrl -ilx | awk 'tolower($3) == "steam.steam"' ) ]]; do
:
done
echo "ALERT: Steam window destroyed"
until [[ -n $(wmctrl -ilx | awk 'tolower($3) == "steam.steam"' ) ]]; do
:
done
echo "ALERT: Steam window respawned"
wid=$(wmctrl -ilx | awk 'tolower($3) == "steam.steam" {print $1}')
echo "ALERT: Focusing console ($wid)"
sleep 0.1s
wmctrl -ai $wid
exit 0
}
f &
steam steam://open/console
OK. Tell me your distro (garuda) and window manager (?) and I'll go back to the drawing board. It's working reliably over here, but there must be some window manager specific issue I'm missing.
Disto: Garuda (Archlinux) DE: KDE Plasma Window Manager: KWin
If I can help, feel free to point me in some direction. I cannot promise that I'll have the time to figure it out, but I can at the very least try.
One question: before running the tests above, did you restore the Steam client to a regular window, or was it already on the console page before running the test? If you left it on the console page before running the test, it would have failed, since the window doesn't despawn in that case.
You've been very patient already, sorry that the Beta client has changed so many internal parameters related to window nomenclature.
One other thing you can do is run xprop
, click the Steam client when it's in library view, and paste the contents here.
did you restore the Steam client to a regular window, or was it already on the console page before running the test?
If I remember it right, I've tried both. I'll try again just to be sure and comment if it's any different. Do I have to restart Steam or just go to (eg.) the library?
You've been very patient already, sorry that the Beta client has changed so many internal parameters related to window nomenclature.
Bro, you're the patient one. I'm literally just adding problems without any code help XD. You've done all the work on this project and I'm really gratefull for that. It's an awesome thing that lets me play with my friends.
xprop
If I remember it right, I've tried both. I'll try again just to be sure and comment if it's any different. Do I have to restart Steam or just go to (eg.) the library?
Doesn't matter.
Bro, you're the patient one. I'm literally just adding problems without any code help XD. You've done all the work on this project and I'm really gratefull for that. It's an awesome thing that lets me play with my friends.
I'm happy! It's really helpful when users are willing to go through troubleshooting and provide data. Most people either get frustrated and quit or leave as soon as the patch drops.
I was thinking you might be a good candidate for a beta tester for the other tool I've been developing for 2.5 years. Relates to Steam, but not DayZ. Unreleased yet, still has about a month of development time in the cooker. Let me know if you'd be interested.
xprop
Thanks for the paste and system info. I'll try to work up something and figure out the root cause. In the meantime, Stable client should continue to work with mod requests.
I was thinking you might be a good candidate for a beta tester for the other tool I've been developing for 2.5 years. Relates to Steam, but not DayZ. Unreleased yet, still has about a month of development time in the cooker. Let me know if you'd be interested.
I'd be glad to help out! Thou, as I already said, probably won't have time to dedicate myself to it I'll be glad to test it out for you.
Thanks for the paste and system info. I'll try to work up something and figure out the root cause. In the meantime, Stable client should continue to work with mod requests.
Thanks! I'll be still using the Steam beta though. RN I'm not on heavily modded servers, so I won't really have problems launching the game. I'll be trying to find a good way to run the commands in some spare time. If I find something interesting, I'll update you.
Did you have the friends list open when you ran the last test? It looks like the friends list can cause collisions when identifying the Steam window because they both report the same window name.
It would be ideal if they assigned unique names to each window type, such as BigPicture, LargeGamesList, etc., because currently it's not easy to distinguish between multiple Steam windows if there are multiple IDs reported, due to the fact that they are all floating. I can look into reporting that issue upstream.
Close the friends list, open some Steam window other than the console, and try this:
#!/bin/bash
find_wid(){
wid=$(wmctrl -ilx | awk 'tolower($3) == "steam.steam" {print $1}')
}
f(){
find_wid
echo "ALERT: Waiting on Steam client"
until [[ -z $(wmctrl -ilx | grep $wid ) ]]; do
:
done
echo "ALERT: Steam window destroyed"
until [[ -n $(wmctrl -ilx | awk 'tolower($3) == "steam.steam"' ) ]]; do
:
done
find_wid
echo "ALERT: Steam window respawned"
echo "ALERT: Focusing console ($wid)"
sleep 0.1s
wmctrl -ai $wid
exit 0
}
f &
steam steam://open/largegameslist
Did you have the friends list open when you ran the last test? It looks like the friends list can cause collisions when identifying the Steam window because they both report the same window name.
I did not, but I'll try again.
Here's what got from the script you just commented:
OK, I finally found the issue. It was something a bit stupid, not your setup. I'm thinking of a workaround, but should be easy enough now.
In the earlier tests, when you just asked to open the console via the terminal (not via DZGUI), did it focus the window and bring it to the front of the stack after loading that page in the Steam client?
In the earlier tests, when you just asked to open the console via the terminal (not via DZGUI), did it focus the window and bring it to the front of the stack after loading that page in the Steam client?
It opens the console in Steam, but it stays focused on the terminal (Steam was already running).
OK, will have a fix in a few hours.
You're awesome. Do you sleep sometimes BTW? You're basically responding immediately no matter what time it is XD
Do you sleep sometimes BTW? You're basically responding immediately no matter what time it is XD
Not enough!
I don't like to leave an issue pending if I know there is a fix and it's affecting users. This report was also very important to me because it revealed some mistaken assumptions I had made about a similar implementation of the beta client in my other project.
The fix should be ready to go, but please test the below before I integrate it.
#!/bin/bash
focus_beta_client(){
wid(){
wmctrl -ilx | awk 'tolower($3) == "steam.steam"' | grep 'Steam$' | awk '{print $1}'
}
until [[ -n $(wid) ]]; do
:
done
wmctrl -ia $(wid)
sleep 0.1s
wid=$(xdotool getactivewindow)
local geo=$(xdotool getwindowgeometry $wid)
local pos=$(<<< "$geo" awk 'NR==2 {print $2}' | sed 's/,/ /')
local dim=$(<<< "$geo" awk 'NR==3 {print $2}' | sed 's/x/ /')
local pos1=$(<<< "$pos" awk '{print $1}')
local pos2=$(<<< "$pos" awk '{print $2}')
local dim1=$(<<< "$dim" awk '{print $1}')
local dim2=$(<<< "$dim" awk '{print $2}')
local dim1=$(((dim1/2)+pos1))
local dim2=$(((dim2/2)+pos2))
xdotool mousemove $dim1 $dim2
xdotool click 1
sleep 0.5s
xdotool key Tab
sleep 0.1s
xdotool key D Z G U I Return
}
steam steam://open/console 2>/dev/null 1>&2 &&
focus_beta_client
HEY! That works!
Excellent! I've pushed an update to testing. Please test:
A simple way of testing is removing one mod needed for a specific server and then attempting to connect.
A simple way of testing is removing one mod needed for a specific server and then attempting to connect.
How do I remove a mod?
It's a bit convoluted. Hang on, I'll add a feature to DZGUI that makes it easier to find the directories.
rm -rf <ID>
unlink <symlink>
We could look at some method of deleting these from inside the app, but it seems a bit overkill at the moment.
Also after the first two tries working, I get Steam must be running...
popup again.
Also after the first two tries working, I get Steam must be running... popup again.
What window was the Steam client on when this happened?
What window was the Steam client on when this happened? It was
I mean, what window of the Steam client?
Console, library, games list, small games list, friends, etc.
Some changes have been made to interact with the latest version of the Steam client in a more reliable fashion.
Info DZGUI version: latest Mode (normal/debug): Normal Linux distribution: Garuda (Arch Linux)
Bug description
steam://open/console
in Firefox the script detected the running process.Enter
was inputed resulting in a long string ofworkshop_download_item
command chain. Had to cancel (thanks for the Esc button), open the server again and press enter after every commend.Expected behavior
workshop_download_item
commandsWhy I put everything into one issue Since I use the Beta client with the UI redesign I suspect that the problems are in some capacity related to the beta version of Steam. I'm ok to split these into multiple issues if that's better.
PS: I haven't played DayZ for a long time so sorry for not replying to some previous Issues. You've done a great job and the launcher works well. Great job!