Building Vortex

[simsrw73]

Anyone get this to build yet? I'm still in process of trying to learn the libs & framework with lots still to learn, but I thought I'd go ahead and try to get it built but after straightening out a few configuration issues (eg. installing Python 2 and getting it put in the PATH ahead of v3, Removing VS Community 2017,etc.) I'm still not getting it built. I've attached output log from 'yarn install' as well as my build environment. I'm sure this is a configuration problem, picking up something wrong, but I'm a bit unsure which. Anything stand out?

 

This is built from cmd, launching from "Visual C++ 2015 x64 Native Build Tools Command Prompt" as Admin. Same results in PS, and without the MSBuild batch file.

[simsrw73]

D'oh. Nevermind. I should have googled before posting and given closer attention to the readme. Needed Node.js 8.x. The 9.x build won't work for building ffi. The build is progressing...

 

Up and running! :teehee:

[simsrw73]

Stopping here for the night. Got Vortex built and running. Except bsa support as shown in the attached log. Not sure about that one yet...

 

I'm guessing that I probably should run this under a different Windows user account than the one that runs my normal release Vortex?

[Tannin42]

The development version you get from running "yarn install && yarn run build"

will store its settings in C:\Users\<username>\AppData\Roaming\vortex_devel instead of C:\Users\<username>\AppData\Roaming\vortex so it should be completely separate from the regular install.

You just need to be careful when trying to manage the same game from both instances because then they will obviously overwrite each other.

Vortex should warn in that case (big dialog saying another vortex instance has deployed mods for that game and it would be better to purge from that other instance before deploying with the current one).

Personally I always disable automatic deployment for the development build.

[simsrw73]

The development version you get from running "yarn install && yarn run build"

will store its settings in C:\Users\<username>\AppData\Roaming\vortex_devel instead of C:\Users\<username>\AppData\Roaming\vortex so it should be completely separate from the regular install.

You just need to be careful when trying to manage the same game from both instances because then they will obviously overwrite each other.

Vortex should warn in that case (big dialog saying another vortex instance has deployed mods for that game and it would be better to purge from that other instance before deploying with the current one).

Personally I always disable automatic deployment for the development build.

 

Excellent. Thanks for that. That will make it considerably more convenient.

 

Can you offer any advice on this runtime error?

 

warn: failed to load dynamic extension name=gamebryo-bsa-support, error=expecting a function but got [object Undefined], stack=TypeError: expecting a function but got [object Undefined]

at Function.Promise.promisify (D:\projects\vortex\node_modules\bluebird\js\release\promisify.js:270:15)

at Object.<anonymous> (D:\projects\vortex\out\bundledPlugins\gamebryo-bsa-support\index.js:1339:30)

at __webpack_require__ (D:\projects\vortex\out\bundledPlugins\gamebryo-bsa-support\index.js:21:30)

at D:\projects\vortex\out\bundledPlugins\gamebryo-bsa-support\index.js:64:18

at Object.<anonymous> (D:\projects\vortex\out\bundledPlugins\gamebryo-bsa-support\index.js:67:10)

at Object.<anonymous> (D:\projects\vortex\out\bundledPlugins\gamebryo-bsa-support\index.js:3302:3)

at Module._compile (module.js:569:30)

at Object.Module._extensions..js (module.js:580:10)

at Module.load (module.js:503:32)

at tryModuleLoad (module.js:466:12)

at Function.Module._load (module.js:458:3)

at Function._load (D:\projects\vortex\out\util\requireRebuild.js:31:25)

at Module.require (module.js:513:17)

at Module.require (D:\projects\vortex\out\util\extensionRequire.js:29:25)

at require (internal/module.js:11:18)

at ExtensionManager.loadDynamicExtension (D:\projects\vortex\out\util\ExtensionManager.js:574:27)

[Tannin42]

Yeah, that error happens because I changed the api for bsatk which that extension loads and for some reason the code for gamebryo-bsa-support is new and the bsatk module is old (or maybe the other way around?).

 

Dependency management is a bit of a pain atm tbh. The current setup with extensions being integrated into the main application repo as submodules is not as convenient as I thought. When time permits I will have to set up something smarter.

[simsrw73]

Thank you! That got me there. 'gamebryo-bsa-support' was out of date. Updating it cleared cleared all remaining errors.

[simsrw73]

Well, not quite there. I played around a bit more today. Installed FO4 on my dev drive. Loaded up Vortex and tried to install a small mod package. On Install, I got an exception for 'edge': It's compiled for Node 8.2.1, so I had to downgrade Node again. 'ffi' doesn't like 9.x, and 'edge' expects 8.2.1 (available here). That got rid of that particular exception but exposed another type exception in 'fomod-installer'. Like 'gamebryo-bsa-support', it is out of date when compared to the latest updates on github. I've never worked with submodules in git before. I RTFM, and tried 'git clone --recurse-submodules' and few other things that Vortex build already does, but every time I clone Vortex or update, I get old versions of the submodules. I haven't checked any modules but those two yet, but I'm assuming I'll find the same for others. What am I doing wrong? I cheated earlier and manually copied changes in 'gamebryo-bsa-support'. But that's not correct or scalable. I just don't understand what git is doing.

 

The installer "ModA.7z (md5: 8804b56261c7f67857ff6f06c0c52bbc)" failed: edge.initializeClrFunc is not a function

TypeError: edge.initializeClrFunc is not a function

at Proxy.exports.func (D:\projects\vortex\node_modules\edge\lib\edge.js:169:17)

at Object.testSupported (D:\projects\vortex\out\extensions\installer_fomod\index.js:39:33)

at InstallManager.getInstaller (D:\projects\vortex\out\extensions\mod_management\InstallManager.js:569:41)

at mInstallers.(anonymous function).testSupported.then (D:\projects\vortex\out\extensions\mod_management\InstallManager.js:575:20)

at tryCatcher (D:\projects\vortex\node_modules\bluebird\js\release\util.js:16:23)

at Promise._settlePromiseFromHandler (D:\projects\vortex\node_modules\bluebird\js\release\promise.js:512:31)

at Promise._settlePromise (D:\projects\vortex\node_modules\bluebird\js\release\promise.js:569:18)

at Promise._settlePromise0 (D:\projects\vortex\node_modules\bluebird\js\release\promise.js:614:10)

at Promise._settlePromises (D:\projects\vortex\node_modules\bluebird\js\release\promise.js:693:18)

at Async._drainQueue (D:\projects\vortex\node_modules\bluebird\js\release\async.js:133:16)

at Async._drainQueues (D:\projects\vortex\node_modules\bluebird\js\release\async.js:143:10)

at Async.drainQueues (D:\projects\vortex\node_modules\bluebird\js\release\async.js:17:14)

at <anonymous>

[Tannin42]

Yes, git submodules are fixed to a specific revision, they always start out as detached heads.

Certain git commands (git submodule update I think) will reset them to that revision as well.

 

The problem is that I can't very well update the main repo every time I make any change in one of the submodules so my advice would be:

do a "git submodule foreach git pull origin master" and "git submodule foreach git checkout master" and then leave the submodules alone.

 

When I change something in a submodule and it's not on master I usually do (on the submodule directory) a "git stash" to save my changes,

then "git pull; git checkout master" to update the submodule to current master, then "git stash pop" to restore my changes and only

then "git commit; git push"

 

Visual studio code has a submodule view in its git page which will tell you when a submodule is detached and thus whether the above is

even necessary.

[jetrico]

The problem is that I can't very well update the main repo every time I make any change in one of the submodules so my advice would be:

do a "git submodule foreach git pull origin master" and "git submodule foreach git checkout master" and then leave the submodules alone.

 

When I change something in a submodule and it's not on master I usually do (on the submodule directory) a "git stash" to save my changes,

then "git pull; git checkout master" to update the submodule to current master, then "git stash pop" to restore my changes and only

then "git commit; git push"

 

 

try adding --init to your git submodule update