Difference between revisions of "Prog Section 5"

From Immwiki
Jump to: navigation, search
 
Line 99: Line 99:
 
     if isbitset: True if the specified bit is set to 1  
 
     if isbitset: True if the specified bit is set to 1  
  
----
+
[[category:Leviticus]]
[[Prog Section 4]] | [[Prog Section 6]] | [http://www.ender.com/~jolinn/avendarbible/wiki.pl?Leviticus Leviticus -- Builder Resources Page]
+

Revision as of 23:41, 26 April 2011

= Mobile Memory and PC Data Fields =
"We all have nightmares to remind ourselves who we really are."
 -- Leonard Shelby, Memento
One of the most prominently lacking features from the original prog specification was 
the ability for mobile’s to have a notion of "memory", or the total lack of any internal
state (other than ‘fighting’ or ‘not fighting’).
For example, mobiles could do none of the following:
 - Remember which pc’s had been tasked with a quest 
 - Remember pc’s who have attacked them in the past 
 - Have a dialogue with a pc, where the mobile remembers what has been said 
 - Marking a pc to be attacked by all the mobs in a given town or location 
 - Marking a pc to get lower prices/preferred treatment from various mobs 
Given the dearth of these features, we have implemented several different solutions for 
these problems. 
MOBILE MEMORY 
 Integer Memory:
  Firstly, every instance of a mobile has ten integer values associated with it. These
  values, or "slots" as they are referred to, are themselves number from 0 to 9. From 
  within a prog, these values can be set to specific values, incremented, decremented, 
  and then tested by the mobile to see if they are equal to, not equal to, greater than, 
  or less than a specific value.
  
  To see why this might be useful, consider a hen, which can be "fed" grain. Every time 
  the hen is fed, it would increment its "0" slot. If the "0" slot is greater than 10 (it
  has been fed ten times), it refuses to eat, being too full. Then, over time (via a rand_prog,
  say), the hen gradually becomes less full, until it’s ready to eat again. 
  The following are the mpcommands and if checks associated with mobile integer memory:
    mpvalueup
    mpvaluedown
    mpvalueset
    if mobvalue(<slot #>)
  In addition to these, the value of a slot can be referenced by a variable, given by $0, $1, ... $9,
  where the number corresponds to the given slot number. 
  
  Thus, if $0 had a value of "3", and $0 appeared in a prog, $0 would be interpreted as "3" wherever
  it occurred. [Note: For technical reasons, the $# variables can never appear on the left hand 
  side of any if check (i.e., before the operator)]. 
 Character Memory:
  After implementing integer memory for mobiles, we discovered that while useful, it was not yet
  complete enough to allow for things we had planned. So, mobiles were given character memory,   
  in the form of focus fields. 
  Essentially, the focus fields allow the mobile to store PC information. Mobiles have two focus 
  fields, though they may have more in the future. Mobiles store their focus in the $f variable. 
    $f0 references the first focus slot.
    $f1 references the second focus slot.
  The following mpcommands govern the focus system:
    mpfocus: Focuses on target player currently in the game, with specified focus slot
    mpunfocus: Unfocuses the specified slot.
 Memory:
  In addition to the ability to focus on individual pc’s, a mobile can also "remember" 
  a pc. Essentially, this is a binary toggle that every mobile has. Given a specific pc, 
  a mobile either does, or does not "remember" that pc. This memory persists until the mobile
  "forgets" the player, or until the mobile perishes.
  The following mpcommands govern the remembrance system:
    mpremember: Remembers target player 
    mpunremember: Forget target player if remembers: True if mobile remembers target player 
 Personal PC Value Fields
  If a mobile has "remember"-ed a pc, they gain a single integer field which they associate
  with a pc. This operates exactly as the mobile integer memory fields, except that a different 
  set of commands reference this value, it is associated only with a specific remembered PC,
  and (most importantly), it is relative to that particular mob. This means, for example, that
  a hen could remember a pc, and set their personal value to 3, while an ethron could remember
  them, set their personal value to 5, and both of them would "see" the PC as having their own,
  personal value. 
  The following mpcommands govern the personal pc value fields:
    mpmemvset: Sets a value on target player 
    mpmemvup: Increase a player’s value by one 
    mpmemvdown: Decrease a player’s value by two 
    if mobvcheck: Checks a player’s personal value field 
   
 
      
PC DATA
 Every player has 65,535 binary values associated with their player file. These values can be
 toggled or checked by progs, and are permanent, until altered by a mobile or an affect. 
 By no coincidence, there is a one to one correspondence between vnums and these binary bits. 
 In general, a builder should only be altering bits which correspond to vnums in his or her area.
 The following are commands which can set bits:
   mpbitset: Sets a bit to 0 or 1
   mpaddaff (using toggleoffaff or toggleonaff to toggle the bit after a specified duration)
   if isbitset: True if the specified bit is set to 1