Page 1 of 3 1 2 3 LastLast
Results 1 to 10 of 23

Thread: Add proxy record field to effect tracking whether it is decremented by PVP

  1. #1
    Senior Member
    Join Date
    Apr 2018
    Posts
    158

    Default Add proxy record field to effect tracking whether it is decremented by PVP

    When you initiate a PVP fight, all but a few effects are decremented. Those exceptions are actually quite important, as minigames like Purity also ignore them. Adding a boolean to the “effect” ASH type to track this property would be very useful for PVP scripts.

    It should not be difficult to spade and implement: KoLmafia could assume any effect is decremented by default, then log any evidence to the contrary. I believe item plurals use a similar approach already.

  2. #2
    Senior Member
    Join Date
    Apr 2018
    Posts
    158

    Default

    Is there any interest in something like this? If so, I can submit a patch that adds the field quite easily.

    I might leave the bit about flagging conflicting evidence to someone who is more familiar with the inner workings of KoLmafia, though. There’s probably a more efficient approach than tracking every effect before initiating a fight, then looping through each effect afterwards to see if it decremented.

  3. #3
    Developer
    Join Date
    Apr 2010
    Posts
    4,997

    Default

    My gut feeling is spading it is going to be really painful, but that the main (only?) ones are already known (http://kol.coldfront.net/thekolwiki/index.php/PvP), so I'd go with what is known.

    As the list is small, and going to be rarely added to, I'd suggest having a hard coded list if we (rather than pvp scripters) are going to maintain them. An extra field in the statuseffects.txt for capturing this would be overkill.

    I certainly have no interest in doing adding this, as getting Purity score right sounds a bit niche to me. I guess if I was a hard core pvper I might feel differently.

  4. #4
    Senior Member
    Join Date
    Apr 2018
    Posts
    158

    Default

    The reason I feel this is a reasonable approach is that the “skill” type already has a ridiculous number of fields. There’s a boolean field for whether or not a skill is an Avatar of Boris song, for God’s sake.

    As for spading, I don’t see why it needs to involve manual effort. Just assume everything is decremented until we know otherwise, then update the fields as we discover more. It doesn’t have to be perfect. Most PVP seasons don’t have a minigame based on the number of effects you have, and all anyone has to do to “spade” this is attack someone with a given effect active.

    There is another reason this would be useful, of course: speed ascenders who engage in PVP might adjust their strategies based on which effects get decremented.

    If you agree to accept such a patch, I do have one question before working on it: how do you implement default values for unknowns? If KoLmafia encounters an effect it has never seen before, I want it to assume that effect is decremented. As I’ve mentioned already, item plurals work with exactly these sorts of assumptions already. I just want a default of “true” rather than “<item name>s”.
    Last edited by Saklad5; 01-07-2019 at 10:15 AM.

  5. #5
    Senior Member
    Join Date
    Apr 2018
    Posts
    158

    Default

    While we’re on the subject of the “skill” type, I feel like a lot of those fields should be on “effect” instead. In particular, “song” and “expression”. That may not be worth fixing, as it would be a breaking change, but still.

  6. #6
    Developer
    Join Date
    Apr 2010
    Posts
    4,997

    Default

    Well, to handle the 'spading' you need to write code to check effects after a pvp fight and compare them to before, make sure that main pane and side pane are synced, and handle it appropriately. I think you will find this non trivial.

    How I'd expect this to be, if it is implemented as a hard coded list, is EffectDatabase would have a function "decrementedByPvP( integer effectId)", which would contain a switch statement with default of true and hard coded effects that return false (added in EffectPool if necessary). Proxy Record would then just refer to that function

  7. #7
    Senior Member
    Join Date
    Apr 2018
    Posts
    158

    Default

    Why would we have to synchronize the GUI? I know Kolmafia maintains a cache of effects, and it already has to refresh that after each PVP fight. The PVP code is a bit hard to understand, but it seems like you could save a map of effects after executing “beforePVPScript", then check for anything that is different after the request is processed.

    It doesn’t have to check PVP fights made in the relay browser, either.

    My main concern, as with any feature request or patch I make for a program, is the difficulty of maintaining it in the future. A simple hardcoded list without any spading mechanism means more work for others in the future.

  8. #8
    Senior Member
    Join Date
    Apr 2018
    Posts
    158

    Default

    How I'd expect this to be, if it is implemented as a hard coded list, is EffectDatabase would have a function "decrementedByPvP( integer effectId)", which would contain a switch statement with default of true and hard coded effects that return false (added in EffectPool if necessary). Proxy Record would then just refer to that function
    Originally Posted by Darzil View Post
    If you feel that particular back-end implementation would be better, then sure. You’re obviously much more familiar with Kolmafia than I am, and the end result would be the same. In fact, I can probably make a patch for that right now.

  9. #9
    Developer
    Join Date
    Apr 2010
    Posts
    4,997

    Default

    The non hard coded method is a lot more work up front, changing config files, writing it in, handling overrides etc. But if it's something you'd otherwise have to change multiple times, it's worthwhile.

    If you are only going to spade on automated fights, then you can use the API hit to get the effects changes, and don't have to worry about sync of side pane (which has effects) with main pain (which has pvp results), which does indeed make things easier.

    So the question becomes, is it worth the extra work, and extra code to support, this, slowing down everyone's fights somewhat (for the processing), to support the automatic spading, when KOLmafia users are pretty good at reporting game changes.

  10. #10
    Senior Member
    Join Date
    Apr 2018
    Posts
    158

    Default

    The only steps that actually have to block are copying the effects before a fight and after. Comparing the two can be done on a different thread, as no functionality is actually impacted by it. I may be used to copy-on-write structures these days, but I’m still fairly confident you could have every effect in the game without making this incur noticeable lag. After all, the Mood system checks effects literally every adventure, and people seem fine with it.

    I agree that KoLmafia users are very good at documenting changes, but this definitely feels like an exception. Besides, this doesn’t have to be implemented right now. We can add the property with the list of effects we know don’t get decremented, and add a spading system later if necessary.

Posting Permissions

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