| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Spelling corrections
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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)"
|
|
|
|
Previously, settings using `<select>`'s for their value only worked on
the `forcedlang` setting, now it just works overall, this wasn't an
issue before, as we had no need for it.
More importantly `forcedlang` is special in that it dynamically loads
the list of languages available, so it was and still is handled
separately, to support that behavior.
|
|
It's not capable of formatting language files, and now has a prompt
interface for editing and adding missing localization strings.
This removes the need for manually editing localization files beyond
`en.json`, it'll still be edited manually. But maintainers will no
longer have to open any localization files.
I also updated the documentation for contributing to localizations.
|
|
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 set the Electron path `userData` to the system's cache folder, as
this is the same path Electron stores cache files in, and its normally
set to the system config folder, obviously not ideal.
However, when changing, we do as such quite late in the startup process
leading to some things (notably the variable used to store where we
download the Northstar archive to), using the older value.
Now its one of the first things we do on startup, fixing that.
|
|
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.
|
|
|
|
Ew! Bad! No! Bad! Bad!
|
|
|
|
This time it's inside the GUI and not just random output.
|
|
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.
|
|
|
|
Due to this button (specifically the "button"/link below the "Launch"
button) serving multiple functions, it incorrectly gets disabled when
the game is running. Now its enabled!
How did I miss this? I assume it crept up after implementing the force
quit button, and not during, but maybe not, was I stupid? Mayhaps.
|
|
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.
|
|
This isn't present in the current release and is a bug that crept up
with the upcoming release, however of course, it's been fixed now.
|
|
Scrollbar is globally different, the release notes and mods page now
look more alike, having adjusted some padding, added some backgrounds
and a few other things.
|
|
When checking for an update whilst the latest release is already cached,
it'll resolve near instantaneously, not even letting the user know what
action they just performed, now however, a check for updates will
visually take at least 500ms.
|
|
|
|
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.
|
|
|
|
|
|
|
|
When closing a category and then re-opening the setting popup, the
categories shouldn't remain closed!
|
|
|
|
|
|
If you're not clicking inside the `#browser` popup, then the preview and
filter popups would stay open, until you do so, or something else causes
them to close.
This fixes that.
|
|
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
|
|
|
|
If the settings popup was opened or closed through other means than
clicking the settings button itself, "Save" button or "Discord"
button, then the cog wouldn't update/rotate accordingly.
|
|
|
|
This makes opening and closing popups a little bit easier, on top of it,
it also fixes a bug where you could open the settings popup on top of
the browser popup or other popups, and it'd hide the background blur,
but still show both popups.
|
|
|
|
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
|
