Difference between revisions of "Talk:Dissecting the Scripts for Weapon Racks"
Talk:Dissecting the Scripts for Weapon Racks (edit)
Revision as of 15:46, 20 December 2013
, 15:46, 20 December 2013→Variables vs. Hidden Literal Properties
imported>HawkFest |
imported>Sclerocephalus |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
'''It's written:''' « ''I'm not going to try and explain states here, but '''it's redundant and has no utility if you only have a single state in a script'''.'' » | '''It's written:''' « ''I'm not going to try and explain states here, but '''it's redundant and has no utility if you only have a single state in a script'''.'' » | ||
Actually, a singleton state can be essential e.g. when monitoring things, while using RegisterForSingleUpdateGameTime for instance. One example which is quite self-explanatory: | |||
<source lang="papyrus"> | <source lang="papyrus"> | ||
Scriptname FactionDetectionScript extends ObjectReference | Scriptname FactionDetectionScript extends ObjectReference | ||
{Script to be attached to some object in the cell you wish to be monitoring for the player to be a member | {Script to be attached to some object in the cell you wish to be monitoring for the player to be a member of some allowed faction} | ||
Actor Property PlayerREF Auto | |||
Bool ShouldWaitForAllowedFaction = True | |||
Event OnLoad() | Event OnLoad() | ||
If | If ShouldWaitForAllowedFaction | ||
GoToState("WaitForAllowedFaction") | GoToState("WaitForAllowedFaction") | ||
EndIf | EndIf | ||
| Line 19: | Line 19: | ||
Event OnBeginState() | Event OnBeginState() | ||
If PlayerREF.IsInFaction(AllowedFaction) | If PlayerREF.IsInFaction(AllowedFaction) | ||
ShouldWaitForAllowedFaction = False | |||
; Do what you want to do | |||
Else | Else | ||
RegisterForSingleUpdateGameTime(0.9) | RegisterForSingleUpdateGameTime(0.9) | ||
| Line 31: | Line 32: | ||
</source> | </source> | ||
--[[User:HawkFest|HawkFest]] ([[User talk:HawkFest|talk]]) 2013-01-29T15:34:42 (EST) | --[[User:HawkFest|HawkFest]] ([[User talk:HawkFest|talk]]) 2013-01-29T15:34:42 (EST) | ||
==Variables vs. Hidden Literal Properties== | |||
A recurring theme that I see in Bethesda scripts is the use of Hidden Properties to represent literal values. This snippet is taken from WeaponRackTriggerSCRIPT.psc: | |||
<source lang="papyrus"> | |||
Bool Property HasBeenTriggered Auto Hidden | |||
Int Property numInTrig Auto Hidden | |||
Bool Property AlreadyInit Auto Hidden | |||
</source> | |||
I'm relatively new to Papyrus, but based on my understanding of the language, the fact that these are Hidden means that they're private; inaccessible outside this script. This would seem to make them functionally equivalent to variables: | |||
<source lang="papyrus"> | |||
;Wouldn't this be the same? | |||
bool HasBeenTriggered | |||
int numInTrig | |||
bool AlreadyInit | |||
</source> | |||
Is there a reason Properties are used in these instances instead of variables? | |||
--[[User:Geekofalltrades|Geekofalltrades]] ([[User talk:Geekofalltrades|talk]]) 2013-12-15T15:42:35 (EST) | |||
A hidden property is neither private nor inaccessible from outside the respective script. For example, the Hearthfires BYOHDivertPrefabsScript reads the hidden PlayersDroppedWeapon property from some weapon racks. A hidden property is just literally hidden, i.e. entirely concealed from public view; in other words, if you didn't have the source code of the script to look at, you wouldn't even know of its existence. Of course, it also doesn't appear in the properties window in the CK - which effectively prevents it from being inadvertently manipulated.--[[User:Sclerocephalus|Sclerocephalus]] ([[User talk:Sclerocephalus|talk]]) 2013-12-20T15:46:54 (EST) | |||