find_demons.ash

the_great_cow_guru said:
I guess it's a good idea to make sure you have the scroll and candles first.
Click to expand...

Earlier today there was a 50 meat price difference between buying the ingredients for the scroll (assuming that you have none of the ingredients) and buying the completed scroll. If you try to summon and do not have the needed items, Mafia purchases the ingredients and creates the scroll.


Is getting the demon name adventure considered a non-combat adventure? Does maximizing the rate of non-combats make it faster to get the name adventure?
 
tgetgel said:
Earlier today there was a 50 meat price difference between buying the ingredients for the scroll (assuming that you have none of the ingredients) and buying the completed scroll. If you try to summon and do not have the needed items, Mafia purchases the ingredients and creates the scroll.


Is getting the demon name adventure considered a non-combat adventure? Does maximizing the rate of non-combats make it faster to get the name adventure?
Click to expand...

Yeah, summon automatically tries to buy them, but just in case you don't have access to the mall or something it's probably still a good idea to check. I'm not sure exactly what summon does if it can't get the necessary items, so better safe than sorry

As zarqon said a few posts back, the demon names occur ~once every 150 adventures in a zone where they can occur (according to the wiki) I'm not sure if this is affected by noncombat % or not. I agree with zarqon that it's probably based off some hidden counter and isn't affected by noncombat %. It would be easy enough to add, I just don't want to waste meat if it doesn't really help anything. If anyone knows more about how noncombat % affects the demon name adventures please let me know.
 
When one has mafia's buy from mall/npc option turned off, any call to retrieve_item() merely says "You need item x to continue" assuming you don't have the item, if you do, it just uses it.

-Spiny
 
the_great_cow_guru said:
And what does it return? I'm assuming it returns false if it couldn't get the item. Is that not the case?
Click to expand...

Yes, it returns false:

Code: 
> ash retrieve_item(1, $item[magical mystery juice])

You need 1 more magical mystery juice to continue.
Returned: false

Editted out my edit cos I'm an idiot, was testing with no meat on hand lol.

-Spiny
 
Last edited:
Okay awesome, so then it should work for this purpose. As long as mafia updates the demonName1 property as soon as it encounters the signals crossed response
 
the_great_cow_guru said:
Okay awesome, so then it should work for this purpose. As long as mafia updates the demonName1 property as soon as it encounters the signals crossed response
Click to expand...

It's still a bit fiddly in that respect. Tried it on a multi and got the same response as before.

Summoning Christopher Guest...
Demon name: Vek'Bazaba
Summoning Chamber
Can't find demon 1 right now
Putting on Lord Spookyraven's ear trumpet...
Equipment changed.
Click to expand...

And again, if I abort the script and restart it says it has found demon 1.
 
I think it must be an issue with mafia not setting the demonName1 property. Because the code looks like it should work and it's returning the same thing if you run it again later... just I think by then the property has been updated so it gives the correct result. Well I guess the important part is that it does find the demon name... even if the feedback isn't perfect. Does anyone know how i could force the property to get updated right away?
 
I'm puzzled - the code specifies "spooky raven" instead of spookyraven, which I believe is correct - why does it work?

I quoted all $item[foo] (to $item["foo"]) to fix emacs highlighting; perhaps quoting it made for stricter matching?

Regardless I removed the space and it now seems to be working. Pie demon is still broken per above, though.
 
Hahaha, did anyone notice my code never incremented i? I just happened to notice that.

I'd recommend a) fixing that, and b) adding some debug print commands, such as "i: demonName1 value" in the while loop, and also printing the property after the while loop is finished.
 
zarqon said:
Hahaha, did anyone notice my code never incremented i? I just happened to notice that.
Click to expand...

Yeah, luckily I noticed that when I was copying it, so I just added a line to increment it ;)

I'll see what I can do to fix the pie demon problem. If worst comes to worst maybe I'll just take out the print statements. Then at least it wouldn't be giving incorrect feedback.

Hmm yeah, that's kind of surprising about the Spookyraven thing. I usually just guess with names and then look them up when mafia doesn't like them... but that one got by I guess.
 
I've figured out what's going on with the pie demon, and it's a bit obscure, I'm afraid...

Discovering a demon name, with no goals active, will stop auto-adventuring. This, and other things that stop adventuring, are handled internally as a "pending state", which is basically the same as an error state except that it doesn't turn the display red. You normally never see a pending state in ASH, since they generally occur in the context of auto-adventuring, which will clear the pending state before returning. The pending states that occur when demons 2-5 are discovered therefore cause no problem.

However, when a demon name is discovered in the Summoning Chamber, there is no adventure request in progress - the pending state is still active on return from the cli_execute("summon..."). Like any error state, this is capable of aborting your script, and since you didn't capture the return value of cli_execute(), it does - the function immediately exits, without executing the final return get_property("demonName1") != "";

However, the return value of find_pie_demon() is used in your script, so THAT captures the error state, and allows the script to continue. Note that the 'return' statement didn't actually execute, so the apparent value of find_pie_demon() is unspecified - it happens to always be 'false' in this case (thus causing the script to believe that the name wasn't found), but in general the result of capturing the return value of an aborted user-defined function (rather than the built-in function that actually caused the abort) is meaningless.

What you need to do is capture the error at the source - the cli_execute(). Any of the following will do the job:
boolean _ = cli_execute(...);
if (cli_execute(...)) {}
(!cli_execute(...));
 
jasonharper said:
(!cli_execute(...));
Click to expand...

Whoa! That will work? All I need to do is to wrap it in parenthesis to capture the error state? No "if" needed? Or is the "!" necessary to capture the state by converting it to a boolean? Anyway, that's a lot prettier than the if(){} that I've been using.

Are the parenthesis really necessary if the "!" is doing the job?
 
Something has to actually use the value in order to capture any errors - negation seems to be the simplest such operation for a boolean return value, unary '-' would likewise be simplest for an int value.

The outer parentheses are necessary to make this syntactically valid, since ASH does not allow arbitrary expressions to be used as statements - only a limited subset (such as function calls) that generally make sense when the resulting value is ignored. That subset does include parenthesized sub-expressions, in which case the sub-expression is not limited in any way.
 
Thank you. I hate the dangling {} as well as the oddness of an if that does not control program flow. This is much prettier. I'll be very happy to use
Code: 
(!adventure(1, locale));

instead of
Code: 
if(adventure(1, locale)) {}
 
You must log in or register to reply here.
Back
Top