Feature Set AutoRecoveryTargets to specific numbers of HP/MP

During an ascension, I rarely care about 20% of my MP, but I DO want to make sure I have exactly enough MP to cast my combat suite. Currently, if you manually set mpAutoRecoveryTarget to an integer larger than 1.0, it still assumes you wanted 100%. Can we get some kind of feature, even if it doesn't use mp(or hp)AutoRecoveryTarget, to restore up to exactly X HP or MP without using a script?

This looks very similar to this rejected FReq from 3 years ago.

There are many ways to do it with a script, but I feature-requested it because I think it's a sensible addition to percentage-based recovery. I don't think I'm the only one who would use it.

Lilac said:

There are many ways to do it with a script, but I feature-requested it because I think it's a sensible addition to percentage-based recovery. I don't think I'm the only one who would use it.

Click to expand...

In addition to the FR requested above, I seem to recall much discussion on this point in the distant past. Sometimes a percentage makes sense and sometimes an absolute number makes sense. My recollection is that the case for percentages was marginally stronger, given that there was only going to be one way of specifying the target. The arguments against absolute numbers, as I recall, had to do with the fact that (at the time) it was difficult to guarantee restoration to a specific number and there was no universally acceptable way to handle that. For everyone who wanted a restoration process that kept restoring until the target was reached or surpasses, there were people who were concerned that resources were being wasted in doing so. I suspect there is also a psychological component - people will complain about restoring to 51 if the target is 50 while they will be silent about restoring to 50% of 100 and having things end up at 51.

So I'd be real interested in how it should work especially in cases where 50 was requested and because of restore all options, restoring to 100 cost less than restoring to 51. I'd also be interested in the reasons why a script was not an acceptable solution since most FRs that can be met by scripts are not being implemented in KoLmafia.

I'm not as familiar with the culture and standards of Mafia requests as I could be, so if other requests of a similar nature (sideways expansion of existing functionality) are being shot down, I don't want special treatment or anything. It's just always struck me as very odd that we get one and not the other (percentage vs. absolute).

Lilac said:

I'm not as familiar with the culture and standards of Mafia requests as I could be, so if other requests of a similar nature (sideways expansion of existing functionality) are being shot down, I don't want special treatment or anything.

Click to expand...

It's because it would be a Big Deal for one of our devs to add that functionality. (Not a trivial amount of work.) Generally, when mafia already provides equivalent functionality, feature requests aren't accepted when the amount of work is out of proportion to the amount of benefit. It might be different if the feature could not be simulated with a script.

Of course, sometimes a dev sees the request and decides that it would be an interesting challenge or suit their particular play style. In those cases the request is granted so it is usually worth asking for a feature even if it is likely to get shot down like this one.

Synopsis: It was worth asking and nobody thinks you were wrong to make the request.

I think it'd be an interesting challenge, but I also think there is lots of work to do to make the various new content work well, and I have a personal list of interesting challenges among which I think this wouldn't currently make the top 10.