Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 21

Thread: Boolean modifiers for certain types of equipment

  1. #11
    Developer
    Join Date
    Aug 2009
    Posts
    2,897

    Default

    r19148 adds the proposed change from #10. A sample run saw improved runtime of the sample maximizer command by something like 30%.

  2. #12
    Developer
    Join Date
    Apr 2010
    Posts
    5,071

    Default

    I have toyed with adding a comparison of outfit sets whose bonus changes with number with the best of other items, so we can prune items that only might help before the full iteration. It should be possible, and make a big difference, but is quite a big project.

  3. #13
    Developer
    Join Date
    Aug 2009
    Posts
    2,897

    Default

    When I manually calculate value of combinations with variable effects (e.g. hobo power), I consider the value on a per-item basis to be averaged across all the items. For instance, full hodgman outfit + sock + Hodgman's garbage sticker (150 hobo power -> 150% meat) would be worth +30% meat drop each.

    I'd need to think some more to figure out how to translate that into code. What works for me in the time being is just maximizing with lots of +equip clauses.


    Some tangential ramblings about meatfarming:

    30% per slot is actually pretty bad in today's climate -- cajun carrot rawhide latte lover's mug, great wolf's beastly trousers, crumpled felt fedora puts you at 40% meat, 25lb which with fish head + robortender is always worth >= 140% from just three items, and at typical operating points (less than 160lb which becomes 185lb buffed robortender), is worth 160%+.

    It might be worth considering for the 5 hobo summons a day, but even then that's only 50% meat on average, which is no longer worthwhile when you consider additional value from, say, Screege drops, which my notes consistently say is worth ~196 meat / combat, which in Barf with boombox song is worth an additional ~71% meat... with cheap sunglasses and belt of loathing, there's not really room in Barf for even +50% meat accessories, and that's ignoring other crazy stuff you might be doing.

  4. #14
    Senior Member
    Join Date
    Apr 2018
    Posts
    221

    Default

    I feel this is getting a bit off-topic. I simply want to eliminate the existing hardcoded behavior for things like equipping a certain weapon type by expanding the existing boolean modifier system.

  5. #15
    Senior Member
    Join Date
    Apr 2018
    Posts
    221

    Default

    ... and possibly explode required computation time.
    Originally Posted by the dictator View Post
    That’s actually not what causes the combinatorial explosion. No, what really makes it suffer is writing a personal ASH library that allows you to specify modifiers and required equipment using records, then telling it to explicitly consider every accessible familiar that either has an impact on the specified modifiers or has the “variable” proxy record field set to true.

    I’ve had it calculate over 12,000,000 combinations once. It’s worth it, too: this approach is clever enough to account for extremely complicated behavior such as different familiar weights, accessible equipment, effect combinations, underwater requirements, and special cases like the Fancypants Scarecrow.

    I’m actually fine with that sort of wait, since I can do other things while it runs, but I can see why familiars are usually ignored. Disabling the portion of my script that concerns familiar switching makes the Maximizer finish almost instantaneously in comparison.

  6. #16
    Developer
    Join Date
    Apr 2010
    Posts
    5,071

    Default

    I feel this is getting a bit off-topic. I simply want to eliminate the existing hardcoded behavior for things like equipping a certain weapon type by expanding the existing boolean modifier system.
    Originally Posted by Saklad5 View Post
    It does look like making club, utensil, knife and accordion into Boolean modifiers would make this work better (and needed as getScore considers only modifiers, not items).

    So I think it's converting bitmaps to longs (as this will take us over 32 booleans), adding 4 boolean modifiers, and remove the current handling for them in Maximizer.

    We've also either got to add these Modifiers when reading equipment.txt, or add them to modifiers.txt and add recognising them on new items in DebugDatabase etc. Or I guess just add them during Maximization to the item may be simpler.
    Last edited by Darzil; 04-05-2019 at 07:57 PM.

  7. #17
    Developer
    Join Date
    Apr 2010
    Posts
    5,071

    Default

    Well, it isn't quite that simple.

    Most items that give a boolean exist on relatively few items, and Maximizer just passes them all through.

    However, there are loads of items that meet these booleans, so we need to prune the list to just the best one in these cases.

  8. #18
    Developer
    Join Date
    Apr 2010
    Posts
    5,071

    Default

    This isn't done yet, but I think I've hit the wall for today.

    It works, badly and slowly, for +club, as it hasn't yet got pruning.

    It doesn't work, yet, for +accordion, +knife or +utensil, I suspect I've missed turning an int into a long somewhere.

    If anyone wants to take a look, feel free, have attached the patch so far. boolean.patch

  9. #19
    Senior Member
    Join Date
    Apr 2018
    Posts
    221

    Default

    It’s worth noting that “Club” has a special case: if you have the effect “Iron Palms” (or possibly just the skill “Iron Palm Technique”, so the Maximizer could toggle it as beneficial), then swords qualify as clubs.

  10. #20
    Senior Member
    Join Date
    Apr 2018
    Posts
    221

    Default

    Well, it isn't quite that simple.

    Most items that give a boolean exist on relatively few items, and Maximizer just passes them all through.

    However, there are loads of items that meet these booleans, so we need to prune the list to just the best one in these cases.
    Originally Posted by Darzil View Post
    I’m not sure I entirely understand why handling like that is necessary. The Maximizer is fine with “min” on a numeric modifier, which seems much more difficult in terms of relevant items. Couldn’t you just use the same techniques for boolean modifiers, with a minimum value of “true”/1?

    On a related note, why make modifiers maximizer-only? It is easy to conceive of use cases for such modifiers in scripts.

Posting Permissions

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