Rinn's Quest Scripts

Hmm... I thought when I went through the code, it calls restoration scripts with the same amount that it tries to heal with itself... so if you're at 10 hp with a target of 25, it should call UR with a target of 25 immediately, not a target of 11 (that UR then needs to ignore and revalue into 25). Is it failing to do that properly?

Edit: I get this impression from invokeRecoveryScript being called with the full 'recover' value in line 161 (and 197, but we haven't brought up MP, so let's continue to ignore it) in RecoveryManager. This is using the same value that recoverHP has been passed, int recover. When we look at RecoverCommand, line 61, we see that it's already passing along Math.max(hpAutoRecoveryTarget*max hp, current hp + 1).

Eh, I must be misunderstanding you, because it sounds like you're saying you scrap the value that mafia passes to you, which wouldn't be intended behaviour... if you wanted to heal to 90% of max and your target is set to 50%, UR would fail to recover that if it were a pure current+1.
 
Last edited:
Spiffy. I'm sorry, I was just having a hard time wrapping my brain around the way it was being expressed.

Anyways, on to fixing mafia's handling of the tavern, so I can automate that script better. One change... the quest no longer has terminal punctuation, so I needed to delete both of those periods before the script realized I was doing/had finished the quest. Also, needed to add a manual visiting of the bartender before running the tavern automation (to unlock it), and added visiting him during the toggling of the faucet as well. As long as you realize that you've found it.
 
I'm not getting any text on the READ QUESTLIB.ASH... so I ran the script and it didn't spit anything out.... what am I doing wrong? I mostly just want to be able to automate the Agua quests.
 
Questlib.ash is just the various extra backend functions. The file for Agua quests is actually Hyboria.ash...
 
So... going back a few steps, looked at why Level 2 wasn't restoring health. Two problems... one, my_hp and my_maxhp both return ints which, when divided, return an int... ie: 0 if my_hp < my_maxhp. However, as hpAutoRecovery is also returning an int, if it's not set to 100%, it also returns 0. 0 will never be less than 0, so it never calls recovery. So that was a failed attempt.

Trying this now, which should actually work properly:
PHP: 
 if ((my_hp() * 100) / my_maxhp() < to_float(get_property("hpAutoRecovery")) * 100)
Fixing the initial int problem by multiplying by 100, thereby causing an actual result to be given. Also, changed hpAutoRecovery to be a float, not an int, so it can be multiplied by 100 and give something besides 0. Since both items now exist as != 0, it should actually restore health when needed now.
 
Or just use
Code: 
if ((my_hp() * 100.0) / my_maxhp() < get_property("hpAutoRecovery") * 100.0)

At least, I'm fairly sure that Mafia does the implicit type conversions, so everything's a float.
 
Nope... actually tested my code before I posted it, and got the same result I expected from yours. ;)
> ash ((my_hp() * 100.0) / my_maxhp() < get_property("hpAutoRecovery") * 100.0)

Operator '*' applied to string operands ()
Returned: void
Click to expand...

However, this is better, and what I will be using now:
> ash (to_float(my_hp()) / my_maxhp() < to_float(get_property("hpAutoRecovery")))

Returned: false
Click to expand...
This can be displayed as working with the following:
> ash (to_float(my_hp()) / my_maxhp())

Returned: 0.8
Click to expand...
 
Only since get_property() returns a string, no matter what. Forgot about that. :P

But yeah, makes sense to not bother multiplying both by 100.
 
Yeah... it's genius like that. :D But did remind me about using to_float on my_hp to turn that side of the equation into a float.

Nice work circuiting that though by doing * 100.0... least ASH is smart enough to detect whether it needs to be a float or int based on the numbers given. I'd considered something similar, then when driving this morning, had a... wait, to_float... to_float... to float! type of moment. :)
 
Thanks for the scripts! I was wondering if you could make it terminate when a fortune cookie counter expires? Not exactly critical but it'd be a nice feature.
 
Easy way to do that... use Bale's CounterChecker script. That actually will watch your counters for you, unlike these...
 
I updated the shared copy of level 6.ash with some fixes. Moved the band visit_urls into a function, I fixed a bug with the add_item_condition (that function adds conditions in + mode not total mode, so it would have acquired more then 5 imp airs or bus passes if you already had some), and I updated the location names. I also added the other Mourn choices as there's no downside to doing them if you have the items, which you should because they appear in a fixed order.
 
Last edited:
Question... any reason for the bracketting of single line bits, besides preference? I know in some cases ASH gets a bit odd about bracketted/non, but noticed that a large quantity of the tweaks were just if (this) { <do> } instead of if (this) <do>. If "else" is getting used, the brackets become important, but... :) Just curious.
 
Just a part of my coding standard, I prefer all conditionals/loops/etc to have brackets.
 
Last edited:
Will keep it in mind in the future. I've worked both ways depending if I was going for code efficiency or making it more idiot-proof. :D
 
More brackets make the code easier to read I feel, but I guess that is definitely a case of personal preference.
 
Theraze said:
Will keep it in mind in the future. I've worked both ways depending if I was going for code efficiency or making it more idiot-proof. :D
Click to expand...

Explain, please, the mechanism whereby
Code: 
if (this) { <do> }
produces less efficient code than
Code: 
 if (this) <do>
. I'll even let you pick the language and compiler/interpreter where you believe that to be true. Alternatively, explain what you mean by "efficient" in terms of quantities that can be measured and compared.

I find that a pretty outrageous statement. However my painful experience has been that outrageous is not always wrong so I'm hoping to learn something new by asking.

Thank you.
 
I think the question is between
Code: 
if (this)
{
   <do>
}

and
Code: 
if(this) <do>
or
if(this { <do> }

Rather than between the last two. The first one is less efficient if you count lines of code, but appart from that I don't think that there is a difference.
 
You must log in or register to reply here.
Back
Top