Results 1 to 7 of 7

Thread: Mummery

  1. #1

    Default Mummery

    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).

  2. #2
    Developer
    Join Date
    Aug 2009
    Posts
    2,709

    Default

    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).
    Originally Posted by lostcalpolydude View Post
    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?

  3. #3

    Default

    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.

  4. #4

    Default

    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.

  5. #5

    Default

    The first part of this is done in 18289, with no support yet for extra bonuses from using beneficial familiars.

  6. #6

    Default

    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.

  7. #7

    Default

    18297 adds a mummery CLI command.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •