I recently changed the familiar types in familiars.txt to replace "combat" with a bunch of different things that a familiar could do during or after combat:
combat0 - physical damage
combat1 - elemental damage
block
delevel
hp0 - hp gain during combat
hp1 - hp gain after combat
mp0 - mp gain during combat
mp1 - mp gain after combat
I also defined "other" to mean "familiar does something else during or after combat" and "none" to mean "familiar does nothing, ever"
I suggest that instead we have
other0 - familiar does something else during combat (steals Meat, for example)
other1 - familiar does something else after combat (explores Black Forest, for example)
... leaving "none" for Pet Rock-type familiars
(what about Doppelshifter, Comma Chameleon, Hatrack, PantsRack?)
We should add the corresponding boolean fields to the $familiar proxy record
.other_action_during_combat
.other_action_after_combat
We should change the menus in the compact side pane to add "other during combat" to the "combat menu", add "other after combat", to the toplevel menu, and change the toplevel "other" menu to "none".
Heck, perhaps "hp restore after combat" and "mp restore after combat" should also migrate out of the "combat" menu and we have a new toplevel menu - "after combat", say - which has submenus for hp1, mp1, and other1.
Given the above, we should carefully examine all familiars and make sure that their categories are complete and correct.
combat0 - physical damage
combat1 - elemental damage
block
delevel
hp0 - hp gain during combat
hp1 - hp gain after combat
mp0 - mp gain during combat
mp1 - mp gain after combat
I also defined "other" to mean "familiar does something else during or after combat" and "none" to mean "familiar does nothing, ever"
I suggest that instead we have
other0 - familiar does something else during combat (steals Meat, for example)
other1 - familiar does something else after combat (explores Black Forest, for example)
... leaving "none" for Pet Rock-type familiars
(what about Doppelshifter, Comma Chameleon, Hatrack, PantsRack?)
We should add the corresponding boolean fields to the $familiar proxy record
.other_action_during_combat
.other_action_after_combat
We should change the menus in the compact side pane to add "other during combat" to the "combat menu", add "other after combat", to the toplevel menu, and change the toplevel "other" menu to "none".
Heck, perhaps "hp restore after combat" and "mp restore after combat" should also migrate out of the "combat" menu and we have a new toplevel menu - "after combat", say - which has submenus for hp1, mp1, and other1.
Given the above, we should carefully examine all familiars and make sure that their categories are complete and correct.