This is something that I'm wondering about. It may or may not require FOSE if it is even possible.

Let's say that someone's load order looks like this.

Fallout3.esm
Craft.esm
Calibr.esm
Fook2.esm
HappyMod.esp
OtherMod.esp

Fook2.esm has a record in it that modifies Object ID 0002d9cf.
Happymod.esp has a record in it that also modifies Object ID 0002d9cf.

Fook2.esm already has a special way to test, using in-game behaviors, to see if 0002d9cf is indeed the version that it personally has defined, as opposed with having been overwritten by any mod, be it HappyMod.esp or OtherMod.esp. It can easily get a yes or no answer on this.

Once Fook2.esm runs its little test and it knows that SOME mod has done this: Is there any way to extrapolate the fact that the mod that is in load order 04 (HappyMod.esp) is the culprit, as opposed with 05? I don't so much care about printing the numbers, I can make 255 little message boxes that tattle-tale on the mod. But the determination of which message box to send the player is another thing, I don't know how to do that.

As far as I know, there is no way to find out which mod(s) an item has been affected by via a script, unless you're trying to find out which mod it came from in which case you can use FOSE's http://fose.silverlock.org/fose_command_doc.html#GetSourceModIndex.

Aside from that function, there are only three more related to information on loaded mods:

• http://fose.silverlock.org/fose_command_doc.html#IsModLoaded
  
• http://fose.silverlock.org/fose_command_doc.html#GetModIndex
  
• http://fose.silverlock.org/fose_command_doc.html#GetNumLoadedMods

Cipscis

GetSourceModIndex seems like its like, almost, the function, sigh. But if I read you right, it's not quite what is needed. It sounds like, for 0002d9cf, it's going to report fallout3.esm as the source of the object, not the mod that is in control of its definition at the time.

If FOSE had a function that could do this, even if it required the script to be run from an .esp that was loaded last in the load order, it would be extremely useful. It would enable me to write an .esp which would identify gamebreaking conflicts with my mod, and tell the user exactly which mod was doing the breakage.You can bet I'd do that if the function existed in FOSE.

As certainly you and I already know - sometimes modders make changes to items or objects or scripts, maybe even insignficant changes, feeling like its such an obscure object that surely it couldn't destroy the function of another mod. But I find instances where that assumption was hell-wrong, and some user is trying to get Phalanx working for them, and it's malfunctioning, and they struggle to even find the offending mod. It is helpful that I can tell them (through script tricks) exactly WHAT is being broken by some other mod. But, the ideal thing would be if I could report back the index # (or hell, the name? but I'd take the index number and run with it).

mm.

Though this is not helping you at all, from a design-standpoint I think it would be not the best idea to do something like this on mod-level.
It should be done on the packaging layer (=> FOMM). If you're good with C# you could write an install script that goes through all installed mods and searches for conflicts on mandatory records, though this functionality would best be placed inside FOMM itself.

Having FOMM attempt to do exactly what I want would be a disaster because FOMM cannot detect which changes destroy my mod's functionality vs. the ones that are just cosmetic. There are conflicts and overrides all the time, but only specific ones are mod-breaking, and precisely those are the ones I want to tattle-tale on to the user. FOMM would have no choice but to report them all.

I was aware of that. Mandatory probably was the wrong word for it, I meant like the author specifies all exclusive records in the mod metadata, and then
1. Search all installed mods for conflicts with the new mods exclusive records.
2. Search all the exclusive records of all installed mods for conflicts with the new mod.
(3. Report)

This of course would require some additions to FOMM. A 'lightweight' version that doesn't require changes to FOMM would be doing it in an installation script, this can cover 1) but not 2).

It wouldn't be that hard to add this to FOMM, mod metadata is already used and I'm sure there are c# libraries around to read/manipulate records.

ohhhhhhhhh.

I've seen some sort of length limitation in GECK on that metadata, but that's not an obsticle if the mod author expects to have to edit the metadata in FO3edit as the final step before release.

If FOMM had such a function, I'd positively do a metadata entry for such a thing.

FOMM's own metadata could be used for this. The one that you can edit with "Edit info" in the package manager, internally it's an XML file that comes with the mod. This editor that FOMM uses to edit the meta data could have another field Exclusive Records, which contains all records of the mod and a checkbox before it, and the mod author could simply check the ones that are supposed to be exclusive.

Now when I said it wouldn't be hard to implement, primarily I meant it would be hard for the FOMM devs to add such a thing, considering FOMM already has all kinds of sophisticated functions that are much more complicated then simply going through some records and comparing them.

Thread linked into the FOMM RELz thread! That sure would pwn.

If I understand correctly, you want to specify a list of form ids that FOMM will warn the user about if they are overridden?

Yes.
Allowing me to comment to the user what/why/etc this particular form ID is about would be nice but it's not necessary I guess =p

http://www.gamesas.com/index.php?/topic/1037768-relz-fallout-mod-manager/page__view__findpost__p__15792663. Let me know if it makes sense, and does what you want.

It's there! It seems to be what I was asking about - - I'll grab it soon and try it

Edit: This is kinda weird... it seems related to the installation, specifically.. like, Fallout Mod Manager has to be the program that is installing your mod for this to work? And when it does that, it follows script instructions, and in there I guess it's possible to specify the formIDs.. I'm not really sure.

I've never used this function of FOMM. I install all mods by hand and just use FOMM if I want to move the load order around. I've never wanted any program to do installation functions for me.

I don't really understand the final effect this will have - - if the anolysis is only available upon installation of the mod in question, or what. That's kinda what it sounds like but I don't know for sure. What I had envisioned when the idea came up was, like, something I would encode in the .esp (or somewhere, I don't care where really) and where the user of FOMM could at any time click a button, and, FOMM would report "Hey, Phalanx-MainFollowerModule says it needs exclusive control over 0002d9cf but Add-1-INT-to-Fawkes.esp, which is loaded before it, has a record for it". The metadata of the .esp itself seemed like the right place to stash the data at the time.

I don't quite see how it all fits in, at this point.

As schlangster suggested, I created a mechanism by which these "critical records" could be specified in the info file of a fomod. Given that FOMM is a fomod manger, doing otherwise might be outside of it's pervue (maybe more appropriate for another tool). That's not to say that other options can't be considered, just that the info file makes the most sense as a starting point for FOMM.

In order to specify critical records:

• Open the package Manager.
  
• Select the mod for which you would like to specify critical records.
  
• Click "Edit Info."
  
• Click "Set Critical Records."

FOMM has to have installed the mod that specifies the critical records. Everything else (barring any bugs) can have been manually installed or installed with FOMM.


FOMM doesn't scan on startup or install; doing so would have introduced large slowdowns, as scanning of this sort is not quick. There is a button on the main window of FOMM labelled "Check for Conflicts." Pressing this button launches the critical record anolysis. Upon completion, any plugins whose critical records have been overridden are highlighted red, and selecting a red plugin will show the user what the conflicts are in the info window under the plugin listing.

Well, I think I understand, now. I did not understand that FOMM worked this way and that the new function is tied to FOMM being like, a package manager.

I'm certain that this will be helpful for some people, and I'm glad it is there. I'm not sure what I can do with it personally for my own mod, but its still good.

Do you have a link to some documentation talking about plugin metadata? I took a quick look around but couldn't find anything.

Here is all I know about it:

An easy way to see it is to run FOMM and in the main screen, click the mod. There's a text box at the bottom of FOMM, and it will have data in there.

Like. here is what CALIBR looks like:

CALIBR.esmAuthor: TubalDescription:Community Ammunition LIBRary: CALIBRVersion 1.3Please refer to the readme.Masters:Fallout3.esm

One of the text fields in there might be "Description" and that's the one that could carry this sort of data.

In FO3edit, you can see it by clicking "file header" right under the mod name on the left, and then you look on the right for "SNAM - Description".

The description field has a max length of 512 bytes, which is not much. Further, I am hesitant to hijack a filed that is used by other tools for something so specific. What if we used a message instead? For example, if a plugin contains a message with the name "fommCriticalRecords" then I can assume it contains the metadata I'm interested in, and use it to perform the collision scan. Does this seem reasonable?

Sure, that could work.

On that length limit - - I'm aware that GECK tries to enforce a limit, but I've also seen where FO3edit can make that field have more than the max data in i and it doesn't seem to break, except GECK complains. At least one of the versions of MMM did this. But what you said with the extra, dedicated file seems that it would work just as well.

I'm not sure if it was a typo or not, but I just want to clarify my last post. I'm not talking about a separate file, but a MESG record called fommCriticalRecords that is put in the actual ESP/esm file.

oh... can that work?
ohhh wait I see

oh!!!!!

Yeah!!!!! If it'll work?

I meant to post this here last night, but it slipped my mind. Sorry.

I've released a http://www.gamesas.com/index.php?/topic/1037768-relz-fallout-mod-manager/page__view__findpost__p__15809643. It incorporates the critical records changes we discussed here. In a nutshell, it works as follows.

In order to specify critical records in a plugin, that plugin must have a message (MESG) record whose editor id (EDID) is fommCriticalRecords. That message is to contain the critical record data in the following format:

    ...

where:

• is the 8 digit hexadecimal form id of the critical record
  
• is 0 for Info, 1 for Warning, or 3 for Critical
  
• is the message displayed to the user if the specified record is conflicted.

For example:

000f4c54 2 This is a level 2 severity, meaning it may not break, but you should be on the lookout.03d3ab51 3 This is a full on breaking conflict.

Note that the must be the actual form id of the record, which is not always displayed in FO3Edit (FO3Edit sometimes displays the form id of the record that is being overridden, instead of the form id stored in the plugin). As part of this addition to FOMM, I have also included a critical records editor, called CREditor. It is accessible through the Tools manu, or by right-clicking on a plugin in the main window.

In order to detect conflicts, the user must click the "Check for conflicts" button in the main window. FOMM will then scan for conflicts, and highlight any conflicted plugins. Selecting a conflicted plugins will display the details in the meaages window below the plugin list.

Hopefully this does what you were wanting. Let me know what you think.

This sounds like a great feature, but I'm confused on this bit:


I wasn't aware that an override record had it's own FormID. I just checked in TESsnip, and it also displays the FormID of the record being overridden. Where would we find the "real" one?

I probably should have been more clear. (You likely know everything I'm about to say, but I just want to make sure I'm explaining myself).

Forms Ids are represented as 8 digit hex number, of the form xx000000. The 000000 part represents a unique number specifying the record. The xx part referes to where the record is coming from. Let's assume a mod has 2 masters. In this case, Form Ids starting with 00 are overriding records from the first master, Form Ids starting with 01 are overriding records from the second master, and Form Ids starting with 02 (or anything larger) are new records that aren't overriding anything.

Let's look at an example. Anchorage.esm has a record with Form Id 0200452B; it's DLCAnchT51DisplayArmor01. Anchorage.esm only has Fallout3.esm as a master, so the 02 indicates that this is a new record, and not an override. Unofficial Fallout 3 Path - Operation Anchorage.esp overrides this record. If you use FO3Edit to look at the record in Unofficial Fallout 3 Path - Operation Anchorage.esp, you will be told that the Form Id is 0200452B. However, as Unofficial Fallout 3 Path - Operation Anchorage.esp only has 2 masters, the 02 would imply that this is a new record, when it is clearly not. That's because 0200452B is not the "real" Form Id in Unofficial Fallout 3 Path - Operation Anchorage.esp. If you use TESSnip to look at the record in Unofficial Fallout 3 Path - Operation Anchorage.esp, you will see that the Form Id is actually 0100452B, meaning that it is on averride of a record from the file's second master (which is Anchorage.esm). This is the "real" From Id.

Again, if you use CREditor to select critical records, you don't need to worry about any of this as it's taken care of for you. This is only a consideration if you want to define critical records by hand (which is a reasonable and not overly difficult task).

Hopefully I've answered your question. If you need further clarification, or have any other questions, let me know.

Well, I understand what you're saying here, but I'm still confused because I don't think I've ever seen anything except what we're calling the "real" FormID - that includes TESSnip, FO3Edit, and the GECK.