Feature - Rejected Add proxy record field to effect tracking whether it is decremented by PVP

Saklad5

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

Saklad5

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

Darzil

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

Saklad5

Member
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:

Saklad5

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

Darzil

Developer
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
 

Saklad5

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

Saklad5

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

Darzil

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

Saklad5

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

lostcalpolydude

Developer
Staff member
Why should this be built-in at all? It is only relevant for one PvP mini. A good way to support this would be a relay script that adds the value to one of the PvP pages, and that script can have a hardcoded list of effects that don't count.

There used to be a GUI for PvP. I removed it because the idea of supporting various PvP minis (after the PvP revamp) seemed ridiculous.
 

Saklad5

Member
First off, this isn’t just about one PvP minigame (not least because it affects two). This affects anyone with active effects who initiates PvP fights.

Some effects are quite valuable, and it is useful to know which ones will be decreased through attacks. Right now, that information is not known, primarily because it is extremely tedious to manually keep track of every effect you have before and after each fight.

Tracking and spading this is completely trivial for a computer program, however. As I mentioned earlier, one of my main concerns when contributing to any software project is the amount of future work my contribution creates. A GUI for each minigame requires an immense amount of maintenance, so I agree it wasn’t worth supporting. This feature, on the other hand, should be able to maintain itself, assuming no mechanical overhauls in the future.

Besides, I think it is fair to say that KoLmafia has a precedent of including any information about the game that cannot be derived independently.
 
Last edited:

Darzil

Developer
You can never assume no mechanical overhauls, KOL changes constantly. You should assume all new features require ongoing support and understanding.
 

Darzil

Developer
First off, this isn’t just about one PvP minigame (not least because it affects two). This affects anyone with active effects who initiates PvP fights.

Some effects are quite valuable, and it is useful to know which ones will be decreased through attacks. Right now, that information is not known, primarily because it is extremely tedious to manually keep track of every effect you have before and after each fight.

What are you expecting to do with that information?

I am expecting two types of PVPers, those that play the game for PVP, who will probably be micromanaging buffs for PVP, and those who are doing PVP to get swagger whilst concentrating on other things, who will be doing PVP every few days at one point (maybe just prior to prism break in Hardcore, when you have the most equipment etc and can't be hit straight back in hardcore).

Which group will benefit from this information and how will it benefit them? Usually we add new tracking when scripters are calling out for the information to be tracked to allow them to improve scripts, and add new automatic spading when it allows Mafia to function without updates and handle new content.
 

lostcalpolydude

Developer
Staff member
Some effects are quite valuable, and it is useful to know which ones will be decreased through attacks.

All effects that are valuable are decreased through attacks. If there is currently an exception to that, then I should probably push for it to be changed, but I can't imagine all the serious PvPers let that go unnoticed.

Since Darzil and I agree that this would be a useless thing to add (as in, no one would benefit from it), this seems easy to reject.
 

Saklad5

Member
Here’s my personal use case: my logout script tries to optimize for PvP as much as possible (without affecting rollover adventures and such). This includes removing buffs that would confer a disadvantage in PvP.

I am in the second camp you described, by the way.
 

Saklad5

Member
If you want a counterexample: “On the Trail” is not decremented.

Also, I’m willing to code this myself, if you would accept the resulting patch. I’m not asking you to spend your own time on it beyond that.
 

Saklad5

Member
I did, with a hardcoded item array. However, I feel that properties of the effects themselves should be part of KoLmafia, as that is precisely the type of information that proxy records are meant to store.

Moreover, a hardcoded array will become outdated quickly, and everyone would have to maintain their own copy. Sure, they could do it themselves, but they could also code a KoL client entirely from scratch.
 
Top