Age | Commit message (Collapse) | Author |
|
The "Steam (Auto)" launch method should ideally work in all scenarios,
ideally! Obviously, I can't and haven't tested in every environment, but
I've attempted to make sure it functions.
Launching Vanilla and Northstar works just fine, custom launch arguments
also work just fine, it works with normal Steam, Flatpak Steam, and as a
fallback with the Steam Browser Protocol (`steam://`)
There's also the option to set your own/custom launch command for both
the Vanilla and Northstar launch options. How well they work will of
course depend on what the user set them to.
"Steam (Auto)" attempts to pick the right Steam launch method depending
on what's available, if the Steam executable can be found, it'll use
"Steam (Executable)", if it cant and Flatpak is found on top of an
install of Steam through Flatpak, then "Steam (Flatpak)" is used, if all
of that fails, then we attempt to use "Steam (Protocol)"
Some toasts will be shown if you attempt to run the game with either
"Steam (Executable)" or "Steam (Flatpak)" and they cant find the
game/Steam. This isn't an issue with "Steam (Auto)"
|
|
I intended to do this when creating src/win.js, but wanted it to be in a
different commit, as that commit made pretty large changes as well.
So no more `main_win`, `win_show` and confusion between what `win` is.
|
|
I've not been able to find anything that breaks from this, as I've gone
through every IPC event that got moved, to ensure it still functions,
and all the breakage I found has since been fixed.
IPC events that dont fit in any particular module is also now in the new
file named `src/app/modules/ipc.js`
There's also another module `src/win.js`, which lets you get the
`BrowserWindow` outside of `src/index.js`
I also took the oppertunity to clean up some of the code when moving it
around, and adding a couple comments, as some of it was quite horrid.
|
|
This fixes a couple issues where the main process wouldn't actually get
changes made to the settings, this fixes that.
On top of this, changing settings is now done with `settings.set()`
There shouldn't be any breakage from this change, but I suppose it is
possible. Especially because the `settings()` function still does
contain backup options set, meaning `settings.nsargs` is technically
still valid, but dont expect it to actually be updated when that
variable is changed, its merely here to avoid any problems.
|
|
Ideally this has no side effects, however, I've not actually tested if
the launching does properly use the launch arguments, due to not having
a Windows device on hand. This will be tested later...
We still attempt to load launch arguments from `ns_startup_args.txt` if
none is set in the settings. However, this may be removed in the future.
|
|
Most of these are from back when Viper was originally started, I also
removed a few keys as they were no longer in use, but were forgotten
about, most of these are from pre-v1.0.0 aka, the old smaller UI
|
|
Now they simply have the red color instead.
|
|
Far prettier, and far more useful at a glance.
|
|
I've made some code return early instead of adding more nesting, on top
of this I've added some more comments in some files, rephrased a few
things, and so on...
|
|
Notably, winLog() and winAlert() are now win.log() and win.alert()
inside modules/window.js.
updateViper(), updateNorthstar and handleNorthstarUpdating() are now
update.viper(), update.northstar() and update.northstar_autoupdate(),
inside modules/update.js
isGameRunning() and isOriginRunning() are now is_running.origin() and
is_running.game() inside modules/is_running.js, along with a
.titanfall() and .northstar() for more specificity. Not used anywhere
right now, but may in the future be used.
setpath() and gamepathExists() are now gamepath.set() and
gamepath.exists() inside modules/gamepath.js
killOrigin() are now kill.origin() inside modules/kill.js
setlang() is now just inlined into the only event where it's used.
|