Could you add WeMod to the next version?

[BrandonKingM]

I have detailed a tutorial on installing it, but too many seem to be having an issue with my method. An STL autoinstall would greatly benefit the community. Also as i am still very much inexperienced with Linux, I have no clue what magic y'all do for symlinking everything properly so one app can access all games in your library, the STL install of Vortex is amazing and I would love to see something similar for WeMod. A centralized compatdata that holds the actual install, with STL symlinking your games to that prefix for it. My understanding of Linux is far greater than a novice, but there is still much beyond my capabilities, such as how beautifully STL handles this exact sort of thing. For reference i have included my tutorial on installing it, which I'm sure an experienced Linux veteran would probably be able to do it better and more efficiently than I did. One of the things i have grown to love about Linux is how many different ways you can do anything.

https://community.wemod.com/t/my-perfected-and-streamlined-wemod-tutorial-for-steam-deck/247160?u=brandonkingm

[sonic2kk]

I am not sure if it will make it into the next version or not but I will certainly take a look into this and see if it could be worth adding WeMod! 😄 I prefer adding "general purpose" tools to STL that support several games as opposed to single-game mod managers (see #720) and this seems like it supports more than a handful of games.

I will need to take a look deeper into this "WeMod" but your background makes it sound viable. Plus it seems like you have a guide (on my phone out of the house atm, so I haven't checked it just yet) so it seems like STL would just need to manually follow some already defined steps. It is still possible that users will still have issues depending on what is required (many users have issues with DotNet 4.8, and sometimes prefixes get borked and users can't fix it), but we can basically adapt the guide you have written into a wiki page :-)

I didn't actually write the symlinking stuff that STL does for Vortex/MO2 (it was written even before I took over as maintained 😅) but I think I have a grasp on how it works and should be able to take a stab at it.

I will investigate adding this when I have some free time. No ETA or anything, I have a couple of medium-sized features in the pipe ready to be merged and a couple of other things up next to look at. Once I have time though I'll look into it, could be fun :-)

[BrandonKingM]

My guide actually is 100% reliant on STL lol and yeah, WeMod supports over 2000 games. It's got all the biggest and best names in the trainer industry behind it like Fling and Mr. Anti-Fun. I'd really appreciate it if you guys considered it and yeah, fair, i don't know how close the next version is to releasing so i guess what i meant is more whenever you guys are able. My process seems to work for some, but not everyone so hopefully people more experienced than me can make it something more accessible. I did the best I could with what little I know.

[sonic2kk]

From reading the comments on the guide it's possible that dotnet48 is the bug bear here.

It can actually be installed with Winetricks using Proton 5.0, but most users don't know how to do this and we can't rely on users having Proton 5.0 installed. Many Linux desktop users also do not update their Winetricks version and so are using a 2-3 years old version which can't properly install newer Winetricks.

dotnet has been a major thorn in my side and many Linux gamers' side, but I will see what kind of implementation I can come up with in the future :-)

[BrandonKingM]

WeMod is a free program, but many Deck owners are subscribed to Pro. The biggest benefit of Pro is access to the mobile app, which is great because some games in Game Mode turn into a tiny little noninteractive box if you switch windows. For those games i have STL fork WeMod for 60 seconds to give me time to login before the game launches, then i move it to 3 seconds after the initial login and use the app to do everything. That is a problem with SteamOS so not something I am asking you to solve, just figured it would be helpful to mention so if you decide this is something you could add at some point you know to include a timer for games that need such workarounds.

[BrandonKingM]

From reading the comments on the guide it's possible that dotnet48 is the bug bear here.

It can actually be installed with Winetricks using Proton 5.0, but most users don't know how to do this and we can't rely on users having Proton 5.0 installed. Many Linux desktop users also do not update their Winetricks version and so are using a 2-3 years old version which can't properly install newer Winetricks.

dotnet has been a major thorn in my side and many Linux gamers' side, but I will see what kind of implementation I can come up with in the future :-)

I include a link in my guide to WineHQ, the DotNet 4.8 installer there is the ONLY one I've personally had success with when trying to get WeMod working properly

This is the link

https://appdb.winehq.org/objectManager.php?sClass=version&iId=38203

[sonic2kk]

For those games i have STL fork WeMod for 60 seconds to give me time to login before the game launches, then i move it to 3 seconds after the initial login and use the app to do everything. That is a problem with SteamOS so not something I am asking you to solve, just figured it would be helpful to mention so if you decide this is something you could add at some point you know to include a timer for games that need such workarounds.

Thanks! Hopefully though for the "initial setup" during installation there won't be any need to have a fork timer, as it will launch independently of the game during installation/when running in the prefix (we could have an option to run in the prefix "standalone" for several other reasons too). Not too sure how to handle game launches yet but I'll try to figure that out once I get around to looking into an implementation.

I guess for games, WeMod runs as a separate custom program with the 3 second fork timer? That way WeMod launches, then 3 seconds later the game launches. And WeMod runs in the game's prefix? I wonder how that works with DotNet, since surely we'd only need to install DotNet for the WeMod's prefix and not each game's prefix. Maybe WeMod doesn't even need to run with a game at all.

I have a lot of things to investigate and it's not a massively high priority but it could be a fun experiment to at least try it out. Though I'm wondering if it would be better delegated to #625, where it could be added as a custom command that way (the idea for the future is that custom commands can have a lot more customisation, you can configure Winetricks, prefixes etc - No ETA on when this will be implemented either but it could be a better go-forward than bespoke WeMod support).

I include a link in my guide to WineHQ, the DotNet 4.8 installer there is the ONLY one I've personally had success with when trying to get WeMod working properly

Huh, interesting. Not sure why this would be, but good to know!

[BrandonKingM]

That is very true! Forgive me, i literally was just talking to someone about how Vortex on STL works by having one install and everything symlinked to it, and yet it slipped my mind lol

[BrandonKingM]

I guess for games, WeMod runs as a separate custom program with the 3 second fork timer? That way WeMod launches, then 3 seconds later the game launches. And WeMod runs in the game's prefix? I wonder how that works with DotNet, since surely we'd only need to install DotNet for the WeMod's prefix and not each game's prefix. Maybe WeMod doesn't even need to run with a game at all.

Yes, on Windows you can launch the game straight from WeMod, though i haven't quite figured that part out on Linux. And I've tried having just one installation, but as i said, the way STL handles symlinking everything so it just works is beyond my capabilities to do, though i do have a fairly solid grasp on how it works. The best i could do is treat WeMod like how Steam treats third party launchers like Uplay and stuff, where everything is installed individually to each prefix and you have to login to each and every one. It works but its incredibly time consuming and tedious. Especially if I'm trying to use WeMod on a game series like Assassins Creed. That's the worst. Gotta login to both the Uplay Connect launcher and WeMod for each and every game in the entire series.

[BrandonKingM]

I have a lot of things to investigate and it's not a massively high priority but it could be a fun experiment to at least try it out. Though I'm wondering if it would be better delegated to #625, where it could be added as a custom command that way (the idea for the future is that custom commands can have a lot more customisation, you can configure Winetricks, prefixes etc - No ETA on when this will be implemented either but it could be a better go-forward than bespoke WeMod support).

Huh, just took a look at 625, and given the example of Cheat Engine, if that function works as that thread envisions it, that could very well be a perfect solution! And yeah, more customization of custom commands is definitely something I'd love to see in general! Awesome! See what i mean though? That's what i love about Linux. For every task there is a million different ways to do it, and so long as it works each one is valid even if some are better ways than others.

[BrandonKingM]

I'm currently testing having WeMod in its own prefix and using Steam Tinker Launch to launch it as a custom command, but it looks like its not as seamless as I'd hoped. This could cut back on some of the tediousness of my method by having WeMod pre-installed, but you still need to install DotNet 4.8 on each game and login to WeMod per game. I have absolutely no clue how STL lets all games share settings the way it does

[sonic2kk]

but you still need to install DotNet 4.8 on each game

Ah, this is going to be extremely problematic as dotnet48 installation is notoriously unreliable for game prefixes... Damn. Perhaps adding this will not really be feasible and will have to be left up to #625, where it is the user's responsibility to understand how to get dotnet48 installed.

[BrandonKingM]

I tend to have the highest rate of success installing that WineHQ installer from Steam Tinker Launch than any other way outside of STL, but like i said, what I think would work is if it could be symlinked like Vortex and MO2. I am not yet experienced enough to test that out on my own, everything I do either doesn't work or partially works when it comes to getting it to be a fairly seamless experience.

[BrandonKingM]

I was just letting you know that i think i have found a slightly less tedious way than my original.

[sonic2kk]

Perhaps at the very least if we can come up with a very defined set of steps to install WeMod and get it to work with Wine, we can leave this issue open and a community member who uses WeMod can contribute support :-)

[sonic2kk]

This likely won't be included in the next release, and dotnet48 is becoming more and more unreliable under Wine, so I don't have much interest personally in implementing this. However I will leave this issue open and up to the community to pick up and implement if anyone wants to :-)

[free-storage]

@BrandonKingM Hello. Did you find an easier way to launch WeMod?

[ro161012]

I would like to know aswell.

[BrandonKingM]

@BrandonKingM Hello. Did you find an easier way to launch WeMod?

No, but i recently made a video showing it.

https://youtu.be/tBafGFgWSmU

[sonic2kk]

Just wanted to note that the issue with WeMod bugging out when switching windows is likely some kind of GameScope/SteamOS issue. GameScope on a regular distribution doesn't actually offer the ability to switch between windows, so this is something Valve have either baked into SteamOS/the Steam client on Steam Deck, or the version of GameScope that they ship (hard to say but i would guess the Steam client).

Steam Deck Game Mode is at its core, just the Steam client running in a GameScope session, and running with -gamepadui (or "Big Picture Mode").

#780 seems to report similar behaviour to buggy windows when switching programs. I don't believe STL can do anything about this but it may be worth reporting general buggy behaviour when switching windows to Valve on one of the following issue trackers (kisak or someone will probably triage it properly, they're pretty cool about that):

• SteamOS issue tracker
• Steam for Linux issue tracker
• GameScope issue tracker

I don't have any expertise working with GameScope or any sort of compositor stuff, and I don't work for Valve, so I can't really investigate the issues relating to that. However, I think reporting it to Valve may be a good idea, as general buggy behaviour when switching GameScope windows is not isolated to STL and could be fixed by Valve :-)

[BrandonKingM]

It only happens on some games, WeMod Pro is very useful for when it happens because you can just use your phone to turn everything you want on

[sonic2kk]

I am not necessarily against accepting a PR to implement this if it can be done reliably I suppose, but relying on WeMod Pro is not something I'm wholly comfortable with. To be honest, adding a program that isn't at least partially open source is not something I'm overly happy with either. We already deal with Steam 😅

I'm going to close this as it seems no one from the community is interested in implementing support. It's something I wouldn't be against adding per se but it would need to be a community contribution which is reliable, and ideally the program would get better support for Wine and Steam Deck's GameScope implementation.

It's a nice idea, maybe if there's a FOSS alternative that doesn't rely on .NET it would be better though :-)

[BrandonKingM]

I am not necessarily against accepting a PR to implement this if it can be done reliably I suppose, but relying on WeMod Pro is not something I'm wholly comfortable with. To be honest, adding a program that isn't at least partially open source is not something I'm overly happy with either. We already deal with Steam 😅

I'm going to close this as it seems no one from the community is interested in implementing support. It's something I wouldn't be against adding per se but it would need to be a community contribution which is reliable, and ideally the program would get better support for Wine and Steam Deck's GameScope implementation.

It's a nice idea, maybe if there's a FOSS alternative that doesn't rely on .NET it would be better though :-)

From my experience, its not many games that do this. Most work fine. Just those particular games the app is really the only way to activate everything. The only two games that come to mind are Brutal Legend and Star Wars Empire at War. But this isn't a WeMod issue, its either a SteamOS issue or an STL because i first had it happen with Star Wars EAW when trying to use Cheat Engine back when STL included it.

[BrandonKingM]

I am not necessarily against accepting a PR to implement this if it can be done reliably I suppose, but relying on WeMod Pro is not something I'm wholly comfortable with. To be honest, adding a program that isn't at least partially open source is not something I'm overly happy with either. We already deal with Steam 😅

I'm going to close this as it seems no one from the community is interested in implementing support. It's something I wouldn't be against adding per se but it would need to be a community contribution which is reliable, and ideally the program would get better support for Wine and Steam Deck's GameScope implementation.

It's a nice idea, maybe if there's a FOSS alternative that doesn't rely on .NET it would be better though :-)

This guy used Linux scripts to get WeMod running on general Linux like a month or so after i figured it out on Deck with STL, he told me he's willing to look into making an installer for it because his method goes way over my head. My knowledge of terminal stuff and .sh scripts isn't much more than semi intelligent copy and paste.

https://www.reddit.com/r/linux_gaming/comments/10ymx04/tool_to_run_wemod_in_linux_and_steam/jg2ccda?utm_source=share&utm_medium=android_app&utm_name=androidcss&utm_term=1&utm_content=share_button

[sonic2kk]

Once the native Linux part of #788 is implemented it would be possible to run this with STL, if it needs to install into prefixes, etc.

Good to know support for it is coming elsewhere though 👍

i first had it happen with Star Wars EAW when trying to use Cheat Engine back when STL included it.

Sounds like SteamOS/GameScope, see #780. Though keep in mind, the resolution issue isn't the problem here. It's the proprietary nature of the software with a premium model, and .NET.

[shymega]

I just came across this issue, and I have to say, it's a shame it's been closed. STL could take full advantage of WeMod (once UAC and .NET have been resolved), despite it being proprietary. Many games are proprietary. It doesn't seem fair to lock WeMod away from users who want to use it.

If they want to, then surely we should allow them? Proprietary software is everywhere, even in the computer being used to game on (except in certain cases).

I would be happy to do some beta-testing, and perhaps some debugging of STL and WeMod. I have to admit though, I do find the STL GUI a little confusing.

Anyway, hopefully, we can re-open this issue. We should allow users to mod how they want, whenever they want. WeMod having a premium tier is not a prerequisite for usage.

[shymega]

I've been thinking of ways to approach this. I'm not familiar with STL's codebase, but one thing that comes to mind is that the UI is a bit.. 'janky'. I wonder if we should first look into a plugin-based approach, where the UI can be extended by plugins - and then if people don't want WeMod available (or anything, really, say if they want to slim STL right down), they just don't install the plugin.

The question is, how do we approach a plugin-based architecture?

Should I open a 'Discussion' or a new issue for tracking this?

[ro161012]

I've been thinking of ways to approach this. I'm not familiar with STL's codebase, but one thing that comes to mind is that the UI is a bit.. 'janky'. I wonder if we should first look into a plugin-based approach, where the UI can be extended by plugins - and then if people don't want WeMod available (or anything, really, say if they want to slim STL right down), they just don't install the plugin.

The question is, how do we approach a plugin-based architecture?

Should I open a 'Discussion' or a new issue for tracking this?

Now this sounds good.

[sonic2kk]

Anyway, hopefully, we can re-open this issue. We should allow users to mod how they want, whenever they want. WeMod having a premium tier is not a prerequisite for usage.

Indeed, it isn't, but I don't think this is something STL needs to implement.

one thing that comes to mind is that the UI is a bit.. 'janky'.

You'll want to open a discussion upstream to Yad about this, as STL's UI is a product of using Yad.

The question is, how do we approach a plugin-based architecture?

I wouldn't be against this, but I am also not fully interested in creating something like this myself.

If they want to, then surely we should allow them?

SteamTinkerLaunch is not disallowing anything by not adding WeMod support. Just because it isn't adding automatic configuration for a given tool doesn't mean it's disallowing users. The tools are there to get it to work, STL doesn't need to implement this itself as far as I'm concerned for the moment.

It doesn't seem fair to lock WeMod away from users who want to use it.

Once again, this a deliberate unfair assessment of what was stated. SteamTinkerLaunch is not locking anything away from users and it is utterly ludicrous to claim that this is the case. Just because a feature request was closed doesn't mean anything is being locked away.

---

I think the wrong impression has been given here and there has been a misunderstanding. The main reasons for not including WeMod support in STL right now is:

• Getting it to work reliably on Linux seems to be a crapshoot (looking at you, .NET).
• If it could be gotten to work reliably, the steps to use it seem to be relatively straightforward to do manually (if .NET wasn't needed and it worked with Mono, just add it as a custom program).
• If it required any further tinkering, it would be possible to use it when Feature Request: More Custom Command Control #625 is worked on. When it comes to WeMod, this could probably be the "plugin" architecture to some extent, as it should allow adding custom programs that need specific steps much more easily.
• The proprietary nature of the software is somewhat offputting.
• Adding more modding tools might further the idea that STL is just a frontend for installing/managing mods, which it isn't.
• WeMod Pro seems to be "encouraged" for now from the impression I got from OP
• I am not interested in working on it, and no one stepped up to look at this.

Locking users out of modding isn't the intent. I just don't see why this would be needed to be implemented in STL if it already gives users the tools to tinker and install it.

I am not sure what "taking full advantage" of WeMod really means. STL is a tool for tinkering, users are expected to tinker. It isn't a frontend to install mod tools, and it should already provide the means to install WeMod manually. I don't see a need to add this to STL explicitly.

---

And before any consideration is made about adding this to STL, any users that want to see WeMod on Linux should make a case for, at minimum, improving support under Wine. Even better, making a case for native Linux support would be ideal. But if upstream WeMod can improve support under Wine that would be a better first step before investigating adding it to STL. MO2, for example, has made great efforts to improve Linux support. The HMM devs make a good effort too but from what I recall are mostly held back because of limitations with the tooling HMM uses that is just currently unreliable under Wine. WeMod seems to be a much larger team, you should make a case to them to improve Wine support before looking into integrating it with a downstream script like STL.