[LE] Accessing Properties in a Global Function

[Kapteyn]

I'm at my wit's end with this, it just doesn't seem possible.

ScriptName SomeScript Extends ReferenceAlias

String Property sSomeString Auto

Event onInit()
    Debug.Notification(getString()) ; "This works fine"
EndEvent

String Function getString()
    Return sSomeString ; "Works for the above, but not below"
EndFunction

Function doThingy() Global
    String sThis = sSomeString ; "Errors because it's not defined"
    String sThat = getString() ; "Can't do this using a global"
EndFunction

What gives?

Edited October 11, 2017 by Kapteyn

[lofgren]

Global functions don't have access to properties, because properties are properties of the form the script is attached to, not of the script itself. You have to use GetFormFromFile, then cast it as the script type, then get the property.

 

This might seem ludicrous at first, but properties are properties of a thing. That's why you can add the same script to six different objects and define the same property differently on each of them. How would a global function know which of the six things you are referring to unless you tell it?

[Kapteyn]

The problem with using GetFormFromFile is... the entire point is not using it.

 

I'm actually trying to create a string property for the ESP file name.

If getGlobal(0x123ABC)
    Debug.Notification("This thing is enabled")
EndIf

Float Function getGlobal(Int iForm, Bool bMod = True) Global
    GlobalVariable vGlob
    If bMod
        vGlob = getThingy(iForm) As GlobalVariable
    Else        
        vGlob = getForm(iForm) As GlobalVariable
    EndIf
    Return vGlob.getValue()
EndFunction

Form Function getThingy(Int iForm) Global
    String sFile = "BobMeThingy.esp" ; "This is where I want the property"
    Return getFormFromFile(iForm,sFile) As Form
EndFunction

I guess it just can't be done, so I'm stuck with defining the file name in the script itself.

Edited October 11, 2017 by Kapteyn

[lofgren]

You can pass the string to the function in as a parameter.

Float Function getGlobal(Int iForm, string sModName, Bool bMod = True) Global
    GlobalVariable vGlob
    If bMod
        vGlob = getThingy(iForm) As GlobalVariable
    Else        
        vGlob = getForm(iForm) As GlobalVariable
    EndIf
    Return vGlob.getValue()
EndFunction

[Kapteyn]

I suppose I could set the property on the other script and then pass it along every time I call these functions, but I'm trying to avoid doing that - if it's all I can do then I'll just not bother at all with using a property and define the file name in the global script instead, which is currently how it is and it works just fine.

[lofgren]

Well yes, the property would have to be defined somewhere. Otherwise how would the global function know what the property is supposed to be? I guess I just still do not understand what you are trying to do. If the string never changes, why would you store it in a property to begin with? I'm also unclear as to what the advantage to making this a global property is.

Edited October 12, 2017 by lofgren

[Kapteyn]

It's not so much about the need to use the property, it's not really necessary at all in this case... I was just trying to figure out if it's possible for a global function to access a property which is in its own script. I don't really care anyway, I have six scripts for my mod and between them they don't use a single property, and hence creating these global functions to handle repeated calls to get forms directly from the file. As long as the form IDs don't change, surely it's more efficient to do it this way. Like this...

    If bThingy
        LeveledActor rThingy = getThingy(0x1000) As LeveledActor
        Int iThingyMin = getGlobal(0x2001) As Int
        Int iThingyMax = getGlobal(0x2002) As Int
        If getGlobal(0x2003)
            iNum = Utility.RandomInt(iThingyMin,iThingyMax)
            rSomething.PlaceAtMe(rThingy,iNum)
        Else
            rSomething.PlaceAtMe(rThingy,iThingyMax)
        EndIf
    EndIf

So what I wanted to do was have that one single property which defined the plug-in as a string. But sod it, there's no point breaking what don't need fixing.

[lofgren]

I don't know that it's more efficient. Global functions are more efficient than local functions in general, but you're dramatically increasing your number of function calls by refusing to use properties. At best it's probably a wash.

[Kapteyn]

I realise that, but surely it's doing a similar thing as hard code does in grabbing data from a property in the first place and then a function still has to do something with it. In any case, I don't actually need these functions just because I'm not using properties - it's more to make the script easier to work with and look at, so yes there's probably an extra function involved but I can't see it adding a significant amount of overheard.

 

What's calling the script might be more relevant. If it's a quest for the player then only one script instance would occur so it may be neither here nor there in such a case; but if it's being called by NPCs which are randomly and regularly spawned then script instances can accumulate dangerously. Thus, by not using properties none of the data is being stored in the save file, which is the main purpose. For a single mod it's not exactly a problem, but if people have well over a hundred mods then collectively they can contribute to save bloat, so I'm trying to alleviate it as best I can.

 

Before I created those functions I had about a dozen form lists which were being called via properties, this in itself limited the number of properties being used but it was still a fair number of lists. By calling the forms directly I've got it down to 3 lists - so the reality is that the overall size of the ESP file and the scripts has been reduced. Even if it shrinks by only 5%, and even if I'm essentially using an additional function, less form lists is surely better than heavily relying on them.

 

Think about it like this: if I have a form list as a property, and in that list I have more form lists... the game code has to call a function in the first instance to grab the property data, then it calls another function to grab a form out of the list and then it calls the function again to deal with that final list (if you catch my drift). So what I'm doing is bypassing the entire need to call either properties or form lists and instead referencing the form directly by its ID. So again, even with an extra function in there I'm possibly causing the game to use less calls than it typically would.