Oops. The link was wrong and has now been http://fallout3nexus.com/downloads/file.php?id=637.

I've done some additional experiments with removing NAVMs and it appears that simply opening the plugin in GECK afterwards and saving it again will correctly remove that invalid entries from the Navigation Mesh Info Map.

Almost slipped by unnoticed (thankyou RSS) and thankyou ElminsterEU

This is something trivial, but is like fingernails on a chalkboard for me

Could you please change the line in the OP from



to



Thanks

@Tyana Rie
That made me laugh so much i fell off my bed.
You must LOVE mobile texting
and the internet for that matter...

Done... and in the 50 other places it occurred as well. But I'm NOT going through the trouble of building another release for a spelling error. So you'll have to wait for whenever there are enough updates to justify another public release to get it fixed in the exe...

I've just uploaded version 2.2.5 EXPERIMENTAL to http://fallout3nexus.com/downloads/file.php?id=637.

This version adds a very experimental implementation of list merging.

After FO3Edit has loaded, right right click into the left hand navigation treeview and select "Create Merged Patch". Then enter a new filename when asked.

After a couple of seconds you should see this newly added file in the navigation treeview.

Please review all records in this file very very closely and report any case where you think FO3Edit this something wrong (a screenshot would be helpful) and an exact description why you think it's wrong and what you would have expected to happen instead.

Currently the following record types and lists are processed:

	CheckGroup(GroupBySignature['LVLI'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVLC'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVLN'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVSP'], 'Leveled List Entries');	CheckGroup(GroupBySignature['CREA'], 'Items');	CheckGroup(GroupBySignature['NPC_'], 'Items');	CheckGroup(GroupBySignature['FACT'], 'Relations');

Hmmm... not happy with ScripterRon's list merging methods?

I'll try both Thanks for the update

I haven't tried FO3Plugin, but from the description it seemed to me that the list merging requires a lot of manual steps if you want to get a full merge taking into account your complete load order.

With FO3Edit, it automatically loads exactly the same modules in the same order as the game engine would and it takes you 2 clicks plus typing in a filename to generate the merged patch plugin.

Sounds easy I like easy.

That's it? 38 downloads and not a single line of feedback about the list merger? Seriously? Is it working so perfectly for everyone?

FO3Edit has a list merger now? Sweet!

Gonna give it a spin when I get home.

Can it auto-detect master override conflicts in the lists? The one that ScripterRon didn't IIRC.

Let me try to verbally describe the merging algo used:

• make a list with all entries from the master record, designate as TargetList
  
• repeat for each existing override record:
  • determine the file containing this override record, designate as CurrentFile
    
  • make a list with all entries from that override record, designate as CurrentList
    
  • go through the list of master files for CurrentFile, from last to first, stop when the first is found containing an override for this record, designate as CurrentMaster
    
  • make a list with all entries from CurrentMaster, designate as CurrentMasterList
    
  • going over CurrentList and CurrentMasterList, for each entry that:
    • exists only in CurrentList, add this entry to TargetList if not yet present
      
    • exists only in CurrentMasterList, remove this entry from TargetList if present
  
  
• make a list with all entries from the winning override record, designate as WinningList
  
• compare TargetList and WinningList, if different:
  • copy the currently winning record as override into the new file, designate as TargetRecord
    
  • remove all list entries from TargetRecord
    
  • go over TargetList and for each entry add a new entry to TargetRecord

And here is the "make a list" algo (as it applies to leveled list entries) which is also important to understand what's going on:

• for each entry, generate a string representation including: Level, Reference, Count, Item Condition, Owner, Owner Rank
  
• sort generated list of strings
  
• walking over the sorted list, add numbers to duplicated entries, so suppose you have a list: A, B, B, C, D, D after this step it will be A#0, B#0, B#1, C#0, D#0, D#1

I've started a new thread with a very important question:

http://www.gamesas.com/bgsforums/index.php?showtopic=971140

The final answer to that question fundamentally decides if Form List merging is possible at all, and if yes, how it is to be done. Please participate in that discussion if you have any relevant input.

I've just uploaded version 2.2.6 EXPERIMENTAL to http://fallout3nexus.com/downloads/file.php?id=637.

This version further extends the experimental list merging implementation.

Please read the release notes for version http://www.gamesas.com/bgsforums/index.php?s=&showtopic=915003&view=findpost&p=14023046 if you haven't done so already.

Also, a couple of posts http://www.gamesas.com/bgsforums/index.php?s=&showtopic=915003&view=findpost&p=14027492 is a description of the merging algorithm that's being used.

This version now processes the following record and list types:

		CheckGroup(GroupBySignature['LVLI'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVLC'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVLN'], 'Leveled List Entries');	CheckGroup(GroupBySignature['LVSP'], 'Leveled List Entries');	CheckGroup(GroupBySignature['CREA'], 'Items');	CheckGroup(GroupBySignature['CREA'], 'Factions');	CheckGroup(GroupBySignature['CREA'], 'Actor Effects');	CheckGroup(GroupBySignature['NPC_'], 'Items');	CheckGroup(GroupBySignature['NPC_'], 'Factions');	CheckGroup(GroupBySignature['NPC_'], 'Actor Effects');	CheckGroup(GroupBySignature['CONT'], 'Items');	CheckGroup(GroupBySignature['FACT'], 'Relations');	CheckGroup(GroupBySignature['RACE'], 'Hairs');	CheckGroup(GroupBySignature['RACE'], 'Eyes');	CheckGroup(GroupBySignature['FLST'], 'FormIDs', True);

This version also introduces an important change in the handling of FLST records. Till now the FormIDs list was considered to be an ordered list. From now on it is considered to be a set. This has a number of consequences:

• the list is always displayed ordered by FormID now
  
• it is no longer possible to move a specific FormID up or down the list
  
• in the detail view the FormIDs are now lined up in the same way as leveled list entries and other sorted lists.
  
• When a FLST record which has been modified is saved, the FLST will be saved sorted by FormID

For any list for which this behavior is not wanted you will have to ensure that the EditorID of the master record ends in OrderedList, e.g. "ABCOrderedList". Any such FLST will continue to be treated as it was before and will not participate in Form List merging.

Please make sure to perform this renaming with GECK or an older version of FO3Edit. Doing it with the current or a newer version will empty the list (whenever a rename results in a change of status from Set to OrderedList or back).

I really need feedback on how well this list merging is working for you!

Out of 54 downloads for the last version I've received exactly 0 feedback on the list merging.

ElminsterEU,

I haven't had a chance to work on my borg.esm/p in a about a week, but I should have some time tonight... Since I rely on FO3E I'll get you some feedback when I muck about with it.

Mynex

You've named your assimilator plugin BORG.ESM as well? Awesome!

[00:22] Background Loader: [BORG.ESM] Header processed. Expecting 4652 records

@Elminster: I've tried making a Merged Patch plugin a few times and it seems to be working rather well. I'll tinker with it more and have more useful feedback later, but this is awesome, like a bash patch for FO3! HUZZAH!

I have used version 2.2.5 to make a "merged lists" patch, and it worked great. Will update to the latest version, and see if anything changes.

One thing I would request though, is give the ability to overwrite the patch. Sure, creating a new one each time is not that much trouble, but, having to delete the old one, might cause some folks trouble.....

I still need to try it... I got home later than usual yesterday and then was trying to finish a mod. I will though

The current implementation is just a quick hack to test the viability of the implemented merging algorithm. Once I've sufficient feedback to decide that I plan to make it more user friendly and probably also provider a simple fire and forget program similar to how TES4LodGen operates that can be started to automatically produce (and replace if already existing) a patch plugin.

Excellent. And, for a "quick hack" it sure works good..... Will test the new version created patch later today. Currently downloading the pitt, so, once that is done, off I go.

Thank you very much for this extremely useful tool. :goodjob:

Just did a "stress test" of sorts. I modified my WMK personalization mod (separate plugin slaved to the main WMK one) to include all the WMK energy weapons into the ExplodesGasTrapsOnHit form list. It successfully included them all when I generated the patch, in addition to my YK40 pulse pistol.

Heh, yea I did. Because of you, you dirty modder you!



Elminster - More user friendly is always good. But it seems to work well. I merged 44 mods together, 13 with some type of leveled list and I didn't get any errors/crashes/funkiness from that...

I haven't had a chance to test it 'live' in a game yet to see if there's any issues in game, that's for tomorrow since I'm still merging mods.

Mynex

I wouldn't expect any crashes.

What I need you and everyone else who is trying this to do is to LOOK at every single one of these generated merged records and THINK about what the implications of this particular merged versions are and then REPORT anything you see where you think the merge process produced a result that is not true to the INTENTION of the original mods which have been merged.

Finding any design issues in the merging algorithm is not something that can be automated or that's going to show up in a 5 minute play test. It requires the combination of a (preferable 2) Mark I eyeball on target and a Mark I brain.

This is kinda my concern about the tool in general -- it would be good if it came with a big fat disclaimer 'DO NOT USE THIS FEATURE UNLESS YOU INTEND TO GO OVER THE RESULTS. IF YOU ARE LAZY, THIS IS NOT FOR YOU'.*

* and lets face it, this will be 99% of people who use it. Most people don't even read READMEs, and then complain when they get issues. *smacks head*

Overring entries merged won't produce any errors and won't, unless it's a serious conflict, show up quickly or easily in someone's game -- but then down the track there will be problems, quests breaking or games not saving, or they'll post bugs that are impossible to track down because they've gone and merged nine mods and produced a bastard mutanted son of Frankenstein .esp that screws up all nine. Or something.

I should clarify: I am incredibly enthusastic for the tool, but only in the hands of modders and not users who don't know what they're doing (and who might prefer not to break their game if they were aware they could do so).