to do=
sho4th(): Sun's site -> Oracle's
hitVs(): ?sub for dibDX use (=d6 from atkVs())
bakOff(): use of nogo rtns of tryMov() for mvd fig - no toCoo -> no fol up
mac/usrMov(): shift -> Hlt if egd -> egd
canHit(): no atk cap thr shd hnd sde
macMov(): ai to mov awy fro tgt shd sde - ?pt vs bdr hex mov trk


Foeman programming notes

dig() coding: `skips over ',' character which would have been value of -4 (assigned to character '+' instead, & etc. to -15= 'space'), since comma used as field delimiter in data strings

z1$[] StringBuffer array Side/ Figure/ Item elements' coding fields:
	sidPoo elements' SidIni field's SidDie digit contains the side's modified Initiative roll value for the round. Modified values may be any valid digit, ranging from negative (allowing a negative mod to a side's Ini) to positive.
	SidIni field's SidSeq digit will contain a number from 1..sidCnt after Movement phase showing the order in which all sides moved their figures (eg. Charge attack qual may include attacker moved before target). While Movement phase is in progress, this digit is used as a controller and holds a value of 0 for a side whose figures haven't yet moved and could do so, -1 for a side whose figures haven't yet moved and which is currently noted as postponed (opted for another side to move first), or the final value of 1..sidCnt for a side which has already moved.

sidPoo elm seq req:
	For every encounter, the sides which are involved must be listed sequentially (packed) as elements beginning at sidPoo (but not necessarily in SidVal numerical order, and the SidVals of all involved sides need not be consecutive), since processing will be incremental through sidCnt. A side will never be removed during an encounter, and a side which no longer has any active figures will still be checked for Initiative order; then being passed over when no active figures are recognized upon each of the following phases.

	Presently, base attributes are recorded as single character "digits", and modified attribute values are recomputed dynamically (using modST(), etc.) as required.
	[`alt: FigSt, FigDx & FigIq fields have both modified and basic stats combined stored in them. The field values are represented as are the column & row components of hex coordinate values with 3 or 4 digits, and in this case, the option of a negative sign. The modified ST, DX, or IQ component is positioned first, should negative values of these stats be useful. For example, a FigSt entry of -112 shows a base ST of 12 with a currently recorded modified ST of -1. A FigDx entry of 1014 shows a base DX of 14 with a currently recorded modDX of 10.]

resolving ties:
	In cases where two or more sides tie on initiative rolls, the computer uses tiebreaker die rolls to choose the next side to move in the sidMov() routine. As it's scanning down the list of sides for the highest unmoved side's initiative result, whenever it encounters a value equal to the highest yet found it rolls a die to decide whether to replace the last noted side with the newly scanned one. It rolls a simulated die of a number of sides equal to the total number of contending (tied) sides up to that point (a d2 for the first tiebreaker, d3 for the second, etc.), and replaces with the newly scanned side if a 1 is rolled. In this manner, the probability for the selection of a side is equivalent to that of a random draw. This can result, though, in displays of inconsequential die rolls if the arrangement of sides causes a tiebreaker roll followed by a supervention by a higher initiative value. The SidSeq digit of the SidIni field of the side's sidPoo element is given a consecutive number to record its movement order (ie. actual initiative order) once the next side to move has been selected; principally as a flag to show that the side has been moved.
	The same process is used to resolve ties on modDX in the nxtOrd() subroutine, and the same type of sequence record is maintained for figures' order of option choices within a segment in the FigSeq digit of the FigSta field. This rough sequence number is generally fixed by the order in which the remaining figures which haven't declared a number of dice choice for their actions are found to have the highest modDX, and doesn't signify an actual action performance order (until after all figures have acted for the round; see following). Technically, to keep from rerolling for ties every time figures change options during a segment as mentioned, the sequence number is just applied as a relative order position (ie. they're mnemonics for already- rolled tie breakers), and may be rezeroed by nxtOrd() within a segment for an already sequenced figure whose modDX becomes lower than any one as yet undeclared #dice figure due to the zeroed figure's change of option and/ or target; causing a skip in value. The FigSeq values will indicate the relative order in which the figures declared their #dice within a segment, but might not be consecutive, and don't reflect action performance order since that's deteremined by the #dice chosen and limited to one figure per segment. To that end, the seqCnt variable is initialized to zero at the beginning of oneRnd() and incremented and assigned to the FigSeq of an acted figure in exeAct(); so acted figures (FigDic digit >=flag val 10 ':') within a round will have seq#s in consecutive order which do denote actual action performance order.
	Although here, the flag used to show that a figure has acted is a value of 10 or more in the FigDic digit of the FigAct field. [`?for use in case of figures who opt to 'pass'/ Watch and who are then requeried in like order - NO: whether a figure chooses an inactive option (those for which no choice of number of dice is required [`?padded with a 1]), or an active option during a segment in which another figure acts, will have its number of dice (= action flag) reset to zero at the end of the segment [`?: until the acting figure has chosen an inactive option - when the round ends]]
	The same process in its simplest implementation is used in the genBst() sbr to choose an offhand wpn to serve as a shield.

	FigSiz field's val: `uses hundredths as unit (although for figures, twelfths would be more efficient & accord with rounds per minute and casting cost divisions) so that relative values might be assigned to items carried by figures, and accounted in Drag encumbrance calculations (so, a single arrow could have Size 1 or 2)

	FigMov field's FigHlt digit vals: Mv0= No MP yet used/ charged to the figure in this round - not moved from hex occupied at end of previous round, or MP not accounted (as in Force Retreat). Mvd= Moved or used MP as a result of other figures' influence, but hasn't yet used any MP of its own volition upon its option to move: thus, hasn't yet taken its move. Mvg= Is taking or has taken its move, and has voluntarily used some MP thereby; and if not now taking its move, may be returned to during its side's portion of Movement phase. Hlt= May take no further option to move in this round, or even for the remainder of its side's portion of Movement phase, but may be moved or use MP as a result of other figures' influence.

	FigMov field's FigDir digit vals: -1= last step was backward, 0= last step was forward (or 2nd backward step was converted to forward), 1..18= number of linear straight forward steps figure has moved consecutively (in direction it faces); if figure pivoted at end of move, adds PivDir (=20): for 19, 20, 21..38. Carries over from one round to the next, with these exceptions: If noted as pivoted, would reset to 0 (Fwd) upon 1st step of next round in tryMov() (so that then if 1st step is lin -> 1, else -1 or 0; as usual), otherwise if unpivoted, increments for lin steps continue to accrue up to a tracking limit of 18. At the end of the sidMov() rou if a figure was left unmoved during a round [FigStp=0], its FigDir value resets to 0 (Fwd) with any pivot noted as made that round retained (ie. unless FigHlt= Mv0 [?or Mvd] when any pivot notation is removed).

	`"segments" for indiv fig action, within rounds - nxtOrd() prc: seq ord chg only for opt piks that reduce a focus fig's modDX to < another's; opt piks that raise > an already acted/ #dic pikd fig don't affect seq#s- just priority for choice of same #dice as prior fig
	`isItm opt var & allowance for item use to affect modDx - isItm allows spec of itm to use in usrPik() - otherwise, item is assumed unless option is nonspecific (spell selection, etc in useItm())

	FigAct field's FigDic digit: Used as an 'opted' and an 'acted' flag for figures during Action phase. 0= hasn't yet had a chance to pick an option for the round; 1..9= has picked an option and chosen to roll this number of dice (also carried over from previous round in this form= -10 from previous round stat - see next para); 11..19= has already performed an action this round.
	To start a round, FigDic values >10 are reduced by -10 in the beginning of sidMov(). They remain at this value in case the previous round's value may be required through Movement phase, and in case the figure might perform its action during Movement, when the value would be changed to the new option's #dice and raised by +10. That value is then retained through proAct() for possible reference. Then at the end of proAct(), all values <10 are zeroed at the same time as every FigSeq is zeroed. Then nxtOrd() in oneRnd() checks only those of FigDic <1, and pikAct() assigns the figures' chosen #dice per option from macAct() or usrAct() to FigDic. Then at the end of exeAct(), after the figure with the highest declared #dice has acted and had its FigDic value raised by +10, all FigDic values <10 are zeroed for the next "segment" of the Action phase to choose the next figure to act.
	In oneRnd(), nxtOrd() and pikAct() are called with a return to the calling case, and nxtOrd() looks at only those figures with FigDic <1, so that oneRnd() through pikAct() polls all unacted figures not yet polled until all have accepted their recorded FigDo options and each chosen a number of dice to roll for it, when oneRnd() through exeAct() then passes on to perform the option for the figure with the highest number of dice chosen, or the highest modDX priority in case of a number of dice tie.

	`(Option) isDib flag & OptDib constants' usage: A figure which chooses an action option of Move, Watch or Defend has its number of optDic assigned automatically rather than by choice, and for this purpose these presets are employed. In none of these cases are any dice actually rolled: the number is only used as a precedence determinant.
	As a reference, the Watch action will generally be assigned optDic of 1; so that it's the lowest in any segment of a round and thus won't be finalized (made the dibDic: the figure being noted as "on watch" for the round - see Aiming under Action Options) until all other figures have executed their actions; unless it's replaced in a further segment prior to the end of the round. In this way a figure who uses it to delay choosing an option in a round may decide on each subsequent segment whether to continue to Watch, or pick another action.
	The Move and Defend actions could be treated in the same flexible fashion, but in principle that would make them substantively equal to (or better than, in terms of MA use) the Watch option as concerning its use to delay a choice and permit another to act first. It's therefore preferable (and conceptually more sensible for such goings- on) to assign these options a high number of optDic; and the default value noted is 9. This causes the action chosen to be adopted immediately in a segment.
	If the isDib flag is set false, Move and Defend actions are assigned an optDic of 10 automatically. This is the default setting, and is practically equivalent to a true setting with a OptDib of 9; except there's no likelihood of one being overridden or carried over to another segment, and mainly the figure is effectively marked as acted right when its option choice is made. So with isDib false, after a player is informed that a figure has chosen to Move or Defend, it's removed from the dibDic running for the segment and there's no further brief to the effect that this choice has exceeded all other FigDic chosen in this segment and thus the figure's option is in effect; while other figures' options chosen in the segment would be discarded and required to be laboriously restated in the following segment.

	FigAct field's FigDo/Did digit: Move =1, Watch =2, Ready =3, Defend =4, Strike =5, Jab =6, Hurl =7, Fire =8, Use =9, Dodge =10, Strike2 =11, Fire2 =12. At beginning of sidMov(), FigDo is copied into FigDid, after which FigDo is zeroed. This zero flag causes modDx(,1) to use an adjacent enemy figure (with the best facing bonus) calculated by isBy() if any, else no figure argument, as a ref instead of FigObj (and without clearing FigObj) until FigDo & FigObj are set in macAct()/ UsrAct(). This is necessary because FigDic wouldn't be zeroed until the end of proAct(), as above.

	FigObj (target of chosen option) field's val: if given a '-' prefix, is a map hex coo; if no prefix, is a fig ary elm; if '+' prefix is fig ary elm that owning figure as attacker did damage to with an adjacent attack

	FigHit field's FigDmg digit: Counts all damage of any type taken by the figure in the course of one round (reset to 0 in Movement phase, after Force Retreats check. [`?at start of Action phase] Also note the use of '+' prefix in FigObj fld to denote that the figure scored hits on the indicated adjacent target figure.

	FigRtg field's FigSpc digit: treated as a character rather than a numeric entry= 'H', 'W', 'C' or 'B' (for Hero, Wizard, Creature or Base [vs True] humanoid type). Works in conjunction with the FigCla field's entries of "Adv" or "Bst". Typically, a FigSpc of 'B' or 'C' will make unarmed, HTH and melee attacks with organic weapons specifiec in the FigAtk field of its figPoo pri() elm; whereas a FigSpc of 'H' or 'W' will use carried weapon items for HTH & melee, and use the Unarmed weapon item for barehanded attacks.

Facing of figures:
	1- & 2- hex figures are hexside- pointed, and represented by rectangular markers. Graphically, a 1- hex figure must have an indicator on its gameboard marker for designating at which of the possible hexsides it is pointed (two possibilities when a square marker is used, as in this game). It's sufficient for a multihex figure's facing just to indicate which of its hexes is considered to be its "head". Howbeit, as a programming construct, every figure has the placement orientation of its "leading" side (for a 1- or 2- hex figure) or its leading vertex (for a 3- or 4- hex figure) specified, and shown on its marker.
	Multihex 3- & 4- hex figures are typically vertex- pointed, and represented by a triangular or diamondlike marker. Facing direction for regulation 3- & 4- hex figures is coded as the direction from the figure's head hex through the side of the front hex to the right of its leading vertex. All existing (presently incorporated) multihex animate figures are as regulation, and are given only one hex from which attacks by that figure may originate and to which its view is restricted. Advanced note: Something like Rick Smith's 3- hex spider figure design, with the triangular marker's flat edge forward (the which I consider as also most appropriate for mammoth- like mounts), would still have 1 key head hex & normal programmed assoc facing, but an alt FigFro (qv) eg. "3aaa2aab6ccb" & can thus still have a regulation multihex figure's hexrow- delimited frontage view angle (qv), but with alt orientation to 124 rather than normal 135 and would have to add hex 2 of fig layout (qv) as a view receptor (equates in this case simply to not counting it as a blocking hex for LOS).

	Marker Pivot operation: `"pivot"= figure rotated around its head hex, rather than around an approximate center point - ie. change its facing, but keep head of figure in current head hex

Layout of figures:
	The FigCoo and first hex for coding of any figure's location is its "head" hex. This is the only occupied hex for a 1- hex figure. The second hex of any multihex figure is the hex adjacent to its head in the direction opposite to the head's facing. Thus any 2- hex figure is equivalent to 2 1- hex figures joined nose- to- tail. The third hex for a regulation multihex figure is that adjacent to both first and second hexes in a counterclockwise rotation from the second around the head. The fourth hex for a regulation multihex figure is located relative to the third as the second is to the first (ie. effectively nose- to- tail), and thereby adjacent to both second and third hexes.

`FigFro Positional pattern coding of figures:
	"Position" (in terms of FigFro front- side- rear positonal patterning) 

`Engagement coding for figures [isEgd() sbr]:
	two conditions= engaged or matched: iaw figures' sizes; and two qualifiers= at start of move or during/ upon move
	criteria: in fro hex of opp
	optional: ?if moved over half MA -> can't engage
	effects: 

`View angles of figures:
	`observation - vtx- ptd figs' hexrow- delimited frontage view angle= regulation [effected at extended ranges by objArc() use of col/row deltas for angle arcs vs 1st LOS step for side arcs]

Feature figures:
	`products of Creation spells
	Wall= pst 3 (Standing), blocks movement & LOS
	Shadow= pst 1 (Lying), interferes with LOS (modDX-)
	Fire= pst 1, causes damage to occupant figures - `?dif dmgNop vals at bo rnd vs on mov

Special Moves:
	`Force Retreat
	`Charge Move
	`Shield Rush
	`Push Back
	`Attempt HTH

Special Moves' (Charge In, Shield Rush) Timing: `individual capabilities operable only upon/ during figure's move option (time to be moved) - however, qualifications (can) allow for application at start of move (without having to be moved a step) - doesn't pertain to those Special Moves requiring entry of an opponent's hex (Push Back, Attempt HTH): which may only occur on the move and require instant resolution (to see if actor's move may be continued, or to adapt postures) - movQlf() contains coding to evict a figure that finds itself in another's hex(es) illegally: for instance having entered through the target's front hexes resulting in a MP total greater than MA/ 2
	Examples: `Charging figure moves to within half MA of target figure, then on next round target wins initiative and moves into front facing hex of charger - target may make Shield Rush or Charging move of its own if qua (note prev rd Moved Sta req for Charging), but when charger's time to move comes, if it hasn't been displaced by a target effect, it may invoke Charging move against target without having to be moved further that round

macMov() AI:
	`macMov() picks the closest enemy figure, or the last one targeted per FigObj, and designates examines the hexes surrounding the target figure's marker one- by- one


itmPoo (parent) item elms' coding:

	ItmCla field - "Amped" class items: `fundamental concept of item distinction is that z1$[] array items with the same Typ but different classes are different things (eg can have a Blur spell as well as a Blur ring) - so using 2 items to spec aspects of one thing (as with offhand wpns doubling as shds) requires a special class designator and insuring that the subclass is never instanced to ownership - the designator used is an ampersand; thus the secondary function of a net as a shield has an [`abbreviated] item in the shdItm category but with "&shd" as its class rather than "shd" - the coding required to generically manage amped classes is simply an added conditional loop block in the locItm() fnc sbr which checks for an applicable subclass item (matching '&'+ the arg class) if an owned item's class doesn't match - `?need adn cdns to reduce time drag
	[`advanced ver] Spiked Shield item amped entry: as reverse of offhand items= principally a shield but secondarily a "&wpn" unskilled weapon item - as usr atk dur mov opt (hit rol in cmb w Shd Rus try/ suc) - unshielded tgt sid or itm retention (incl usr) qua

	ItmFnc field to include category of Action for utility magic items= which type of Action a figure Using item is considered to be performing (Watching, Readying, Defending, Charging, Striking, etc.)

	ItmRep field's codes:
	nil= Not carried/ possessed by a figure - for data recording only (eg. Defend opt).
	mul=
	acu= `note that since all "crude" wpn/ shd items are acu (for end of enc lumping together), a figure may carry just 1 of any type
	1ea= A figure may not carry more than one item of this type.
	1of= A figure may not carry more than one item from this type's category (eg. _ Armor).
	uni= unique


itmGrp (child) item elms' coding:

	ItmOwn field: An item may be "hex owned". Such an item's ItmOwn field will contain an '@', suffixed with a two- letter area$ code ("Aa" for the Arena scenario), and then two digits comprising the col & row coos (n+ Asc0: 1..99= '\0049'..'\0147') of the item's hex location. Such an item won't be "attached" to an owning figure element in figGrp [`?alt: addFig(dummy) as needed]. The ItmLoc field will then specify conditions of placement: "buried", "laid", "hung", "cast", "stuck", "littered", etc.

	ItmCla field is same as ItmCla field for parent itmPoo elm, but items which may be either ordinary or magical (or special) employ a designator prefix character: '=' (eg "=wpn") for ordinary types, '+' for magical types, or '*' for special types. `info regarding provisions for generic lookups in has() & locItm() - Use of "by": for DxMod -2 rd ff dg >4 in 1 atk, hitVs() adds a DxMod itm w "by" rpl "fx" in ItmCla -> sidMov() nxt rd chg bak to "fx" for tally in modDx()

	addItm() note: since creating an instance of a nonordinary item requires first adding an ordinary type and then replacing the ItmCla ety (eg with "+wpn"), it might be most convenient to use a dummy/ trove figure to give the item to initially (especially for single acu- type ItmRep itms) and then givItm() to the recipient after ItmCla changes have been made.

	ItmLoc field: `To provide for and record a figure's option to use a 1-handed weapon with both hands (called "2- handed grip") in making a Strike or Jab attack, the ItmLoc field for the weapon used gets an 's' appended to its current entry: so it would read as either "1thands" or "2dhands" `for the duration of ? `to be shown as such rather than just "hands" in chkPfl()

	ItmOpn field: `"fx" ItmCla modifier/ temporary items: =round of expiration - phase of deletion= endRnd().
	Missile weapon item reloading (see Reloading under Item equipping below): Amo itm's field holds total of rolled numbers for Reload attempts while less than required; then holds 0. Wpn itm's field holds 0 upon firing,  or the Reload attempt number rolled this round while total is less than required; then holds itmGrp elm# of loaded amo itm.
	Shield item: Holds Lwr, Odr, Cvr carrying status.

	ItmBon field: 

	ItmId field: 


Item equipping (pikAlt() rou):
	Some options for minor alterations/ revisions in a user- controlled [`?only] figure's items status that require less preparation than would be suitable for a Ready option are handled by provision in pikAlt(), which is coded to manage calls from usrMov() and usrAct(), for changes at any point of a figure's move during the Movement phase, or whenever a figure selects an option during Action phase. Also, pikAlt() is called automatically for a figure at the beginning of usrMov() just as a reminder [`?cfg as pgm opt w optRmd flg var]. Currently, these options include repositioning a shield (Cover, Order, Lower - see fmn_arm.rtf), and reloading a missile weapon other than crossbow or Matchlock (Dart, Stone, Arrow - see fmn_wpn.rtf). In addition, pikAlt() provides for toggling a 2- handed grip on a 1- handed weapon; which automatically reverts to 1- handed at the end of exeAct() for unacted figures preparatory to highest remaining modDX calculation, and in endRnd() for all figures at the end of Action phase.

	[`?opt: coding cmtd out for prv to choose from pikAlt() aft a fig exe an opt of Mov, Wch, Rdy, Dfd - end of exeAct()]

	Reloading a missile weapon puts the selected ammo item's z1$[] itmGrp element number, either the ItmRep= acu- type item of a normal variety or the individual item of a magical/ special one, into the ItmOpn field of the missile weapon's itmGrp element. No reduction or transfer is made to the ammo item until the weapon is fired; when the ItmBon value is decremented for an ammo item of acu- type ItmRep. An entry of less than itmGrp in the weapon's ItmOpn field indicates that the weapon is discharged/ unloaded. An entry of more than zero but less than itmGrp indicates that the owner had tried to load the weapon that round and the value in the entry was the number rolled. The accumulated reloading score is kept in the ItmOpn field of the ammo item selected by the owner for loading that weapon.


Action options:
	Use=
	Fire=
	Watch= Wait as postponement of precedence, plus with automatic Aim bonus
	Jab=
	Ready=
	Hurl=
	Defend= Opponent figure Strike attacks through any front hexes [`?cause attacking weapons' -nH stats to become -(n+1)H and] enable target Defend opt armor (shield) operation. - Aim if MA use <=Watch opt
	Strike=

	Aiming: A figure is credited with Aiming at a target figure it can see when it chooses to Watch or Defend (with Dodge permitted), having used no more MP than allowed for the Watch option, in Action phase. It must pick a target figure, whose array element is entered in the aiming figure's FigObj field (whereas a Defending or Dodging figure not credited with aiming has its own value entered there). When a figure is credited with Aiming, the integer constant of Aim is placed in the FigOn digit of its FigAct field, and the FigSnc digit of its FigAct field is set to the current rndCnt.
	A figure who's credited with Aiming gets a bonus of +(rndCnt- FigSnc, (max 2)) when it makes an attack. Aiming is terminated (FigOn reset) in Action Phase (in pikAct() post- macAct() or usrAct()) if the aiming figure used MP greater than would be allowed for the Watch option, or it chooses an option other than Watch or Defend (with Dodge permitted), or if it chooses a target figure and the value in the attacker's FigObj action focus field is not that of the target figure (the FigObj value is recorded in pikAct() prior to calling macAct() or usrAct(), for comparison upon return).
	macAct() and usrAct() will also prohibit the option selection of Watch when the target isn't in sight. Similarly, when an option of Defend is selected, if the (or a) target figure isn't in sight the target is designated as the acting figure (which would cause Aiming to terminate).
[`alt: fig wishing to Aim at a tgt must pik Wch as 1st opt of rd (rpl FigAct FigDo val of 0) & des tgt FigObj [FigAct FigOn then set to Aim] - Aimg fig will then be assumed to Dfd vs Aim tgt fig's atk only, rather than genl Dfd/ Ddg cap - FigOn will be nul by chg of opt/ tgt, or any Mov/ Ddg]

Action phase priority procedure:
	`id high modDX fig by asgnd opt [ini from proAct()= ?highest modDX opt, or most appro to prev rnd opt] - query for action opt; if dibDic= 0 & rev action or tgt -> recyc (top)
	`set dibFig, dibDx - query dibFig for dibDic; or on Watch/ Defend opt -> fig's FigDic [>0 flgs opt chosen]/ dibDic= 1
	`query lower modDX figs in modDX order; if any revs action or tgt -> recalc modDX
	`query lower modDX fig for poss supervention of dibDic (incl if modDX> dibDx - no tie res: > only - & chosen #dic= dibDic) -> rev dibFig, dibDic (& dibDx only if modDX> dibDx)
	`after all FigDic= 0 figs queried, query any Watch opt figs w FigDic> 0 in FigSeq order - !but, dibDic supervened/ dibFig superceded only if chosen #dic> dibDic as usual for subsequent decl

(potential) Item use effect on modDX
	`pikItm() placed on lvl 4, so may be called from usrPik() in order to specify an item to be used for a figure's selected action, in case various items might cause +/- to modDX - also, FigItm fld incl in figGrp elms to rcd such a choice for nxtOrd() scan (also needed to rcd type of spell cast, etc. even post- action) - However, in basic program, no item choice is required for figures' modDX calcs (pikItm() could be made lvl 3 pre- useItm(), called from exeAct()) - note other basic program simplifications: no actions in Movement phase, no moves in Action phase

atk/ hitVs()'s dmgNop flag int variable - 
	As: Dfd Spl Amr Shd Phy - gets ini at eo hitVs() as 99999 [Use cst=9 ie. normal usage] - Dfd may have upper limit of 5 for integer systems imited to positive values less than 66000
	Phy opt vals: 0= causes no dmg, 1= causes no Phy dmg, 2= causes no Exh dmg, 3= SV ST nulls, 4= SV DX nulls, 5= SV IQ nulls. SVs checked in atkVs(), w number of dice for SV= 4 if fig's side moved first, else 5.
	Shd opt vals: 0= any stops none, 1= nonmagic stops none, 2= no Prot (Rtg % Blk only), 3= 1 & 2
	Amr opt vals:  " "
	Spl opt vals: ignores protective spells of IQ lvl 2 *(n +4 +(hit dice >4)) or less
	Dfd opt vals: 1= neither defend nor dodge effective, 2= can't be defended against, 3= can't be dodged


Excess IQ (talents use):
	For the initial Foeman module [`?expansions retain title] of the Arena scenario, all Hero figures (ie. true classes vs base classes) are granted the following talents automatically.

	(Knowledge [`?/Use] of Weaponry, KOW, Weaponry) Weapon Proficiency (2 IQ [`all will be "Effectual": req "casting" roll])= Use requires current modIQ greater than IQ level of pertinent weapon talent (`? IQ 6). Attacking figure must declare use of Weapon Proficiency prior to dice roll. If the attack hit roll fails, the attacker loses modIQ -1. If the attack hit roll is successful, the attacker loses modIQ -2 on a 4- dice roll, modIQ -1 on a 5- dice roll, or no modIQ loss on a greater than 5- dice roll; and the Low die (note must be >1 dice per Top, Low, Cup of fmn_wpn.rtf) of the damage dice roll for the attack gains +1 if odd, or +2 if even.
	(Burst of Speed, BOS, Speed) Fleetness (1 ST)= Using figure must SV 4D: modST [`?or, nD: modDX w n dep on modST], only permitted at the start of its move. If the SV fails, the figure loses 1 exh ST point; otherwise the figure adds 1D/ 3 (0, 1, 1, 1, 2, 2) to its MA for the round.


Continuing/ Recasting of Spells:
	Spell fx items, noted with the target's cut() FigNam in the ItmOwn field, and which are designated with the spell's itmPoo cut() ItmTyp in the itmGrp ItmCod field, incorporate the xpi rd in ItmOpn and the caster's cut() FigNam in ItmId. These target- owned tag items return the same itmPoo splItm- category primal of the cast spell as does the caster- owned memorized spell item (due to special programming in the pri() sbr that identifies a spell fx item by "mem" in its itmLoc field), so as not to necessitate an extra fx itmPoo item for each spell.
	Note that this implementation format differs from the simpler Beastrove SplMR holding system wherein the fx is owned by the caster with the target noted, even though other fx- type items are owned by their objects. The MindWand practice tries to regularize the assignment of fxs to objects; so the spell fx tag is owned by the object with the caster's cut(FigNam) noted in the ItmId field.
	Continuation of an existing spell fx is prompted for in proAct() when the current value of the rndCnt variable is greater or equal to the fx item's ItmOpn val(); but if not continued, doesn't immediately expire but lasts as an fx until the end of the round (through the succeeding Action phase). Paying the casting/ continuing cost for a spell causes it to last an additional number of rounds determined by a renewal- sequencial factorial progression; in which the casting cost powers the spell through round cast+1 (must be renewed on the round after casting), and the 1st continuation lasts through +2 (just the round following renewal), but then the 2nd continuation lasts through +6 (an additional 4 rounds), the next +24, the next +120, etc. For this purpose, when the spellcast fx tag item is attached to the target, the unused ItmCdn field gets a record string with a ItmCtu dig() starting at 1 and incrementing with each renewal. In this way, with n as the current ItmCtu (prior to incrementation if renewing), the ItmOpn expiration round is increased by n*n! upon renewal, and the round of casting is calculated by ItmOpn minus n!.
	`Recasting option for existing fx: as equal to continuation, but must be Used in Action phase, vs opted in proAct() -  procedure= pick target as self -> pick item as fx item owned by spell's object (special coding in chkPfl() #2/ picking lists such alongwith figure's known spells)


Item Readying (makRdy() sbr):
	Assumptions for initial Foeman module= All figures are right handed (figGrp FigGen field's FigHnd char= 'r'): that is, a figure's "1thand" represents its right side hex, and its "2dhand" represents its left side hex. [`alt: All figures are assumed to be ambidextrous; so that a "1hand" (itmPoo ItmRdy field's dta$) item is considered ready if held in either hand (itmGrp ItmLoc field's dta$= "1thand" or "2dhand").] A "2hand" item is considered ready if held in either hand and the other hand is empty. In such a case with a "2hand" item, however, its status will be displayed as "hands" by the simple player's review screen of the chkPfl() sbr, rather than its actual ItmLoc dta$. Unreadying an item changes its itmGrp ItmLoc field's entry to one of two dta$: either "back" for "2hand" (itmPoo ItmRdy field's dta$) items and shields, or "belt" for any others.
	When makRdy() is called for an item held in a figure's "2dhand" (itmGrp ItmLoc field's dta$), whether the item is considered ready or not, the item is unreadied (dta$ ety chgd to "back" or "belt" as above).
	When makRdy() is called for an item held in a figure's "1thand", whether the item is considered ready or not, the item is transfered to the figure's "2dhand" and any item in the figure's "2dhand" is transfered to the figure's "1thand".
	When makRdy() is called for an unheld item, the figure's 2dhand is first checked for a "2hand" item and if held and the figure's 1thand is empty the item is transfered to the figure's 1thand. Then the unheld item is transfered to the figure's "1thand" if empty; otherwise to the figure's "2dhand" and any item previously in the figure's "2dhand" is unreadied (dta$ ety chgd to "back" or "belt" as above).
	After the changes, if a "2hand" item is held in a figure's "1thand" and the figure's "2dhand" is empty, the item is transfered to its "2dhand" (so that the displayed location of "hands" in the chkPfl() sbr won't repeat if the item is readied).
	[Thus, switching a shield, etc. from the 2dhand to the 1thand when nothing is held in the 1thand is a 2- step process: first ready unreadies to back or belt, then second ready to 1thand. Same in reverse for unreadying an item held in the 1thand: first ready transfers to 2dhand, then second ready unreadies to back or belt. A figure which wishes to keep its shield ready while it plunders a trove would keep the shield in its 1thand, rather than its normal 2dhand location.]


drw() & quarter sbr:
	drwHue colors incl any <0 as "-n:" (nop [`?or transparent hue]) for use to allow a quartered outlined shape to be drawn without having to actually draw the quartered filled shape prior to it when using the fill- inclusive quartering brackets ("[]") argument coding.

z1$[] data elements:
figPoo:
Typ, Siz, Atr, Atk, Ega, HiP, Shp

figGrp:
	Inanimate figure elements are abbreviated with the following common fields
Typ, Cla, Are, Coo, Ori, Img, Hue, Nam
	Animate figure elements then append the following fields
, Ctl, Chr, Lvl, Ep, Gen, Hit, Ogn, Mov, Sta, Sbj, Act, Obj

itmPoo:
Typ, Nat, Cla, Rdy, Src, Rep, Req, Rng, Fnc

`? fx Items:
StMod: mul
DxMod: mul
WpnPr(oficiency): 1ea
Unbal(anced): 1ea
Clinc(hed): mul

itmGrp:
Own, Cod, Cla, Loc, Opn, Bon, Id

variables usage
	optSrc used for the actor fig is replaced by movSrc in routines of lower level


Observation option:
	Every figure, animate or not, maintains a FigObs flag digit which is simply a 0 or 1 in its FigOri field. The FigObs flag is used on a momentary basis in two ways: firstly to flag for process consideration those figures which are acquired by a phasing figure (the actor), and seccondly to flag for display update those figures which are acquired by any figures of the active user side (the watcher).
	The FigObs digit is set by the chkObs() sbr (`when), and then serves to note which figures are acquired for the time being, in place of additional usage of isObs (`?isSee test usage). The isAcq() sbr merely `.
	Display update is fundamentally performed by the shoFrc() sbr (for the watcher's pov), or can be restricted by the shoObs() sbr (for just the actor's pov), and then dynamically updated piecemeal by the movFig() sbr (for the watcher's pov). In the freeware version, configured for only one user- controlled side with but one other machine- controlled side, there is just the one active user side at all times; so when checking for display update, chkObs() can flag any figures acquired by any user- controlled figures, and there's no need for occasional masking/ concealment of the screen display as there would be for two or more opposing user- controlled sides who would need to exchange oversight by phases. `?in such case may use dpyPov var in conjuction with isObs; where dpyPov =currently viewing/ active user side

	The conditions utilized in chkObs() for a source figure to observe a target figure are: if the figures are adjacent, or (their origin hexes per their FigOgn fields) were adjacent at the start of the round (after Forced Retreats and prior to any side's movement), or the source can see the target (with a 60 or 180 degree viewing arc dependent on source status), or the source can see the target's origin hex within a 60 degree viewing arc.

	During a Movement phase, the macMov() rou may be called from the sidMov() rou in stages for a single machine- controlled figure, a number of times up to the MovCyc cst. In order that the moving figure be able to keep in mind its target figure throughout its move once acquired, the FigPrj field is used as a holder. This is mostly useful in the case of avoidance- type moves conducted in steps, in the course of which the moving figure might turn away from its target, but would not be required to subsequently reacquire it before the end of its move.

Utilities:
txt() & rpt(): String argument uses dig()- format number representations. rpt() to dpy long Dta$s in seq segments when user hits Ent.
	txt("011");
	txt("025");
	txt("0112");
	txt("02312");
	txt("111Dta");
	txt("211Dta"); return;
	txt("311Dta"); return;
	txt("411Dta"); return;
	txt("511Dta");