Turija Posted June 23, 2016 Share Posted June 23, 2016 Just thought I'd point out that xEdit says the no auto calc flag for ingestibles is "unused". That's not entirely accurate. The no auto calc flag is used to determine price when the effects added to ingestibles is given a duration greater than 1. you can get some crazy high prices if that flag is not set and you give ingestibles an effect that lasts for a few seconds. Link to comment Share on other sites More sharing options...
Sharlikran Posted June 23, 2016 Share Posted June 23, 2016 Is that for Fallout 4, Skyrim, or something else Turija? Link to comment Share on other sites More sharing options...
Turija Posted June 23, 2016 Share Posted June 23, 2016 Is that for Fallout 4, Skyrim, or something else Turija?Skyrim. Link to comment Share on other sites More sharing options...
zilav Posted June 23, 2016 Author Share Posted June 23, 2016 Skyrim. Those flags were copied from New Vegas definitions, looks like we forgot to update them. Link to comment Share on other sites More sharing options...
Sharlikran Posted June 24, 2016 Share Posted June 24, 2016 I was looking for differences in a plugin for Fallout 4 and I ran across something that to me is stupid. The CK changes the Model record in Static Collection even though I haven't made any changes to the NIF. So for Fallout4.esm it's "SCOL\Fallout4.esm\CM00140617.NIF" and for the plugin it's "SCOL\Homemaker.esp\CM000011B2.NIF". However, once I am done making changes in the CK I am going to set the ESM flag and rename the file to Homemaker.esm which I would think will mess that up. Since I can't write scripts, I have tried and I fail a lot during my attempts, is there a script that comes with FO4Edit that will pull that value from Fallout4.esm? EDIT: I just noticed something else. The FormID of these records does not reference Fallout4.esm at all. So you can't say, look at Fallout4.esm FormID xx0011B2 and change "SCOL\Homemaker.esp\CM000011B2.NIF" to "SCOL\Fallout4.esm\CM00140617.NIF". The FormID of the Static Colection in Fallout4.esm is not xx0011B2 it's xx140617. Why is the CK rebuilding or copying the unmodified Static Collection and changing the FormID suffix pointing to it? Link to comment Share on other sites More sharing options...
Arthmoor Posted July 1, 2016 Share Posted July 1, 2016 Any chance you guys might upload the current 3.1.3 over on the Skyrim side? That one fix for the NPC attack values is kind of important and it should be made available via the expected channel for Skyrim tools. Link to comment Share on other sites More sharing options...
Roy Batty Posted July 1, 2016 Share Posted July 1, 2016 LODGen is broken again with tree's and other objects in custom worldspaces. Also, it's been two weeks since any acknowledgement of issues on the bug tracker, everything OK over there? Link to comment Share on other sites More sharing options...
zilav Posted July 1, 2016 Author Share Posted July 1, 2016 Any chance you guys might upload the current 3.1.3 over on the Skyrim side? That one fix for the NPC attack values is kind of important and it should be made available via the expected channel for Skyrim tools. It is not finished on FO4 part and I prefer simultaneous release for all games. LODGen is broken again with tree's and other objects in custom worldspaces. Also, it's been two weeks since any acknowledgement of issues on the bug tracker, everything OK over there? Need more information on what is broken and where, steps to reproduce. You should know that simply saying "not working" doesn't help at all. Development is a bit slow during summer for obvious reason. Link to comment Share on other sites More sharing options...
Nebulous112 Posted July 1, 2016 Share Posted July 1, 2016 Does the NPC attack values bug affect conflict resolution patches carrying over such values? I'm just wondering if CR patches like the STEP patch and SR:LE patch should be rebuilt with the latest alpha version or if that is unnecessary. Link to comment Share on other sites More sharing options...
zilav Posted July 1, 2016 Author Share Posted July 1, 2016 Does the NPC attack values bug affect conflict resolution patches carrying over such values? I'm just wondering if CR patches like the STEP patch and SR:LE patch should be rebuilt with the latest alpha version or if that is unnecessary. You must be very unlucky for this issue to affect anything. Even Arthmoor noticed it only several years later after xEdit first release and only because unoffficial patch has to edit that unlucky value. And even if that issue crops on you, you probably will never notice it in game. That's why this issue has remained undiscovered for so long. 1) A mod must override NPCs that inherit attack data from template NPC 2) A mod must toggle some attack data entries to be overrides of templated ones 3) A mod must NOT change anything else in overriding attack data itself Link to comment Share on other sites More sharing options...
dAb Posted July 1, 2016 Share Posted July 1, 2016 Is the current 3.1.3 safe for use with Skyrim? Link to comment Share on other sites More sharing options...
Roy Batty Posted July 1, 2016 Share Posted July 1, 2016 Need more information on what is broken and where, steps to reproduce. You should know that simply saying "not working" doesn't help at all. Development is a bit slow during summer for obvious reason. I neglected to send you a PM. Did so now on nexus. Link to comment Share on other sites More sharing options...
zilav Posted July 1, 2016 Author Share Posted July 1, 2016 Is the current 3.1.3 safe for use with Skyrim? Should be. However I spend most of dev time in FO4Edit mode now, so can't say for sure. There were no issue reports so far regarding previous games though. Link to comment Share on other sites More sharing options...
Arthmoor Posted July 2, 2016 Share Posted July 2, 2016 Does the NPC attack values bug affect conflict resolution patches carrying over such values? I'm just wondering if CR patches like the STEP patch and SR:LE patch should be rebuilt with the latest alpha version or if that is unnecessary. It can affect them, yes. Is the current 3.1.3 safe for use with Skyrim? It is. That's what we used to repair USLEEP once the bug had been fixed. @zilav: That's why I was asking if you could put up the Skyrim side. The current FO4Edit code has that fix in it already in a Nexus release. Link to comment Share on other sites More sharing options...
zilav Posted July 2, 2016 Author Share Posted July 2, 2016 It can affect them, yes. @zilav: That's why I was asking if you could put up the Skyrim side. The current FO4Edit code has that fix in it already in a Nexus release. When I finish with FO4Edit. I don't consider this issue serious, like I said there must be some very unlikely conditions to happen together 1) The value of flag is preserved, it is just not visible and so affects only "filter for cleaning" and removing ITM records 2) That flag must be set and record must not modify anything else in the attack data otherwise there will be visible conflict and record is no longer ITM. There should be also no other changes in the same NPC_ record for the same reason. I mean, what's the point of overriding attack data of template NPC and not changing it at all apart from creating intentional ITM? I still don't understand why USLEEP does it. I can even bet money that there are no such mods on Nexus at all because it makes no sense. Link to comment Share on other sites More sharing options...
Arthmoor Posted July 2, 2016 Share Posted July 2, 2016 I think you've gotten a bit confused USLEEP isn't intentionally editing anything with those. The problem in our case is that USLEEP lost the edits Bethesda had made. Which we had to restore since the parts we DID change had nothing to do with that subrecord. Link to comment Share on other sites More sharing options...
zilav Posted July 3, 2016 Author Share Posted July 3, 2016 I think you've gotten a bit confused USLEEP isn't intentionally editing anything with those. The problem in our case is that USLEEP lost the edits Bethesda had made. Which we had to restore since the parts we DID change had nothing to do with that subrecord. The value of that flag is not lost, it is just hidden when viewing and doesn't participate in conflicts resolution. Such hidden flags are preserved when saving a plugin in xEdit. Read my previous post about the tests I performed. No idea how did you lost anything in USLEEP, but that involved something else. The only way to lose that flag is like I mentioned above: clean ITMs when this flag is the only changed value in NPC_ record. Link to comment Share on other sites More sharing options...
Arthmoor Posted July 3, 2016 Share Posted July 3, 2016 I explained it to you when it was initially reported. The flag DOES get lost, because the CK drops the data if the mod is saved again after xEdit touches it. We went over this already Anyway, if you're going to update the Skyrim entry for it soon, no biggie. Link to comment Share on other sites More sharing options...
zilav Posted July 3, 2016 Author Share Posted July 3, 2016 I explained it to you when it was initially reported. The flag DOES get lost, because the CK drops the data if the mod is saved again after xEdit touches it. We went over this already Anyway, if you're going to update the Skyrim entry for it soon, no biggie. All my tests showed that it is not true. If that flag is set in CK, then saving this mod in xEdit won't remove it regardless if record was modified or not, and I'm 100% condifent on this (I used "Mark Modified" option on a CK plugin with flag set). However if you try to copy a record in xEdit with that flag, it will be lost. This also includes drag&dropping attack data between records. This is why I don't consider this to be a serious issue. Link to comment Share on other sites More sharing options...
Arthmoor Posted July 3, 2016 Share Posted July 3, 2016 All my tests showed that it is not true. If that flag is set in CK, then saving this mod in xEdit won't remove it regardless if record was modified or not, and I'm 100% condifent on this (I used "Mark Modified" option on a CK plugin with flag set). However if you try to copy a record in xEdit with that flag, it will be lost. This also includes drag&dropping attack data between records. This is why I don't consider this to be a serious issue. I guess you and I have different definitions of "serious issue" because to me, data loss is serious regardless of what the method for causing it is. I can tell you with absolute certainty that we did the NPC edits originally in the CK and that somewhere along the way after that, other stuff was done and the flags got lost WITHOUT touching the NPC records. Then the CK dropped the data when it got saved again for whatever reason. Link to comment Share on other sites More sharing options...
zilav Posted July 4, 2016 Author Share Posted July 4, 2016 I guess you and I have different definitions of "serious issue" because to me, data loss is serious regardless of what the method for causing it is. I can tell you with absolute certainty that we did the NPC edits originally in the CK and that somewhere along the way after that, other stuff was done and the flags got lost WITHOUT touching the NPC records. Then the CK dropped the data when it got saved again for whatever reason. "...somewhere along the way after that, other stuff was done..." this is a very vague information of what was done and how. Like I said you need to copy or drag&drop attack data to trigger the bug in xEdit. Computers are digital and computational results are deterministic, it can't lose the flag for you but not for me when simply saving a plugin Maybe you discovered another bug in CK similar to how it easily loses script properties when saving. Link to comment Share on other sites More sharing options...
Arthmoor Posted July 4, 2016 Share Posted July 4, 2016 No, I didn't discover another bug in the CK. I outlined precisely what was done. An NPC was edited in the CK at some point. At some later point, xEdit saved the file and the flag was lost. Maybe it was due to a cleaning, maybe not, neither of us seems to be able to say for sure, but the only constant in this is that xEdit was definitely responsible for losing the data. I don't even know why we're arguing about it when a simple upload to the Skyrim file entry would solve the issue I brought up the other day Maybe I should have just done it myself since you guys gave me access to the entry Link to comment Share on other sites More sharing options...
zilav Posted July 5, 2016 Author Share Posted July 5, 2016 I don't even know why we're arguing about it I don't think we are really arguing here, just talking about different things from different point of view. You talk as user of application, I talk as a programmer. I simply outlined the precise conditions to trigger the bug as it as now with the older version on nexus. But as you said, you don't remember what have happened with your plugin "somewhere along the way". I have no doubt that the flag gone missing in your particular case, ITM cleaning could do that if that flag was the only change in NPC_ record and thus xEdit ignored it for conflicts resolution. Maybe you set that flag in CK but didn't change the attack data itself, then switched to something else, then cleaned a plugin along the way and the flag got lost. The only difference in our opinins is if this issue a serious bug and worth the forced update now or not. You think it is serious because it affected you personally which is understandable point of view. I don't think it is serious because from technical point the conditions triggering the issue are very specific and normal plugins should not override attack data in NPCs without changing that data. I might as well just mark that flag as ignored for conflicts resolution and force xEdit to always clean it anyway if there are no other changes. Overridden unmodified atrack data doesn't make sense unless mod author wants to create intentional ITM, it is most likely an erroneous/wild edit and should be cleaned out. Link to comment Share on other sites More sharing options...
Arthmoor Posted July 5, 2016 Share Posted July 5, 2016 Dude. Really? You're now claiming it was an erroneous wild edit when I gave you the specifics of what happened and pointed it out in clear terms? Erroneous my butt. It was an intentional change introduced by Bethesda in their DLC which xEdit lost due to a bug because you said at the time you didn't even know about this flag. I'm sorry if I'm coming off as a bit angry at this point but unless I'm hallucinating things here, your explanation for this is changing with each post you make about it and I think that's a BAD THING. Link to comment Share on other sites More sharing options...
zilav Posted July 5, 2016 Author Share Posted July 5, 2016 Edit: removed everything written here. Pushed the new 3.1.3 update on Skyrim Nexus because whatever. I don't want to talk about this anymore. Link to comment Share on other sites More sharing options...
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