Talk:Variables and Properties

Conditional properties

What does it actually mean if a property is "conditional"? I'm assuming this means I can access it through conditions in spells and such, is this right? Fowl 20:24, 7 February 2012 (EST)

The conditional keyword seems to be described here - Papyrus Introduction: Writing Custom Functions

It's hardly the most obvious place, however. Perhaps the keyword reference should be expanded?

-- Cipscis 20:29, 7 February 2012 (EST)

That's awesome, thank you. I'm going to add that link to the article Fowl 19:13, 8 February 2012 (EST)

Manipulating Properties

I can't seem to get the referencing. I'm in an active magic effect (AME) script wanting to add/subtract on an Int property attached to a quest script. I have a quest property (called QST) attached to the AME script whose value is the quest whose Int property I want to manipulate. But doing a line like (from within the AME script):

QST.IntProperty += 1

just gives a compile error saying that the quest doesn't have property "IntPropery." So, I'm thoroughly confused. I don't completely understand "casting," either. That may have something to do with it. --Doulos 04:53, 11 February 2012 (EST)

You're absolutely right that casting has something to do with it. The problem is, as the compiler tells you, that "IntProperty" doesn't exist on the type "Quest".

The important thing to remember here is that, when you wrote the script containing "IntProperty", you wrote it such that you extended "Quest". What' you've essentially done is create a new object type that is an extension of "Quest" and, as such, I expect you should be able to access your property like this (with "MyNewQuestScript" as a placeholder for the name of the script containing "IntProperty"):

(QST as MyNewQuestScript).IntProperty += 1

-- Cipscis 05:35, 11 February 2012 (EST)

Thanks for the reply, it worked! I think I'm getting more of a handle on the idea, but I'm still having some conceptual problems. So, if I understand it right, when I made a new Quest script on a quest that extends "quest," I can only use the stuff in the "quest" object. Then, if I make a AME script with a property whose value is MyQuest, I really only have a property that uses stuff from the "quest" objects. So, in order to use objects specifically from MyQuest, I have to have to cast the AME property as MyQuestScript? Why MyQuestScript and not just MyQuest? Thanks, --Doulos 14:17, 11 February 2012 (EST)

Ah, I think I figured it out. I'll keep all of this up here in case someone else might benefit from it. I'm so used to Oblivion and how quests own variables. So I was assuming that I should be able to something like MyQuest.IntProp. But that's not the case. I have to attach a quest property (value MyQuest) to my AME script because that's the quest wherein the variable of interest lies. However, the property "IntProp" doesn't belong to MyQuest, it belongs more specifically to the script to which it it attached. So, if I want to use the properties of MyQuest, I have to cast the QST property as MyQuestScript, since the script contains the property I want. --Doulos 14:49, 11 February 2012 (EST)

"Warnings" Unclear

At the moment, the "Warnings" at the bottom of the page reads like this:

"Be careful with variables and auto properties on scripts that are extended by other scripts - especially where some script somewhere else may have a property pointing to the base script, or trying to cast to the base script. This is because it would be possible to have two copies of a script attached to the same object, thereby creating two copies of the variable/auto property - and the other scripts that refer to the base script may randomly pick which one to talk to.

This is doubly-true of scripts with native functions, as the game can attach these to in-game objects at any time if it needs to, thereby creating another copy of the variable or auto property."

To me, at least, this seems rather unclear. Could anyone help me decipher it?

-- Cipscis 17:27, 14 February 2012 (EST)