Difference between revisions of "Talk:Dissecting the Scripts for Weapon Racks"

From the CreationKit Wiki
Jump to navigation Jump to search
imported>HawkFest
imported>Sclerocephalus
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Erroneous assertion ==
== Erroneous assertion ==


'''It's written:''' « ''OnTriggerEnter and OnTriggerLeave - Next, you see the OnTriggerEnter and OnTriggerLeave blocks inside the 'WaitingForReference' state. 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'''.'' »


'''That's plain wrong:''' a singleton state can be essential e.g. when monitoring things, while using RegisterForSingleUpdateGameTime for instance. One example which is quite self-explanatory:
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 in some allowed faction}
{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}
ObjectReference Property MarkerEnabler Auto
Actor Property PlayerREF Auto
{A marker reference parent of other objects that you wish to enable when the player becomes member of some allowed faction}
Bool ShouldWaitForAllowedFaction = True


Event OnLoad()
Event OnLoad()
If MarkerEnabler.IsDisabled()
If ShouldWaitForAllowedFaction
GoToState("WaitForAllowedFaction")
GoToState("WaitForAllowedFaction")
EndIf
EndIf
Line 19: Line 19:
Event OnBeginState()
Event OnBeginState()
If PlayerREF.IsInFaction(AllowedFaction)
If PlayerREF.IsInFaction(AllowedFaction)
MarkerEnabler.Enable()
ShouldWaitForAllowedFaction = False
; Do what you want to do
Else
Else
RegisterForSingleUpdateGameTime(0.9)
RegisterForSingleUpdateGameTime(0.9)
Line 30: Line 31:
EndState
EndState
</source>
</source>
--[[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)

Latest revision as of 15:46, 20 December 2013

Erroneous assertion[edit source]

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:

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 of some allowed faction}
Actor Property PlayerREF Auto
Bool ShouldWaitForAllowedFaction = True

Event OnLoad()
	If ShouldWaitForAllowedFaction
		GoToState("WaitForAllowedFaction")
	EndIf
EndEvent

State WaitForAllowedFaction
	Event OnBeginState()
		If PlayerREF.IsInFaction(AllowedFaction)
			ShouldWaitForAllowedFaction = False
			; Do what you want to do
		Else
			RegisterForSingleUpdateGameTime(0.9)
		EndIf
	EndEvent

	Event OnUpdateGameTime()
		GoToState("WaitForAllowedFaction")
	EndEvent
EndState

--HawkFest (talk) 2013-01-29T15:34:42 (EST)

Variables vs. Hidden Literal Properties[edit source]

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:

Bool Property HasBeenTriggered Auto Hidden

Int Property numInTrig Auto Hidden

Bool Property AlreadyInit Auto Hidden

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:

;Wouldn't this be the same?
bool HasBeenTriggered

int numInTrig

bool AlreadyInit

Is there a reason Properties are used in these instances instead of variables? --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.--Sclerocephalus (talk) 2013-12-20T15:46:54 (EST)