.esm or .esp ?? Does anything frigging work?

[davidlallen]

Your steps say to start with a 62 kB file, and you finish with a 22 MB file. This seems like 22 MB of overhead. Please upload the 22 MB file for FNV and we will take a look. You can assume we know how to use fnvedit to see what has changed.

[ccmechanic2]

This is certainly interesting, but as far as I know none of the quest mods distributed at newvegasnexus use this (based on filesize) and there has not been any mention of this during the six months I have been in these forums and the bethsoft forums. Where did you learn about this?

 

Do any of the other experienced modders here have any thoughts about this? It seems unlikely that a mod with one internal room changed, needs to have 22 MB of other stuff along with it. The effect seems similar to the "recompile all scripts" button, which we have been told to never use.

 

BTW it is very easy to post screenshots; click the "use full editor" button and then click the "attachment" button. Fortunately your descriptions are clear enough that screenshots aren't needed to follow your description.

I would sum this up as generalized complatency on the whole. Even the company doesn't go to places I go. They can't afford to waste time. See, thats where things like this get lost. The slate is indeed laird out here. Being this location where the data resides, I would suggest you folks get your copies while it's here. No telling when it may disappear!<< look at that, talking in rhymes for the times.

[ccmechanic2]

Your steps say to start with a 62 kB file, and you finish with a 22 MB file. This seems like 22 MB of overhead. Please upload the 22 MB file for FNV and we will take a look. You can assume we know how to use fnvedit to see what has changed.

sorry 462 I thought something looked strange there, Correction (462kb) To (22,491kb) is that more to your liking?

[ccmechanic2]

I will post them on NVnexus when I finish the documentation. The first package will consist of My work On the stabilizer mod I made and am still compiling further with a second generation of the mod/ control file. WIP as always But as in the fo3 version , all stats remain the same.

Just a different game. Also in the package will reside the finalized mod/product as stated here for you scrutiny and use. Not to be re uploaded ar changed in any way. I will include a read me with the layout as seen here on the thread just encase some for get to copy it. A very short guide . This after noon. Right now I need sleep.

[davidlallen]

sorry 462 I thought something looked strange there, Correction (462kb) To (22,491kb) is that more to your liking?

This doesn't change anything; it still gets larger by 22 MB. I don't think I will try the steps you wrote up since it would make my PC unusable for almost a day; but if you are interested to upload the file which you already created with these steps, I am sure many people would be interested to look at it.

[tunaisafish]

@ccmechanic2

 

I apologize for thinking you were winding us up. Although I am still very skeptical of this method, I do appreciate that you are genuinely convinced with your theory.

 

I did run your steps to the letter. Took about 20 mins to complete and the file increase was about 22Mb as you said.

This was on a 400kb mod that didn't actually alter or add items to any cells.

 

Viewing in FNVEdit showed that it hadn't altered any of my resources at all. It just added 22Mb worth of cell/worldspace portal & navmesh data.

 

Then using FNVEdit to remove 'identical to master records' -> 12918 records were deleted and the filesize dropped by ~19Mb.

I took a *quick* look at the remaining 3Mb of generated data. I didn't notice any differences in the portal data. I'm not sure but it looked like none of these records were removed. On the navmesh data that was kept, the only difference I noticed was a flag labelled as 'unknown' was changed from 0 to 3, while coordinate data was identical.

 

For all I know, included in that data were the fixes to the original Bethesda data (Those times when you companions charge off and take the 'long route'). But it would probably be easier to edit those areas directly if somebody intended to fix them.

 

So if I'd have run this on a say, a mod of an interior cell, and the esp was last in somebodies load order. It would revert the whole wasteland portals and navmeshes to close to the original. Effectively undoing other modders work on those resources.

 

I look forward to seeing some of your research and tutorial on this. I'd suggest avoiding the 'blanket' navmesh commands though and concentrate on advocating use of the targeted commands that only act on the cells the user has actually editted. Using FNVEdit afterwards to remove 'identical to master records' would be a useful step near the end.

 

Good luck, and I've got my fingers crossed your studies will shed more light on the original problem of this thread.

 

My problem: navmeshes in .esp file are evidently know to be sketchy.

... and why just setting the master flag fixes this?

[rickerhk]

I don't think any of this has anything to do with the OP.

The quest is not going to stop working just because you set the esm flag.

The quest is going to stop working because there are result script errors, and apparently the script engine is more strict in regards to references marked as persistent in an esm than they are in an esp. I just went through someone else's quest mod with this very same problem, with the Geck Powerup enabled, and fixed my copy of it so that it works with the esm bit set.

It appears that without GP, result scripts will save even if referencing objects that don't have the 'persistent' flag set.

[davidlallen]

Thank you for dragging the thread back on topic. The problem you mention is that geck will let you save an esp which contains errors, when a script references an item which is not persistent. The esp will work correctly. But when you convert to esm, the same code no longer works correctly. Do I understand?

 

For both of my mods, I have done most of the work and testing using esp, then converted to esm at the last minute. I did not play through all the different test scenarios again after converting to esm. It seems "possible" I may have missed something.

 

I have geck 1.3 and Geck Powerup for 1.3 and I have verified that it gives popups on errors. Suppose I have Geck Powerup turned on, and I load my esm and save it in geck, and no errors pop up. Am I safe from this problem you describe? Having to go through each quest topic and click seems very tedious. Will fnvedit catch this type of error with the "Check for Errors" menu choice?

[Quetzlsacatanango]

Sounds like you have it right. I don't think fnvedit will catch (or at least 'alert' you somehow) or else we would have noticed it before now. I think the only time you will actually have a problem is if you do some enabling of non-persistent refs via a result script box. Vanilla geck will not catch this, and will allow you to save/compile just fine. Doing it any other way, like object or quest script, you will not see the issue because geck will not let you save, even though it doesn't tell you what the problem is.

 

When you get into game, the game treats esps "improperly" as well, and these instances will function, even when it seems like they shouldn't. But when you make it an esm, it treats them properly and they don't work.

 

Simple :wacko:

Edited May 10, 2011 by Quetzlsacatanango

[ccmechanic2]

@ccmechanic2

 

I apologize for thinking you were winding us up. Although I am still very skeptical of this method, I do appreciate that you are genuinely convinced with your theory.

 

I did run your steps to the letter. Took about 20 mins to complete and the file increase was about 22Mb as you said.

This was on a 400kb mod that didn't actually alter or add items to any cells.

 

Viewing in FNVEdit showed that it hadn't altered any of my resources at all. It just added 22Mb worth of cell/worldspace portal & navmesh data.

 

Then using FNVEdit to remove 'identical to master records' -> 12918 records were deleted and the filesize dropped by ~19Mb.

I took a *quick* look at the remaining 3Mb of generated data. I didn't notice any differences in the portal data. I'm not sure but it looked like none of these records were removed. On the navmesh data that was kept, the only difference I noticed was a flag labelled as 'unknown' was changed from 0 to 3, while coordinate data was identical.

 

For all I know, included in that data were the fixes to the original Bethesda data (Those times when you companions charge off and take the 'long route'). But it would probably be easier to edit those areas directly if somebody intended to fix them.

 

So if I'd have run this on a say, a mod of an interior cell, and the esp was last in somebodies load order. It would revert the whole wasteland portals and navmeshes to close to the original. Effectively undoing other modders work on those resources.

 

I look forward to seeing some of your research and tutorial on this. I'd suggest avoiding the 'blanket' navmesh commands though and concentrate on advocating use of the targeted commands that only act on the cells the user has actually editted. Using FNVEdit afterwards to remove 'identical to master records' would be a useful step near the end.

 

Good luck, and I've got my fingers crossed your studies will shed more light on the original problem of this thread.

 

My problem: navmeshes in .esp file are evidently know to be sketchy.

... and why just setting the master flag fixes this?

On your test file, before and after, did you run fnvedit check for errors on both. Deleting objects on the 22mb file you should have found a ton of errors after wards.

Edited May 10, 2011 by ccmechanic2