g96968

Hmm... Yes you're right it seems to work... Sometimes. But, when I try: C:\Games\ModOrganizer\ModOrganizer.exe C:\Games\ModOrganizer\mods\NifSkope\NifSkope\NifSkope.exe "C:\home\public\skyrim_armour_from_scratch\CA4S - Creating Armors for Skyrim - Nightasy\unp custom armor\data\meshes\armor\hide\f\fin2\cuirasslight_0.nif"NifSkope fails to locate the file and reports that "C:\Games\Skyrim\data\NifSkope\armor\data\meshes\armor\hide\f\fin2\cuirasslight_0.nif" wasn't found... But this works fine if I direct it to Notepad.exe instead of NifSkope.exe... Maybe MO is trying to be clever and is modifying the path of the file if the executable is defined in the VFS even though it's out of bounds (from the VFS)? Or maybe it's striping the quotation mark? Or maybe NifSkope isn't handling the file path argument properly unlike notepad? Doesn't matter. I know now how to circumvent this bug without the external dependencies. Just write NifSkope.bat, place it next to NifSkope.exe and associate .nif files to it: @echo off C:\Games\ModOrganizer\ModOrganizer.exe C:\Games\ModOrganizer\mods\NifSkope\NifSkope\NifSkope.exe ""%*""There. Problem solved :D Not sure why the double quotation marks are necessary (could be a bug down the chain and not in the script as speculated above) but as long as it's working I'll bite the bullet and call it mea culpa :D Regardless, Thanks! I guess you could add this trick in the wiki since for most people it solves the big problem of associating files to creative kit? I think it should also allow passing arguments - such as fullproc - and the like...

Oh I already have a straight-forward workaround using a named pipe. I was just looking for a proper fix. But here's my NifSkope workaround for future reference: 1. Place NifSkope in it's own mod dir. The resulting dir structure as follows in my case: C:\Games\ModOrganizer\ModOrganizer.exe C:\Games\ModOrganizer\mods\NifSkope\NifSkope\NifSkope.exe 2. Download createAndWritePipe.exe off https://github.com/psmay/windows-named-pipe-utils/releases 3. Place it so: C:\Games\ModOrganizer\mods\NifSkope\NifSkope\createAndWritePipe.exe 4. Write C:\Games\ModOrganizer\mods\NifSkope\NifSkope\NifSkopeMO.bat as follows: @echo off start C:\Games\ModOrganizer\ModOrganizer.exe C:\Games\ModOrganizer\mods\NifSkope\NifSkope\NifSkope.bat echo %* | "C:\Games\ModOrganizer\mods\NifSkope\NifSkope\createAndWritePipe.exe" NifSkope5. Write C:\Games\ModOrganizer\mods\NifSkope\NifSkope\NifSkope.bat as follows: @echo off FOR /F "delims=" %%i IN ('type \\.\pipe\NifSkope') DO NifSkope.exe %%i6. Open Mod Manager and add NifSkope.bat as an executable. 7. right click any nif file, Open with -> Choose default program... browse and select NifSkopeMO.bat. The end result is that NifSkopeMO.bat will create a named pipe storing the arguments. Then MO will initiate NifSkope.bat which will read that named pipe and run NifSkope.exe with those arguments. It's a simple enough solution but you can circumvent a lot of hoops (creating the named pipe and depending on another executable to do so) by having MO just pass arguments forward to the executable it's been asked to run. Edit: If you have spaces in your path to NifSkope.bat you might need to escape them by using quotation marks or carat ("^").

First off, let me switch to talking about CreationKit.exe instead of NifSkope since it's the wider case and it's an official part of the game so supporting it's proper functionality is palatable. Now, I'm not talking about inspecting *.nif files from MO. I'm talking about the system-wide associations. So, in my case, say I'm working on a an armor piece and I'm constantly opening and reopening *.nif files from the file manager (My Computer/explorer.exe) since the nif plugins for 3dsmax and maya are buggy requiring frequent export/imports. Normally the association is to CreationKit.exe but if I'll just double click the file in the file manager following this direct association then I'll get a CreationKit.exe instance that's working outside MO virtual file system and it won't have access to my mods and overwrites where I actually store my modified textures and such. So, my suggestion is to modify MO to pipe (pass-on) the extra arguments it gets in stdin to it's stdout. Then write a small batch file like the one I showed above and associate *.nif files to that. Btw, my current solution is to open CreationKit.exe (well, actually I use NifSkope for these things but for the sake of this example) from MO and then open the file I want from there. It's a clunky and slow workflow and makes my life hard since I also need to restart Skyrim frequently to test out mesh adjustments if I'm fitting a piece of armor to a body.

There's a known problem when using executables with Mod Organizer and programs like NifSkope where you can't associate files to the internal executable. My solution is pretty straight forward: pass the arguments forward. That is, currently ModOrganizer.exe takes the first argument and executes it after applying* the internal virtual file system. My solution is to just forward the following arguments to the executable. Then, a user could associate a batch file to the desired extension as follows: @echo off C:\Games\ModOrganizer\ModOrganizer.exe "C:\Games\ModOrganizer\mods\NifSkope\NifSkope\NifSkope.exe" %1This will cleanly pass the first argument. It's even possible to pass all arguments forward using: @echo off C:\Games\ModOrganizer\ModOrganizer.exe "C:\Games\ModOrganizer\mods\NifSkope\NifSkope\NifSkope.exe" %*Anyhow, that's just my two cents. Thanks * no clue how that works... I'm not too familiar with how windows does these things. In linux it would likely get done with containers these days or links or mounts... I don't think either system has union mounts...

When creating a new account, forum.step-project.com is sending the following validation link: https://forum.step-project.com/index.php?app=core&module=global§ion=register&do=05 where it should be: https://forum.step-project.com/index.php?app=core&module=global&section=register&do=05 Similarly, the auto validation link is broken: https://forum.step-project.com/index.php?app=core&module=global§ion=register&do=auto_validate&uid=xxxx&aid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx but it should be: https://forum.step-project.com/index.php?app=core&module=global&section=register&do=auto_validate&uid=xxxx&aid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Finally, the https interface is open with a bad certificate and an admin management access. Even if you don't care about secure access, you should at least close down that interface since it's a separate running instance. Alternatively if you're using it for admin operations you should assign a non-default port so it won't get accessed by mistake.