| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Ew! Bad! No! Bad! Bad!
|
|
|
|
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.
|
|
|
|
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 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.
|
|
|
|
If the gamepath is lost or similar then it'll disable many buttons,
notably the install/launch buttons and other similar buttons, however
for obvious reasons we shouldn't be stopping the user from changing
their gamepath in this scenario. This is still useful when installing a
mod or updating NS, so it's just this scenario.
|
|
Very useful stuff!
|
|
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.
|
|
|
|
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
|
|
|
|
From my testing this works without problems, but further testing will be
requested in #211
|
|
If the main process has changes to the settings, said settings will now
also be sent to the renderer, making them synchronized.
|
|
This would mean if the gamepath cant be found automatically you'll be
asked to set your gamepath every time Viper starts, instead of it
remembering it, and if it can find it automatically, then you'd never
have known this was a problem (hence why this was even a problem)
|
|
|
|
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.
|
|
I may or may not have missed some properties or something somewhere,
perhaps we'll see if something ends up broken in the future...
|
|
This should've already been a thing, and was a thing for when the game
was currently launching, but this functionality seems to have been
broken at some point.
|
|
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.
|
|
On restart, if the json file was broken supposedly would try to repair but it wouldn't work, it would keep repairing but failing.
This should fix it by deleting the json file and creating a new one at the start with the correct settings (hopefully)
|
|
"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.
|
|
Notably, winLog() and winAlert() are now win.log() and win.alert()
inside modules/window.js.
updateViper(), updateNorthstar and handleNorthstarUpdating() are now
update.viper(), update.northstar() and update.northstar_autoupdate(),
inside modules/update.js
isGameRunning() and isOriginRunning() are now is_running.origin() and
is_running.game() inside modules/is_running.js, along with a
.titanfall() and .northstar() for more specificity. Not used anywhere
right now, but may in the future be used.
setpath() and gamepathExists() are now gamepath.set() and
gamepath.exists() inside modules/gamepath.js
killOrigin() are now kill.origin() inside modules/kill.js
setlang() is now just inlined into the only event where it's used.
|
|
|
|
The current design for the installed mods is not exactly the best. And
it has been due for a redesign for quite a while, I'm finally starting
work on this.
|
|
This doesn't entirely uphold support, as it doesn't use the author file
for anything, however it does write it as intended.
|
|
When JavaScript errors occur outside of the renderer, they'll no longer
display a big and confusingly detailed error stack, now they'll simply
be shown a toast about the fact that an error happened.
The user can then click this to get more details, but still without it
being as invasive and obtuse as before.
|
|
Some functions have been renamed:
update() -> updateNorthstar()
updatevp() -> updateViper()
Overall these are far better function names...
|
|
|
|
|
|
|
|
Mostly syntax, but also a few fixes with how the settings system work,
and also a change in localization strings.
|
|
Quite a lot of them aren't in the same syntax/style, and it's quite bad
to look at, this should fix them all without causing issues.
|
|
I know, commas aren't needed, however, going in and out of using commas
and not using them also looks bad, so generally I try to always use
them, with exceptions.
|
|
If you already have all the dependencies or some dependencies of a
package those will be skipped, if there is no dependencies missing it'll
just install, and otherwise it'll show the missing and ask whether you
want to install them.
Meaning if a package has two dependencies and you've one of them only
the one you don't have will show up.
|
|
This should allow you to install packages that have dependencies,
however maybe not with the best UI/UX experience, as currently there's
only an English localization, and we also install dependencies even if
the dependency is already installed.
|
|
Essentially just validates the config file and then prompts you about
it, it allows you to reset it directly or just to exit and let yourself
fix it. And because the error message appears directly in the renderer
we have access to navigator.language, and can therefore still localize
the string. However! We can't actually care if the user has disabled
auto detection of their language, since... y'know, the config file where
that's stored isn't able to be read properly.
And so I added an argument to lang(), which allows you to force it to
use a specific language if that language is available, if not it
defaults back to English.
|
|
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.
|
|
I've known about this bug for a bit but haven't been bothered to fix it,
essentially a language key was being logged instead of the string
attached to that key :p
|
|
This allows someone to have their system in any language, and then have
Viper in a separate language. This is also useful for testing.
|
|
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.
|
|
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.
|
|
This only has the actual UI for the settings page in place, no actual
functionality has been implemented yet. I made several changes not
directly related to the settings page, such as changes the CSS color
variables to use RGB, as to easily add an alpha channel to colors. I
also changed the way the Browser is toggled in some respects and many
other changes that makes it easy to re-use the browser code to create
the settings UI
|
|
Since apparently dragleave and dragenter don't quite work as intended we
have to resort to this obscure method which should work just fine on the
user's end.
|
|
If you closed the file selection window after clicking the "Install Mod"
button it would improperly try to install "nothing", and therefore never
re-enable the buttons, this is now fixed.
|
|
|
|
|
