Suggestion - Please make a Linux native version

[VortexFeedback]

Vortex Version: 0.16.15
Memory: 15.61 GB
System: win32 x64 (6.1.7601)
Please make a Linux native version so that I don't have to just run it through WINE.

Reported by: AmayaSasaki

[8BitCerberus]

Especially with Valve's Proton/Steam Play now getting so many games, including many serviced by Nexus' mods, running as or nearly as easy as on Windows. And for non-Steam games there's Lutris that takes a lot of the hassle out of managing Windows games on Linux.

[TanninOne]

Vortex is built on technologies that are also available on Linux (and MacOS), except for a few native libraries that would have to be re-implemented (stuff like reading the application version from a .exe file).
It's mostly a matter of investing the time, something we can't do at the moment.

[TheMatthew]

I was looking through the code "lightly" I don't pretend to know what I'm doing/saying.

It appears as though the only "windows" dependency left is Nexus/wholocks which could be replaced by https://www.npmjs.com/package/@ronomon/opened or something similar.

Everything else at the moment looks OK.

I am not sure when I will be competent enough to make a PR. if there are any Node/typescript masters out there, this could be a cool feature.

[VortexFeedback]

Vortex Version: 0.16.15
Memory: 15.66 GB
System: win32 x64 (6.1.7601)
I see Vortex is an electron app, with the improvements being made to Proton/Steam Play it would be incredible if there were a native Linux version of Vortex to use with Steam Play games.

Or at the very least some documentation put into getting every thing up and running under Linux, since Vortex does seem to run fairly well under WINE.

Reported by: Dreae

[TheMatthew]

I doubt that steam play / wine would work well on vortex as it uses undocumented windows apis. Just a heads up.

[8BitCerberus]

It works very well, actually. You can either install it directly in your game's prefix to manage that game (and subsequently install it in to each game's individual prefix that you want to manage), or set up it's own prefix and use symlinks to point it at each game install. I've currently got it managing Skyrim SE and installing mods is no problem. The only real issue is SKSE64 (and F4SE) doesn't work under Proton or Wine yet. There is a patch you can use and manually compile both Wine and Proton to get the script extenders working. But Vortex itself works pretty much flawlessly.

Since Vortex is using sym/hardlinks instead of MOs virtual file system, a native Linux version should just need to know where the games are installed and use Linux's link command instead of Windows' (ln vs. mklink).

[TheMatthew]

There's a magnificent individual that did this Nexus-Mods/node-wholocks#2 I got vortex working in wine, so it "works" but a native version would still be an interesting prospect for some.

[Mumrik93]

Getting Vortex to work on Linux would really kick up Linux as a viable alternative for gamers who are tired of Windows.. of which there are many, myself included.

[codeman101]

@TanninOne

I'd love to assist this issue and devote time to solving it but a hurtle I'd have to overcome that I'm not willing to do at the moment is going through the process of learning TypeScript. I'm curious as to why that was decided to be the base language of the project vs C/C++, C#, Java, Python ect?

[TanninOne]

TypeScript is a much easier language to learn than C++, C# or Java and less "unusual" syntax wise than python.
The decision was made
a) to encourage contributions from less experienced developers because if you already know one of the above mentioned languages you can start writing useful typescript code within hours
b) because a customisable UI was one of the top requirements for the project and HTML/CSS (vortex is based on electron) is more readily customisable and better known to more people than something like QML or XAML.
c) If this project had been written in C# (which was in fact an option we discussed), it would be using WPF and XAML and a Linux port would be entirely out of the question. If it had been written in C++ (another option) there would be a lot more code that would have to be ported for Linux (or MacOS). Java is never a good choice for UI-heavy, close-to-the-system applications (A lot of what Vortex does is managing files, creating symlinks, fixing permissions and such, I wouldn't want to do all that through JVM...). And python - what would be the advantage of python over javascript?

[codeman101]

A few things.

1. As far as python over javascript I'd think the syntax is easier for a beginner. (but I agree aside from Qt as of recently, there's no simple framework to write a GUI with python)
2. If the reason the project wasn't made in C# was because it'd be very hard to bring over to Linux why wasn't it designed with the intention of bringing over to Linux in the first place?
3. If the project is based off electron why is it using typescript instead of javascript? I thought all electron based apps used javascript for their UI and by their nature were cross-platform (for example slack) I even watched a youtube video a while back making it sound like the big plus to making an electron based app was that it would automatically be cross-platform. So you can imagine my confusion.

Update As far my third point I started going through the list on electron wiki of electron based apps and realized their not all javascript based. I'll add it to my to-do-list to try to help with making this project Linux native. :)

[Patricol]

@TanninOne

I'd also be interested in working on this; but unless I can figure out which components are os-specific without needing to read through the whole project; it'll be hard to prioritize.

If you can point out any of the relevant areas in the code; it'd greatly lower the barrier to contributing.

Or potentially add inline markers (e.g. //TODO: fix for linux) noting os-specific things as you run into them during the work you're already doing on the project. Or any other thing you'd prefer to do that'd achieve a similar result.

[codeman101]

@TanninOne

In addition to what @Patricol said can you confirm whether or not having a Windows system is a requirement to figure out some stuff? (I don't run one anymore other than wine)

[Patricol]

@codeman101 We'd need to test that our changes don't break the Windows version, so I'd say yes.

[TanninOne]

• Python may be easier if you know no programming languages at all, but as soon as you know any language with C inspired syntax, JS/TS will be easier
• We don't currently have the resources to support Linux but we always made it a point to don't burn down any bridges in regards to Linux support.
• typescript is more of a "meta" language that gets compiled to javascript at build time, all it does is provide us with type checking during build time. For an extension developer it doesn't matter whether you use javascript, typescript, coffescript, probably also stuff like elm or whatever. All languages that transpile to javascript are fine.
• slack is cross-platform because it uses no/practically no platform dependent functionality. Vortex is by nature closer to the system and more performance critical. It is a much more complex project and much closer to the OS. For example: Slack has no need to access the windows registry (directly).

A few examples of how Vortex might require and use platform dependent code:

• Vortex does require using the registry, because it's the quickest, most reliable way (on windows) to figure out where the games are installed.
  Electron is a cross-platform toolkit but it doesn't provide functionality to access the registry (obviously).
  Our only choices here were to either limit the usefulness of Vortex on our main platform or write platform dependent code.
  However, to my knowledge we put all code accessing the registry is behind a platform check and so Vortex wouldn't attempt to use it on Linux, instead using a fallback mechanism which would work on all platforms (either parsing Steam configuration files or searching the disk).
  But we don't know, because we didn't test if
  a) Vortex actually looks for the steam configuration files in the right place on Linux
  b) Whether the steam configuration files are actually the exact same format on Linux
  c) Whether Vortex correctly determines automatically the correct search path for games

• electron (or rather node.js) provide a cross-platform way to read directories but the way it works when you want to read recursively is excruciatingly slow on windows because the cross-platform ui emulates posix api where you have to readdir, use stat for each entry to determine if its a directory, if so read that directory as well,...
  The native windows equivalent to readdir already provides the information which entry is a directory (nodejs just drops that info) so all those stat calls (which are probably more expensive on Windows) are unnecessary.
  Because we have to read directories so often with Vortex we use our own library (turbowalk) that wraps the faster windows api directly, and falls back to the readdir/stat code on other platforms.
  So we already have provisions to support Linux, they just aren't tested and they may not support the same options as the windows variant (stuff like "follow symlinks or not" or "list hidden files or not") which might then manifest in subtle (or not so subtle) bugs when running Vortex in Linux.

Tbh.: My advice to anyone trying to work on a Linux version: Start by setting up a fork for working on Linux compatibility, start by trying to build it. Investigate build errors if there are any, fix them in a way that hopefully doesn't affect the windows build, when you have a running build, test the stuff that is intuitively more low-level (stuff like getting at the icons for executables, searching disk, creating links)
Don't start looking at the code trying to figure out what needs to be done.
Once you have it working natively on Linux, see if you can reduce the difference to the official build and then we can check together if anything might affect Windows compatibility before merging it into the official fork.

Also: the parts that are most likely require work are native modules we created, not the Vortex repo itself.
look at the dependencies in package.json, our custom modules are the ones that aren't listed with a version number but with an identifier for a github repo.
Stuff like

• Nexus-Mods/node-crash-dump
• Nexus-Mods/node-exe-version
• Nexus-Mods/node-icon-extract
• Nexus-Mods/node-permissions
• Nexus-Mods/node-turbowalk
• Nexus-Mods/vortex-parse-ini
• Nexus-Mods/node-wholocks

are bound to require platform-specific code that is either not implemented for Linux or not tested.

[codeman101]

@TanninOne

Tbh.: My advice to anyone trying to work on a Linux version: Start by setting up a fork for working on Linux compatibility, start by trying to build it. Investigate build errors if there are any, fix them in a way that hopefully doesn't affect the windows build, when you have a running build, test the stuff that is intuitively more low-level (stuff like getting at the icons for executables, searching disk, creating links)
Don't start looking at the code trying to figure out what needs to be done.
Once you have it working natively on Linux, see if you can reduce the difference to the official build and then we can check together if anything might affect Windows compatibility before merging it into the official fork.

I made a fork of the project last night. Although at the time it was out of anger over the comment Patricol made in response to my question about needing to run windows. Although now thinking about it more I suppose I can run a VM of a windows preview build to test it.

Due to the fact that the program is using the registry to detect the games the only way I can see to make it cross-platform is to have the program detect which OS it's running and do a recursive search of the users home directory for the Linux implementation.

Edit: Also you claim that having the program use the registry to find games is faster but I just remembered from when I ran windows that although that may be true it didn't get all of the games.

I realize now that the design trade-off is "should we do an implementation that would make game searching really fast and use something that is windows dependent or do an implementation that would be slower but more cross-platform friendly." Personally I don't feel the the correct tade-off decision was made for two reasons.

1. The current implementation of the registry method doesn't get all of the games
2. I never considered the game search method to be much of a plus over vortex's predecessor. The main plus I realized with vortex over it's predecessor is the ease in the way mods are added. The slowness in the search didn't bother me nearly as much compared to how mods were added.

[TanninOne]

@codeman101 we're not debating design decisions here. Just let me make one thing very clear here: I'm open to a Linux version but no trade-offs will be accepted for the Windows version. 0. Zilch.

second: Please educate yourself. Seriously, it's getting pretty annoying discussing with you because you insist on discussing about things you don't fully understand.

Vortex has custom detection code for all games, usually with fallbacks. Every game that Vortex tries to detect through the registry does get detected immediately (within less than a millisecond), the only people having problems with that are those that insist on mucking about manually in their registry or move games around manually instead of doing it properly.
So 99% of our users get all their games discovered within milliseconds, a full disk search like NMM did (which is also an option in Vortex!) can take hours on a large disk.
The claim that this is worse than just having a disk search is either misinformed or insane.
The fact you don't even seem to be aware that Vortex already supports searching the disk for games also shows you have spent very little time with the tool before coming here to tell us what to do.

You seem intend to construct an excuse for changing core functionality because you think it would make cross-platform support easier. a) It wouldn't b) it will not happen anyway.
Again: Windows is the primary platform, absolutely no concessions will be made to the Windows support just to make Linux support easier.
Either accept that and try to be constructive or please go away.

[Patricol]

Although at the time it was out of anger over the comment Patricol made in response to my question...

@codeman101 My apologies; I didn't intend for my last comment to be abrasive in any way.

[codeman101]

@Patricol

All good. I feel like some good has come out of me making my own fork because it's forcing me to learn the Windows API which has always been on my to do list anyway for the desire to help wine development.

@TanninOne

I agree. I will not argue with you anymore. Let's just agree that we have fundamental differences as to how we would've approached this project and move on. If I'm able to convert the necessary submodules to Linux code (which by the way aren't the ones you listed above) I'll post links to my changed files here. Unfortunately that's the best I'll be able to do as I copied a branch that makes the project ad-free. (one of the fundamental differences) Again I don't want to argue anymore I'm just explaining why my changes won't be mergable. Since this difference prevents my changes from being mergable anyway I'm going to try to covert the code into a pure Linux version (overwriting the Windows API code)

All and all I'm glad I forked this because as I said before it forces me to learn the windows API so even if someone beats me to punch of making this Linux compatible at least I got quite a learning experience out of it.

Oh also I'm sorry for what I said in the pull request. I didn't read the whole post of your first response and I've come to agree with you about that request.

[Patricol]

@codeman101

Just try to be more understanding. We're all human, and attacking people (and/or their views) left and right will get you nowhere in life; regardless of whether or not you are correct.

[codeman101]

@TanninOne

While trying to work on making the project Linux native I realized something and made this issue on proton (explained in issue) ValveSoftware/Proton#2670 and because of that I've decided to delete the fork I made since as far as I can tell it would only benefit native Linux games.

To future readers who still want to make this native for Linux

• you need to install mono to get yarn install not to fail
• Most if not all of work that needs to be converted from the Windows API are a set of a submodules in the Nexus github page. Aside from the one's TanninOne mentioned a few post above the others I've identified are
• node-esptk
• node-bsatk
• node-ba2tk
  Each of them (including the one's mentioned a few post above I think) has a file called string-cast.h which seems to be the only file that needs to be redone and fortunately the code seems to be same (for the most part at least)

Search

node-

in the Nexus-mod github page to find all the modules that have this header file.

[TanninOne]

esptk, bsatk and ba2tk are all for gamebryo games (TES, Fallout) which don't run natively on Linux anyway.

Tbh if you're playing a game through wine on Linux, I would also run Vortex through wine and use native Vortex only for native games - things are just going to be too complicated otherwise.
For example: Vortex uses LOOT to order plugins for the gamebryo games. LOOT being a tool exclusive to windows games itself works under the assumption it's on windows - having stuff like case-insensitive file name comparisons hard-coded into it - same with the "gamebryo-plugin-management" vortex extension that uses it.
Another example: Vortex has to manipulate ini files for certain features (e.g. to have separate save directories for different profiles in gamebryo games). Now ini is not a standardized format, implementations differ in how they handle comments, multi-line strings, encodings and so on. Vortex uses a library called "vortex-parse-ini" with a plug-in interface to support different ini-styles. The only one implemented right now is the one used by the windows api and we use winapi functions directly to ensure perfect compatibility with games that also use those apis - like the gamebryo games.
On Linux you won't have those apis available, so you have to use some other ini format. Easy enough to implement but it may not be 100% compatible with the game, which could then lead to obscure bugs where ini settings don't stick or stuff like that.

I imagine there is a lot of grief down that rabbit hole.

[codeman101]

@TanninOne

esptk, bsatk and ba2tk are all for gamebryo games (TES, Fallout) which don't run natively on Linux anyway.

Oh ok.Well if someone tries to make a native Linux version of vortex they'll need to do something about them because yarn build fails because of them being there.

Tbh if you're playing a game through wine on Linux, I would also run Vortex through wine and use native Vortex only for native games - things are just going to be too complicated otherwise.

Yes I know but I didn't realize it until my previous post because I was actually trying to run TES via proton from the native steam client and then realized it'd make more sense to install vortex into that proton install of TES (hence the issue I linked to in previous post)

Another example: Vortex has to manipulate ini files for certain features (e.g. to have separate save directories for different profiles in gamebryo games). Now ini is not a standardized format, implementations differ in how they handle comments, multi-line strings, encodings and so on. Vortex uses a library called "vortex-parse-ini" with a plug-in interface to support different ini-styles. The only one implemented right now is the one used by the windows api and we use winapi functions directly to ensure perfect compatibility with games that also use those apis - like the gamebryo games.
On Linux you won't have those apis available, so you have to use some other ini format. Easy enough to implement but it may not be 100% compatible with the game, which could then lead to obscure bugs where ini settings don't stick or stuff like that.

Fortunately since the games aren't Linux native anyway this isn't an issue since you'd have to use a wine backbone to run the game so you can install the windows version of vortex into that bottle. (which is a feature being worked on for proton see link above)

Side note: I'm going to see if the wine database has reported this bug but I was reminded by my computer tonight that currently vortex doesn't run on wine past installation regardless of install the dotnet version mentioned in the one review on the database.

Edit: I made the bug report for it on the wine database.

[TanninOne]

esptk, bsatk, ba2tk and gamebryo-savegame are all libraries pulled in from extensions: gamebryo-plugin-management, gamebryo-savegame-management, gamebryo-archive-invalidation, gamebryo-...
I would disable those extensions entirely, that way it will not try to build the extensions either.

The best place to do that is probably in "BuildSubprojects.json" and "BuildSubprojects.js".
The js is the code, json is the data file which specifies which subprojects (mostly extensions) to build.
I would add a new "platform" parameter there, something like
platform: ['win32', 'linux']
Of course this would have to be implemented in the js file: "if build platform not in list of platforms, skip subproject"

Then, to start off, just mark all subprojects as windows only, try to build.
Get the core application to build and run on Linux, then check which extensions even make sense for native Linux and enable/fix them one-by-one.

[Freso]

LOOT being a tool exclusive to windows games itself works under the assumption it's on windows

As one of "the LOOT people", I’d just like to point out that LOOT actually has built Linux native binaries for years (available on Bintray). While it is true that it by default assumes Windows‐ness, it shouldn’t err out if not run on Linux and should be able to sort load orders for Wine/Proton installed games given the right settings. I’m not sure if we’ve actually had anyone do this yet, but it should theoretically be possible AFAIK. :)

(This also means it should be possible to also use LOOT(/loot-api) on a Linux‐native Vortex build, either for modding Proton-CK games or for something like OpenMW. If there are any issues with that on the LOOT side of things, please let us know!)

[ScumbagDog]

The best place to do that is probably in "BuildSubprojects.json" and "BuildSubprojects.js".
The js is the code, json is the data file which specifies which subprojects (mostly extensions) to build.
I would add a new "platform" parameter there, something like
platform: ['win32', 'linux']
Of course this would have to be implemented in the js file: "if build platform not in list of platforms, skip subproject"

Then, to start off, just mark all subprojects as windows only, try to build.
Get the core application to build and run on Linux, then check which extensions even make sense for native Linux and enable/fix them one-by-one.

I just tried doing exactly this, I actually got the main UI working. That being said, the dashboard threw this error when it tried to render, and I can't actually set a game mode (as well as a slew of minor issues).

[awsdert]

You can query that from the UI and record it in the file, here's an example in JSON:

{
  "system" : 
  {
     "name" : "Proton Experimental",
     "id" : "proton_experimental",
     ...
   },
   /* Record in the order they're to be loaded */
   "mods" =
   [
     {
       "name" : "Mod A",
       /* ".../steamapps/common/game/.vortex" should symlinked to "~/.vortex",
          when steam launches game/.vortex/vortex.exe with proton, it will then
          load this file created / overwritten prior to it's launch and look
          inside it's own folder for the mods, just needs ../game.exe to launch
          the game after
        */
       "path" : "./games/game/mods/mod_a"
     },
     ...
   ]
}

[TanninOne]

What if you have to run a third-party tool, like fnis or bodyslide or OpenIV as part of the modding process? That would probably have to run through wine too if it's not supported natively.
What if that tool reads a configuration file Vortex needs to first generate while running on the correct platform?
Allowing all of this (and all the issues I can't think of the top of my head) to be delegated to a secondary process that can be driven through a configuration file gets so complicated (and also makes the application and extensions so complex) that it defeats the purpose.
Plus it would, in fact, be pretty much a new application.

[Arcane21]

What if you have to run a third-party tool, like fnis or bodyslide or OpenIV as part of the modding process? That would probably have to run through wine too if it's not supported natively. What if that tool reads a configuration file Vortex needs to first generate while running on the correct platform? Allowing all of this (and all the issues I can't think of the top of my head) to be delegated to a secondary process that can be driven through a configuration file gets so complicated (and also makes the application and extensions so complex) that it defeats the purpose. Plus it would, in fact, be pretty much a new application.

Sounds to me like Vortex for Linux (or Vortux) would require Wine as a dependency at the very least by default. While getting Vortex itself to work natively on Linux is the bare minimum I would expect, everything else that is not a native Linux application would have to be filtered through Wine.

[NicBOMB]

How long did it take you to find this code position? Exactly, a few seconds after running Vortex, because you got a crash with a stack trace.
If Vortex had "handled" this by not loading the EGS module, how long would it have taken you to find out that, and why, EGS games aren't discovered on Linux? Likely a lot longer.

No, this didn't throw an error because other issues were encountered sooner at runtime. As I said in the disclaimer, the examples I used were selected because they're quick and obviously wrong, not because I ever actually encountered it as an error at runtime. What did throw an error was GameStoreHelper.

Crashing isn't the worst thing a software can do, hiding problems is. Vortex aims to reveal problems asap so that they can be fixed quickly, not try to hide them until the user notices.
We did not know if/how EGS can be handled on Linux so we ensured that if someone looks into a Linux port they will become aware of this immediately. You're welcome.

My point has consistently been that Vortex doesn't reveal problems soon enough. The relaxed tsconfig settings literally ignored thousands of issues. Simply, the interface should never have possibly been undefined.

Should probably just guarantee the extension API's properties all exist and check the property on the API as needed

And how would you do that if not by provoking a "compile" time error? You think a runtime error would be superior? If the unit test suit wouldn't take literal minutes to run with only a few dozen tests, unit tests would be a good way to catch that but as it stands, running unit tests on every build was simply not practical.

I am not saying to not provoke a compile time error. In fact, I have been clear that it needs to be a compile time error rather than a runtime error. The problem with that code is specifically that it does not provide a compile time error which is actually useful. Instead, tsc warns that those properties of the api are being assigned disallowed values (undefined). Discussion of the unit tests is irrelevant to what I was pointing out.

string should never have been null or undefined to begin with

You do understand that Vortex isn't a closed system? We get data from files, files managed by mod authors or games, from the network, ... We can not ensure a sting is never null or undefined when we aren't the source of the data.

Then use an unknown or any, not a string! You are still not using types correctly. If you receive something unknown|any declare it that way and then check it till the type is known. Don't write a random helper with a direct string type parameter and then operate on it like it's a null. That function is still poorly defined. What you want is different than what it strictly means. Typescript has types which describe a non-closed system. You don't have to ruin all the primitive types just because you work with some things which are ambiguous.

The comment literally explains why not to use this? Just use !!val.

No, it explains why !!val is obscure and should not be used. explicit === good

Explicit is good! proceeds to import and use an abstraction for an operator

typeof functionToCheck === "function" was a thing even when this was written? I don't see how calling toString is better here?

Just because you don't understand it doesn't mean it isn't, the equivalent function on lodash also works roughly like this. But I will admit it doesn't look like could I would have written, pretty sure this is stackoverflow copy&paste

I do understand it. You know I understand it. I wouldn't have said 'I don't see how calling toString is better' otherwise. If lodash has this and is a direct dependency, why are you not importing and using that instead? None of the reasoning in your reply is sound.

No one will argue that the Vortex code is perfect, no code base of this size maintained by an understaffed team over 6 years will be, but not every piece of code you personally don't understand or code you would have written differently is bad, get your head out of your own a**.

I'll amend my previous statement, this one reply does make sense.

[Akselmo]

I want mom and dad to stop fighting

[NicBOMB]

@Akselmo

I want mom and dad to stop fighting

But again, that is my opinion and I'm fairly certain NicBOMB will disagree, I doubt there is a solution that everyone agrees with.

It's okay, we do understand each other sometimes.

[TanninOne]

No, this didn't throw an error because other issues were encountered sooner at runtime. As I said in the disclaimer, the examples I used were selected because they're quick and obviously wrong, not because I ever actually encountered it as an error at runtime. What did throw an error was GameStoreHelper.

That is literally incoherent gibberish. You're saying at the same time you didn't get an error, got other errors too and got an error after all...

My point has consistently been that Vortex doesn't reveal problems soon enough.

No it hasn't. If that was the point you were trying to make you failed.

The relaxed tsconfig settings literally ignored thousands of issues

What relaxed tsconfig settings? We have not a single non-default tsc setting that relaxes any standard rules. There are non-default stricter rules introduced into tsc over the years but those would require us to change or rewrite existing and tested code which would be completely mental.

I am not saying to not provoke a compile time error. In fact, I have been clear that it needs to be a compile time error rather than a runtime error.

No, you haven't. You complain about the compile time error and then claim it was obvious you wanted a compile time error.

The problem with that code is specifically that it does not provide a compile time error which is actually useful.

Nope, that code gives you a build time error if you introduce a new function for that interface and don't assign it. This is the only "static" instance of IExtensionContext so this is the only way to achieve this in the absence off unit tests.

Instead, tsc warns that those properties of the api are being assigned disallowed values (undefined).

No it doesn't, not unless you misconfigured it or run a different version of typescript from the official repo. This code has worked and served its designated purpose as expected for 6 years. Yes, if the compiler changes we may have to change the code to something more complex but not at this time.

Then use an unknown or any, not a string! You are still not using types correctly.

Look, if you took a moment at where the function is actually used, you would find it's only used on data marshalled from c# code, to align 1:1 with calls to the c# function "isNullOrWhitespace" https://learn.microsoft.com/en-us/dotnet/api/system.string.isnullorwhitespace

And yes, if the code was written today, the type should have been "string?", but at the time we started, nullable syntax didn't exist in typescript, that was introduced later, all variables were implicitly nullable.

If you receive something unknown|any declare it that way and then check it till the type is known.

We don't, we receive something that by documentation should be a string but because of serialization we can't rely on the types to be verified automatically. Not the same situation.

Don't write a random helper with a direct string type parameter and then operate on it like it's a null.

Again: That code was written when that was literally how typescript worked, all types were nullable.

Explicit is good! proceeds to import and use an abstraction for an operator

Maybe look up what "explicit" means?

I do understand it. You know I understand it.

No, I really don't.

If lodash has this and is a direct dependency, why are you not importing and using that instead?

Because lodash is a heavy dependency and I'd rather have a one-line function than unnecessary dependencies. We do use lodash, doesn't mean I want to import it in every single source file.

None of the reasoning in your reply is sound.

Again, just because you don't understand doesn't mean it's wrong.

[awsdert]

What if you have to run a third-party tool, like fnis or bodyslide or OpenIV as part of the modding process? That would probably have to run through wine too if it's not supported natively. What if that tool reads a configuration file Vortex needs to first generate while running on the correct platform? Allowing all of this (and all the issues I can't think of the top of my head) to be delegated to a secondary process that can be driven through a configuration file gets so complicated (and also makes the application and extensions so complex) that it defeats the purpose. Plus it would, in fact, be pretty much a new application.

Again, as long as it's stored in the symlinked ~/.vortex directory then it won't matter if a 3rd party tool is needed, the vortex.exe that is launched inside wine can launch it without issue

[TanninOne]

I'm reading a lot of "simple", "easy" and "trivial" here. Makes me wonder why this ticket is still open 4 years later and all contributions we got were all a few build system fixes, many of which would have broken more than they'd have fixed. ;)

[ThisNekoGuy]

I'm reading a lot of "simple", "easy" and "trivial" here. Makes me wonder why this ticket is still open 4 years later

To be clear, what I specifically was speaking of isn't necessarily an indicator of difficulty but rather willingness of an individual to actually tackle specific issues that prevent this from happening. I'm sure there are probably people willing to do so, they're just probably not in the Nexus Mods community to actually care to do them.

That's apart from the build system, though; I won't saying anything on that topic since I don't personally mess with build systems for projects like this.

[Continous]

Does Vortex even guarantee that launched third party apps like OpenIV will work on Windows, let alone Linux? To my knowledge, Vortex already facilitates it at the user's own risk/without official or direct support of the application itself. If OpenIV or Wyre Bash suddenly stopped working on Windows 11 in spite of Vortex continuing to work, I don't think Vortex would be too inclined to do any more than it would do for Linux, that is, tell people to go talk to the third party app makers.

[Arcane21]

Does Vortex even guarantee that launched third party apps like OpenIV will work on Windows, let alone Linux? To my knowledge, Vortex already facilitates it at the user's own risk/without official or direct support of the application itself. If OpenIV or Wyre Bash suddenly stopped working on Windows 11 in spite of Vortex continuing to work, I don't think Vortex would be too inclined to do any more than it would do for Linux, that is, tell people to go talk to the third party app makers.

Hence why Wine would be required so Vortex can ensure all Windows applications try to hook through that, but with a "caveat emptor" of no guarantees this will function perfectly. Way I see it, that's the best Vortex under Linux could do for third-party apps like that.

[Continous]

Hence why Wine would be required so Vortex can ensure all Windows applications try to hook through that, but with a "caveat emptor" of no guarantees this will function perfectly. Way I see it, that's the best Vortex under Linux could do for third-party apps like that.

My point is simply that the obsession over guaranteeing third party apps on Linux is just weird because Vortex never guarantees third party apps work.

[NicBOMB]

All my forks of Vortex and its extensions have been published.

[BloodyIron]

Man this is a long thread. So what exactly is the current barrier for having Vortex be native on Linux? The UX through WINE right now is utter pain, and the "demand" for this is only going to go up. Especially with the success of Steam Deck (and that's definitely not going away at this point).

[NicBOMB]

Man this is a long thread. So what exactly is the current barrier for having Vortex be native on Linux? The UX through WINE right now is utter pain, and the "demand" for this is only going to go up. Especially with the success of Steam Deck (and that's definitely not going away at this point).

Currently Vortex uses build tools which are deprecated (and/or no longer supported) and is not configured for cross-platform builds. Electron builder, the release platform, has limited support for newer build tools (basically legacy package build configuration modes only). Also, Vortex has many custom libraries (extensions) which need to be updated for cross-platform support. In some cases that is/was trivial. In others, it means writing alot of stuff from scratch and/or landing new dependencies. In terms of current runtime/direct dependencies, Vortex is critically outdated; some core depends are 2-3 major versions outdated.

Until webpack gets support for 'Universal Chunk Loading' (switch from CJS require to ESM and CJS compatible import), upgrading to newer depends will be rough at best, impossible at worst. We may be waiting till webpack 6. Rome might even be available by then. I might try completely switching to esbuild or Rome. Vortex has some other issues, but most of the actual codebase will only need a few fixes.

It's getting the the right environment setup for the project to build consistently that's the issue. See the latest edits to the Vortex readme for examples of flaky build tools.

My fork uses newer build tools and completely overhauls the build process to leverage the bundler alot more, but cannot start or package. There's alot to be done in Vortex adjacent projects before Vortex can do anything meaningful about the current situation IMO. I can understand why Nexus Mods App is getting dev time as the alternative, I just think that dev time could have been spent contributing to Vortex's upstreams to improve the situation rather than dump Vortex...

[TanninOne]

Man this is a long thread. So what exactly is the current barrier for having Vortex be native on Linux? The UX through WINE right now is utter pain, and the "demand" for this is only going to go up. Especially with the success of Steam Deck (and that's definitely not going away at this point).

Depends on who you ask. As you see in NicBOMBs reply, he spends a lot of time forking projects and rewriting the build configuration, none of which is necessary to get a native build going. He's just selling his preferences as a necessity.
In reality our build chain is largely up-to-date, we just avoided breaking updates (yarn in particular) that would cause a lot of transition cost with no practical benefit.
None of our build chain is actually deprecated.

There is no actual barrier to having Vortex build natively on Linux, I suspect that could be done in an evening if the person doing it would actually focus on that.
The main barrier is that that release would also have to be maintained, updated, tested every time Vortex is updated and we (official maintainers) don't have the time to do it.

Further, there is a lot of problems to solve that aren't purely about creating a native build, various parts of Vortex would require a complete separate code path to support games being emulated through wine/proton when Vortex itself is running native, e.g. because the paths Vortex sees would be in linux syntax (/mnt/e/games/foobar) whereas the game uses windows syntax (e:\games\foobar).
To support Steam Deck specifically you'd probably need a completely separate UI designed to be used with a controller and adjusted font size and layout, I don't think you'd have a lot of fun with the collections screen for example on a 720p screen.

[Continous]

Further, there is a lot of problems to solve that aren't purely about creating a native build, various parts of Vortex would require a complete separate code path to support games being emulated through wine/proton when Vortex itself is running native, e.g. because the paths Vortex sees would be in linux syntax (/mnt/e/games/foobar) whereas the game uses windows syntax (e:\games\foobar).

While I'm sure this is far from the only issue, I'm pretty sure WINE will translate paths on the fly with little-to-no issue. I'm pretty sure of this because the file picker in WINE supports both the Windows and Linux Syntax within Vortex under WINE, and plenty of non-native games will naively show or accept the non-Windows syntax.

To support Steam Deck specifically you'd probably need a completely separate UI designed to be used with a controller and adjusted font size and layout, I don't think you'd have a lot of fun with the collections screen for example on a 720p screen.

To be fair, this is not a Linux-specific issue and would largely apply to Steam Deck running Windows as well. It's a handheld and would need an interface accessible to a handheld. Whodathunkit

[TanninOne]

While I'm sure this is far from the only issue, I'm pretty sure WINE will translate paths on the fly with little-to-no issue. I'm pretty sure of this because the file picker in WINE supports both the Windows and Linux Syntax within Vortex under WINE, and plenty of non-native games will naively show or accept the non-Windows syntax.

The problem isn't just the syntax, windows itself supports both backslashes and forward-slashes, the problem is that the path is different. As in dir "/mnt/e" is a valid command in windows, it says "list the content of the directory mnt/e at the root of the current drive", so if you call it while the cwd is "x:\foo\bar", it will list the content of "x:\mnt\e". But that is not the directory as /mnt/e in the Linux host OS.

That translation can't possibly be done correctly and automatically by wine.

To be fair, this is not a Linux-specific issue and would largely apply to Steam Deck running Windows as well. It's a handheld and would need an interface accessible to a handheld. Whodathunkit

It's not a surprise to anyone but it's still time that someone would have to spend on it, time they're not spending on something that benefits the other 99.5% of our user base who are not modding on a handheld.

[Continous]

The problem isn't just the syntax, windows itself supports both backslashes and forward-slashes, the problem is that the path is different. As in dir "/mnt/e" is a valid command in windows, it says "list the content of the directory mnt/e at the root of the current drive", so if you call it while the cwd is "x:\foo\bar", it will list the content of "x:\mnt\e". But that is not the directory as /mnt/e in the Linux host OS.

That translation can't possibly be done correctly and automatically by wine.

I've yet to see an application actually have issues with this.

It's not a surprise to anyone but it's still time that someone would have to spend on it, time they're not spending on something that benefits the other 99.5% of our user base who are not modding on a handheld.

I personally don't think the current interface is so unfriendly as to be worth overhauling.

[NicBOMB]

While I'm sure this is far from the only issue, I'm pretty sure WINE will translate paths on the fly with little-to-no issue. I'm pretty sure of this because the file picker in WINE supports both the Windows and Linux Syntax within Vortex under WINE, and plenty of non-native games will naively show or accept the non-Windows syntax.

The problem isn't just the syntax, windows itself supports both backslashes and forward-slashes, the problem is that the path is different. As in dir "/mnt/e" is a valid command in windows, it says "list the content of the directory mnt/e at the root of the current drive", so if you call it while the cwd is "x:\foo\bar", it will list the content of "x:\mnt\e". But that is not the directory as /mnt/e in the Linux host OS.

That translation can't possibly be done correctly and automatically by wine.

To be fair, this is not a Linux-specific issue and would largely apply to Steam Deck running Windows as well. It's a handheld and would need an interface accessible to a handheld. Whodathunkit

It's not a surprise to anyone but it's still time that someone would have to spend on it, time they're not spending on something that benefits the other 99.5% of our user base who are not modding on a handheld.

I dont have a device small enough device to make changes for the Steam Deck visually. Yarn classic is outdated, though I agree updating that specific depend is not required, not being able to update it or use the latest package managers imposes other build constraints mentioned prior.

This drive path name concern is unnecessary. WINE definitely works just fine crossing drive paths from C:\ to /path/ . You are saying this is one of the problems Vortex will have, but I already used posix paths in Vortex under WINE just fine. Don't scare off your own users with the non-issues. There certainly are issues, just not that.

[ranenvious]

The problem isn't just the syntax, windows itself supports both backslashes and forward-slashes, the problem is that the path is different. As in dir "/mnt/e" is a valid command in windows, it says "list the content of the directory mnt/e at the root of the current drive", so if you call it while the cwd is "x:\foo\bar", it will list the content of "x:\mnt\e". But that is not the directory as /mnt/e in the Linux host OS.

That translation can't possibly be done correctly and automatically by wine.

I've run plenty of game installers and simply selecting the right folder allows them to run just fine. Unless the code is seriously spaghetti it shouldn't be more complicated than a single line change, or even just offload that work to the user and have them manually select the locations. While that route is suboptimal, it might simplify it a bit since IIRC steam does some weird shit with it's prefixes that might cause issues. It's still not toooooo hard to solve for, you'd just need to iterate through the possible steam prefix folders (ideally still allowing the user to say where the steam folders are just in case) and then search for games like is done natively on windows.

In other words, having used Wine/Proton extensively, the only issue that you're likely to have is locating the prefixes as every program I've ever used has been able to seamlessly operate inside of a wine prefix. (in terms of file operations I mean)

Depending on exactly what you mean here it could be a bit more complicated, but if I'm interpreting what you mean correctly it literally ought to be just finding the right offsets to apply (e.g : /home/user/.steam/~PathToPrefix/drive_c/~RestOfThePathLikeNormal) and then iterating through the prefixes to search for games. (and maybe adding a section in a settings window to let the user manually add additional prefixes to search through)

One thing to keep in mind though is that the steam deck DOES have a traditional desktop UI in the form of KDE. It's not ideal, but if focus is simply put on getting vortex to work on linux first, a steamdeck dedicated UI can come second. While navigating a traditional UI on a steamdeck sized screen isn't optimal, it's entirely possible, so if getting a dedicated controller friendly UI is getting in the way of having vortex be functional on linux at all, it definitely is better to just drop the UI. It's better to be able to mod your games, albiet through a big of a cumbersome UI, than to just not be able to. (and this is ignoring the fact that, with proton becoming as good as it has, many people are just switching their gaming computers to linux as well)

[ghost]

I was too lazy to read through all of this thread but I here to vouch for linux support, as a current linux user I WISH to use vortex mod manager and am not able to. NO I WILL NOT SWITCH TO WINDOWS, NEVER.

[jthoward64]

I think the solution at this point is probably going to be to just wait until Nexus-Mods/NexusMods.App is ready and then use that since it looks like it will support Linux in some shape or form from day 1 (even if it is only via CLI or something, see the issue). I think the work needed to bring Vortex to Linux is probably more than is needed for an MVP of the Nexus Mods App at this point (from the POV of an outside observer at least).

[BloodyIron]

I think the solution at this point is probably going to be to just wait until Nexus-Mods/NexusMods.App is ready and then use that since it looks like it will support Linux in some shape or form from day 1 (even if it is only via CLI or something, see the issue). I think the work needed to bring Vortex to Linux is probably more than is needed for an MVP of the Nexus Mods App at this point (from the POV of an outside observer at least).

Thanks for pointing to that! I'll go sub to that ;)

[HawthorneK456]

Hi all,

Thank you for your contribution and patience relating to this request for Vortex. You may have seen our recent news post letting our users know that we are currently working on developing a successor to Vortex; Nexus Mods App which will deliver the next generation of mod management.

With this in mind, we are undertaking a review of all outstanding Vortex requests to determine their validity. As a result, this request will be closed here as we are implementing Linux support for the web app, see this linked epic within the web app teams backlog: Nexus-Mods/NexusMods.App#148 (comment)

Once again, thank you for being an active member. If you missed the news post, you can read it here: https://www.nexusmods.com/news/14874