GetFormFromFile VS Properties

[PAPVAFS11]

I've been introducing a few global mechanics into my mod, like bleeding and casing collection. I've also read multiple times that game-wide scripts like this should economize their properties as much as possible to avoid save/memory bloat. I've also, also recently gotten a grasp for the GetFormFromFile function to get game objects as variables in scripts. It seems so far like GetFormFromFile largely sidesteps the bloating problem since you can create and discard variables mid-script rather than permanently storing them as properties.

Assuming I'm not completely misunderstanding things, what are the differing use cases for properties VS variables assigned by GetFormFromFile? Are there any pitfalls or limitations I'm not picking up on? Apart from IDs having a non-zero chance of changing or disappearing.

[SKKmods]

I use GetFormFromFile extensively in development so I can update, recompile and [ ReloadScript ] in running games. Once the design is stable, then they are turned into script properties for performance.

I use GetFormFromFile extensively to avoid master dependencies on DLCs and such.

I use GetFormFromFile extensively for inter mod communication.

BUT

GetFormFromFile is EXTREMELY slow compared to a script property lookup.

GetFormFromFile will not work with non persistent ObjectRefences that are unloaded.

Byte size script property pointers are hardly going to bloat a savegame, read this page to learn about actual bloat issues.

If your script hits the per script limit for variables and property pointers (forget the value, someting like 4096) it needs redesign. I am aware of one early uncapped spawning mod which hit the limit, it was corrupting many save games for many reasons.

If you are attaching non CONST scripts with extensive property counts to ObjectReferences and then placing/spawning THOUSANDS of them ... redesign.
 

[LarannKiar]

The only thing I could add is that calling GetFormFromFile may cause the game to create a record in the save for the reference, even without filling it to Script Property.

For example, if you make a script like:

Scriptname testscript3

function test(ObjectReference ref) global
	Debug.MessageBox("GetFormFromFile = " + (Game.GetFormFromFile(0xdc9, "cctosfo4001-neosky.esm") as Form).GetFormID())
endfunction

Then call the test function in the Console, it would return the FormID of one of the Vases in the Noir Penthouse, assuming the vase is persistent (somehow) or more likely, because it's in the loaded area.

Even though both GetFormFromFile and the test function above are global (i.e. static), the VM would internally create a Papyrus "Bound" Object for it (after casting it to its appropriate type: ObjectReference) and write its Script Object record to the save. 

(By the way, you can determine whether a reference has a Papyrus Object without F4SE with IsBoundGameObjectAvailable() and by attempting to call ObjectReference script functions on it; "No script named ObjectReference is attached to the object." means it doesn't have a bound object).