Vortex doesn't open - Githubissues

System Information

SteamTinkerLaunch version: 12.12-1
Distribution: Arch Linux, Kernel: 6.9.3-zen1-1-zen
Installation Method: aur/yay

Issue Description

Tried starting vortex but it never opens. Using the console to launch it all it outputs before opening:

steamtinkerlaunch vortex start
sed: -e expression #1, char 0: no previous regular expression
Tue Jun  4 06:23:16 AM EEST 2024 INFO - startVortex - Starting Vortex without options

Logs

steamtinkerlaunch logs when opening vortex 31337.log

All issues from users ignoring the issue template dictating to use the latest commit from master will be closed.

Feel free to search through currently open issues to see if someone else has already reported your issue, or to see if your issue has already been resolved. If at all possible, try testing the latest version of SteamTinkerLaunch from the master branch to see if the issue has already been fixed. You can also check the changelog on the wiki to see if its been fixed since the latest release: https://github.com/sonic2kk/steamtinkerlaunch/wiki/Changelog

The changelog notes extensive changes to Vortex behaviour. Also, checking the GitHub releases would show v12.12 is over a year old. There will eventually be a v14.0 but you should never, never, never, ever use anything except master, pulling and re-installing or rolling back to last known working commits in the event of issue.

Uninstall and re-install Vortex from master. If the issue still persists, feel free to investigate and submit a PR. Vortex works for me on master but I don't recommend using that software and soon hope to remove it from STL in favour of their Vortex app.

It weirdly started working today xD

Also thanks for making me notice nexus deprecated vortex and made a new c# app

what did you do to fix it?

They said it just started working in their reply, however, make sure to use SteamTinkerLaunch from master. Users who do not and insist on ignoring all guidance and common sense and using a version from over a year ago despite hundreds of commits and changes since then, should expect problems.

My advice to that user still stands; remove Vortex entirely, use STL from master (you should never use a release unless you have a very good reason), and if the issue persists, dig into the code and logs and see if you can find the issue. If you are on SteamOS, do not use mods, it is a waste of time.

Be especially mindful of what Vortex version you're using (is it confirmed to work with Wine?) and what Proton version you're using to install Vortex (latest GE is probably a good bet). Similarly, try messing with the option to enable the Steam Linux Runtime for Vortex installation if it's not already enabled.

But above all, if you experience issues, it is best to investigate the problem yourself first to see if it's an upstream Wine problem. Users who simply say "Vortex isn't working" are unlikely to get any help or resolution. Users who say "There is a regression/missing feature in Wine that breaks Vortex version X.Y.Z" are far more likely to actually get a resolution.

Try the steps I outlined earlier and in this comment, and see if you can get Vortex going.

They said it just started working in their reply, however, make sure to use SteamTinkerLaunch from master. Users who do not and insist on ignoring all guidance and common sense and using a version from over a year ago despite hundreds of commits and changes since then, should expect problems.

My advice to that user still stands; remove Vortex entirely, use STL from master (you should never use a release unless you have a very good reason), and if the issue persists, dig into the code and logs and see if you can find the issue. If you are on SteamOS, do not use mods, it is a waste of time.

Be especially mindful of what Vortex version you're using (is it confirmed to work with Wine?) and what Proton version you're using to install Vortex (latest GE is probably a good bet). Similarly, try messing with the option to enable the Steam Linux Runtime for Vortex installation if it's not already enabled.

But above all, if you experience issues, it is best to investigate the problem yourself first to see if it's an upstream Wine problem. Users who simply say "Vortex isn't working" are unlikely to get any help or resolution. Users who say "There is a regression/missing feature in Wine that breaks Vortex version X.Y.Z" are far more likely to actually get a resolution.

Try the steps I outlined earlier and in this comment, and see if you can get Vortex going.

interesting, I only would want to use vortex because downloading like hunderds of mods one by one can be annoying, but I understand. I was able to get it working but in a weird skuff way by installing it weirdly. Now I cant deploy the mods so I understand, I think my plan is to download all the mods and then once they are all download, and move them to my actually game.

Thanks for the tips.

They said it just started working in their reply, however, make sure to use SteamTinkerLaunch from master. Users who do not and insist on ignoring all guidance and common sense and using a version from over a year ago despite hundreds of commits and changes since then, should expect problems.

My advice to that user still stands; remove Vortex entirely, use STL from master (you should never use a release unless you have a very good reason), and if the issue persists, dig into the code and logs and see if you can find the issue. If you are on SteamOS, do not use mods, it is a waste of time.

Be especially mindful of what Vortex version you're using (is it confirmed to work with Wine?) and what Proton version you're using to install Vortex (latest GE is probably a good bet). Similarly, try messing with the option to enable the Steam Linux Runtime for Vortex installation if it's not already enabled.

But above all, if you experience issues, it is best to investigate the problem yourself first to see if it's an upstream Wine problem. Users who simply say "Vortex isn't working" are unlikely to get any help or resolution. Users who say "There is a regression/missing feature in Wine that breaks Vortex version X.Y.Z" are far more likely to actually get a resolution.

Try the steps I outlined earlier and in this comment, and see if you can get Vortex going.

I am a bit confused by this response; 12.12 is widely used because in the README, the first listed and "preferred" installation option is using a package manager (which all use 12.12 or lower, and 12.12 is marked green, implying good to use):

If you expect the majority of users to use the master branch, the installation section should reflect that. Note that ProtonQt also tries to install 12.12 out of the box.

I would also add that users may not be aware of how to access logs to tell if an issue is due to an upstream wine problem. I personally am having this issue as well and have no idea where to look. There is nothing in steamtinkerlaunch vortex start that indicates an issue, it just hangs and no UI is launched (which I assume is unexpected behavior). Is there a button I am supposed to press to get logs? Is there a specific folder I am supposed to look at?

I am a bit confused by this response; 12.12 is widely used because in the README, the first listed and "preferred" installation option is using a package manager

No, the preferred installation method is to use a package manager. If package maintainers aren't packaging from git, that isn't up to me; some package managers are still packaging very old versions, and some are packaging from a more up-to-date version of master.

The Installation wiki should also be read before installation, because if a user does not, they may be missing some packages.

Similarly, the issue template already tells users to use master before filing an issue, so all of this is moot anyway. Even a user who doesn't use master should know to test master before opening an issue.

Once v14.0 does eventually release I will also include a warning for users to not use releases unless they absolutely have to, and that they should use master. I don't know what the release cadence will be after v14.0, if there is really demand for some reason, perhaps every 6 months or so, but I would prefer to not really have releases at all, since SteamTinkerLaunch is just a Bash script.

(which all use 12.12 or lower, and 12.12 is marked green, implying good to use):

No they don't all use v12.12. Nix named their package oddly but it isn't using v12.12. The AUR steamtinkerlaunch-git package has a similar naming issue, but it will pull from master.

Also, the packages being marked green is irrelevant. That comes from repology, that has nothing to do with me. It is just an embed that displays a selection of available packages. I can understand why it may be confusing if users are unfamiliar but I don't have control over that

They aren't listed by repology, but the SteamTinkerLaunch Flatpak for Steam Flatpak isn't even using v12.12.

Note that ProtonQt also tries to install 12.12 out of the box.

I wrote the ProtonUp-Qt integration for SteamTinkerLaunch with guidance from the ProtonUp-Qt maintainer. Granted that was quite a long time ago and things have changed (I wasn't SteamTinkerLaunch maintainer back then) but I explicitly write support to install SteamTinkerLaunch-git via ProtonUp-Qt, and even documented this on the ProtonUp-Qt wiki, which should be read before installation with ProtonUp-Qt. The Readme even links to this page.

So, if you enable Advanced Mode, this isn't a problem. And because SteamTinkerLaunch is a tool for enthusiasts, I would expect them to try to enable Advanced Mode. Perhaps it could be clearer how to do this in ProtonUp-Qt, and there has been discussion on that project about it (I am a semi-regular contributor), but that is not something for discussion on this project.

If you think SteamTinkerLaunch-git should be available in ProtonUp-Qt without Advanced Mode, I can open a PR and discuss it with that project's maintainer.

I would also add that users may not be aware of how to access logs to tell if an issue is due to an upstream wine problem.

The Readme already documents where to find the Wine output that it gets from running the Vortex executable. Modding games on Linux with a mod manager is a bad idea, but if you're going to do it, you need some awareness and familiarity with Wine (one should really have this before using SteamTinkerLaunch to begin with).

If there is anything specific SteamTinkerLaunch can do to propagate any more logging information up to make this easier to troubleshoot, I am absolutely all ears. I am always in favour of improving logging and giving users the tools to help troubleshoot!

I personally am having this issue as well and have no idea where to look.

As the Readme states, "SteamTinkerLaunch may also store additional logging information in /dev/shm/steamtinkerlaunch."

From a quick look at the code, this seems to get written to /dev/shm/steamtinkerlaunch/vwrun.txt. By running the executable and redirecting the Wine output it gets to this file with > "$VWRUN" TheVWRUN variable is set to $STLSHM/vwrun.txt near the top of the script (https://github.com/sonic2kk/steamtinkerlaunch/blob/28c98581524e8ee309a36087f6b3abe1136e990c/steamtinkerlaunch#L95).

I don't use Vortex and didn't write the integration, but general Wine application troubleshooting should help you get any more detailed logs if the ones in that file aren't adequate. They look a bit sparse from my run, but Vortex runs correctly for me, so there probably doesn't need to be any further logs.

There is nothing in steamtinkerlaunch vortex start that indicates an issue, it just hangs and no UI is launched (which I assume is unexpected behavior)

If you're referring to a broken program simply hanging, It's not SteamTinkerLaunch's job to try and detect Wine program failures. If the Wine process hangs, it is very rare for any program to propagate that up. If you launch a game with a borked prefix from, for example, Lutris, it will just hang. There is no good way to know when a program hangs. The Steam Client does this too.

If you run an executable with Wine and it fails for whatever reason but the process doesn't crash,

If you have found a specific problem with how SteamTinkerLaunch runs Vortex that is more than "Vortex doesn't open" then absolutely open an issue. But this isn't a troubleshooting forum, this is an issue tracker to report and fix specific bugs. #792 is a good example of a Vortex bug report; a specific version of Vortex is failing with Wine, and some specific logs to troubleshoot why.

The details of how SteamTinkerLaunch work are no secret either, the project is open-source. All SteamTinkerLaunch does to run Vortex is run the executable with the specified Proton version in a Vortex-specific Wine prefix (https://github.com/sonic2kk/steamtinkerlaunch/blob/28c98581524e8ee309a36087f6b3abe1136e990c/steamtinkerlaunch#L15780-L15784). Sure, it has a bit of spice to be able to get that information, but it's not doing anything differently to Lutris, Heroic, Bottles, or even the Steam Client.

You can even run the command yourself. In fact, I should probably add logging that enters the raw command (with the expanded variables) so that a user can copy and paste it from the log themselves. I will work on that after this reply. But the command basically boils down to this:

# PATH has to be set historically for some issues, not sure if it's still a problem
# The WINE and WINEPREFIX paths can of course vary
# The path to the Vortex executable will change depending on where you installed it, by default STL puts it in the Vortex prefix
PATH="$PATH" LD_LIBRARY_PATH="" LD_PRELOAD="" WINE="/home/username/.local/share/Steam/steamapps/compatibilitytools.d/GE-Proton9-7/files/bin/wine" WINEARCH="win64" WINEDEBUG="-all" WINEPREFIX="/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx" "/home/username/.config/steamtinkerlaunch/vortex/compatdata/pfx/drive_c/Program Files/Black Tree Gaming Ltd./Vortex/Vortex.exe" > "/tmp/vortex-wine-log.txt" 2>/dev/null

It does do some other things before running this exe, but to see what Wine runs into maybe with some specific debug options or your own redirects or custom Wine versions, a command to this effect should work.

Is there a button I am supposed to press to get logs? Is there a specific folder I am supposed to look at?

Log information for SteamTinkerLaunch, as stated on the Readme, is stored at /dev/shm/steamtinkerlaunch.

SteamTinkerLaunch serves a niche of Linux gamers. Previously, Linux gamers were the niche, where most Linux gamers were enthusiasts. That is changing, and perhaps there are tools to serve their needs better, but SteamTinkerLaunch is not that tool. However, that doesn't mean the project is perfect, and I am very open to feedback so long as it is specific and provides clear benefit to technical users. There is always overlap, and serving technical users doesn't mean something has to be unfriendly, but what I'm trying to say is I keep the target audience in mind. This isn't a tool for people who are new to tinkering with games is what I'm getting at.

In my opinion, a lot of the issues surrounding Vortex come from less than great documentation on my part (I don't use nor like Vortex), and users who just want to run Vortex and aren't familiar with Wine. I think some people write guides and advertise SteamTinkerLaunch as some kind of gamers tool instead of an enthusiast tool (hence the name SteamTinkerLaunch, as the creator named it long ago), but that is just speculation on my part.

Improvements to Vortex documentation are welcome but I also appreciate that it is difficult to submit docs improvements. GitHub Wikis are not great for collaboration and it frustrates me, but opening issues with specific wording changes and such for documentation is welcome and has been submitted before.

So, in summary:

No, the Readme doesn't list v12.12 as the preferred version, it lists the Package Manager as the preferred installation method. But regardless, before reporting issues, the issue template tells users to use master first.
ProtonUp-Qt allows you to use SteamTinkerLaunch-git, and the ProtonUp-Qt wiki page already documents to enable Advanced Mode.
Users attempting to use mod tools on Linux, or do any sort of tinkering for that matter (that is, using SteamTinkerLaunch, a tinker tool), should be familiar with how to do at least basic Wine troubleshooting. Feedback is welcome on improving propagating any log information better.
Logs can be found at /dev/shm/steamtinkerlaunch as noted on the Readme. Vortex-specific logs appear to be under /dev/shm/steamtinkerlaunch/vwrun.txt.
The "hanging" is because the Wine process fails and hangs. It would do the same if you ran the executable manually. This is common with other tools like Lutris and the Steam Client.
Log information is not presented with a button, it is redirected out to a text file at /dev/shm/steamtinkerlaunch/vwrun.txt.

So, feedback and improvements are welcome and I understand where some of the confusion is coming from, I think a lot of it can be answered above though. I hope the elaboration helps. I do not want to appear or even act obtuse. I took over this project because I use it and want to help others. But in some ways, you cannot help users who do not first help themselves.

The frustration you're putting across indicates that it is not always clear how users can help themselves to provide better issues or even solve issues themselves. I've put across my side and views, and the decisions and steps I have taken and continue to take. And as stated above, feedback and improvements are still welcome. I do welcome constructive discussion about this project, and my frustration comes from issues where I don't get enough information to help, or where users may not be in the target audience for SteamTinkerLaunch (there have been users reporting issues that were brand new to using a desktop computer, not even just Linux).

I am always open to discussing and improving this project, documentation, and so on, so long as it can be agreed that it's necessary and how to approach it. In terms of this issue, I think answering your questions on where to get logs is a good first step. For the documentation on which version to use, I think that is a misunderstanding. You didn't open an issue afaik so you wouldn't have seen the issue template (although OP should have). And for users not knowing where and how to diagnose something as a Wine issue, that is down to possibly SteamTinkerLaunch not being the correct tool for that user. If they have never spent time using Wine manually before then maybe SteamTinkerLaunch is not the right tool. There is an expectation with this project that a user should be a Linux enthusiast, and maybe that needs to be clearer somewhere from my side.

Since the release of Proton, Valve taking it under their wing and releasing the Steam Deck, Lutris, and easy to use custom tuning like Proton-GE, it is the easiest time ever to be a Linux gamer. Personally most stuff just "works" for me and has for years. I suspect increasingly, people coming to excellent tools like your own will only have experience with selecting their Proton version from the Compatibility dropdown in Steam, or even less than that (people freshly migrating from Windows for example). They might barely know what WINE is. I think this may be where you are at:

An average semi-technical user, even a technical one like myself (full time developer) would not bother to assume that the first two installation options in the README are likely to be wrong. (They are wrong, if you follow them blindly you WILL install the 12.12 version.) Users just want to read the minimum amount and install it and get it running. If it doesn't work from that, users will simply move on and do something else.

I did this last time I tried to get mods working for my intended game a couple years ago and only recently came back to it now. In the past I personally just assumed it was horribly broken (because following basic installation instructions on the README did not work) and played something else. I never bothered to read the installation wiki because the README says "preferred" which implies the other options are not preferred / only need to know for niche use cases, and my use case seemed fairly simple and non-niche (simple STL install and press the Vortex button).

For what it's worth, using Vortex to install mods for my game works beautifully after I went to master branch (which I only learned from happening to read this Github issue after searching "Vortex" in this repo). But if you want all users to have a similar experience, the top of the installation guide in the README should say "clone the repo and build it using XYZ" like it says buried in the Installation Wiki.

Similarly, the issue template already tells users to use master before filing an issue, so all of this is moot anyway. Even a user who doesn't use master should know to test master before opening an issue.

How many end users do you think try and open a Github issue when they encounter a problem? I would guess less than 10%. Do you want 90%+ of users to install the wrong package version? I have had trouble even in workplaces, where people are ostensibly paid to be communicative and responsible, to get them to bubble issues up to me - people will just bodge a solution or find another way. Receiving ANY user feedback is a miracle of sorts.

I am always open to discussing and improving this project, documentation, and so on, so long as it can be agreed that it's necessary and how to approach it. In terms of this issue, I think answering your questions on where to get logs is a good first step.

If there is anything specific SteamTinkerLaunch can do to propagate any more logging information up to make this easier to troubleshoot, I am absolutely all ears. I am always in favour of improving logging and giving users the tools to help troubleshoot!

Yes, I appreciate this! This would be a large change but you might consider the Lutris style of logging, where a window pops during game installation / setup for logs. Since STL is a tinkering tool it could just always have a log window open. Additionally, if logs are sometimes hidden, a "logs" button would be helpful - Lutris lets you right click on the game and click "Show Logs", but for STL you could include it in the settings / mainmenu grid. It doesn't have to be fancy, just xdg-open the user's editor pointing at /dev/shm/steamtinkerlaunch/vwrun.txt. Somewhere in here perhaps:

I'd like to level-set here a bit, some of your reply comes across the wrong way to me, and in fairness I feel as though my responses have as well. I'm not out here to make any enemies, I'm not here to put you down or be rude.

I'm opinionated about the direction of this project to an extent, and I feel as though that comes across as shutting down discussion. To some degree, some things are not entirely up for discussion, but I do welcome your feedback here.

people freshly migrating from Windows for example They might barely know what WINE is

Again, I can appreciate this, but please understand, SteamTinkerLaunch is not for those users. I am not targeting those users. I am targeting people who do have this experience.

There's nothing stopping anyone from using SteamTinkerLaunch physically, but the "development philosophy" is not for people coming fresh from Windows. From my experience before taking over as well, it never has been.

I'd also like to point out that while the general sentiment of the comic is true, typical users don't have expertise, I'm not trying to claim I'm an expert. I am far from it. I'm just a user who has been tinkering with using Wine (not developing, just surface level usage) for maybe closs to 10 years.

I suspect increasingly, people coming to excellent tools like your own will only have experience with selecting their Proton version from the Compatibility dropdown in Steam

And SteamTinkerLaunch is not made with these users in mind, broadly speaking. Of course I'm not going to block anyone over something like this or anything extreme, but if a user doesn't know what a Wine prefix is, there is only so far they're going to get with a tool that gives you the means to tinker with such things.

SteamTinkerLaunch is not a general purpose tool, it is for the niche of Linux enthusiasts.

Users just want to read the minimum amount and install it and get it running. If it doesn't work from that, users will simply move on and do something else.

They might move on and they're welcome to. SteamTinkerLaunch is very much a "RTFM" project, if you'll excuse the crude acronym. I expect users to read the documentation.

SteamTinkerLaunch has various options dependencies that are going to be missing on a lot of systems. Some of these dependencies (like GameScope) should ideally be also installed from their respective main branches. If a user doesn't read the wiki, they're going to miss these.

and my use case seemed fairly simple and non-niche (simple STL install and press the Vortex button).

In my opinion, using Vortex is not simple. In the context of SteamTinkerLaunch, this is one of the areas where you absolutely should have experience modding games with Vortex using Wine manually, so that you can troubleshoot when things go wrong. To put it in perspective, I would not even trust myself and my own Wine knowledge to be able to fix Vortex and Wine issues.

If I can make it clearer that Vortex is only meant for people with extensive nodding games with Wine knowledge, let me know.

Do you want 90%+ of users to install the wrong package version?

If they don't read the documentation thoroughly, I think it's natural to expect problems. Running into problems and revising docs is how you get things running. A lot of users coming from Windows might not do that, but long-time tinkerers generally will think.

They are also free to ask their package maintainers to update their packages.

I don't really mind if users don't open issues. I'll help users that provide meaningful information, and continue developing SteamTinkerLaunch based on users that do open issues, and for my own needs.

However the users that do open issues should thoroughly read the issue template. This is common courtesy to the developer in my opinion. And if they read this, they'll know to switch to master.

Receiving ANY user feedback is a miracle of sorts.

Feedback in the form of issues is of course welcome, but the best feedback and the feedback I look for most are pull requests.

This would be a large change but you might consider the Lutris style of logging, where a window pops during game installation / setup for logs.

I dislike this kind of logging (imo it's easier to just read a text file) but I'm not sure if this degree of dynamic window content is possible with Yad (the GUI toolkit used with SteamTinkerLaunch).

For using xdg-open, such a button doesn't belong on the Main Menu in a dedicated way but it can go under Games Files I think which already has this integration.

But if you want all users to have a similar experience, the top of the installation guide in the README should say "clone the repo and build it using XYZ"

Alright, I will restructure the Readme to make this clearer alongside the v14.0 release. I feel like understanding repology from experience with other projects should be common knowledge about the target audience of SteamTinkerLaunch, but fair, I won't make too many assumptions.

I will make it clearer that users should manually install, and ensure they also install the relevant hard dependencies and any optional dependcies that they need.

I think some of the confusion here is that SteamTinkerLaunch is not a general purpose tool. It's development philosophy so to speak serves a specific niche.

I stumbled across SteamTinkerLaunch to solve a very specific problem I had. I began contributing, I was one of the only regular contributors, and eventually took the project over. I develop SteamTinkerLaunch the exact same way as maintainer that I did as contributor (fixing bugs I stumble across or that are reported, implementing features I think are useful or that are requested, and enhancing areas that I use).

Anyone is free to contribute to this project. If they have found ways to make things easier I always welcome PRs and do my damnest to review them thoroughly (an area I am new to, but I enjoy helping people contribute). Ideally the people using it are using it to replace their own manual scripts and solutions, and so should also be able to submit PRs.

From my own side however, I am not interested in making SteamTinkerLaunch hard to use but I'm also conscious of who the project was created with in mind and who I develop it for in mind. I think most of what you're raising here is "most users won't do XYZ" but in this case, SteamTinkerLaunch isn't really made for "most users". I don't forbid or gatekeep, but I have an audience in mind. I welcome improvements, PRs, and feedback, but at the same time I'm not creating this project for users whose experience with Linux gaming begins and ends with selecting a Proton version with the Steam Client. That is simply not who this project is made in mind with, because it is for tinkerers. And to emphasise again, I don't forbid anyone from using this project, everyone with an interest has to start tinkering somewhere, but I'm not here to make a project for users who just want to download and use SteamTinkerLaunch without reading the documentation.

This is not a commercial project developed the same way as a broad commercial consumer application. It isn't even developed the same way other Linux gaming tools are, that target users who "just want to play games". I develop this project, after work, in my bedroom, for zero monetary gain. I don't owe anybody anything here and vice versa, I extend this project as I would if it was archived by the creator and I continued it locally. As I tried to put across in my first reply, this doesn't mean I think the project is perfect, but you have to know your audience. Anyone is free to submit improvements that might also help a wider audience, but I develop it for a specific niche in mind.

When I'm contributing to ProtonUp-Qt for example, the users I have in mind for that project and the users I understand that project to be targeting, are vastly different from the users I develop SteamTinkerLaunch in mind with. There is always overlap (part of why SteamTinkerLaunch is in ProtonUp-Qt) and each users have their own goals, this is not a slight against any category of user. But I'm trying to illustrate what I mean by knowing your audience here. You don't need to know much about Wine to use ProtonUp-Qt to install GE-Proton, but you should know about Wine for SteamTinkerLaunch because it's a tool for explicitly digging down and tinkering.

EDIT: I wanted to clarify something. Although this project is developed pretty much mainly for my own needs, I do consider others' views when they voice them. When users open PRs I consider their opinions on approaches and implementations. The reason this project is mostly made up of my own needs is because I'm the main developer. If there were other active contributors/reporters/etc then a broader pool would of course be considered. I do not want to come across that this project is made for me because I have the only good ideas, because that is far from the case. I love a well thought out feature request, I love a PR implementing it even more. If and when there are more contributors, their ideas will always be considered. It is not "my way or the highway" as they say.

(random lurk)

Thank you very much taking the time to give this excellent answer @sonic2kk (imho worth to be pushed into the wiki ;))

I never had the patience (and language skills) for that.

sonic2kk / steamtinkerlaunch

Vortex doesn't open #1118

System Information

Issue Description

Logs