Change Script

From HLKitWiki
Revision as of 05:19, 14 December 2008 by Rob (Talk | contribs) (New page: {{context|Kit Reference|Script Types}} ==Technical Details== :{| class="scripttable" |class="leftnormal"|Initial Context: |Container |- |Alternate Context: |None |-...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Context: HL KitKit Reference … Script Types 

Technical Details

Initial Context: Container
Alternate Context: None
Fields Finalized? Yes

The Change script utilizes the following special symbols:

-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.

~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