Difference between revisions of "Prog Section 5"

From Immwiki
Jump to: navigation, search
 
m
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Mobile Memory and PC Data Fields =
+
=Mobile Memory and PC Data Fields=
 +
 
 
  <i>"We all have nightmares to remind ourselves who we really are."</i>
 
  <i>"We all have nightmares to remind ourselves who we really are."</i>
  -- Leonard Shelby, Memento
+
    -- Leonard Shelby, Memento
  
One of the most prominently lacking features from the original prog specification was  
+
: 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
+
: 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’).
+
: state (other than ‘fighting’ or ‘not fighting’).
  
For example, mobiles could do none of the following:
+
: For example, mobiles could do none of the following:
  - Remember which pc’s had been tasked with a quest  
+
- Remember which pc’s had been tasked with a quest  
  - Remember pc’s who have attacked them in the past  
+
- Remember pc’s who have attacked them in the past  
  - Have a dialogue with a pc, where the mobile remembers what has been said  
+
- 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 be attacked by all the mobs in a given town or location  
  - Marking a pc to get lower prices/preferred treatment from various mobs  
+
- 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  
+
: Given the dearth of these features, we have implemented several different solutions for  
these problems.  
+
: these problems.  
  
<b>MOBILE MEMORY</b>
+
=MOBILE MEMORY=
  
  <b>Integer Memory:</b>
+
==Integer Memory==
  Firstly, every instance of a mobile has ten integer values associated with it. These
+
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  
+
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,  
+
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,  
+
and then tested by the mobile to see if they are equal to, not equal to, greater than,  
  or less than a specific value.
+
or less than a specific value.
 
    
 
    
  To see why this might be useful, consider a hen, which can be "fed" grain. Every time  
+
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
+
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,
+
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.  
+
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:
+
The following are the mpcommands and if checks associated with mobile integer memory:
    mpvalueup
+
:    mpvalueup
    mpvaluedown
+
:    mpvaluedown
    mpvalueset
+
:    mpvalueset
    if mobvalue(<slot #>)
+
:    mpvaluerand
 +
:    if mobvalue(<slot #>)
  
  In addition to these, the value of a slot can be referenced by a variable, given by $0, $1, ... $9,
+
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.  
+
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
+
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  
+
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)].  
+
side of any if check (i.e., before the operator)].  
 +
 
 +
==String Memory==
 +
(new info should go here...)
  
  <b>Character Memory:</b>
+
==Character Memory==
  After implementing integer memory for mobiles, we discovered that while useful, it was not yet
+
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,   
+
complete enough to allow for things we had planned. So, mobiles were given character memory,   
  in the form of focus fields.  
+
in the form of focus fields.  
  
  Essentially, the focus fields allow the mobile to store PC information. Mobiles have two focus  
+
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.  
+
fields, though they may have more in the future. Mobiles store their focus in the $f variable.  
  
    $f0 references the first focus slot.
+
:    $f0 references the first focus slot.
    $f1 references the second focus slot.
+
:    $f1 references the second focus slot.
  
  The following mpcommands govern the focus system:
+
The following mpcommands govern the focus system:
    mpfocus: Focuses on target player currently in the game, with specified focus slot
+
:    mpfocus: Focuses on target player currently in the game, with specified focus slot
    mpunfocus: Unfocuses the specified slot.
+
:    mpunfocus: Unfocuses the specified slot.
  
  <b>Memory:</b>
+
==Memory==
  In addition to the ability to focus on individual pc’s, a mobile can also "remember"  
+
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 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
+
a mobile either does, or does not "remember" that pc. This memory persists until the mobile
  "forgets" the player, or until the mobile perishes.
+
"forgets" the player, or until the mobile perishes.
  
  The following mpcommands govern the remembrance system:
+
The following mpcommands govern the remembrance system:
    mpremember: Remembers target player  
+
:    mpremember: Remembers target player  
    mpunremember: Forget target player if remembers: True if mobile remembers target player  
+
:    mpunremember: Forget target player if remembers: True if mobile remembers target player  
  
  <b>Personal PC Value Fields</b>
+
==Personal PC Value Fields==
  If a mobile has "remember"-ed a pc, they gain a single integer field which they associate
+
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  
+
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,
+
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
+
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
+
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,
+
them, set their personal value to 5, and both of them would "see" the PC as having their own,
  personal value.  
+
personal value.  
  
  The following mpcommands govern the personal pc value fields:
+
The following mpcommands govern the personal pc value fields:
    mpmemvset: Sets a value on target player  
+
:    mpmemvset: Sets a value on target player  
    mpmemvup: Increase a player’s value by one  
+
:    mpmemvup: Increase a player’s value by one  
    mpmemvdown: Decrease a player’s value by two  
+
:    mpmemvdown: Decrease a player’s value by two  
    if mobvcheck: Checks a player’s personal value field  
+
:    if mobvcheck: Checks a player’s personal value field  
 
      
 
      
 
    
 
    
 
        
 
        
<b>PC DATA</b>
+
=PC DATA=
  
  Every player has 65,535 binary values associated with their player file. These values can be
+
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.  
+
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.  
+
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.
+
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:
+
The following are commands which can set bits:
    mpbitset: Sets a bit to 0 or 1
+
:    mpbitset: Sets a bit to 0 or 1
    mpaddaff (using toggleoffaff or toggleonaff to toggle the bit after a specified duration)
+
:    mpaddaff (using toggleoffaff or toggleonaff to toggle the bit after a specified duration)
    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]
+

Latest revision as of 00:30, 31 January 2015

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
mpvaluerand
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)].

String Memory

(new info should go here...)

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