New Content - Implemented Mummery

lostcalpolydude

Developer
Staff member
This should be interesting to handle. The first step is tracking what bonus is applied to each familiar. I'm thinking a _mummery setting that tracks familiar number and choice number, separated with some arbitrary punctuation, looking something like
Code:
211,1:1,4
Keeping that updated requires actually checking it, in case a value needs replacing instead of simply appending (when putting something new on an already-buffed familiar).

After that there will need to be some modifier handling. Even the simplest case requires some new code, but this will have to wait on spading.

I expect it's worth having a mummery CLI command, and to support that (and because people will want it anyway) some tracking of used buffs (since _mummery won't completely cover that).
 

heeheehee

Developer
Staff member
Keeping that updated requires actually checking it, in case a value needs replacing instead of simply appending (when putting something new on an already-buffed familiar).

My (albeit limited) understanding is that the replaced choice is no longer around, though. Blindly appending could make sense here (in that it would allow us to track the entire history), provided that parsing does the right thing (i.e. takes the last matching value in the preference).

Splitting this out into a family of prefs might also make modifier handling simpler. I don't suppose nesting functions (e.g. "fam(pref(foo))") works in modifier expressions, does it?
 

lostcalpolydude

Developer
Staff member
So now that the variable modifier stuff is working and at least partly spaded, it's probably clearer why properly supporting the modifiers is difficult, regardless of how things are saved in preferences.

There seem to be common elements to familiars that get extra bonuses from various costumes. Perhaps that could be tracked in familiars.txt somehow. I haven't really thought about the rest of the process for how that would work.
 

lostcalpolydude

Developer
Staff member
I finally have an idea for supporting basic modifiers. Have _mummeryMods, which could have something like
Code:
Meat Drop: [15*fam(Leprechaun)], Item Drop: [15*fam(Baby Gravy Fairy)]
Keep that updated as new things are applied, and applying modifiers is straightforward.

The wiki has 13 familiar attributes listed for giving some extra benefit, with at least 5 of those being important enough to track properly. Actually applying those would just mean adding
Code:
Meat Drop: [30*fam(Robortender)]
to _mummeryMods, and the complicated part is knowing that it should be 30 instead of 15.

I'm thinking about having attributes in familiars.txt as a new field after arena parameters, comma-separated, and then stored in a Map<FamiliarData? String?,List<String>>. Throw together a function or two to check if a familiar has an attribute, and this doesn't seem too bad outside of trusting a community spreadsheet for data.
 

lostcalpolydude

Developer
Staff member
With 18295, I think support for this is mostly complete. All that's missing is familiar attributes, and those can be added as they are spaded and people notice that mafia is missing them still.

Familiars now have an attributes field, which can help with a script that is comparing mafia's data with other source, as well as whatever else it gets used for.
 
Top