Ahhh - it's all in the day's work I guess

Hmmm - added a note in the BAIN issue and will come back for more - what basically happens is that Bash does not rescan the data folder - so it can't know the file changed. A Refresh Data should cure that and having Bash rescan the data folder would be just too much work - although an option to just rescan the espms would fix the most usual case (I bet the same would be true if you edited say a texture)

I think what's going wrong here is the apostrophe in Player's Hanbook - see Common Mistakes in the technical readme http://wrye-bash.github.io/docs/Wrye%20Bash%20Technical%20Readme.html. Not sure if escaping works - try Player\'s Hanbook (btw should be Handbook ?)

Did not look into this but if you find some time post me an issue at github - wizards are indeed low priority but once someone (Lojack ?) starts looking at them better have them all there ready

Will try to reproduce and get back to you - the installer is a project right ?

Alright will try to reproduce - you installed from a project right (not a zip/7z) ?

Managed to launch BOSS from Bash alright: https://www.dropbox.com/s/sj7cjxcv9is2bju/BOSSlog.html?dl=0

But apparently you are using latest (2.3.2) ? Will try that too once I get round to it

Keep using my wip branch - it also contains (as the dev branch) the edits to skyrim records from Sharlikran's branch - so we need to make sure no corruption occurs (remember 306 dev corrupting esps). Timestamps are still important in skyrim when it comes to scanning for changes

Keep'em coming - BAIN was needing a refresh so to speak, and you can't make an omelet without breaking some eggs.

No, I mean a zip or .7z installation package. This is when I change an installed file and want the installation package to use that updated file.

Incredibly minor thing - launching for Fallout 4 does not have an icon for FO4Edit the way other games have for their links to xEdit.

Sharlikran's branch does though, and it's kind of an expected thing for that to be there.

For Skyrim (if it matters).

I checked a project folder, noticed 2 of the .psc files were listed as out of sync with the Data folder. So I figured it was because they hadn't been updated yet. Then noticed the .pex files that go with them were not listed.

When I recompiled the scripts and came back to Bash, the BAIN window started a refresh on the installers. Which I figured was a good thing. Unfortunately it got stuck in a loop and kept going back to refresh the data over and over again, even if I canceled it. I could not get off the installers tab and was forced to kill the Python process from the task manager.

On the bleeding edge branch. I'll fall back to the more stable dev branch for now since that's a fatal error

Thanks Supierce. So you are manually repacking the esp in the archive ?

Hmm - will have a look at sharl's branch

Haha - I am right now debugging just this It does not happen in the dev branch right ?

Yeah, bleeding.

It doesn't, no. Dev doesn't even know there's been a change when I alter the files.

Try again the wip branch Arthmoor - should be fixed. This probably also fixes the saebel bug if related to projects. Will have a look at the Supierce one

EDIT: giving up for now - @Supierce, how are you repacking the archive ? is Bash open and you give it focus between the steps ?

@saebel: that's what I tried (on my updated wip branch)

1. Install a mod from the installers tab. # I unpacked an archive to a project and installed the project (unpacking the archive triggered the refresh loop Arthmoor reported and is fixed on the updated branch (same link))

2. BOSS reorder the mod. Boss has to be started form outside Wrye Bash.# did that from inside Bash - the mod was redated

3. Use CSE or TES4Edit to modify an element of the mod. Say a script step. # renamed an NPC in Tes4Edit

4. Save the change. # saved

6. The data should be marked as being out of sync. <--- not my case - as with Arthmoor, BAIN does not detect the change (so I closed and reopened Bash - refresh Data would do, I bet)

7. Choose option update/sync files. # I right clicked on the project and chose "Sync from Data"

8. After update, the installer package will still be marked out of sync, but if you look in the director, you can confirm the file was updated. <-- it turned green on my case, hmmm - I am on windows 7 and I am tempted to think it makes a difference, except if I missed one of the steps or it was fixed in the updated branch which is probable

Refreshing the folder of the installation package has not worked consistently. Generally speaking, the only ways I have managed to resolve the issue is to either re-install after syncing the data or to completely exit out of Wrye Bash and reboot. But, again, it's not consistent. For instance, I just launched WB after modifying a .dll and an .esp. I loaded up the installers tab, it saw that there was a difference. It correctly identified the two files. I synced the data, and the mod went green as expected. (using dev version, not bleeding edge)

I always assumed that a "refresh" of the installation folder would scan the contents of the folder and then scan the data folder, filtering for just the contents of the installation folder. Is that was is happening? BTW, even full refreshes didn't necessarily correctly identify either changed or updated files.

Thanks for catching the spelling error. Missed that one. Normally, if the primary form of quoting is with double quotes, you don't need to escape the single quotes. I didn't in other places in the wizard script and had no issues. But just to be sure, I escaped all the singles anyway, but it didn't make any difference. The note did not appear.

Okay, I'll do that. (side note, not happy to find someone else took my user name of saebel on GitHub. Don't they know I'm the only one?)

I am installing from a folder, not an archive. In general, I don't install from archives. I prefer my mods unzipped. (There is a joke there somewhere)

Sorry, I probably wasn't clear. I could launch BOSS fine from Wrye Bash, but then if I ran the BOSS updater and returned to the Wrye Bash mod list, Wrye Bash would crash. If I launched BOSS manually outside of Wrye Bash, I never ran into that problem. Edit: To be sure, I redownloaded the dev version of WB, and it's still freezing up after running the Boss load order and going back to the mod list if BOSS is launched from Wrye Bash.

Nope. Behavior is back to ignoring changes made. The Installers tab is not refreshing the project. Restarting Bash updates to the proper information.

@Arthmoor - I meant the infinite loop - the behavior of ignoring the change is as you noted a 306 thing and needs extra refreshes to be amended. Could you test if the column menu "Refresh Data" wakes Bash up ?

Thanks @saebel - sorry for your username being taken - silly them. Sorry also the note was not an easy fix - add it to the bug in github, just so it's there - may open a new issue myself.

Re: BOSS will download 2.3.2 and test at some point but meanwhile any options in the boss button ? Are you running using the gui ? If yes be sure to close the boss gui before returning to Bash and see if it helps.

Re: refreshes - did I follow the steps right ? is it still present on my wip branch ?

Also the fix for the infinite refreshes may have cured the crc hang @saebel and @Supierce - you can test the https://github.com/wrye-bash/wrye-bash/archive/supierce-hang.zipbranch to see if still there.

Re: refreshes - once the dust settles would be great (read necessary) to come up with a rundown of what BAIN will or won't refresh to at least add it to the docs and start seeing if/how to extend it.

Thanks for feedback - much needed

EDIT:

> I always assumed that a "refresh" of the installation folder would scan the contents of the folder and then scan the data folder, filtering for just the contents of the installation folder. Is that was is happening? BTW, even full refreshes didn't necessarily correctly identify either changed or updated files.

You mean right clicking the project and choosing "Refresh" - nope it does not re refresh the data folder - it would be sensible - hmmm - can you post that here: https://github.com/wrye-bash/wrye-bash/issues/219

A full refresh does refresh the data dir however so should detect modified files - hmmm - as does a refresh Data - only difference being tha a full refresh recalculates _all_ crcs

Gah! It never occurred to me that I needed to close the BOSS Gui because I didn't need to do it when I launched manually not using Wrye Bash. But you are correct, closing the BOSS Gui restored my ability to work with Wrye Bash.

In all honesty, I'm not sure why that would be necessary. It's kind of a draw back because if I am messing around with load order user rules, I don't want to have to open/close BOSS every time I want to see the results. I will probably just launch BOSS manually moving forward.

I appreciate the help though! I was going nuts!

Is there a bash tag to prevent the bash patch from adding HNAM - Hair entries to NPC records if missing and from adding a postive value to LNAM - Hair Length when current value is zero?

I would have expected either tag NPCFaces or NpcFacesForceFullImport to add from NPC records the FaceGen Data and FNAM entries into the bash patch, but they do not, instead last-loaded gets bashed (when other entries require the NPC record to go into the bash patch) - is there a tag which will add FaceGen Data and FNAM entries?

Bash is never open when I update the installation package. I always run it after editing the file and then copying it to the installer package. That subsequent scan is where the difference occurs.

When I edit the file in an external folder, and then update both the installation package and the installed location, Bash claims they are not identical and flags the installer yellow. When I edit the file in its installed location, and then copy it to the installation package, Bash then recognizes them as identical and flags the installer green. The only difference is where I do the editing, which must somehow make a difference to the checksum.

Well the GitHub people were very nice. Apparently the previous possixr of the "saebel" user name hadn't used it in a very long time, so they released it and let me have it. How cool is that?

I added all my BAIN issues to the thread here: https://github.com/wrye-bash/wrye-bash/issues/219

@Utumno, it looks like you've solved the CRC hangs. The updated wrye-bash-utumno-scandir and wrye-bash-supierce-hang builds work fine!

EDIT: BTW, of the three post-DEV builds, supierce-hang completes the installer scan/CRC check MUCH faster than the others. I hope whatever magic it contains is something you can keep!

EDIT 2: As an extra added bonus, supierce-hang also solves the issue I reported above, where identical files imported from an external folder to both the installer and the installed location are reported as mismatched. With supierce-hang, that problem doesn't exist.

So reiterating my hope that supierce-hang scan magic is retainable.

Interesting- of course in the stable release BOSS is run outside of Wrye Bash the mods are redated on GUI activation. What's the plan?

Thanks @saebel and @Supierce - please keep using the supierce-hang branch then so we make sure nothing crops up - in which case I can go ahead and merge it to dev.

@ display name is already in use: not sure, patches I have not (yet) looked into. Anyone ? You could go ahead and post a request at github I guess but don't hold your breath - we need people to code.

@Imstearn: dunno - not using boss much actually

Generally speaking, it feels like the way WryeBash loads third party apps is just a little weird. I still get errors whenever I attempt to launch Oblivion or Construction Set extender. And it's still weird to me that if I launch BOSS separately from Wrye Bash, I don't need to close it before I see the updated date changes vs. what happens if I launch Boss from WryeBash.

I really wish I knew how to code better. I can handle FileMaker databases, basic MySQL, javascript, php and some really basic stuff C++ stuff for my plug-in. But I don't think that's going to be enough to help out. I'm just not hard core enough.