Difference between revisions of "Prog Section 5"
From Immwiki
m |
|||
Line 45: | Line 45: | ||
: 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...) | ||
==Character Memory== | ==Character Memory== |
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