CanAdv -- check whether you can adventure at a given location
- Thread starter zarqon
- Start date
Theraze
Active member
So, here's what I've done to my version... basically, anything that said Knob Goblin became Cobb's Knob, and knob.php became cobbsknob.php... also, I check to make sure that theprop above (--) actually exists in the line before looking for where, just in case someone does something stupid to set their unlockedLocations manually.
This is version .72, so don't use it after zarqon releases... anything newer.
This is version .72, so don't use it after zarqon releases... anything newer.
Last edited:
So, here's what I've done to my version... basically, anything that said Knob Goblin became Cobb's Knob, and knob.php became cobbsknob.php... also, I check to make sure that theprop above (--) actually exists in the line before looking for where, just in case someone does something stupid to set their unlockedLocations manually.
This is version .72, so don't use it after zarqon releases... anything newer.
I'm confused. What are your mods above and beyond what zarqon did as noted here?
Thanks.
zarqon
Well-known member
He changed the Knob checks to use the new URL. I was making an emergency fix so that it would stop throwing errors and didn't actually update the checks -- just the names. I've now added the new URL cobbsknob.php to the first post as well. While I was at it, I bumped the verbosity up a few notches since it seems that various applications of this script could lead to CLI spamming.
Methinks it would be nice to give Theraze editing privileges to the first post here!
Methinks it would be nice to give Theraze editing privileges to the first post here!
Theraze
Active member
Yeah, as I said... the .72 official patch didn't replace any of the "Knob Goblin" zone names, just the King's Chamber, so mine replaced all of those. Also, it checked "knob.php" for the adventuring locations, and that url changed to "cobbsknob.php" so that's in the change above...
As well, someone managed to break their unlockedLocations a week or two back by removing the ascension count from it, making indexof -- equal -1, making the substring check at the start fail, which make the whole script crash out. I put a check to make sure that if unlockedLocations is not set to "", indexof -- must be >0. If not, unlockedLocations has been improperly set, so reinitialize it.
Basically, it changed the line with theprop to this:
Anyways, I'll remove my patch from the post above now though, since .73 is out.
Edit: The "theprop" change isn't in main, but it's only needed if someone sets unlockedLocations improperly. I like it as a paranoia thing though... never can tell when someone will screw it up themselves again and blame the script or a script that uses it for not working.
Also, I may give a few more added zones... if you remember there was a "goget" alias that you (zarqon) made more efficient (mainly in that it used has_goal instead of just taking the first location). I got tired of it trying to use dark heart and other zones like that when I needed something post-level 6, so I made "cangoget" which does the same, but imports canadv instead of zlib, and runs a canadv (false prep) check on the locations to see what's actually available. Because of that, it highlights some of the holiday zones that mafia still contains, but aren't in canadv yet, like the elf alley, the new knob barracks, etc. I'll try to pay attention on the next run or three and actually update my script with the screaming zones and post here. Make it a quieter script for weird people who call it against the full location list.
As well, someone managed to break their unlockedLocations a week or two back by removing the ascension count from it, making indexof -- equal -1, making the substring check at the start fail, which make the whole script crash out. I put a check to make sure that if unlockedLocations is not set to "", indexof -- must be >0. If not, unlockedLocations has been improperly set, so reinitialize it.
Basically, it changed the line with theprop to this:
PHP:
if (theprop == "" || index_of(theprop,"--") < 0 || substring(theprop,0,index_of(theprop,"--")) != to_string(my_ascensions()))Anyways, I'll remove my patch from the post above now though, since .73 is out.
Edit: The "theprop" change isn't in main, but it's only needed if someone sets unlockedLocations improperly. I like it as a paranoia thing though... never can tell when someone will screw it up themselves again and blame the script or a script that uses it for not working.
Also, I may give a few more added zones... if you remember there was a "goget" alias that you (zarqon) made more efficient (mainly in that it used has_goal instead of just taking the first location). I got tired of it trying to use dark heart and other zones like that when I needed something post-level 6, so I made "cangoget" which does the same, but imports canadv instead of zlib, and runs a canadv (false prep) check on the locations to see what's actually available. Because of that, it highlights some of the holiday zones that mafia still contains, but aren't in canadv yet, like the elf alley, the new knob barracks, etc. I'll try to pay attention on the next run or three and actually update my script with the screaming zones and post here. Make it a quieter script for weird people who call it against the full location list.
Last edited:
Bale
Minion
Sadly, vBulletin does not allow us to give a member permission to edit a specific post by another member. It's an all or nothing permission.
However any minion (such as myself) can change the attachment in the first post. So, if you tell us to edit it with Theraze's updates we would probably do that.
I'm getting an error any time canadv is called, telling me that "Begin index 0 greater than end index -1 (canadv.ash, line 48)" it's particularly odd, as it starting happening part way through my session, after calling canadv several times. I've tried downloading the newest version of the script, and the newest build, as of this writing, r9131, neither of which helped. Any thoughts?
Theraze
Active member
Also updated zlib?
Edit: No wait, this is the error that happens when people get screwed up unlock zones. Fix it with this: Basically, the error happens when SOMEhow you get unlockedLocations that's set, but doesn't have the double hyphen (--) in it anywhere. This means that indexof -- is -1, making it very difficult to find it in a substring. Heh.
Edit: No wait, this is the error that happens when people get screwed up unlock zones. Fix it with this:
I posted a suggestion to fix this for zarqon, but it isn't in the source yet.
Basically, the error happens when SOMEhow you get unlockedLocations that's set, but doesn't have the double hyphen (--) in it anywhere. This means that indexof -- is -1, making it very difficult to find it in a substring. Heh.
Last edited:
Bale
Minion
This script isn't my usual beat, but I would like to contribute a little code to improve canadv. Starting at line 336:
Code:
// never open
case $location[A Skeleton Invasion]:
case $location[CRIMBCO cubicles]:
case $location[CRIMBCO WC]:That was kinda a no-brainer, but I also found an actual error in canadv!
Code:
case $location[Post-Quest Bugbear Pens]:
case $location[Bugbear Pens]: return (in_muscle_sign() && primecheck(13) && perm_urlcheck("woods.php","pen.gif"));The problem here is that Post-Quest Bugbear Pens is a completely different zone from the Bugbear Pens and it has no combats! After you complete the quest you cannot adventure in the regular Bugbear Pens or encounter any of the monsters therein. So change the above to:
Code:
case $location[Post-Quest Bugbear Pens]: return (in_muscle_sign() && primecheck(13) && perm_urlcheck("woods.php","pen.gif") && contains_text(visit_url("questlog.php?which=2"),"You've helped Mayor Zapruder"));
case $location[Bugbear Pens]: return (in_muscle_sign() && primecheck(13) && perm_urlcheck("woods.php","pen.gif") && !contains_text(visit_url("questlog.php?which=2"),"You've helped Mayor Zapruder"));Edit: Ugh. Actually the above doesn't work because of the nature of perm_urlcheck(). I'll figure out how to do this at a future date. I've just remembered another reason I gave canadv a facelift when I rewrote it for CounterChecker.
Last edited:
Winterbay
Active member
In a similar vein to the above I would like to suggest the following for the Spooky Gravy Barrow:
Because you can't really get to that area just because you have a elemental fairy. You need to pass the "get fairy/item from the mayor" first.
Code:
case $location[Spooky Gravy Barrow]: return (in_muscle_sign() && primecheck(40) && (contains_text(visit_url(questlog.php?which=1), "powerful Gravy Fairy") || (contains_text(visit_url(questlog.php?which=2), "spooky gravy fairy"))));Because you can't really get to that area just because you have a elemental fairy. You need to pass the "get fairy/item from the mayor" first.
Theraze
Active member
Couldn't you check the zone to see if it has the link, using the standard perm_urlcheck for a single server hit instead of checking two quest log pages?
More importantly, there needs to be an equivalent to equipcheck for familiars... famcheck or familiarcheck or something. Because you need to actually have those equipped for it to work, but depending on your 100% settings, that might not be possible. In those cases, it should report back that your 100% setting makes it impossible. If it is possible, then it should either use have_familiar or my_familiar depending on the need... have_familiar for prep off, my_familiar to see if it needs to change with prep on and have_familiar to see if it's possible. If it's possible and not the current one, then it can equip using use_familiar...
Something like this (blatantly tweaked from equipcheck):
The reason for the have_familiar check in prep is so that if you don't have the familiar, it won't try to equip it... meaning you don't get mafia's error message (it gets skipped instead, and fails on the have_familiar check). If for some reason, though you officially 'have' a familiar but it can't be equipped due to something mafia or KoL related stopping it from happening, mafia should report back that the use_familiar failed.
A few examples how the code above works, regarding 100% runs and having/not having familiars, using a verbosity of 5 (takes 6 to see the 100% run vprint error, so just gives us return conditions):
More importantly, there needs to be an equivalent to equipcheck for familiars... famcheck or familiarcheck or something. Because you need to actually have those equipped for it to work, but depending on your 100% settings, that might not be possible. In those cases, it should report back that your 100% setting makes it impossible. If it is possible, then it should either use have_familiar or my_familiar depending on the need... have_familiar for prep off, my_familiar to see if it needs to change with prep on and have_familiar to see if it's possible. If it's possible and not the current one, then it can equip using use_familiar...
Something like this (blatantly tweaked from equipcheck):
PHP:
boolean famcheck(familiar req) {
if (to_familiar(vars["is_100_run"]) != $familiar[none] && req != to_familiar(vars["is_100_run"])) return vprint("You need to equip a "+req+", which you currently can't due to being on a 100% run with a "+to_familiar(vars["is_100_run"])+".",-6);
if (my_familiar() == req) return true;
if (have_familiar(req) && prep) return use_familiar(req);
return have_familiar(req);
}The reason for the have_familiar check in prep is so that if you don't have the familiar, it won't try to equip it... meaning you don't get mafia's error message (it gets skipped instead, and fails on the have_familiar check). If for some reason, though you officially 'have' a familiar but it can't be equipped due to something mafia or KoL related stopping it from happening, mafia should report back that the use_familiar failed.
A few examples how the code above works, regarding 100% runs and having/not having familiars, using a verbosity of 5 (takes 6 to see the 100% run vprint error, so just gives us return conditions):