Universal Recovery Script

slyz said:
The script thought you had one because Mafia thought you had one. Why Mafia thought you had one when you didn't would be the real question.
Click to expand...

The UR script was previously using the scrolls happily, so it's likely Mafia missed one crumbling to powder somehow.

Perhaps the script could check to see that it actually accomplished the healing it thinks it's performed and throw up an error if it hasn't?
 
Could you make ur respect if "Auto-remove malignant status effects" is checked off and not uneffect anything?
 
Interesting. I've unticked that in order to make UR take care of it instead, so there would definitely need to be a setting of some sort if that is to work...
 
Yeah... there's been a moderate amount of talk about having that setting on meaning that UR can't handle to effects as efficiently as possible, so the suggestion is to always have that off if you are using UR.

Is there a specific 'malignant effect' that you'd like to have UR not remove?
 
In the new event, keeping you stats low saves HP and more importantly MP. So people were adventuring with poison, beaten-up and other "malignant effects" in Valhalla.
 
slyz just made the kind of explanation that causes me to make changes quickly. I don't have the time to spin off a proper release at the moment. Maybe later, but you can download it from this post for now.

To make this version ignore any status effects you inflict on yourself, copy-paste this into the CLI:
set baleUr_ignoreStatus = true
 
Last edited:
Thanks Bale. That is a nice fast fix for a special event. I just had UR use the hot tub to restore hp and it removed my malignant effects, but that's ok because it's limited to 5 times a day. It's much nicer than going the whole day without UR.
 
Well, when slyz explained that there was a good reason to avoid removing effects right now...

IceColdFever said:
I just had UR use the hot tub to restore hp and it removed my malignant effects, but that's ok because it's limited to 5 times a day. It's much nicer than going the whole day without UR.
Click to expand...

You can disable Hot Tub usage. That's already an option in the relay script.
 
Here's an easy fix: rather than making it specific to certain zones (and rather than add yet another setting), simply skip removing negative status effects in all zones with no known combats.

If you wanted to get super awesome about it, you could actually calculate whether each negative effect was harmful in a given location (characters who are backfarming wouldn't be inconvenienced by certain -stat effects).

EDIT: there may be a better way, but for a quick fix adding this to the top of cure_status() ought to do it:

PHP: 
float[monster] ar = appearance_rates(my_location());
if (count(ar) == 0 || ar[$monster[none]] == 100.0) return;
 
Last edited:
slyz: Good point. I fixed it in the above code.

zarqon: An interesting suggestion, but I fear that would lead to UR failing to work properly when a zone's monsters have not yet been added to KoL properly. There have been times like that. For those few days it would cause trouble. This would also fail for restoring after fighting Ed, The Man, The Dude and maybe a few others.
 
In the infrequent event that there are new monsters in a new zone which grant known negative status effects (the only situation that would cause UR to behave undesirably given my suggestion), users could very easily switch mafia's negative effects removal back on until the monsters are added to the zone. This single click of inconvenience is a small price to pay for saving SGEE's and/or MP in other (more frequent) situations.

Also, I don't think that Ed, The Man, or The Dude grant negative status effects. I checked -- Beaten Up removal and HP/MP restoration are handled outside of cure_status().
 
The mini-hipster makes monsters appear where there shouldn't be any!

I liked the idea of a property anyway, since people might want to adventure in a zone with status effects for other, strange, reasons.
 
Eh, I just find toggling properties more annoying than actually coding something to be automatically optimal and then forgetting about it. That, and I also prefer to avoid creating properties and settings for things when they can be handled programmatically -- and I think this can. I can't think of any strange reasons for this which couldn't be accounted for in ASH.
 
Winterbay said:
Well, you could say that all people do not want to play optimally...
Click to expand...

With all of the corner cases, true optimality probably means not using a script for healing, at least during a run. Restoring at the end of a turn cannot account for suddenly switching to a zone where you need to restore more or less than the previous zone, for example. That's why a recovery script, no matter how well-written, will never be for me.

I expect that people using one at all would prefer not having to change a setting/preference/whatever on a regular basis.
 
I think that having a property for people who wish to turn it off, but having it default to whatever is 'optimal' is the compromise I prefer, since it allows for both sides and Bale doesn't necessarily have to keep tweaking it if people want to be non-optimal but still use the script...
 
There is always the option to disable the recovery script, of course.

Having a property has the advantage of making the script's decisions easily understandable to the user: if you don't want that, just change the setting.

Having a complicated internal logic is great for some mechanics, but too complicated also means opaque, and it makes it more difficult for users to predict what and when the script will do or not do.

In my runs, I generally switch off UR for the first 6 levels, either by setting recoveryScript to "" or by simply setting my HP/MP restore to 0. After that, I have a good enough understanding of how the script will behave to adapt my HP/MP restore settings so that it does exactly what I expect.
 
What I meant was that just because a script can be written to do something in an optimal way not everyone wants that way since they have their peculiar little ways of doing things that they find better. A preference also makes it easier to turn one thing off rather than having to remove UR in order to test something that requires a negative status effect.
 
lostcalpolydude said:
With all of the corner cases, true optimality probably means not using a script for healing, at least during a run.
Click to expand...

I tend to hold to the ideal espoused by Dangerpin back when he was around -- anything you can do in vanilla KoL (including the weighing of options in the decision-making process) can be done in ASH. You evidently have a different view, no doubt influenced by the pragmatic fact that most scripts cut a lot of corners.

I agree that true optimality is outside the scope of most scripts posted on these forums -- but it is possible. It's one of the things that keeps me scripting.

The problem you mentioned is basically that UR doesn't know where you're going to adventure next. That can be fixed -- all that needs to happen is for your betweenBattleScript to also call the recovery script. The recovery script could then be made as permissive as possible since it would always have an accurate location for your character, rather than relying strictly on absolute settings. It would run twice: once after adventuring, with your current location, and once before adventuring, with your new location. If the recovery amounts were specified as 0, it would only restore a comfortable minimum HP needed for a safe turn at your location, considering possibilities such as hipster monsters, assassins, and holiday monsters. This might be lower or higher than your actual restore setting.

Problem solved for automatic adventuring. For relay play, a global override that replaces links to adventure.php with a portal page that sets the location and calls your recovery script before adventuring, transparent with mafia relay settings.

Then, add a setting "strictlyFollowSettings" to let users override location-sensitive recovery with UR's current behavior.

Optimal automation is possible, including corner cases, with a minimum of settings to allow for sub-optimal play. My philosophy is that settings should exist to tweak or override existing scripted optimality; configuring them as you play should not be required to achieve that optimality. I'm not claiming to have accomplished this in any of my scripts, but it's the ideal I have in mind.

Bale, sorry for the rant in your thread. :) Although I do think a location-sensitive mode, though challenging to script, would be a ridiculously sweet feature for UR and would save players a chunk of meat each run.
 
You must log in or register to reply here.
Back
Top