Synthetic Mod Name Incorrectly Includes '.installing'

[KirkH420]

Describe the bug It seems to happen a bit randomly, but maybe it's caused by a mod author not properly configuring their uploads for use with a mod manager, I don't know. The issue is that I can use the "download with vortex" nxm handler to download a mod and Vortex can detect the Nexus Mod ID and the File ID. But when I tell Vortex to install the mod, it will unpack the mod in the staging directory but it's creating an additional unneeded folder with a ".installing" suffix in the name. This extra directory gets deployed to the game folder too.

To Reproduce Steps to reproduce the behavior:

1. I've just been downloading mods the recommended way, by using the nxm button on Nexus.
2. In Vortex, right-click on the mod and choose "Install", that's all. This bug happens to some mods.

Expected behavior The expected behavior is that Vortex would not create this weird directory. I've created some screenshots to help show what I'm talking about. Everything seems to be going correctly, except that it is creating this additional directory. As you can see in the screen shots, the mod author's archive appears to be set up correctly, so I don't know what's going on here.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: Windows 10 LTSC (build 19044.1889)
• Mod (e.g. "Disable As Looting Choice")

Additional context I've seen this happen to mods from different authors. It's not only this mod.

Workaround: If you right-click and choose "Unpack-as-is" the mod will install and deploy fine.

[effs]

Thanks @KirkH420! We intentionally move 'orphan' files like that to the expected structure for the mod type — so it should be something like r6/scripts/looties/disassembleAsLootingChoice.reds in the mod. We just generate a 'mod name' from the mod install dir name and at some point it looks like it's stopped dropping the .installing suffix for the 'mod name'.

Just to confirm, the mods do work correctly, right?

[effs]

Need to chop off the .installing, and should probably finally pull the mod info or read the metadata if we can so that we can extract the mod name.

[effs]

Tests and fix for this in #207

[KirkH420]

Hello, Sorry I haven't been back to provide more info. I would like to say that it's definitely still happening, as of today. I was trying to create my own mod packed in either a .zip or .7z and of course, it will install just fine if "Unpack (as-is)" is used. But if I try to use "Install" it's been placing my mod into directories that are rather confusing.

I've created a mod that should unpack to the base game directory \Cyberpunk 2077\[files here] The mod is packed like any typical Vortex-ready mod that I've seen on Nexus, where the root of the archive contains the files that will end-up in \Cyberpunk 2077\ For example: MyMod.zip\mods\MyNewMod\[files here] unpacked it would look like: \Cyberpunk 2077\mods\MyNewMod\[files here]

The bugged install ends up in the Vortex Staging directory with the following directory structure: \Vortex\cyberpunk2077\mods\MyMod\red4ext\plugins\V2077-MyMod.installing\[files here] The above represents Vortex's mod staging folder. Notice the name "MyMod" is appearing twice now, one is the oddly generated "V2077-MyMod.installing" folder.

This mod has nothing to do with red4ext, so it's perplexing that it would create these directories at all. This may be a new behavior, because I only remember seeing the "V2077-MyMod.installing" in past behavior.

To be clear, my mod doesn't have the folders '\red4ext\plugins\' in it's archive at all.

Now to answer the questions that you guys had asked.

Q) Just to confirm, the mods do work correctly, right? A) Only when I use the method "Unpack (as-is)". And randomly, sometimes mods that I download from Nexus may work correctly if I use the "Install" method but it's really hit-or-miss. So my general habit is to always use "Unpack (as-is)". I have never seen this bugged behavior when using the "Unpack (as-is)" method.

Again, sorry that I've not been back in a while. Thanks for being patient with me.

UPDATE: I edited my post a bit to try and make it somewhat easier to read. GitHub was removing some of my forward-slashes.

[E1337Kat]

hmmm could you share the archive that installing weirdly? the archive isn't just the info.json, right? I don't understand how it messes up so badly though.

[effs]

@KirkH420

I think I fell asleep writing the reply yesterday XD

Anyway. If I understand correctly, there's three problems here:

1. Redscript can't be installed as REDmod
2. v0.8.3 doesn’t fully support REDmod yet (v0.9 will) so you might possibly get strange results even without 1.; and
3. The mod is not structured correctly for Redscript (even without 1.)
4. (v0.8.3 still sometimes incorrectly includes the .installing suffix which probably makes it look even more confusing.)

Of these, 3. is the original issue. Redscript mods should use a layout of r6/scripts/<MOD NAME>/**/*.reds. If the mod doesn’t have a modname 'namespace' directory, the installer adds one.

We use the mod ID from Vortex as that namespace directory name. So when correctly installed by Vortex, you should end up with r6/scripts/V2077-Disassemble As Looting Choice-4648-1-1-1-165565610/disassembleAsLootingChoice.reds. In v0.8.3 it also adds the extra .installing.

As for why the REDmod attempt fail fails the way it does, that’s an interesting one (but it shouldn’t work anyway.)

[KirkH420]

@E1337Kat As far as sharing it, I don't know if I'm able to do that due to the fact that I extracted the files from an official GOG-REDmod DLC installer and as such, I am unsure of the legality of sharing this project. It was more of a personal project, for my own use.

@effs Yes, I understand that Redscript mods are packaged with the "r6" directory in the root of the zip archive. However the mod I was working on is not Redscript based, nor is it a red4ext plugin, nor is it a CET mod. It's also not a REDmod... because the mod I created physically IS "REDmod" and all the files that come with the REDmod DLC.

My goal was to create a modular "mod" of REDmod (redundant much?) and the mod's archive is packed to be Vortex-ready. The project was for personal use and my reasoning for creating it is because it enables me to Install/Enable/Deploy/Disable/Purge the REDmod DLC with a couple clicks. I keep a purely vanilla backup copy of the game on an external HDD, and in the event of a corrupted game: I can disable/purge all of my mods, delete the game directory, copy the game backup to my SSD (c:\), and then enable/deploy mods and resume gameplay. It works well for me. (I don't install ANY mods or mod dependencies directly to the game directory). Anyway, this modular REDmod mod project turned out great, it's working better than I could have hoped.

The project that I just described, unpacks many of it's files to the root game directory, as well as some files in \Cyberpunk 2077\tools\(and so on...). If I attempt to use Vortex's "Install" feature, that's when the files were being unpacked to the incorrect location, having generated 3 additional folders, 2 of which are for red4ext plugins. Again, there's no reason these "red4ext\plugins\" folders should have been created: %APPDATA%\Vortex\cyberpunk2077\mods\Modular_REDmod\red4ext\plugins\V2077-Modular_REDmod.installing\tools\redmod\bin\(and so on...)

Next I use Vortex's "Remove" feature to uninstall the mod (this works fine) and then use the "Unpack (as-is)" feature, and everything unpacks to the correct location (and no extra folders): %APPDATA%\Vortex\cyberpunk2077\mods\Modular_REDmod\tools\redmod\bin\(and so on...)

Yesterday I found a mod (click the 'Preview file contents' link and observe how it has no \mods\ folder) and this mod unpacks correctly with Vortex's "Install" feature, but will not unpack correctly if using "Unpack (as-is)". I thought maybe it could be helpful to point to this particular REDmod because it's archive is packed differently that I usually see. It's archive directory structure does not contain the \mods\ folder, and I assume your Vortex extension is able to identify that this is a REDmod and then it Installs it in \Cyberpunk 2077\mods\ (my opinion is that this is confusing behavior).

Now, here is a mod that I can repeatedly get to install incorrectly when using Vortex's "Install" feature, but it will ALWAYS install correctly if I use "Unpack (as-is)". Here is a screenshot of the Vortex Staging folder after I've used "Install" and the mod is installed incorrectly. Notice that the directory being shown in this screenshot is: %APPDATA%\Vortex\cyberpunk2077\mods\Clear Skill Checks-2805-1-0-0-1623448525\r6\scripts\V2077-Clear Skill Checks-2805-1-0-0-1623448525.installing

Notice that there is no reason that this "V2077-Clear Skill Checks-2805-1-0-0-1623448525.installing" extra folder should exist at all.

[KirkH420]

... I know that was a lot to read, sorry. I put a lot of time into it hoping that I could provide something useful to you.

[effs]

Well. On one hand I’m impressed, this is a good idea and an interesting attempt to get it working!

On the other, though, you have so many unintended or unsupported things going on here that I don’t think it’s a good use of our time — you included — to try to sort out exactly what’s going on in the current state of things.

Red4ext? DLLs. Installing DLC? Maybe as a Tool instead of a mod. Maybe not, it’s not conceptually quite right, but might work. Or maybe it would be the best way. An alternative approach we’re working on is just prompting the DLC install. You can see the 0.9 work here: https://github.com/E1337Kat/cyberpunk2077_ext_redux/projects/1

[KirkH420]

Look, whatever you think is best. There is a problem, and maybe you don't exactly see it yet... But I'm sure you will eventually. Take care and best wishes.