Fomm - Custom Build - 0.14.11.13

[niveuseverto]

I need your InstallLog.xml files... and what OS is in use?

Very interesting crash btw. have no idea what is going on atm.

Will try to fresh install it on VM.

[Guest luthienanarion]

There is no install log, because there's nothing installed. I cleared out my FOMM folder and reinstalled 0.14.10.2 (which runs fine) and extracted 0.14.10.4 on top of it.

OS Version 6.3.* is Windows 8.1.

[niveuseverto]

I've catched that bug.

Will make fix today.

 

Reason: unknown collision in settings from old FOMM: C:\Users\{%USER%}\AppData\Local\FOMM

[Guest luthienanarion]

Reason: unknown collision in settings from old FOMM: C:\Users\{%USER%}\AppData\Local\FOMM

 

The first thing I did when it crashed was delete those folders and try it again, so that's not the issue on my machine.

[niveuseverto]

Found it! It linked to settings, but mostly there were Getter, that asked itself so StackOverflow occured.

Fixed in new release: FOMM v0.14.10.5

 

Here is link to commit.

[Guest luthienanarion]

That fixed it. Glad I could help.

[prideslayer]

Niv, give me a quick "what's new" for the OP and I'll get your new version posted there.

[niveuseverto]

This is a service build. Main target of it - that we no more have largely diverged tree.

Plus Updater.exe, that checks and install new version from GitHub releases.

[prideslayer]

Hmm ok. Need to think about that a little, thought the updater stuff you were working on was the nexus etc. mod side, not the app side. Not sure I want to further 'split' the github+gitlab stuff.

 

What runs the auto-update? Is it manual or automatic, and if automatic, can it be disabled by the end user? Default state?

[niveuseverto]

Right now it manual.

Later - checkbox in the settings to check for updates at FOMM start-up.

Plus I'm planning to move Need-Elevation stuff into Updater (features like change file associations etc.)

 

Main idea on this utility is to do any hard migrations and actions, that are not mod management, that may appear with future versions (Like converting some inner DB or something like this, update associations, any cleanup...)

 

Version checker is WIP now.

 

Can you please give me status update on mod sorting?

[prideslayer]

Why move the privilege management out of the existing permissions manager? Seems like a decent enough central place for it, as it's used by more things (and more often) than just the update thing. I'd like to change that to pull from gitlab as well, as that is the 'official' repo. I want to keep everything "under one roof" and am not really comfortable having it pull updates from a different project.

 

If WIP why merged into master? Should stay a feature branch until it's ready to be pushed to users and tested.

 

BOSS is on hold for the time being due to issues I've found in the API integration and versioning. I'm still determining if I should use whichever BOSS the user currently has installed (preferable), or if I should just include a specific version and update as needed. The DLL is difficult to integrate with .net due to the calling convention, and there are 32/64 bit concerns as well that I need to deal with.

[niveuseverto]

Can you point me to existing permission manager?

 

GitLab (as for now) doesn't have any GitHub-like release mechanism, so I do not know, how can we handle releases with it. I'm open for suggestions.

 

WebsiteAPIs (may be renamed soon) right now not referenced from anywhere, so it not interacting with production code.

 

WrinklyNinja, developer of LOOT (BOSS), proposed to call existing LOOT.exe to handle sort operations (at least, while it is under heavy develop), so I think it is way for us to go for now.

May be I'll make some Pull Requests making it semi-unattended.

[prideslayer]

Can you point me to existing permission manager?

PermissionsManager.cs in fomm/Games/PackageManager. I think that could be moved out of the package manager and into a more generic setting that the updater, package manager, etc can use. Is that the kind of maangement you need for the escalation, or is it something else?

 

GitLab (as for now) doesn't have any GitHub-like release mechanism, so I do not know, how can we handle releases with it. I'm open for suggestions.

I can't really offer a suggestion since I don't know what you're trying to accomplish with it. My concern with pointing it to github is mainly that I'm not comfortable having the code come from one repo and the binaries from another -- especially if the binaries are eventually going to be automatic. I'm ultimately responsible for any problems the end users have, and if they end up having problems with something outside of my control, the only way I'll be able to fix it is to pull out the updating code and force them to manually update.

 

To be honest, I'm skeptical of the whole idea of an auto-update for the app as a whole. I think the potential for "irreversible" damage to the users installs is growing with each release as I dig deeper into the archiving and I prefer only people who know exactly what they're getting into get the new versions.

 

WebsiteAPIs (may be renamed soon) right now not referenced from anywhere, so it not interacting with production code.

 

WrinklyNinja, developer of LOOT (BOSS), proposed to call existing LOOT.exe to handle sort operations (at least, while it is under heavy develop), so I think it is way for us to go for now.

May be I'll make some Pull Requests making it semi-unattended.

That thread is saying to just wait, so I'm content to wait. There is no big hurry to integrate something like that. What I do need to do though is tell FOMM to watch for changes to the modlist load order and active plugins and automatically update it's display of they are changed by an outside program.

 

My first choice for that entire situation is to completely pull BOSS out of FOMM. There's no reason for it to be there. Users who want it should just run it externally (it could detect an install and provide a button like it does for fnvedit etc) and they can run any version they want without me having to chase down API incompatibility issues.

[niveuseverto]

PermissionsManager.cs in fomm/Games/PackageManager. I think that could be moved out of the package manager and into a more generic setting that the updater, package manager, etc can use. Is that the kind of maangement you need for the escalation, or is it something else?

 

No, that's not that. To set file associations (for example) on UAC machines we need elevated process.

 

I can't really offer a suggestion since I don't know what you're trying to accomplish with it. My concern with pointing it to github is mainly that I'm not comfortable having the code come from one repo and the binaries from another -- especially if the binaries are eventually going to be automatic. I'm ultimately responsible for any problems the end users have, and if they end up having problems with something outside of my control, the only way I'll be able to fix it is to pull out the updating code and force them to manually update.

To be honest, I'm skeptical of the whole idea of an auto-update for the app as a whole. I think the potential for "irreversible" damage to the users installs is growing with each release as I dig deeper into the archiving and I prefer only people who know exactly what they're getting into get the new versions.

 

We should think about this more carefully. But parsing forum as new version check is a little nail-in-an-ass... P.S. as you said earlier - link to loverslab thread is a bit nasty thing...

 

That thread is saying to just wait, so I'm content to wait. There is no big hurry to integrate something like that. What I do need to do though is tell FOMM to watch for changes to the modlist load order and active plugins and automatically update it's display of they are changed by an outside program.

My first choice for that entire situation is to completely pull BOSS out of FOMM. There's no reason for it to be there. Users who want it should just run it externally (it could detect an install and provide a button like it does for fnvedit etc) and they can run any version they want without me having to chase down API incompatibility issues.

 

I think it is logical step and agree with it. I just curious, if I will be able to make this process little bit automatic. In next releases of LOOT we will be able to include library.

[LukeDuke]

All versions newer than 0.14.10.2 are crashing for me, same for BOSS for Skyrim, any version newer than 2.1.1 are crashing for me including LOOT, I have all VC libraries installed from 2005 to 2013 with hotfixes for both x86 and x64 versions, and both installer and 7zip versions have the same problem :-(

[niveuseverto]

All versions newer than 0.14.10.2 are crashing for me, same for BOSS for Skyrim, any version newer than 2.1.1 are crashing for me including LOOT, I have all VC libraries installed from 2005 to 2013 with hotfixes for both x86 and x64 versions, and both installer and 7zip versions have the same problem :-(

Any crash dump?

[prideslayer]

No, that's not that. To set file associations (for example) on UAC machines we need elevated process.

What file associations does it need? Are you planning to make it handle the 'download with manager' stuff on nexus? That is a network protocol handler ("nmm://") IIRC, not a custom file/mime type.

 

We should think about this more carefully. But parsing forum as new version check is a little nail-in-an-ass... P.S. as you said earlier - link to loverslab thread is a bit nasty thing...

I'm not suggesting an auto-updater (if we actually end up with one) should parse forum posts. It can just check the most recent version tag and if it doesn't match the current version, prompt to fetch and update.

 

That said:

 

First, I don't think an auto-updater for the application itself is desirable right now. I don't want users getting a new version without doing it manually and knowing the risks involved, since there will continue to be above-normal risks at least until I'm done with the archive stuff.

 

Second, it was a conscious decision on my part to make LL the "official" release channel, despite any potential issues with the adult nature of the site. When I was hosting the project on sourceforge, before moving it to gitlab, I didn't use the release management there either.

 

It's a philosophical difference, but I do not see it as a downside, despite how it may limit exposure. Ashal has taken tenative steps in the past to move away from being a strictly adult-oriented site, and I'm sure more will follow.

 

I'm still confused (and a little disturbed) about the merge into master. Why was the update code put there and not in a feature branch? Master shouldn't have any commented, dead, or otherwise 'unused' code in it. I've been trying to pull it out as I come across it, and you've put it back in. The next time I run the resharper cleanup it's going to find all the unused classes and suggest I delete them..

 

I think it is logical step and agree with it. I just curious, if I will be able to make this process little bit automatic. In next releases of LOOT we will be able to include library.

(I will call BOSS, LOOT, and any other load order things just 'BOSS' here. I'm talking about any external load order manager.)

 

The existing load order thing is crap but it doesn't actually use BOSS -- it just uses the BOSS master list. My goal was to make it actually use BOSS -- whichever version the user has installed. I've been thinking for a while that this is actually a bad idea.

 

Calling the external DLLs for whichever version the user has installed is what I talked about with the users here a while back and is the only really acceptable method. Including a prebuilt BOSS of whatever version will just lead to conflicts with people that do use an external BOSS, and will also require new FOMM releases simply to track BOSS bugfixes.

 

Supporting just v1 and v2 external DLLs, both 32 and 64bit, is difficult enough as it is thanks to some bad decisions by the developers (changing entry points, etc). I'm sure adding the 3rd version will be no easier.

 

So the right thing to do is the same thing that it does with FNVEdit, but a bit more sophisticated. Check to see if the user has a load order manager installed, and provide a button to call it if they do. That's it. No more masterlist downloading or built in sorting.

[prideslayer]

With BOSS crashing too, that is probably an unrelated issue. Missing .net 4 runtime or something maybe?

[prideslayer]

I think I missed what you meant in your response about BOSS, so to reiterate (shortly).

 

I'm in favor of completely pulling it out and limiting support to simply calling whatever installed version the user wants, if they have one. It can make an effort to determine if there is a version installed by checking the registry and/or common locations, and worst case, allow a user supplied setting for where to find it.

 

Automation would be limited to simply monitoring the plugins.txt and timestamps for loadorder so it can keep itself in sync, maybe with a VS style popup saying "something changed the load order, refresh? Yes/No/Always". This is something it should be doing anyway because it would be one less barrier to running FOMM and NMM together, potentially even at the same time (though why anyone would...).

 

If the UI for BOSS/LOOT/whatever is no good, users can take it up with the operators of those tools, write their own, or beg someone to write one. I'm sure they will come along eventually if there is enough demand.

[niveuseverto]

 

With BOSS crashing too, that is probably an unrelated issue. Missing .net 4 runtime or something maybe?

 

LOOT is a VC++ project. so no .net is required. Latest FOMM - is require .net 4.

 

What file associations does it need? Are you planning to make it handle the 'download with manager' stuff on nexus? That is a network protocol handler ("nmm://") IIRC, not a custom file/mime type.

 

FOMOD for example. And I've thinked about handling nmm://...

 

 

 

I'm not suggesting an auto-updater (if we actually end up with one) should parse forum posts. It can just check the most recent version tag and if it doesn't match the current version, prompt to fetch and update.

That said:

First, I don't think an auto-updater for the application itself is desirable right now. I don't want users getting a new version without doing it manually and knowing the risks involved, since there will continue to be above-normal risks at least until I'm done with the archive stuff.

Second, it was a conscious decision on my part to make LL the "official" release channel, despite any potential issues with the adult nature of the site. When I was hosting the project on sourceforge, before moving it to gitlab, I didn't use the release management there either.

It's a philosophical difference, but I do not see it as a downside, despite how it may limit exposure. Ashal has taken tenative steps in the past to move away from being a strictly adult-oriented site, and I'm sure more will follow.

 

Ok, then I closing auto-updating features and will use this assembly only as "Simple Program for Actions requires Elevation" (I don't like idea to run FOMM in "As Administrator" mode)...

 

About release channel: may be Ashal can make topic, that only two of us can post? Every post is new release and changelog for that release.

This kind of thread can be used as release channel.

 

 

 

I'm still confused (and a little disturbed) about the merge into master. Why was the update code put there and not in a feature branch? Master shouldn't have any commented, dead, or otherwise 'unused' code in it. I've been trying to pull it out as I come across it, and you've put it back in.   The next time I run the resharper cleanup it's going to find all the unused classes and suggest I delete them..

 

You're good to go =) I can restore them anyway

That parts was on my master, when I first contacted you.

 

 

 

(I will call BOSS, LOOT, and any other load order things just 'BOSS' here. I'm talking about any external load order manager.)

 

The existing load order thing is crap but it doesn't actually use BOSS -- it just uses the BOSS master list. My goal was to make it actually use BOSS -- whichever version the user has installed. I've been thinking for a while that this is actually a bad idea.

 

Calling the external DLLs for whichever version the user has installed is what I talked about with the users here a while back and is the only really acceptable method. Including a prebuilt BOSS of whatever version will just lead to conflicts with people that do use an external BOSS, and will also require new FOMM releases simply to track BOSS bugfixes.

 

Supporting just v1 and v2 external DLLs, both 32 and 64bit, is difficult enough as it is thanks to some bad decisions by the developers (changing entry points, etc). I'm sure adding the 3rd version will be no easier.

 

So the right thing to do is the same thing that it does with FNVEdit, but a bit more sophisticated. Check to see if the user has a load order manager installed, and provide a button to call it if they do. That's it. No more masterlist downloading or built in sorting.

 

 

I think I missed what you meant in your response about BOSS, so to reiterate (shortly).

I'm in favor of completely pulling it out and limiting support to simply calling whatever installed version the user wants, if they have one. It can make an effort to determine if there is a version installed by checking the registry and/or common locations, and worst case, allow a user supplied setting for where to find it.

Automation would be limited to simply monitoring the plugins.txt and timestamps for loadorder so it can keep itself in sync, maybe with a VS style popup saying "something changed the load order, refresh? Yes/No/Always". This is something it should be doing anyway because it would be one less barrier to running FOMM and NMM together, potentially even at the same time (though why anyone would...).

If the UI for BOSS/LOOT/whatever is no good, users can take it up with the operators of those tools, write their own, or beg someone to write one. I'm sure they will come along eventually if there is enough demand.

 

That exactly what I meant for this time. Just make users to Install/Run LOOT to handle Load Order.

[prideslayer]

Ok.

 

The auto-update idea is fine as long as it defaults to *off*, and I don't think we can expose it to end users at least until the archive stuff is done. That is mostly because I don't trust *myself* to not make mistakes. I already made two in the last few revs that resulted in partially installed mods that FOMM did not know got installed.

 

I don't know how many users got bit by that, but I at least know it was only people who came here and manually downloaded, and going from the download counts it wasn't very many.

 

As for the NMM and .FOMOD thing -- handling NMM I think would be a good thing to do, certainly. I don't know about the fomod extension. I agree, running FOMM as administrator is a big no-no and I've told people not to do that repeatedly. If permissions need elevated in order to manage the extension handling, that's fine, though we should discuss exactly what functionality we're after in that regard anyway.

 

I'm going to fire off a PM to make sure we're on the same page with everything.

[LukeDuke]

With BOSS crashing too, that is probably an unrelated issue. Missing .net 4 runtime or something maybe?

Hmn... I have all versions of the .NET Framework (from version 1.0 to version 4.5.1) installed, all other programs/games works fine - including older versions of the BOSS (2.1.1 and older) and FOMM (0.14.10.2 and older), any newer version than I mentioned and boom crash at startup.

[niveuseverto]

In FOMM 0.14.10.4 there is a bug, that leads to crash-on-startup. It is fixed in 0.14.10.5.

BOSS 3+ requires Visual C++ Redist.

[LukeDuke]

Any crash dump?

No, just this:

 

The application was not properly launched (0xc000007b).

 

The same error shows for LOOT and all versions of BOSS newer than 2.1.1

[niveuseverto]

As for the NMM and .FOMOD thing -- handling NMM I think would be a good thing to do, certainly. I don't know about the fomod extension. I agree, running FOMM as administrator is a big no-no and I've told people not to do that repeatedly. If permissions need elevated in order to manage the extension handling, that's fine, though we should discuss exactly what functionality we're after in that regard anyway.

 

Little app, that takes no user input and do only specific things (like setting associations).