Familiars

From Immwiki
Revision as of 17:02, 22 February 2015 by Chadim (Talk | contribs)

Jump to: navigation, search

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. There are no data_progs which are not unique to a familiar.
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.
Note that an echo data_prog can have many lines, offering options to the prog engine, which will pick one at random. More lines means more variety, which helps the familiar feel special, so add any good ones you think up! Just keep in the mind the comments for each echo, listed below, to avoid any awkwardness with the phrasing.

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

Fires when the mob becomes an obj
>data_prog echo_on_become_object
Fires when told to flee
>data_prog echo_on_flee
Fires when the mob refuses to do a command
>data_prog echo_on_disobedience
Fires when the mob doesn't recognize the command
>data_prog echo_on_unrecognized_command
Fires when told to remember a location
>data_prog echo_on_location_remembered
Fires if told to do something which requires a remembered room, but no room is remembered
>data_prog echo_on_location_missing
Fires if there is no path to a remembered room when it is needed
>data_prog echo_on_location_unpathable
Fires when beginning the walk to fetch or deposit something
>data_prog echo_on_walk_begun
Fires upon returning to the master with a fetched item, right before giving the item to the master
>data_prog echo_on_fetch_success
Fires upon returning to the master after a failed fetch attempt
>data_prog echo_on_fetch_failure
Fires if told to deposit, but has nothing in inventory
>data_prog echo_nothing_to_deposit
Fires upon returning to the master after a failed deposit attempt (generally from a path that got closed after starting)
>data_prog echo_on_deposit_failure
Fires upon returning to the master after depositing something (or somethings)
>data_prog echo_on_deposit_success
Fires if told to safeguard something, but cannot resolve what it is
>data_prog echo_no_safeguard_object
Fires when told to safeguard something, and recognized it (i.e., is prepared to safeguard)
>data_prog echo_safeguard_object_ready
Fires when returning a safeguarded item to a master who died
>data_prog echo_on_safeguard_success
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
>data_prog echo_on_safeguard_failure
Fires when told to scout, but cannot resolve a PC from the string
>data_prog echo_no_pc_to_scout
Fires when scouting begins
>data_prog echo_scouting_start
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 ;))
>data_prog echo_on_scouting_success
Fires REMOTELY when mob gets bored of scouting and gives up, without ever sensing the PC; same caveat as above
>data_prog echo_on_scouting_failure
Fires when told to listen for a rumor
>data_prog echo_on_rumor_listen_start
Fires when about to relate a rumor to the master (with mprumor, so it will be a 'say')
>data_prog echo_on_rumor_listen_end
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.
>data_prog echo_on_rumors_unsupported
Fires when told to spread a rumor, but already did so recently
>data_prog echo_on_spread_rumor_refused
Fires when told to spread a rumor, but the master hasn't said what yet
>data_prog echo_on_spread_rumor_waiting
Fires when told to spread a rumor and is ready to begin (master supplied rumor already)
>data_prog echo_on_spread_rumor_start
Fires upon returning from spreading a rumor
>data_prog echo_on_spread_rumor_end
Fires when told to stop doing its current task
>data_prog echo_on_cancel
Fires when familiar transitions to bored state
>data_prog echo_on_bored
Fires randomly from time to time
>data_prog echo_on_random
Fires when handed bad food. The familiar will then drop the food.
>data_prog echo_on_food_bad
Fires when handed good food; the familiar will then eat the food
>data_prog echo_on_food_good

Obj Echoes

Fires when turning into a mobile from an object
>data_prog echo_on_become_mobile
Fires when requested to turn into a mobile, but too recently became an obj
>data_prog echo_on_remaining_object
Fires when ready to become a mobile again
>data_prog echo_on_ready_to_become_mobile
Fires on an unrecognized command
>data_prog echo_on_unrecognized_command
Fires randomly during fights
>data_prog echo_on_fight