Int Property vs GlobalVariable

[SMB92]

Hi all,

 

I'm just curious to know (because I can't find a serious answer) if there is any disadvantage to using (setting and getting) an Int Property vs using a globalvariable, other than that the global would retain its set value when the script is stopped etc (or do Int properties save their set value too?)

 

I am currently using a lot of glibals but I started using Int properties and bool properties for a few things involving my fragments, and they seem to work just fine. Which makes me want to drop using globals at all.

 

Cheers.

[chucksteel]

I will start with the fact that I suck with scripting but, when I was working on my gnome quest I originally was going to use a global but a Beth employee over on the Beth site told me that the only reason to use a global would be if there were needs for quest conditions to also reference that global.

 

I was also told they took longer to calculate, by how much I have no idea but, I ended up just using a variable in my script itself and it all worked out.

 

not that my scripts are all that complicated and again I suck at scripting but maybe it will give you something to think about.

[Reneer]

I'd have to hear more about what your specific use cases are, but generally a script property is going to be just fine and will be slightly faster than using global variables. Basically any script you have on an object or quest won't lose its property values unless you stop the quest or delete the object.

[SMB92]

Thanks for the info. I was told that globals are a bit slower, it'd be a nice optimization to use a direct property.

 

Basically a quest holds all the functions and variables for settings that the player can set in a menu, such as chance values, difficulty level value, array index ID values, max counts etc etc.

 

The menu works via quest fragment script/stages on the same quest (this works very well) and sets the values of the globals according to either a preset I made or a value listed in a sub menu, whatever the user selects. I went with globals as to be sure the value would stick but if an Int property will stick I'll convert to that.

 

The quest had an idle stage, startup stage and stop/uninstall stage.

 

On another note is there any difference between:

 

Int Property myint = 0 Auto

And

Int property myint Auto

 

I'm lead to believe there isn't and this would save me filling every property manually, and the value I set in the former example will return to that when the quest stops.

[Jebbalon]

The way I learned it is that Global variables are global meaning other scripts and even in-game console can view set and get the value.

Int properties would be used more as a Local variable used in that one script or on that one object.

So, it's dependent on the usage. Always good to think ahead also - will this be useful as global or is it restricted to this one use?

 

As for the speed of processing - we're talking about machine code and unless you are scripting things like combat OnHit() events or processing many npc's in battle at once then you really don't need to worry about saving a few cycles. And on 64bit it's even less of a worry.

[Reneer]

Thanks for the info. I was told that globals are a bit slower, it'd be a nice optimization to use a direct property.

 

Basically a quest holds all the functions and variables for settings that the player can set in a menu, such as chance values, difficulty level value, array index ID values, max counts etc etc.

 

The menu works via quest fragment script/stages on the same quest (this works very well) and sets the values of the globals according to either a preset I made or a value listed in a sub menu, whatever the user selects. I went with globals as to be sure the value would stick but if an Int property will stick I'll convert to that.

 

The quest had an idle stage, startup stage and stop/uninstall stage.

 

On another note is there any difference between:

 

Int Property myint = 0 Auto

And

Int property myint Auto

 

I'm lead to believe there isn't and this would save me filling every property manually, and the value I set in the former example will return to that when the quest stops.

I certainly won't tell you how to write your own mod, but I would have personally never thought to use quest fragments for a menu system. It seems like way too much overhead in terms of typing up lots of little scripts when you could just as easily create a function in your Quest script.

 

Now, as I mentioned earlier, the only time your Quest properties will become unfilled is when you stop the quest.

 

As for setting a property value in the declaration, that's just fine and doesn't impact anything as far as I know.

 

The way I learned it is that Global variables are global meaning other scripts and even in-game console can view set and get the value.

Int properties would be used more as a Local variable used in that one script or on that one object.

So, it's dependent on the usage. Always good to think ahead also - will this be useful as global or is it restricted to this one use?

 

As for the speed of processing - we're talking about machine code and unless you are scripting things like combat OnHit() events or processing many npc's in battle at once then you really don't need to worry about saving a few cycles. And on 64bit it's even less of a worry.

Just as a quick point, it is possible to access script properties from other scripts and quests.

Edited June 18, 2017 by Reneer

[SMB92]

Cheers, I think I'll convert over to Int Properties now.

 

Its a bit unorthodox using fragments but the thing is the menu is colossal and the amount of settings is extreme. Something like up to 6000 combinations per NPC if said NPC is involved in every system!

 

I had a lot of problems making functions out of the menu in terms if keeping track of the code and also stacking while loops. Because I provide convenience functions like a back button and exit button things got out of control very fast. Using the fragments and stages I can keep track of everything like a journal so to speak, it's that much more blissful, everything makes sense :) I'm very happy with it.

[Reneer]

Cheers, I think I'll convert over to Int Properties now.

 

Its a bit unorthodox using fragments but the thing is the menu is colossal and the amount of settings is extreme. Something like up to 6000 combinations per NPC if said NPC is involved in every system!

 

I had a lot of problems making functions out of the menu in terms if keeping track of the code and also stacking while loops. Because I provide convenience functions like a back button and exit button things got out of control very fast. Using the fragments and stages I can keep track of everything like a journal so to speak, it's that much more blissful, everything makes sense :smile: I'm very happy with it.

If you're happy with it, then by all means keep it. :)

[Zzyxzz]

I haven't read everything in this thread so to make it short:

 

Global Variables are accessed with functions MyGlobal.GetValue() and thus cause more stress on the scripting system.

Properties are accessed directly with no function call.

 

Another example of saving papyrus time:

 

(MyGlobal.GetValue() as int) vs MyGlobal.GetValueInt()

Casting a float to an int is faster than calling the GetValueInt function, as it causes more function calls.

 

How much does this make a difference?

More than you expect. My latest update for Better Locational Damage, adds scripted headshots and dismemberment. Time is very important as you can imagine. You don't want to shoot someone and see him fall over after a short time. When i started with scripting i made many of those "mistakes" and at some point it was noticeable. Especially with dismemberment i had issues. When you cut a bodypart off, the script has to process very fast and mine wasn't that fast. You could see as soon as you hit the target, how the script processed the hit and the bodypart got dismembered after a split second. I've changed many variables to properties and global values are cast to int, if needed. Now the delay between a headshot and dismemberment is nearly zero. You don't notice it.

 

Papyrus is tied to frames, that is also something you need to know. Papyrus does not cripple frames but low frames cripple papyrus. So even a script that works perfectly fine at 60 FPS, may have small delays when at 40 FPS.

It also depends on what the script is used for.

 

Most of my GlobalValues get called onInit and are then handed to other properties to be processed.

I've spent a lot of time to optimize my scripts and testing different approaches and how many time they need to process. You can also analyze your code with papyrus, how long it needs to process.

[Zebrina]

Should you still need to, you can access your property values in conditions with the condition function called GetVMQuestVariable. Of course global variables still have the advantage of being accessible on both the left and right hand side of the expression. If you wish to access your properties you must make the script and properties "conditional".

 

Scriptname myquest extends quest condtional

 

int property myvalue auto conditional