prideslayer Posted February 17, 2014 Author Posted February 17, 2014 It finished quick (gogo new raid! + megagigabytes!) but I think what I've actually done is broken FOMM for every mod using performBasicInstall in its install script, not just TTW. Which is really a good thing since it means TTW is nothing special. It's a bad thing because I'm an idiot that didn't test enough.
ChianasGeek Posted February 17, 2014 Posted February 17, 2014 Everyone's an idiot sometime or other... So, this means I'm not going fahrbot, and neither is my PC's Win7 install?
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 Yeah you're fine. Somehow the error is getting captured.. somewhere.. and ignored, hence it saying it was a succsss. It's not even actually trying to install all the files. It fails on the first one (Path.GetTempFileName() is causing a security exception -- wtf) and doesn't even try the rest, and just says "I did it!" FRELL THIS!
ChianasGeek Posted February 17, 2014 Posted February 17, 2014 Yeah. That's fahrbot! So, is the security exception on the temp path or the install path?
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 It's not even a filesystem permission error, it's blowing up just trying to read the environment variable representing the temporary file path. It only happens when the function is called from a fomod c# script, the same function internally works. The c# script (fomod script) is "unmanaged code" so it needs permissions assigned, which are requested by the main app. The problem is I don't know which goddamn permissions it wants -- which environment var it's trying to read. I've given it access to TEMP and TMP but maybe it wants more. The documentation for System.IO.Path.GetTempFileName() doesn't say. It doesn't help that I have no idea what I'm doing with this .net shit.
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 If anyone out there DOES know .net shit... full exception: System.Security.SecurityException was caught Message=Request for the permission of type 'System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed. Source=mscorlib StackTrace: at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) at System.Security.CodeAccessPermission.Demand() at System.IO.Path.GetTempPath() at System.IO.Path.GetTempFileName() at Fomm.PackageManager.ModInstallScript.InstallFileFromFomod(String p_strFile) at Fomm.PackageManager.ModInstaller.PerformBasicInstall() at fomm.Scripting.GenericBaseScript.<PerformBasicInstall>b__0() at fomm.Scripting.GenericBaseScript.ExecuteMethod(GenereicVoidMethodDelegate p_gmdMethod) InnerException: Generated by unmanaged code trying to call System.IO.Path.GetTempFileName();
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 Giving it unrestricted access to ALL environment vars did the trick, but that seems a bit untidy.
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 9beta7 here with adjustment. TTW Main installed OK for me with this version. If it works for y'all, going to call it a release after rebuilding with x64 support back in. Edit: Smoked, standby.
blisst Posted February 17, 2014 Posted February 17, 2014 gack.. make 1 suggestion then disappear for a day or 2 and all this happens.. heh jus to confirm a couple things.. Niveus yes it's a brilliant idea by the NMM team that's why i'd like to see it in GeMM.. (just "trying GeMM on" as a name for now).. and while my "spreadsheet view" idea is certainly a much more ambitious display of the same functionality.. i'm certain there's other people out there who would lust after such an OCD-friendly feature.. no reason why t6m replacer should overwrite my loadscreens XD (except some are packed in the damn BSA) Pride.. ya from what I saw of the TTW source.. the installer doesn't really do anything special when writing the fomod script.. I think TTW installer source is public accessible if you have any desire to view it I can find a link.. Also the filesize on earlier builds seems much less than ttw's 5gb archives.. the TTW port of lings (about 800Mb) chokes for me w/o LAA bit flipped Chi.. thanks for your continuous support of Pride's dev efforts here *Anxiously awaiting the x64 build.*
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 v0.14.9 in OP -x64 support -Large archive support in x32 -"Yes to mod" and "No to mod" support -Redesigned 'overwrite' window to not resize and move around. tada!
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 gack.. make 1 suggestion then disappear for a day or 2 and all this happens.. heh jus to confirm a couple things.. Niveus yes it's a brilliant idea by the NMM team that's why i'd like to see it in GeMM.. (just "trying GeMM on" as a name for now).. and while my "spreadsheet view" idea is certainly a much more ambitious display of the same functionality.. i'm certain there's other people out there who would lust after such an OCD-friendly feature.. no reason why t6m replacer should overwrite my loadscreens XD (except some are packed in the damn BSA) It's possible, just a bit more involved. The NMM-style functionality was easy. I have an overhaul of the package manager form on my todo list because I'd like to add another idea from NMM there -- user defined categories. That will be a big enough UI change in itself that adding a simple lock/unlock that overrides the "yes to all" functionality would not be too difficult. If I understand it that's basically all you want right, nothing more complex? Just something like a lock icon on each mod on the package manager screen, and if a mod is locked it overrides "yes to all" or "yes to folder" with a confirmation? Pride.. ya from what I saw of the TTW source.. the installer doesn't really do anything special when writing the fomod script.. I think TTW installer source is public accessible if you have any desire to view it I can find a link.. Also the filesize on earlier builds seems much less than ttw's 5gb archives.. the TTW port of lings (about 800Mb) chokes for me w/o LAA bit flipped There were three problems.. 1. The program was compiled for x32 originally, by timeslip. This meant even with more memory and LAA it still could not handle files *inside* an archive that are > 4GB in size. 2. The internal fomod installation process involved opening the archive and for each file inside reading the entire file into memory and then burping it back out again. This is the main thing I replaced to fix the issue on both x32 and x64. No amount of LAA or x64 can fix this, just cover it up for a while. LAA on x32 would still fall down on files inside the archive > 4GB, and it would still fail on x64 if the file was larger than your memory+swap. Now it will always work, just like 7zip itself, because I do it the same way --- extract to a temporary file and then copy the file to it's final destination. 3. The fix for #2 caused a permissions problem that I thought was x32 and/or TTW related. It turned out to be neither. I'm not a .net guy so I didn't realize a running fomod script did not simply inherit the same permissions as the parent process. This was the problem that took me so long to figure out. Chi.. thanks for your continuous support of Pride's dev efforts here Agreed! *Anxiously awaiting the x64 build.* It's up -- though now, there is actually no need for an x64 build. There are still parts of the code using the old archive extration to memory thing, but at first glance, it looks like they're only used to show the screenshots and do script editing from within FOMM -- so unless a fomod has a > 2GB screenshot, script, or readme they should not pose a problem.
ChianasGeek Posted February 17, 2014 Posted February 17, 2014 Chi.. thanks for your continuous support of Pride's dev efforts here Agreed! Most welcome - glad it's sorted, 'cos it was sure confusing here lol
KainsChylde Posted February 17, 2014 Posted February 17, 2014 I have an overhaul of the package manager form on my todo list because I'd like to add another idea from NMM there -- user defined categories.
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 Hmm. Should I replace that with "get glasses?" haha.
KainsChylde Posted February 17, 2014 Posted February 17, 2014 Pride, I love your work. You are an excellent programmer, a great modder, and a nice guy. But maybe, just maybe, you should open the program as a user and explore all of it's functions before planning changes? Just hit all the buttons, see what they do. Just a thought, to save yourself some duplication of effort.
Slammer64 Posted February 17, 2014 Posted February 17, 2014 Works very nicely so far Pride, as long as I don't forget to run it as Admin. Win7 x64 bit here.
prideslayer Posted February 17, 2014 Author Posted February 17, 2014 Pride, I love your work. You are an excellent programmer, a great modder, and a nice guy. But maybe, just maybe, you should open the program as a user and explore all of it's functions before planning changes? Just hit all the buttons, see what they do. Just a thought, to save yourself some duplication of effort. Point taken.. That said, I hate the existing layout of FOMM so much I simply don't "see" half the stuff in there, and the history of clickign things just to have it blow up makesme a bit nervous. I'll take some time to go over it though. Works very nicely so far Pride, as long as I don't forget to run it as Admin. Win7 x64 bit here. You need to run as admin? That's odd.. what's failing if you don't?
prideslayer Posted February 18, 2014 Author Posted February 18, 2014 Well, first stab at realBOSS integration is done. Getting the BOSS install dir from the registry and then hooking into the DLLs was "easy" at first, then got tough, but it's settled and I kinda know what I'm doing now. Unfortunately the idea isn't quite as 'cool' as I thought it was going to be, since BOSS isn't as cool as I expected it to be. Boss 2.x will be required, they changed way too much between 2.x and 3.x for me to support both right now, and 2.0's API has the far better documentation. Later I'll be able to support whichever is installed but it's a little tricky since they made some bad choices rendering the interfaces between the two versions incompatible. Half a day spent just ending up with this gibberish! [DllImport("boss32.dll", EntryPoint = "GetLoadOrder")] protected static extern UInt32 bapi32_GetLoadOrder(UInt32 boss_db, ref IntPtr plugins, ref IntPtr numPlugins); [DllImport("boss64.dll", EntryPoint = "GetLoadOrder")] protected static extern UInt32 bapi64_GetLoadOrder(UInt32 boss_db, ref IntPtr plugins, ref IntPtr numPlugins); ... and this gibberish ... Array.Resize(ref ret, cnt.ToInt32()); plugins = new String[cnt.ToInt32()]; pPluginArray = new IntPtr[cnt.ToInt32()]; Marshal.Copy(pPlugins, pPluginArray, 0, cnt.ToInt32()); for (int i = 0; i < cnt.ToInt32(); i++) { ret[i] = Marshal.PtrToStringAnsi(pPluginArray[i]); }
blisst Posted February 18, 2014 Posted February 18, 2014 It's possible, just a bit more involved. The NMM-style functionality was easy. I have an overhaul of the package manager form on my todo list because I'd like to add another idea from NMM there -- user defined categories. That will be a big enough UI change in itself that adding a simple lock/unlock that overrides the "yes to all" functionality would not be too difficult. If I understand it that's basically all you want right, nothing more complex? Just something like a lock icon on each mod on the package manager screen, and if a mod is locked it overrides "yes to all" or "yes to folder" with a confirmation? Here's how I was envisioning it.. Locked mods will disable the prompt for overwrite and auto-magically select "No to overwriting files for the locked mod." Ending with a notification stating that the new mod attempted to overwrite files from the following locked mods (list) but overwrites were prevented due to lock. In MY mind that makes the most sense.. so you get the functionality of the lock.. and if you want to overwrite your locked mods.. you have to put some real effort in to do so. In theory that would make it a bit harder to reflex-click the wrong button. pardon the multi-post to follow.. IE's not letting me paste into the response box...
blisst Posted February 18, 2014 Posted February 18, 2014 There were three problems.. 1. The program was compiled for x32 originally, by timeslip. This meant even with more memory and LAA it still could not handle files *inside* an archive that are > 4GB in size. 2. The internal fomod installation process involved opening the archive and for each file inside reading the entire file into memory and then burping it back out again. This is the main thing I replaced to fix the issue on both x32 and x64. No amount of LAA or x64 can fix this, just cover it up for a while. LAA on x32 would still fall down on files inside the archive > 4GB, and it would still fail on x64 if the file was larger than your memory+swap. Now it will always work, just like 7zip itself, because I do it the same way --- extract to a temporary file and then copy the file to it's final destination. 3. The fix for #2 caused a permissions problem that I thought was x32 and/or TTW related. It turned out to be neither. I'm not a .net guy so I didn't realize a running fomod script did not simply inherit the same permissions as the parent process. This was the problem that took me so long to figure out. 1).. true... so while the 5gb TTW fomods would be hosed.. the ~1gb lings should work with the LAA bit flipped.. 2).. makes a lot of sense... I can imagine it must have been necessary at the time due to the existing compression library of the time... also who would have expected that we're dealing with multiple 2gb bsa's in a single fomod archive like some of the larger texture intensive mods out there are. 3).. ya.. .net is weird.. and current implementation is a source of woe for the TTW team on Win8.1... due to the new handling of UAC on win 8.x the BSAopt part of the installer can't be run unattended, because there appears to be NO way to spawn a hidden console, or parse the console output to pass back to the main installer so it can manage the stages w/o user input.. having said that.. I *think* what you came across was more of a UAC-related symptom, and the extra steps you took wouldn't matter on pre-vista versions of windows... that is if I understand any of what I've read about inheritable object permissions and .net ok on to grabbing new version so I can try NO TO MOD
niveuseverto Posted February 18, 2014 Posted February 18, 2014 As Prideslayer mentioned few times (in comments in the source, and may be - here) so... I'm going to ask: is it necessary to continue support of .net 2.0 - 3.5 or it is ok to move to 4.0 - 4.5?
prideslayer Posted February 18, 2014 Author Posted February 18, 2014 Here's how I was envisioning it.. Locked mods will disable the prompt for overwrite and auto-magically select "No to overwriting files for the locked mod." Ending with a notification stating that the new mod attempted to overwrite files from the following locked mods (list) but overwrites were prevented due to lock. That does make more sense to me as well. Lets see what the kids think. pardon the multi-post to follow.. IE's not letting me paste into the response box... If you click the 'multiquote' button on each post a little box appears on the bottom of the screen that will start a reply with all of them quoted. As Prideslayer mentioned few times (in comments in the source, and may be - here) so... I'm going to ask: is it necessary to continue support of .net 2.0 - 3.5 or it is ok to move to 4.0 - 4.5? I don't think there's an OS that can run .net 2.0 that can't also run 4.0, is there? We'd have to scream in big letters that 4.0 is now required, but personally I don't think that is a big deal.
prideslayer Posted February 18, 2014 Author Posted February 18, 2014 1).. true... so while the 5gb TTW fomods would be hosed.. the ~1gb lings should work with the LAA bit flipped.. 1GB things will work without LAA, it's stuff over 2GB that doesn't. LAA tells the OS that the program is using unsigned values (0..+4GB) rather than signed values (-2GB..+2GB). having said that.. I *think* what you came across was more of a UAC-related symptom, and the extra steps you took wouldn't matter on pre-vista versions of windows... that is if I understand any of what I've read about inheritable object permissions and .net I don't think it was UAC related; I've never had to run FOMM as admin and never seen a UAC prompt when running it. It's just the fact that if a mod has an install script (script.cs) inside it, then FOMM will just execute that code -- that code is considered what's called "unmanaged" so it must be granted permissions explicitly by the parent process. I didn't realize that things as simple as reading environment vars are protected by that mechanism. The unmanaged code protection makes sense when I think about it, I just wasn't aware of how it worked.
nyaalich Posted February 18, 2014 Posted February 18, 2014 If you're going to lock the mods, I would think that you should get some output file (or something) to know which files the mod tried to change so that if you did want to change something manually you could. For example, SCR and Pregnancy. both have a pacifier iirc. While there probably isn't really a difference, you'd still want the latest one.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now