Change Script - Revision history

Colen at 05:51, 20 December 2013

2013-12-20T05:51:28Z

← Older revision		Revision as of 05:51, 20 December 2013
Line 38:		Line 38:

	When invoked, the Change script starts out with a container as its initial context. This container is the one that the portal is associated with. For example, a chooser portal will reside within a layout, which is within a panel or form. The container associated with the panel or form is the initial context.		When invoked, the Change script starts out with a container as its initial context. This container is the one that the portal is associated with. For example, a chooser portal will reside within a layout, which is within a panel or form. The container associated with the panel or form is the initial context.

			The "altpick" context may also be accessed from this script. This transitions to the pick that the selection was changed on (i.e. the pick "behind" the template) for menus, or to the newly selected pick for choosers. This is intended for use on the iPad, where changing the currently equipped weapon in a menu needs to deselect all other equipped weapons.

			Note that altpick transitions to the pick behind the current template for menus, NOT the pick that was selected by the menu, as you can get the latter from the former. "altthing" is not supported in these contexts, only "altpick".

	==Example==		==Example==

Rob: /* Technical Details */

2009-02-20T09:01:30Z

Technical Details

← Older revision		Revision as of 09:01, 20 February 2009
Line 15:		Line 15:
	\|Where Used:		\|Where Used:
	\|[[Portal Element (Data)\|Portals]]		\|[[Portal Element (Data)\|Portals]]
			\|-
			\|Procedure Use:
			\|"container" context
	\|-		\|-
	\|}		\|}

Rob at 00:22, 16 December 2008

2008-12-16T00:22:49Z

← Older revision		Revision as of 00:22, 16 December 2008
Line 12:		Line 12:
	\|Fields Finalized?		\|Fields Finalized?
	\|Yes		\|Yes
			\|-
			\|Where Used:
			\|[[Portal Element (Data)\|Portals]]
	\|-		\|-
	\|}		\|}

Rob at 21:59, 14 December 2008

2008-12-14T21:59:03Z

← Older revision		Revision as of 21:59, 14 December 2008
Line 24:		Line 24:

	==Description==		==Description==

	~~-Choosers and menus can define a "change" script~~
	~~-Script is invoked any time the contents of a chooser or menu are changed~~
	~~-Behaves similarly to a trigger action portal~~
	~~-Defined via a "change" element where the PCDATA contains the actual script~~
	~~-Script is invoked via UI by calling C_Portal_Select::Change_Trigger~~
	~~-Script starts with container context associated with the portal~~

	The Change script is utilized within chooser and menu portals. The purpose of the script is to enact special handling whenever the contents of the portal are changed.		The Change script is utilized within chooser and menu portals. The purpose of the script is to enact special handling whenever the contents of the portal are changed.

Rob at 21:58, 14 December 2008

2008-12-14T21:58:44Z

← Older revision		Revision as of 21:58, 14 December 2008
Line 24:		Line 24:

	==Description==		==Description==


	-Choosers and menus can define a "change" script		-Choosers and menus can define a "change" script
Line 33:		Line 32:
	-Script starts with container context associated with the portal		-Script starts with container context associated with the portal

			The Change script is utilized within chooser and menu portals. The purpose of the script is to enact special handling whenever the contents of the portal are changed.

	~~The Split script handles~~ the ~~splitting~~ of ~~one piece of gear into two separate picks~~ via ~~stacking behavior~~. It is ~~invoked whenever~~ the user ~~performs~~ a ~~split operation of stackable gear~~. ~~The goal~~ of the ~~script~~ is ~~to allow authors to properly reconcile whatever fields~~ are ~~necessary for an accurate splitting of one pick into two distinct picks.~~		It is rare that you'll need to use this mechanism, because the impact of a selection will usually be handled via Eval scripts during the next evaluation cycle. The key exception to this is when the user is customizing a gizmo within the form for that gizmo. If the influence of the selection is required before the gizmo changes are finally saved, a Change script is needed to apply the necessary effects.

	~~The Split script is defined for~~ a ~~component. As such, it is inherited into every thing that derived from that component. Each~~ script is ~~intended~~ to ~~properly split~~ the ~~fields within that component and nothing else. This ensures that a thing derived from multiple components, each with their own Split script, will perform appropriate split behavior without incident~~.

	~~When invoked~~, the ~~Split script starts out with a pick as its initial context. However, there are two picks involved in the split operation~~. When a ~~split takes place~~, ~~there is~~ the ~~initial pick that is being split (e~~.~~g. decreasing its quantity) and the new pick that~~ is ~~ultimately created through~~ the ~~split process. The initial context is~~ the ~~existing pick that is being split. The second pick is made available via an alternate pick context~~, which can be ~~accessed via~~ the ~~"altpick" context. This makes it possible to split one pick into two, regardless of what fields or behaviors are involved~~.		As an example, consider the World of Darkness data files. When a character spends XP during advancement, the XP cost for each advancement varies based on a numerous conditions. The Change script is utilized to properly calculate the XP cost for the selected advancement, which can then be displayed to the user before the advancement is officially added.

	When ~~splitting picks~~, the ~~engine will automatically update~~ the ~~"stackQty" field of both picks~~ with ~~the appropriate values~~. ~~Therefore~~, if a ~~pick with~~ a ~~quantity of 20~~ is ~~split,~~ with ~~a new quantity of 7 specified,~~ the ~~engine will setup the pick being split with a "stackQty" field of 13 and~~ the ~~new pick with a "stackQty" of 7. You can then use these field values to accurately adjust everything else for each pick~~.		When invoked, the Change script starts out with a container as its initial context. This container is the one that the portal is associated with. For example, a chooser portal will reside within a layout, which is within a panel or form. The container associated with the panel or form is the initial context.

	==Example==		==Example==

	The ~~sample Split~~ script below ~~splits one pick into two and properly adjusts all user-tracking details~~ to ~~accurately reflect~~ the ~~impact of~~ the ~~change~~.		The Change script below shows how the calculation of XP cost is performed for the World of Darkness game system. This example is edited down to show the core behaviors, as the real script handles additional factors.

	<pre>		<pre>
	~~~save~~ the ~~quantity~~ of ~~ammo that still remains unused~~		~get the cost of each dot for the ability
	var ~~user~~ as number		var eachdot as number
	~~user~~ = field[~~trkUser~~].value		eachdot = firstchild["Advance.Gizmo"].field[idotcost].value

			~determine the tagexpr with which to identify the pick we're interested in
			var tagexpr as string
			tagexpr = "component.CanAdvance & Advance." & firstchild["Advance.Gizmo"].idstring

			~if there is a half-price discount for the ability, incorporate that
			if (hero.tagsearch["HalfPrice." & firstchild["Advance.Gizmo"].idstring] > 0) then
			eachdot = eachdot / 2
			eachdot = round(eachdot,0,1)
			endif

			~if there is a double-cost penalty for the ability, incorporate that
			if (hero.tagsearch["DoubleCost." & firstchild["Advance.Gizmo"].idstring] > 0) then
			eachdot *= 2
			endif

	~~~update~~ the ~~new "max" values for both picks based on the new stack quantity~~		~get the previous dot level
	~~field[trkMax].value~~ = ~~field[stackQty].value~~		current = hero.firstchild[tagexpr].field[iprevlevel].value
	~~altpick~~.~~field~~[~~trkMax~~]~~.value -= altpick~~.field[~~stackQty~~].value

	~the ~~user value for the first pick is the quantity of ammo still unused,~~		~get the current dot level
	~~~subject to the maximum size for the pick~~		nextlevel = hero.firstchild[tagexpr].field[ilevel].value
	~~field~~[~~trkUser~~].~~value = minimum(user,~~field[~~trkMax~~].value)

	~~~subtract~~ the ~~quantity allocated~~ to the ~~first pick from what's now left~~		~determine the XP cost to improve to the next dot level
	~~user~~ -= ~~field[trkUser].value~~		var xp as number
			var dotcount as number
			var dotcost as number
			dotcount = nextlevel
			call dotcost
			xp = dotcost
			dotcount = current
			call dotcost
			xp -= dotcost
			xp = xp * eachdot

	~~~if we have any unused ammo left to assign to~~ the ~~other pick, assign it~~		~save out the calculated XP cost
	~~if (user <= 0) then~~		child[advDetails].field[ixpcalc].value = xp
	~~altpick~~.field[~~trkUser~~].value = 0		child[advDetails].field[inewdots].value = nextlevel
	~~else~~
	~~altpick~~.field[~~trkUser~~].value = ~~user~~
	~~endif~~
	</pre>		</pre>

Rob: New page: {{context|Kit Reference|Script Types}} ==Technical Details== :{| class="scripttable" |class="leftnormal"|Initial Context: |Container |- |Alternate Context: |None |-...

2008-12-14T13:19:19Z

New page: {{context|Kit Reference|Script Types}} ==Technical Details== :{| class="scripttable" |class="leftnormal"|Initial Context: |Container |- |Alternate Context: |None |-...

New page

{{context|Kit Reference|Script Types}}

==Technical Details==

:{| class="scripttable"
|class="leftnormal"|Initial Context:
|[[Container Context|Container]]
|-
|Alternate Context:
|None
|-
|Fields Finalized?
|Yes
|-
|}

The Change script utilizes the following special symbols:

:{| class="infotable"
|class="leftnormal"|-None-
|There are no special symbols for the Change script.
|-
|}

==Description==

-Choosers and menus can define a "change" script
-Script is invoked any time the contents of a chooser or menu are changed
-Behaves similarly to a trigger action portal
-Defined via a "change" element where the PCDATA contains the actual script
-Script is invoked via UI by calling C_Portal_Select::Change_Trigger
-Script starts with container context associated with the portal

The Split script handles the splitting of one piece of gear into two separate picks via stacking behavior. It is invoked whenever the user performs a split operation of stackable gear. The goal of the script is to allow authors to properly reconcile whatever fields are necessary for an accurate splitting of one pick into two distinct picks.

The Split script is defined for a component. As such, it is inherited into every thing that derived from that component. Each script is intended to properly split the fields within that component and nothing else. This ensures that a thing derived from multiple components, each with their own Split script, will perform appropriate split behavior without incident.

When invoked, the Split script starts out with a pick as its initial context. However, there are two picks involved in the split operation. When a split takes place, there is the initial pick that is being split (e.g. decreasing its quantity) and the new pick that is ultimately created through the split process. The initial context is the existing pick that is being split. The second pick is made available via an alternate pick context, which can be accessed via the "altpick" context. This makes it possible to split one pick into two, regardless of what fields or behaviors are involved.

When splitting picks, the engine will automatically update the "stackQty" field of both picks with the appropriate values. Therefore, if a pick with a quantity of 20 is split, with a new quantity of 7 specified, the engine will setup the pick being split with a "stackQty" field of 13 and the new pick with a "stackQty" of 7. You can then use these field values to accurately adjust everything else for each pick.

==Example==

The sample Split script below splits one pick into two and properly adjusts all user-tracking details to accurately reflect the impact of the change.

<pre>
~save the quantity of ammo that still remains unused
var user as number
user = field[trkUser].value

~update the new "max" values for both picks based on the new stack quantity
field[trkMax].value = field[stackQty].value
altpick.field[trkMax].value -= altpick.field[stackQty].value

~the user value for the first pick is the quantity of ammo still unused,
~subject to the maximum size for the pick
field[trkUser].value = minimum(user,field[trkMax].value)

~subtract the quantity allocated to the first pick from what's now left
user -= field[trkUser].value

~if we have any unused ammo left to assign to the other pick, assign it
if (user <= 0) then
altpick.field[trkUser].value = 0
else
altpick.field[trkUser].value = user
endif
</pre>