| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
If the main process has changes to the settings, said settings will now
also be sent to the renderer, making them synchronized.
|
|
Oopsie woopsie, my badddd, so sowwieeee, i wwwont doww it agaainnn!
|
|
|
|
This generally is fine, as the folder is created on startup... IF
Northstar is installed! And so, if you start Viper for the first time or
Viper as only just extracted/created the R2Northstar folder, then the
folder wont exist, but it'll simply assume as such.
Now we actually handle this correctly.
|
|
|
|
|
|
Now they simply have the red color instead.
|
|
This messed with how Northstar searches for packages, as it doesn't
conform to it's standard.
|
|
|
|
whoopsie, i made an oopsie, doopsie doo, my bad uwu, im so sowwyyy,
whoooppss, i caused an uncauwght exceptwion, ooowps ;w;
|
|
If the gamepath isn't found or unmounted or similar, then the profile
doesn't exist either, but we previously just assumed that it did, now we
refuse to create the `packages` folder, fixing an error.
|
|
Convert is a strong word, in reality, when a user installs (and thereby
also updates) a package, we attempt to search for a mod that we can with
pretty high confidence, we could theoretically make this even better,
but at some point you'll accidentally delete mods that are manually
installed and weren't actually the right ones.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Far prettier, and far more useful at a glance.
|
|
|
|
Install toasts, installing overall, dependencies and so forth, all seem to be fully functional, however more bug testing is probably required to concluce whether that is actually the case or not...
This also doesn't break `src/modules/mods.js`, i.e dragging mods in to
manually install them still functions the same as always.
|
|
This means instead of showing the invididual mods inside a package, we
simply show 1 mod/package, we then use the name, description, version
and so forth from the `manifest.json` inside the package folder. Further
we now also support a local `icon.png` file, instead of relying on
remotely stored icons and trying to match names against each other.
|
|
I also love how I spent a very long time trying to figure out why
Electron's serializer was failing, turns out, it just throws errors when
it encounters functions, instead of stripping them out, like
`JSON.stringify()` does
Oh well...
|
|
I may or may not have missed some properties or something somewhere,
perhaps we'll see if something ends up broken in the future...
|
|
|
|
|
|
If you're now installing a mod that's currently in the `mods/` folder
it'll remove that, then install the new one to `packages/` with the new
naming scheme and everything.
|
|
This caused errors where the folder would already be moved even though
it's not entirely done unzipping.
|
|
|
|
This is missing a lot of things, notably support for detecting and
installing dependencies, it also is actually being used by the frontend,
that still uses `mods.js`, this'll change soon™️
It should also when done, be capable of removing mods installed in the
old `mods/` folder when updating those mods, and then installing in the
new `packages/` folder, making the upgrade a smooth ride.
|
|
|
|
win.alert() now has a Promise return value, which'll allow you to wait
until an alert has been closed before continuing code execution.
win.confirm() was also added it's the same as win.alert() except it runs
confirm() in the renderer instead of alert(), and has a return boolean
in the Promise resolve callback. This boolean being whether the user
confirmed the action or not.
|
|
EADesktop.exe is now killed alongside Viper when toggled in settings,
alongside this, it also now contributes towards whether "Origin" is
detected as running.
|
|
This was from the modularization commits, managed to miss this...
|
|
In case we get a 404 or similar we should be cancelling the update, as
otherwise we'll end up downloading the HTML for a 404 page, and
subsequently try to extract that. Clearly not intended or good.
|
|
"cache_dir" being wherever your OS puts it's cache, it's the same place
mods.js uses to download mods.
This prevents cluttering up the gamepath with temporary files.
|
|
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...
|
