Talk:GetFormFromFile - Game

GetModLoaded

In the example on the page, the form ID 0x800 is used to test whether or not a mod is loaded. In my experience, a mod's first form has form ID 0x800 only if you're creating it without having loaded any masters.

If any other files have been loaded, then the form ID is usually 0xD62. Perhaps it would be better to re-write the example as

If bDLCArray[aiIndex] != (Game.GetFormFromFile(0x00000800, sDLCArray[aiIndex]) \
			|| (Game.GetFormFromFile(0x00000D62, sDLCArray[aiIndex]))

Of course, even that might not work if the mod creator had deleted the very first object he/she created in the mod. --Fg109 01:37, 27 June 2012 (EDT)

As it turns out, Dawnguard has an 0x00000800, but D62 does seem to be pretty consistent. Good call, Fg109. At that, the function can be condensed and, in most cases, remain effective. I ended up adding an Int array to take out the guesswork.

-- JustinOther

Appropriate Use

Since I first started scripting with Papyrus, I've tried to treat "Keep the script blind to information in the data files" as a rule, or at least best practice, exclusively using Properties as the script's interface with data files and avoiding the use of functions such as GetForm. To date, I have seen no good reason to change this behaviour.

While at first glance it seems as though this rule should also lead me to entirely neglect this function, I can see one legitimate use for it: Enabling compatibility with mods without setting them as masters. The advantage of this is that only a single data file is required for any combination of loaded mods that would otherwise have been masters, and I expect it also decreases dependency on load order.

Is anyone able to think of any other ways in which this function could be used that couldn't be replicated with Properties alone without downsides? At the moment, just like I feel all use of GetForm should be discouraged, I feel as though all use of this function aside from the one I mentioned above should also be discouraged.

--Cipscis (talk) 23:14, 21 August 2012 (EDT)

So far, I've not found any other reason to use these over Properties directly pointed at the other plugins' forms than to avoid said master dependency. It does work regardless of load order, so a mod can reach 'down' as well as 'up'. So far, I've only used it with FormID arrays to add Dawnguard compatibility in order to avoid adding it as a secondary/tertiary master. I agree though, that it's best to not use GetForm/GetFromID/GetFormFromFile unless it's actually necessary. In those cases, I've no qualms using it.

Possible to stop scripts if parent plugin is no longer loaded

Another possible use for this function is setting scripts up to unregister on save load via a maintenance function in the event their parent plugin is no longer loaded.

Function Maintenance()
	If Game.GetFormFromFile(GetFormID(), "Parent Plugin.esp")
		Debug.Trace("Plugin is loaded.")
	Else
		Debug.Trace("Plugin is not loaded.")
		UnregisterForUpdate()
	EndIf
EndFunction

Needs more extensive testing, but it appears to work. --JustinOther