Difference between revisions of "Familiars"
(Created page with "'''Overview''' : Mortal helpfiles give a decent overview of familiars, check them out at: : CALL BAT, CALL CAT, CALL SERPENT, CALL RAVEN, CALL FOX, CALL TOAD : FAMILIAR, FAMILIAR...") |
|||
Line 42: | Line 42: | ||
</tr> | </tr> | ||
</table> | </table> | ||
+ | |||
+ | '''Implementation''' | ||
+ | : Many of the progs on each familiar are exactly the same from familiar to familiar; to customize the behavior, data is pulled from the various data_progs on them, as well as one special sub_prog. These data_progs (and one sub_prog) are unique to each familiar, unlike all the other progs which can be copy/pasted freely between them. | ||
+ | : Most of the data_progs start with "echo_"; these are the various echoes which give the familiar its personality. There is one non-echo data_prog for each mob and obj, called "settings"; this data_prog contains some numbers which control the behavior of the familiar, for things like how picky it is, how obedient, how fast, etc. The one special sub_prog goes on the mobile form, and is called "do_fight_special". This is a hook called from the more general fight_prog on each familiar, and this is where customizations for special fight powers can go. | ||
+ | |||
+ | '''Settings''' | ||
+ | : The settings data_prog, as noted above, controls the behaviors of the familiar. On the obj form, this consists of just two fields: | ||
+ | : Field 0: vnum of mob form, used to transition the obj to mob | ||
+ | : Field 1: minimum number of pulses the familiar will remain as an obj; until this elapses, the familiar will refuse commands to become a mob again (though it will mobify upon death of the caster) | ||
+ | : | ||
+ | : On the mob form of the familiar, there are 9 fields: | ||
+ | : Field 0: vnum of obj form, used to transition the mob to obj | ||
+ | : Field 1: sn of the appropriate call familiar effect. Maintaining this effect on the mob is needed to support the code, for things like proximity bonus. The obj does not need this effect. | ||
+ | : Field 2: obedience threshold; lower is more obedient, meaning the familiar will accept more commands before getting tired. If the work score drops below this number, commands are refused. See sub_prog do_calculate_obedience for implementation details. | ||
+ | : Field 3: speed of the familiar, from 1 to 100. This represents the percentage of pulses the familiar will move to a new room, when en route to somewhere. | ||
+ | : Field 4: patience of the familiar. This is the number of pulses the familiar will wait while scouting, before growing bored. | ||
+ | : Field 5: rumor setting. A value of 0 means the familiar does not support rumors, and will refuse commands to do them. Positive values indicate how many pulses are needed to spread a rumor, or listen for one. Don't use negative values. | ||
+ | : Field 6: spread rumor cooldown, in pulses. This is the number of pulses the familiar will wait after spreading a rumor before it is willing to spread another. | ||
+ | : Field 7: boredom pulses. This is the number of pulses the familiar can be idle before becoming bored (which right now just means it gives a boredom echo, with no mechanical change). | ||
+ | : Field 8: pickiness, higher is more picky about its food. Basically when testing whether the familiar likes a given food vnum, there is a seeded random call from 0 to this number; only on a 0 result will the familiar like it. | ||
+ | |||
+ | '''Mob Echoes''' | ||
+ | [i]Fires when the mob becomes an obj[/i] | ||
+ | >data_prog echo_on_become_object | ||
+ | |||
+ | [i]Fires when told to flee[/i] | ||
+ | >data_prog echo_on_flee | ||
+ | |||
+ | [i]Fires when the mob refuses to do a command[/i] | ||
+ | >data_prog echo_on_disobedience | ||
+ | |||
+ | [i]Fires when the mob doesn't recognize the command[/i] | ||
+ | >data_prog echo_on_unrecognized_command | ||
+ | |||
+ | [i]Fires when told to remember a location[/i] | ||
+ | >data_prog echo_on_location_remembered | ||
+ | |||
+ | [i]Fires if told to do something which requires a remembered room, but no room is remembered[/i] | ||
+ | >data_prog echo_on_location_missing | ||
+ | |||
+ | [i]Fires if there is no path to a remembered room when it is needed[/i] | ||
+ | >data_prog echo_on_location_unpathable | ||
+ | |||
+ | [i]Fires when beginning the walk to fetch or deposit something[/i] | ||
+ | >data_prog echo_on_walk_begun | ||
+ | |||
+ | [i]Fires upon returning to the master with a fetched item, right before giving the item to the master[/i] | ||
+ | >data_prog echo_on_fetch_success | ||
+ | |||
+ | [i]Fires upon returning to the master after a failed fetch attempt[/i] | ||
+ | >data_prog echo_on_fetch_failure | ||
+ | |||
+ | [i]Fires if told to deposit, but has nothing in inventory[/i] | ||
+ | >data_prog echo_nothing_to_deposit | ||
+ | |||
+ | [i]Fires upon returning to the master after a failed deposit attempt (generally from a path that got closed after starting)[/i] | ||
+ | >data_prog echo_on_deposit_failure | ||
+ | |||
+ | [i]Fires upon returning to the master after depositing something (or somethings)[/i] | ||
+ | >data_prog echo_on_deposit_success | ||
+ | |||
+ | [i]Fires if told to safeguard something, but cannot resolve what it is[/i] | ||
+ | >data_prog echo_no_safeguard_object | ||
+ | |||
+ | [i]Fires when told to safeguard something, and recognized it (i.e., is prepared to safeguard)[/i] | ||
+ | >data_prog echo_safeguard_object_ready | ||
+ | |||
+ | [i]Fires when returning a safeguarded item to a master who died[/i] | ||
+ | >data_prog echo_on_safeguard_success | ||
+ | |||
+ | [i]Fires when returning to a master who died, when unable to safeguard an item; be generic, as this also happens if nothing was specified to safeguard[/i] | ||
+ | >data_prog echo_on_safeguard_failure | ||
+ | |||
+ | [i]Fires when told to scout, but cannot resolve a PC from the string[/i] | ||
+ | >data_prog echo_no_pc_to_scout | ||
+ | |||
+ | [i]Fires when scouting begins[/i] | ||
+ | >data_prog echo_scouting_start | ||
+ | |||
+ | [i]Fires REMOTELY when scouting succeeds; make sure this is mpechoat, tell, or something else for remote (or yell if you want the familiar to be useless and obnoxious ;))[/i] | ||
+ | >data_prog echo_on_scouting_success | ||
+ | |||
+ | [i]Fires REMOTELY when mob gets bored of scouting and gives up, without ever sensing the PC; same caveat as above[/i] | ||
+ | >data_prog echo_on_scouting_failure | ||
+ | |||
+ | [i]Fires when told to listen for a rumor[/i] | ||
+ | >data_prog echo_on_rumor_listen_start | ||
+ | |||
+ | [i]Fires when about to relate a rumor to the master (with mprumor, so it will be a 'say')[/i] | ||
+ | >data_prog echo_on_rumor_listen_end | ||
+ | |||
+ | [i]Fires if this familiar does not do rumors, when a rumor is requested. Fill this out for all familiars even if they support rumors, so that we can safely toggle it on and off if we want.[/i] | ||
+ | >data_prog echo_on_rumors_unsupported | ||
+ | |||
+ | [i]Fires when told to spread a rumor, but already did so recently[/i] | ||
+ | >data_prog echo_on_spread_rumor_refused | ||
+ | |||
+ | [i]Fires when told to spread a rumor, but the master hasn't said what yet[/i] | ||
+ | >data_prog echo_on_spread_rumor_waiting | ||
+ | |||
+ | [i]Fires when told to spread a rumor and is ready to begin (master supplied rumor already)[/i] | ||
+ | >data_prog echo_on_spread_rumor_start | ||
+ | |||
+ | [i]Fires upon returning from spreading a rumor[/i] | ||
+ | >data_prog echo_on_spread_rumor_end | ||
+ | |||
+ | [i]Fires when told to stop doing its current task[/i] | ||
+ | >data_prog echo_on_cancel | ||
+ | |||
+ | [i]Fires when familiar transitions to bored state[/i] | ||
+ | >data_prog echo_on_bored | ||
+ | |||
+ | [i]Fires randomly from time to time[/i] | ||
+ | >data_prog echo_on_random | ||
+ | |||
+ | [i]Fires when handed bad food. The familiar will then drop the food.[/i] | ||
+ | >data_prog echo_on_food_bad | ||
+ | |||
+ | [i]Fires when handed good food; the familiar will then eat the food[/i] | ||
+ | >data_prog echo_on_food_good | ||
+ | |||
+ | '''Obj Echoes''' | ||
+ | [i]Fires when turning into a mobile from an object[/i] | ||
+ | >data_prog echo_on_become_mobile | ||
+ | |||
+ | [i]Fires when requested to turn into a mobile, but too recently became an obj[/i] | ||
+ | >data_prog echo_on_remaining_object | ||
+ | |||
+ | [i]Fires when ready to become a mobile again[/i] | ||
+ | >data_prog echo_on_ready_to_become_mobile | ||
+ | |||
+ | [i]Fires on an unrecognized command[/i] | ||
+ | >data_prog echo_on_unrecognized_command | ||
+ | |||
+ | [i]Fires randomly during fights[/i] | ||
+ | >data_prog echo_on_fight |
Revision as of 16:56, 22 February 2015
Overview
- Mortal helpfiles give a decent overview of familiars, check them out at:
- CALL BAT, CALL CAT, CALL SERPENT, CALL RAVEN, CALL FOX, CALL TOAD
- FAMILIAR, FAMILIAR REQUESTS, FAMILIAR SUMMARY
VNUMs
Familiar | Mob vnum | Obj vnum |
Bat | 54 | 146 |
Cat | 56 | 149 |
Fox | 53 | 148 |
Serpent | 52 | 144 |
Raven | 50 | 147 |
Toad | 55 | 145 |
Implementation
- Many of the progs on each familiar are exactly the same from familiar to familiar; to customize the behavior, data is pulled from the various data_progs on them, as well as one special sub_prog. These data_progs (and one sub_prog) are unique to each familiar, unlike all the other progs which can be copy/pasted freely between them.
- Most of the data_progs start with "echo_"; these are the various echoes which give the familiar its personality. There is one non-echo data_prog for each mob and obj, called "settings"; this data_prog contains some numbers which control the behavior of the familiar, for things like how picky it is, how obedient, how fast, etc. The one special sub_prog goes on the mobile form, and is called "do_fight_special". This is a hook called from the more general fight_prog on each familiar, and this is where customizations for special fight powers can go.
Settings
- The settings data_prog, as noted above, controls the behaviors of the familiar. On the obj form, this consists of just two fields:
- Field 0: vnum of mob form, used to transition the obj to mob
- Field 1: minimum number of pulses the familiar will remain as an obj; until this elapses, the familiar will refuse commands to become a mob again (though it will mobify upon death of the caster)
- On the mob form of the familiar, there are 9 fields:
- Field 0: vnum of obj form, used to transition the mob to obj
- Field 1: sn of the appropriate call familiar effect. Maintaining this effect on the mob is needed to support the code, for things like proximity bonus. The obj does not need this effect.
- Field 2: obedience threshold; lower is more obedient, meaning the familiar will accept more commands before getting tired. If the work score drops below this number, commands are refused. See sub_prog do_calculate_obedience for implementation details.
- Field 3: speed of the familiar, from 1 to 100. This represents the percentage of pulses the familiar will move to a new room, when en route to somewhere.
- Field 4: patience of the familiar. This is the number of pulses the familiar will wait while scouting, before growing bored.
- Field 5: rumor setting. A value of 0 means the familiar does not support rumors, and will refuse commands to do them. Positive values indicate how many pulses are needed to spread a rumor, or listen for one. Don't use negative values.
- Field 6: spread rumor cooldown, in pulses. This is the number of pulses the familiar will wait after spreading a rumor before it is willing to spread another.
- Field 7: boredom pulses. This is the number of pulses the familiar can be idle before becoming bored (which right now just means it gives a boredom echo, with no mechanical change).
- Field 8: pickiness, higher is more picky about its food. Basically when testing whether the familiar likes a given food vnum, there is a seeded random call from 0 to this number; only on a 0 result will the familiar like it.
Mob Echoes [i]Fires when the mob becomes an obj[/i] >data_prog echo_on_become_object
[i]Fires when told to flee[/i] >data_prog echo_on_flee
[i]Fires when the mob refuses to do a command[/i] >data_prog echo_on_disobedience
[i]Fires when the mob doesn't recognize the command[/i] >data_prog echo_on_unrecognized_command
[i]Fires when told to remember a location[/i] >data_prog echo_on_location_remembered
[i]Fires if told to do something which requires a remembered room, but no room is remembered[/i] >data_prog echo_on_location_missing
[i]Fires if there is no path to a remembered room when it is needed[/i] >data_prog echo_on_location_unpathable
[i]Fires when beginning the walk to fetch or deposit something[/i] >data_prog echo_on_walk_begun
[i]Fires upon returning to the master with a fetched item, right before giving the item to the master[/i] >data_prog echo_on_fetch_success
[i]Fires upon returning to the master after a failed fetch attempt[/i] >data_prog echo_on_fetch_failure
[i]Fires if told to deposit, but has nothing in inventory[/i] >data_prog echo_nothing_to_deposit
[i]Fires upon returning to the master after a failed deposit attempt (generally from a path that got closed after starting)[/i] >data_prog echo_on_deposit_failure
[i]Fires upon returning to the master after depositing something (or somethings)[/i] >data_prog echo_on_deposit_success
[i]Fires if told to safeguard something, but cannot resolve what it is[/i] >data_prog echo_no_safeguard_object
[i]Fires when told to safeguard something, and recognized it (i.e., is prepared to safeguard)[/i] >data_prog echo_safeguard_object_ready
[i]Fires when returning a safeguarded item to a master who died[/i] >data_prog echo_on_safeguard_success
[i]Fires when returning to a master who died, when unable to safeguard an item; be generic, as this also happens if nothing was specified to safeguard[/i] >data_prog echo_on_safeguard_failure
[i]Fires when told to scout, but cannot resolve a PC from the string[/i] >data_prog echo_no_pc_to_scout
[i]Fires when scouting begins[/i] >data_prog echo_scouting_start
[i]Fires REMOTELY when scouting succeeds; make sure this is mpechoat, tell, or something else for remote (or yell if you want the familiar to be useless and obnoxious ;))[/i] >data_prog echo_on_scouting_success
[i]Fires REMOTELY when mob gets bored of scouting and gives up, without ever sensing the PC; same caveat as above[/i] >data_prog echo_on_scouting_failure
[i]Fires when told to listen for a rumor[/i] >data_prog echo_on_rumor_listen_start
[i]Fires when about to relate a rumor to the master (with mprumor, so it will be a 'say')[/i] >data_prog echo_on_rumor_listen_end
[i]Fires if this familiar does not do rumors, when a rumor is requested. Fill this out for all familiars even if they support rumors, so that we can safely toggle it on and off if we want.[/i] >data_prog echo_on_rumors_unsupported
[i]Fires when told to spread a rumor, but already did so recently[/i] >data_prog echo_on_spread_rumor_refused
[i]Fires when told to spread a rumor, but the master hasn't said what yet[/i] >data_prog echo_on_spread_rumor_waiting
[i]Fires when told to spread a rumor and is ready to begin (master supplied rumor already)[/i] >data_prog echo_on_spread_rumor_start
[i]Fires upon returning from spreading a rumor[/i] >data_prog echo_on_spread_rumor_end
[i]Fires when told to stop doing its current task[/i] >data_prog echo_on_cancel
[i]Fires when familiar transitions to bored state[/i] >data_prog echo_on_bored
[i]Fires randomly from time to time[/i] >data_prog echo_on_random
[i]Fires when handed bad food. The familiar will then drop the food.[/i] >data_prog echo_on_food_bad
[i]Fires when handed good food; the familiar will then eat the food[/i] >data_prog echo_on_food_good
Obj Echoes [i]Fires when turning into a mobile from an object[/i] >data_prog echo_on_become_mobile
[i]Fires when requested to turn into a mobile, but too recently became an obj[/i] >data_prog echo_on_remaining_object
[i]Fires when ready to become a mobile again[/i] >data_prog echo_on_ready_to_become_mobile
[i]Fires on an unrecognized command[/i] >data_prog echo_on_unrecognized_command
[i]Fires randomly during fights[/i] >data_prog echo_on_fight