| Age | Commit message (Collapse) | Author |
|---|
|
When the game is running the buttons will go from saying "Launch" to
"Running" and the buttons will also disable, so you can't run the game
multiple times, avoiding a lot of issues.
|
|
Overall we should now be able to find the latest version of Proton, the
Prefix, and everything a like, all automatically.
Albeit launching is sort of iffy, and seems to work, but with some
issues that seem to be caused mostly by my system.
|
|
extras/findgame.js is now extras/find.js, as it now also is able to find
the prefix of your Steam install and the path to Origin. Generally
speaking you can technically launch the game right now, both Vanilla and
Northstar (from what I can tell), albeit Wine is being weird for me
currently and leads to the game freezing while it's loading, or simply
never running because Origin is technically already running in the
background.
Maybe I should add a "kill" function to the launch screen. Besides that
some status text would also be nice i.e change "Launch" to "Launching",
to make sure the user doesn't think Viper isn't doing anything.
On the Windows side of things I also made the NS Launch use
"Titanfall2.exe -northstar" instead of "NorthstarLauncher.exe" to
prevent some authentication issues, I haven't tested it yet, and will do
later, we unfortunately can't do that on Linux as "-northstar" never
gets passed, hence why we manually have to launch Origin and everything.
Overall needs more testing, and not complete. As I'm still missing a way
to find Proton, which would in the end lead to a hassle free experience.
|
|
This only has GUI elements, and slight changes to the utils.launch()
function, but none that would result in anything working yet.
|
|
Because viper.json doesn't exist it also means settings.gamepath is
null, which triggers the gamepathlost message.
|
|
I don't really understand why or how anything broke, all I know is this
fixes it, and I don't know how to feel about this madness.
|
|
|
|
When Viper starts up it'll check to make sure the gamepath still exists,
and throws errors if not, it also redirects you to the first page (the
one where you can set the gamepath), and gives you an informative error.
This could happen because the user unmounted the drive the gamepath is
on, or it could happen if the user moved their game location.
|
|
This allows someone to have their system in any language, and then have
Viper in a separate language. This is also useful for testing.
|
|
I forgot about this when merging the VDF fix
|
|
* added debug messages
* more debug logging
* even more debug logging
* removed debugging and fixed VDF problem maybe?
Apparently the libraryfolders.vdf doesn't always come with the same
values, sometimes it comes with the contentstatsid variable and other
times not, we assumed it always was there, and never checked for it,
this caused problems if it wasn't there. This should fix that...
|
|
If the nsargs are edited by a third-party program or anything that isn't
Viper, the next time you launch Viper it'll reset the nsargs back to
what it was when you last opened it.
|
|
When #87 was merged an unnoticed problem slipped in where if Viper was
running in a version that did not support auto-updates we would never
auto-update Northstar. Now that's fixed, and the nsupdate option is
completely implemented.
I also took the liberty of removing the auto-update option in the
settings page if Viper can't auto-update anyway, as it's useless if
that's not possible.
|
|
Albeit with some caveats, due to the way electron-updater is setup, if
you're not on a version of Viper which supports auto-updates the event
which runs the NS Updater code will never be run, and hence it'll never
auto-update. This was also an issue before, but I only noticed it now.
|
|
|
|
It actually saves settings, loads them properly and everything...
|
|
|
|
Albeit only frontend functionality, it doesn't actually save your
settings, it simply loads them, and Settings.get(), allows you to
convert them to a format that can be used to save settings.
|
|
Usually utils.js would default to simply unzipping whatever was uploaded
if it wasn't a folder, now we check if it has "zip" as the extension,
case insensitive. If not simply report back the file wasn't a mod.
As opposed to the obscure error you got before this.
|
|
incomplete update process
|
|
|
|
I have no clue why this is only a Windows error, but it is, which is
also why it slipped through into the 1.2.0 release.
|
|
The failed to install toast now pops up when it actually should.
|
|
The modpath variable is now refreshed when you change the game path.
Which stops the problem altogether.
|
|
It'll notify of incorrectly formatted mods, it'll also notify on errors
and on success.
|
|
|
|
|
|
We now directly check the manifest file info as well therefore in all
cases even if the folder name for the mod is completely obscure, we
should now finally still get an installed status, both on removal and
install.
|
|
If a developer for some reason decides to put their mod inside mods/
instead of putting it inside a folder in mods/, it used to fail the
install, now that's fixed.
However since there's no folder to directly copy the name from we take
it from the manifest.json provided by Thunderstore.
It of course also has the proper status in the browser UI
(update/reinstall etc)
|
|
|
|
A setInterval() will do the job, it's not performant, and I'll have a
look at improving this further down the line to something better.
|
|
I also fixed the archive not being extracted properly for some reason,
the setTimeout() seems to solve it, no clue if it needs to be adjusted
in the future or replaced with something that works 100% of the time,
I'm not even quite sure why it happens in the first place.
|
|
If a mod had a file that was bigger than 512mb inside it, it'd error
out, simply switching the copy-dir module to recursive-copy fixes this.
|
|
When a new mod has been installed through the browser UI it's button is
changed from "Install" to "Re-Install" instantly. We also now disable
modding related buttons when updating NS, or when installing mods. This
should prevent issues.
|
|
This should work for all mods, assuming that all mods come packages the
same, aka, in a Zip, with mods/<mod> in it. Which from what I know they
do.
|
|
This also fixes mods not showing up after first install of NS
|
|
When changing the game path by clicking the button you shouldn't be told
it can't find the game and you've to select one manually, as you know
that already. More importantly, if it could be found automatically it'll
just not do anything.
With this change I also changed the "gui.setpath" string to be more
logical, and to make it clear what it does.
|
|
* Edge case
* Alert user only when automatic detection failed
* extra info on not found message
* support for [Free/Open]BSD
Co-authored-by: 0neGal <mail@0negal.com>
|
|
|
|
I moved requests.js into extras and made the function for finding the
potentional gamepath into it's own module. I also made the exec() called
Promise based.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was some Vim shenanigans (accidentally pressing "." after adding
that text a little further up), at least that's my guess.
|
|
Currently I've only added documentation in the utils.js file, however
I'll add the other files later on, along with likely changing up the
documentation in here.
|
|
|
|
|
