Oblivion Mod talk:Mod File Format/GMST

Formid Assignment

It actually looks as if the only GMSTs that get a new FormID after a change are those that do not exist in Oblivion.esm. See this thread for details. Can anyone else confirm this?--Dev akm 15:38, 17 April 2007 (EDT)

For example, I modified fVanityModeAutoDelay and fChameleonMaxRefraction. In my plugin, the GMST for fVanityModeAutoDelay is 0007BE55 and the GMST for fChameleonMaxRefraction is 0100256A. fVanityModeAutoDelay is present in Oblivion.esm while fChameleonMaxRefraction is not. So it appears a form ID is assigned when you modify a GMST setting that is not defined in Oblivion.esm. This can lead to problems when merging plugins if the form ID is used to detect collisions since two plugins can have different form ID values for the same GMST. In this case, it appears the editor ID should be used instead of the form ID when merging records. ScripterRon 16:04, 17 April 2007 (EDT)

Yes, that's true. Game engine comes with default values for all gmsts. If those aren't changed (and most aren't in Oblivion.esm), they're not assigned formids. I think there was actually a problem related to this with a foreign translation -- presumably the foreign translations have to define all the string gmsts -- which assigns them formids in the 00 modindex space -- and apparently one these ended up conflicting with something added in the 1.1 patch. (Fleeting memory, and by hearsay only -- I could be wrong.)

Because of the conflict problem I've started assigning "standard" formids for gmsts in Wrye Bash. As needed, I generate a new 00-space formid and use that -- and keep a record of the new standard formid from then on. I could publish these, but it's pretty incomplete right now -- and I should check to see what's been assigned in non-English versions of Oblivion (so that I can use those for strings). --Wrye 17:52, 17 April 2007 (EDT)