Difference between revisions of "Prog Section 5"
From Immwiki
m |
|||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
− | + | =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 | |
− | + | : 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 | |
[[category:Leviticus]] | [[category:Leviticus]] |
Latest revision as of 00:30, 31 January 2015
Contents
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