e1337kat / cyberpunk2077_ext_redux Goto Github PK

Mainly optional/rest param positioning, recursive inference

• Everything in 0.3.0 milestone completed
• Version updated for package
• Tagged
• Release Notes written
• Changelog updated
• Nexus docs/images etc. updated
• Manually tested (see how the test suite fares?)
• Release created on GH
• Uploaded to Nexus
• Announced
  • Discords
  • Where else?

Some kind of summary that's easily readable, plus actual implementation for each mod type.

By my reckoning, this:

1. Files only

• Archives only (with or without options)
• CET (+ possibly archives) #13 and #25
• Redscript (+ possibly archives) #27
• Red4Ext (+ possibly archives) #5
• TweakDB (+ possibly archives) #6 - do these always come with one of the other types?
• ArchiveXL (+ possibly archives) #28 - do these always come with one of the other types?
• INI (engine\config\platform\pc) #29
• Other config only (xml/json) #30
• Reshade #8
• LUT #31
• Enabling mods (like CET, Redscript, etc.) #32
• Tools (like CSVMerge) #32

2. Tool or other modification required

• Archives requiring CSVMerge
• Config changes to insert things like a new keymapping

JSON installer will install any app that has a JSON file in its directory structure.

For most mod types, it's preferable to just wipe the previous install and deploy clean.

Questions/concerns/stuff:

• Handling the mods that modify something (say an INI diff) rather than add/replace need special handling anyway, that's probably enough to keep them out of this?
• Should removing a parent/enabler mod remove the mods under it? E.g. CET's mods. Probably not - this should likely be solved by real dependencies (which we may have to do ourselves..) but it does make some things harder, namely:
• What do we do with files generated at runtime? Require them to be included as placeholders? Otherwise we may not be able to do clean deploys
• Can we support files that shouldn't be cleaned, e.g. user's settings files? For the major mods like CET or AMM we can probably support these as exceptions but could also have a demarcation - and as an addendum
• Figure out how and where to persist stuff we want to persist. Profile probably?
• What if the user changes something outside the staging folder? Probably can't do anything with this, just discourage ever doing that? If there are cases where this happens, maybe we can provide a way to encourage getting the change into stage.

We can probably get a bunch more info to the user about what exactly went wrong and how to fix it. See where this is feasible to do. Who knows, maybe it's best UX if the error is just good at getting us the debug info to use..

At least the MultiType errors might be hard to puzzle out. Or maybe not. Evaluate :)

Related: #55 and #76

Extension version: 0.2.1

Vortex version: ?

Mod link: https://www.nexusmods.com/cyberpunk2077/mods/3016

Mod type: CET

Error message: ?

Steps to reduce: try to install

Further info: ?

Reported by: Xiniox#0001 CP2077MC

Just simple tests so we get some level of regression protection.

(I can add this, memo here)

Kinda vague, yes. But:

• Review the messaging facilities in the Vortex API
• See if there’s a nice way to e.g. inform the user that a mod needs manual work
• Which conditions do we want to warn/error on, in general?
• Can we easily get bug reports/issues either directly to GH or sent to us?
• …?

Just a memo again.. :)

Small change to make it clearer the created subdirs were created by the mod. Plus refactor the 'game info' stuff into a separate file.

The actual mods themselves, separate tracking for the mods that use them.

We should be able to install valid combinations of mod types. Initial version will require essentially canonical layouts, maybe we branch out later.

Examples:

• CET and Red4Ext E-mode
  
• All possible mod types combined in Furigana
  

Added a VortexApi wrapper that also includes the log so we don't have to pass the two around separately. Refactor to use this everywhere so we can get rid of the extra param.

For extraArchiveLayout we will want to do stricter checking than for the regular stuff... probably, anyway, until we have a resolver. Extras are used with other mod types, and in those cases we should probably assume that for the most part any configuration is not done by selecting archives.

For right now, the implementation silently ignores these conflicts and returns everything. This is probably safe for most real mods, but it'll be better to handle this case explicitly.

One possible enhancement is to create a separate ArchiveLayout.CanonWithOptions (or whatever) and conditionally return that instead of the regular layout type from the archive layouts, so that it's simpler for downstream to decide to do something special without knowing archive layout internals or on the other hand archive having to try to guess what downstream wants.

Stuff that goes in engine/config/platform/pc/, loose files for config changes in general. If any INI files go elsewhere, maybe separate thing.

Error popup, and an error in the logs: Invalid installer text=The installer in "Metro System 1.2-3560-1-2-1645621743.1.zip" tried to install files that were not part of the archive.

These seem to be legit files, the source of the error is here:

https://github.com/Nexus-Mods/Vortex/blob/a5e38512f0eb2024d8bee6260fe41b7ce43b5488/src/extensions/mod_management/InstallManager.ts#L2570

Hi, I ran into some issue when two mods brought a file with the same name. One was Reduced Loot and the other Ai Netrunners Enhanced. I resolved this by moving their scripts into new subfolders. Could this be a resolution for such a conflict?

Reshade uses INI files, too, so if we want to support them or prevent them from being miscategorized as INI mods, add some detection..

(I can add this, good for getting feet wet. Just putting it up as a memo!)

INI mods change config to achieve their effect.

NB. reshade mods use INI as well, but go in a different place. Detect these?

As stated in the title, #35 broke installation support for mods that contain both CET and redscript dependencies. Example mod Vendor and UI Improvements. It only installs the redscript components.

As principles (and I think we're doing pretty well already!):

• All messages should attempt to be as helpful as possible: don't just describe a problem, offer solutions
• Conversational tone
• Use intrusive messages (dialogs) where they could be important, unintrusive (notifications) when we know it's ok - err on the side of intrusion for now, we can change later
• Make sure the important part is clear at a glance
• Use Error/Warn/Info/Success appropriately

Don't include developer info in user-facing messages, use the log instead (and select log level appropriately, it's fine to use Info and Error wherever we expect it to be useful frequently, debug when not)

A set of regression tests that verifies a given set of mod ‘files’ (of every kind we want to support) is transformed into the expected instructions will be good and give some confidence nothing breaks too 🙂 Don’t have to include actual mods, just grab the arrays of paths, but can use real mods in addition to constructed test cases

Can't mix KeyTree methods with the new abstraction because it handles dirs differently. Need to just go through all cases where KeyTree is used directly and fix them to the new interface.

(Basically search for KeyTree and/or _getNode..)

The docs on Nexus are a bit out of date - it's probably best if we keep the documentation source here in the repo, but let's update it to Nexus too, and try to come up with a process(tm) that ensures we update it at least every release.

This mod is an example of a poorly packaged JSON mod. The game includes four JSON files, two of which are named options.json. If the path is not provided by proper structure, we should actually refuse to install. Current behavior is that fallback support installs it to the game directory where it does nothing.

If a CET mod doesn't adhere to conventions, either reject it or fix it the rest of the way.

Need to at least:

• Ensure it's [bin/../]somename/init.lua so that we can correctly put it in the CET folder
• Allow init.lua in subfolders of the mod

Optional, maybe later:

• Allow mod to just have the mod at top level, and place it in CET/mods/MODNAME/

Having to deal with the "." and "" difference spreads in a bunch of functions inside FileTree.. if we normalize the dirname on add in the constructor, then we don't need to. But have to fix a bunch of test case orderings etc. because of it so leaving it till later.

There's a lot of overlap and duplication in the messaging stuff plus we're not using enough of it. Refactor the common stuff out so that it's both consistent and easier to use.

(Just a memo rather than a TODO in code..)

Rather than go through all types and possible conflicting heuristics, try to figure out which type of mod it is and only apply specific logic to avoid possible misplacement of files.

E.g. CET mod can contain .archive files, but Archive mods can't contain lua files, or Red4ext mods can contain .ini files, but INI mods can't have red4ext stuff.

Noting here because I will forget about it that IExtensionContext has not one but several kinds of persistence (we could for example store whether the user wants to have a manual step of file selection), suppressNotification might help with spurious warnings, there's functions for opening a file or dir (how?) , there's some kinds of 'known paths' that getPath() accesses, there's an event system, footer and banner settings, attributeExtractor to get some kind of data from an archive, the mod type which I'm still not entirely sure what it does, plus some external interpreter support, plus there's load order management, some kind of a preview support

If possible to do here without relying on FOMOD, possibly optionally perform clean installs and especially updates for CET/Reds/Red4Ext mods which unlike archives and INIs can create files at runtime.

NB. protecting user-editable configuration files like CET's bindings.json? May be this needs FOMOD or other direct mod author action to do reliably.

.json and .xml files. Only file moving, support for injecting changes e.g. with xpath tbd.

It was supposed to be main in the beginning, but I must have miss-clicked or mistyped something when setting up the repository.

It might be useful if the error dialog allowed the user to continue installation for cases where we don't know for absolute certain that some installation shouldn't be allowed (like say replacing cp2077.exe), but would normally cancel the installation. It's possible there's some corner or unknown case and it's better to offer the user some kind of a failsafe (other than purely manual install)

Only file copied is global.ini

Mod: CET 1.5 hotfix 2

Reported by: @effs

MultiType will handle Red + CET too.

https://github.com/psiberx/cp2077-archive-xl

• Standalone ArchiveXLs
• MultiType supports ArchiveXLs

Probably not the right title, but... basically handle mods that are laid out like:

mod.7z
|-modname
|-bin
| |-x64
|-r6
and so on....

Basically if there's a directory and no files in it, but bin, r6, engine, etc. in it

Make sure we can install (and uninstall) AMM correctly - could create an InstallerType.SpecialCase* category for these if there's something that requires specific support.

• AMM installs
• AMM uninstall and upgrade verified and possibly fixed to work correctly
• Support for various AMM addon types (Locations, Props..)

TweakDB is deprecated, so make sure the user knows this is the case - but support installing these 'heritage' mods.

It would be absolutely fabulous if we could store the layout info in a way that allows it to be both near use in code and available for documentation - one option is to expand on the method used in Red4ExtLayout, using the valid layout descriptions as enum values. This means that the data is always close. Need to be validated in some way still.

And if we want to get fancy, could make everything its own type so that we can store both a nice and an ascii version etc. etc.

Verify FOMODs work, or fix :)

A couple installers are already starting to get close to final form, so let's move those out into separate files. Anything that is moved should get refactored to use the layout style.

As per #82 drop RedCetMix entirely

Refactored and moved:

• Core, CSVMerge, Wkit (not fully refactored yet)
• MultiType
• Red4Ext
• Redscript
• ArchiveOnly
• CET
• JSON
• INI
• Reshade
• Fallback
• ...

No point reproducing it at the top/bottom of each.

Since the api object isn’t passed into the callbacks by default, we need to wrap install() inside the init function so that we can pass in a reference. The api object is needed for e.g. user-facing messages and any modals or other ui elements we want to create.