| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Very minimal uses of it, currently it simply checks every 30s and on
startup whether a set of domains/endpoints we use work, and if all fail,
then we assume something is wrong with the internet.
|
|
fixes #252
|
|
feat: support thunderstore ror2mm protocol for installing mods
|
|
|
|
|
|
|
|
|
|
This is achieved by sending an IPC event to the renderer and waiting for a reply once
Since this is async we return from the function after sending the event and recursively invoke it once the reply arrives
The package data is returned a a JSON String because Electron is unable to copy the Object over IPC
|
|
|
|
|
|
Co-authored-by: 0neGal <mail@0negal.com>
|
|
|
|
|
|
|
|
|
|
|
|
feat: Linux launch support v2
|
|
|
|
|
|
Too busy with the frontend, and forgor to change the main process IPC
event listeners, whoopsie.
|
|
Far from done, but this pretty much splits everything inside
`src/app/main.js` into separate files.
|
|
|
|
|
|
Pesky EA Desktop being annoying as always, leaving behind processes, to be
fair, I don't exactly think you're supposed to be killing it it like
this, but oh well, it seems to function now.
|
|
This didn't happen in all cases, so it took me until randomly
discovering it recently, for me to actually realize there was a problem,
and then subsequently fixing it.
|
|
Did an oopsie whoopsie doopsie, now its unoopsied
|
|
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)"
|
|
|
|
unzipper apparently has a bug that causes extracted files to be
corrupted, switching to unzip-stream may not be the best long term, but
it at least solves this corrupting problem!
|
|
Some code relating to removing core mods when updating/installing didn't
account for `R2Northstar/mods` not even existing, thought I made checks
for that already, managed to mess them up, oopsie whoopsie.
|
|
Previously we downloaded the Northstar archive and packages to a folder
named "vipertmp" in the system's cache folder, now that's just moved
into "Viper/Temp" (still inside the system's cache folder)
With this, all Viper cache is stored in the same folder in the system's
cache folder... Wait... Why wasn't it always like this? Oh right, my
past stupidity and lack of foresight. Oh well.
"vipertmp" still gets deleted when clearing install cache, along with
the new folder, so doing so will by itself clean up the old folder.
|
|
We previously had a requests cache file just named `viper-requests.json`
in the system's cache folder, we now also delete that alongside the
current file, simply cleaning up a user's cache folder, as that file
will not be used anymore.
We also technically had a file named `requests.json`, however the name
is too vague and could potentially (unlikely, but oh well) delete
something that isn't actually Viper's older requests cache file.
|
|
After Northstar has been downloaded, we start extracting into the
gamepath, this causes Viper to think Northstar isn't installed, which is
fine, except it'd whine about it when many `src/modules/mods.js`
functions we're called, some of which get run on an interval, so it'd
often lead you to have multiple "Northstar is not installed!" messages
whilst updating Northstar. Which is quite unneccesary and it may also,
be able to confuse the user, as to whether something has gone wrong.
|
|
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 means if you dont have any internet, but there's a cached requests,
it'll use that, even if it was cached a very long time ago. This just
attempts to eliminate errors.
This can still be turned off for things where you dont want this to
happen, notably the masterserver status.
|
|
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.
|
|
We're the renderer to request for an update multiple times, then it'd
simply start both updates, at the same time, causing all kinds of
issues. This was only really realistically possible to happen if you
were to manually check for updates whilst an update automatically were
to be checked from right before then. As an example, when Viper starts
up, it'll by default check for updates for itself, then Northstar, if
you within that time frame checked for updates manually, it'll run both.
Now however, we check if an existing update is occurring, and do nothing
if so, this is both for Viper and Northstar updates.
|
|
Its now been split into 2, requests.js and releases.js, the latter
simply gets relevant info from GitHub release pages. The prior however
gives simple functions for doing `GET` requests, and caching the result,
and then transparently it'll use that cache when you request it next
time. On top of this, some requests made by the renderer will now also
use this, and this in turn ends up making loading the mod browser much
faster. As instead of having to request the list of packages from
Thunderstore, we can simply load the result of an old request.
The current lifetime of the cache is 5 minutes, however this can also
easily be adjusted.
This also moves the cached requests away from
<cache_folder>/viper-requests.json, and over to
<cache_folder>/Viper/cached-requests.json
|
|
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.
|
|
This solves #223
|
|
This takes a bit of code from #220 to implement percentage progress on
the download, then with the new pseudo element on the Launch button, we
can have a slight progress bar inside the button, along with
percentages, and it all works handy dandy.
This may not be finished, but it's definitely far there.
|
|
I will likely add more buttons in the future, but for now this is most
of the ones a user could need to repair problems.
|
|
|
|
We now show an alert if the gamepath is detected to be missing
read/write perms, both when selecting the gamepath initially, when it
gets auto detected, but also after it's selected, passively.
|
|
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
|
|
|
|
This is quite counter intuitive, as, if it's invalid, how do we
re-validate it, if we can't even save it again.
This existed here because the idea was for the re-validation to occur
somewhere else, and to make sure incorrectly formatted data wasn't being
given to this function. Now the function simply resets the config, a
restart may be required to add missing settings, in case the parsed
`conf` doesn't have all keys.
|
