Universal Recovery Script

Is there a way to get the script to prioritize using Caccoon instead of items when at all available? Right now the script is using items, even filling up my spleen, to fill HP when I've got MP to spare. Perhaps make it check vs your "use buffs down to" or "recover" numbers to see if it thinks you have the MP to use that instead of consumables?
 
Ran into an issue where UR decided pixel energy tanks were the best option for in-combat restoration. I couldn't make them because they require having completed the crackpot mystic psychoses, so I've just blacklisted them in my local copy.

Code: 
Purchasing some pixel energy tanks for use as a combat restorative.
Verifying ingredients for pixel energy tank (1)...
Creating 1 pixel energy tank...
Mystic shopping was unsuccessful.
Did not fully restore HP for some reason.
 
darkcodelagsniper said:
Ran into an issue where UR decided pixel energy tanks were the best option for in-combat restoration. I couldn't make them because they require having completed the crackpot mystic psychoses, so I've just blacklisted them in my local copy.
Click to expand...

Please explain what is required to create these items. Also, is this a mafia issue for believing it can create them?
 
Looks like my copy of the script is currently stuck trying to buy cups of hickory chicory, but the only store left that has any in stock is currently frozen because the account is disabled for policy violation. It fails every time.

Edit: I managed to get it working by editing the map txt file, but just letting you know this is a case that other people could run in to.
 
Last edited:
I had a similar problem with hickory chicory. In the Purchases tab there were only two stores with them and they both appeared gray'd out. UR insisted on trying to buy them, even after I manually purchased several or some other item that was also a combat restore. I gave up and temporarily stopped using UR.
 
Yes.

Code: 
			ArrayList<PurchaseRequest> search = i1.next();
...
			Iterator<PurchaseRequest> i2 = search.iterator();
...
					i2.remove();
Removing the current element via an iterator removes it from the underlying list.

void remove()

Removes from the underlying collection the last element returned by this iterator (optional operation). This method can be called only once per call to next(). The behavior of an iterator is unspecified if the underlying collection is modified while the iteration is in progress in any way other than by calling this method.

Throws:
UnsupportedOperationException - if the remove operation is not supported by this iterator
IllegalStateException - if the next method has not yet been called, or the remove method has already been called after the last call to the next method
Click to expand...
 
There's a frozen store at 700, and one other store at 1m for cup of hickory chicory. I wonder why mall_price( $item[cup of hickory chicory] ) isn't updating after discovering the frozen store.
 
Actually, perhaps the problem is that it should break, rather than return after recalculating mall prices.
We want to remove this store from ALL saved search results, not just the first one we found.
 
Which is to say, if we pass in itemId -1 - all saved searches - we should look for more matches.
If we pass in a single itemId, we should return after removing the search we found.
 
Code: 
			Iterator<PurchaseRequest> i2 = search.iterator();
			while ( i2.hasNext() )
			{
				PurchaseRequest purchase = i2.next();
				if ( purchase instanceof MallPurchaseRequest &&
				     shopId == ((MallPurchaseRequest) purchase).getShopId() )
				{
					i2.remove();
					StoreManager.updateMallPrice( ItemPool.get( itemId ), search );
					if ( itemId != -1 )
					{
						return;
					}
					break;
				}
			}
 
This subtraction should probably be an addition:
Code: 
int mpcost(skill sk) {
	int cost;
	if(sk==$skill[lasagna bandages]) // Dang in-combat vs out of combat mp cost reduction for Astral Bracers
		cost = max(1,6 - mana_cost_modifier());

mana_cost_modifier() returns a positive value when spells are more expensive, and negative if it's less. With Radiating Black Body™ active:
Code: 
> ash mana_cost_modifier()

Returned: 3
Which is an bandage MP cost of nine, but that code calculates three.
 
Thanks. I've fixed the mana cost for lasagna bandages.

What an oddly specific bug for you to discover, but I'm glad you found it.
 
For those looking to temporarily change UR to not cure Hardly Poisoned at All, the necessary surgery is on lines 1580 and 1581 of the script:

Code: 
		return beset($effects[Hardly Poisoned at All, A Little Bit Poisoned, Really Quite Poisoned,
			Somewhat Poisoned, Majorly Poisoned]);

if you take out "Hardly Poisoned at All, ", all your other recovery bits will keep working, without curing that level of poisoning.

If you have a hottub, it still may cure your poison incidentally, but it'll no longer do so at the beginning of every fight.
 
I think this is UR but maybe not.

Calling the restore settings Low and Target, what happens is that restoration triggers at Low. It is able to restore to something greater than Low but does not actually reach Target. Automation aborts. But when I do nothing but restart automation proceeds because the current value is greater than Low.

If it is UR then I would like to request a Feature that changes "when to abort" from "abort if Target not achieved after restoration " to "abort if Low not achieved after restoration".

Thanks.
 
If it's UR, the abort message should be, ""Did not fully restore HP for some reason." If the message is different then there's another cause.

UR should abort whenever it fails to reach the restoration target. Which is what you describe. Which is also your feature request.

I don't understand your feature request because low is less than target.

BTW: I'd prefer calling the values trigger and target.
 
Bale said:
If it's UR, the abort message should be, ""Did not fully restore HP for some reason." If the message is different then there's another cause.

UR should abort whenever it fails to reach the restoration target. Which is what you describe. Which is also your feature request.

I don't understand your feature request because low is less than target.

BTW: I'd prefer calling the values trigger and target.
Click to expand...

That is the message.

Sometimes I only care about a minimum value. I'd be glad to restore up to a maximum but as long as I have met the minimum, I don't care that I failed to max out.

So my request would be to optionally allow the condition "target not met" to not trigger an abort and have "unable to restore to trigger" be an abort condition instead.

My OCD is bothered by something that starts automation and then allows me to restart WITHOUT DOING ANYTHING!!!!! If I didn't have to do something then why did it abort? :-)

I suppose if I set trigger to be equal to target I would get the non-abort behavior I want but the last time I did that I did not like the choices UR made to restore. It has been a while since I tried with this but my recollection is that it was choosing higher meat per mp options compared to lower meat per mp options that exceeded the target but did not exceed the max mp.

The problem occurs with low level but highly skilled and poor characters.
 
You must log in or register to reply here.
Back
Top