| Age | Commit message (Collapse) | Author |
|---|
|
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)
|
|
|
|
The mod browser before this pre-maturely thought it had loaded all the
available packages, when in fact, it'd barely started. Now this is
fixed, and you can scroll for quite some time before actually reaching
the real end of the package list.
|
|
Oopsie woopsie, my badddd, so sowwieeee, i wwwont doww it agaainnn!
|
|
|
|
This doesn't break the old way of detecting things, for various reasons,
but notably it'd cause more harm than good. As we still need to be able
to detect packages that haven't been converted into the new location.
|
|
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.
|
|
#193
|
|
|
|
|
|
|
|
#191
|
|
|
|
|
|
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.
|
