| Age | Commit message (Collapse) | Author |
|---|
|
The lower delay that was there previously would lead to the
axes/joysticks moving around the UI way too fast.
|
|
It now waits until the button has been released before that button can
again do its action.
|
|
|
|
Either with the top bumper buttons on a gamepad, or with Q/E on a
keyboard instead.
|
|
|
|
|
|
This will be particularly useful for #239
|
|
This will be particularly useful for #239
|
|
|
|
|
|
Far from complete, but this does the bulk of the work, the rest is just
fixing places where the selection moves in weird ways after doing some
things, and overall improving the look and feel of it.
|
|
|
|
|
|
Too busy with the frontend, and forgor to change the main process IPC
event listeners, whoopsie.
|
|
Technically this is also broken on the main branch, however it's a lot
easier to just fix here, instead of having to fix it there, then also
fix it here, due to the modularization
|
|
|
|
|
|
|
|
And `js/popups.js`, but it was already technically a CommonJS module, it
was just leftover in `index.html` due to `js/browser.js` not being a
CommonJS module.
|
|
It's not actually used anywhere outside of itself, but oh well.
|
|
|
|
|
|
Renamed from `toast.js` to `toasts.js` as well
|
|
|
|
|
|
Far from done, but this pretty much splits everything inside
`src/app/main.js` into separate files.
|
|
|
|
|
|
|
|
Spelling corrections
|
|
|
|
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)"
|
|
|
|
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.
|
