CanAdv -- check whether you can adventure at a given location
- Thread starter zarqon
- Start date
We're going to have that until someone edits CanAdv to deal with the Hidden City revamp.
Crowther
Active member
The following should return true, since I can adventure in the garage:
I believe it's because the image checked for is "knoll1" instead of "knollinside". This View attachment patch.txt worked for me, but I'll admit I'm not sure what logic was intended.
Code:
> ash import <canadv.ash> ; can_adv($location[The Degrassi Knoll Garage])
Returned: false
zarqon
Well-known member
CanAdv Update! (hopefully)
I took some time today and worked on a major update to this script, since it ties into another project I'm working on. Since I can't submit changes I'm uploading it here at the bottom of this post. Changes include:
Since I've lost almost all control of this script, it remains to be seen whether this is a fork or not.
EDIT: Now requires that users have disabled zone warnings, as suggested by lost.
EDIT EDIT: Adjusted some of the URLs which are now redirects so this will play nicely from the relay browser, and added a v9 debug print for debugging redirects.
EDIT EDIT EDIT: script removed -- scroll down for latest.
I took some time today and worked on a major update to this script, since it ties into another project I'm working on. Since I can't submit changes I'm uploading it here at the bottom of this post. Changes include:
- Drastically simplify quest tracking property checking (reduce 6 functions to 1).
- A new zone_check() function allows us to avoid repeating a lot of code for locations in the same zone. CanAdv now checks the zone before continuing to check the specific location.
- In keeping with the zone theme, reorganize the entire script by zone since it was getting really difficult to find a given location.
- Save some sever hits by checking for equipment being equipped before attempting retrieve_item() (which unequips it only to re-equip it).
- Fix unlockedLocations getting multiple entries for a single location.
- Rework unlockedLocations to contain a comma-delimited list rather than a space-delimited list.
- Use a matcher which includes delimiters to detect the presence of locations in unlockedLocations, since there are some 20 locations which are substrings of another location.
- Use ZLib's new list_add() to add locations to unlockedLocations, which avoids duplicate entries.
- Add jar_check() function for checking all Psychoses jars.
- Remove the old forum-based version checking.
- Exact names for everything. Using TortoiseSVN's diff I saw quite a lot of inexact names still in use, but I suspect Theraze must have updated the script without TortoiseSVN detecting it, because it was really quite a lot.
- Removed outfitequipped(), since an ASH equivalent now exists.
- Remove author notification since this script can be called in combat.
- In checkguild(), visit each quest-giver until you have completed the last quest that NPC offers.
- Don't require Ultrahydrated for the Ultrahydrated Desert, since you will automatically get it when you go to adventure there.
- Fix URL for Penultimate Fantasy Airship.
- Added Hidden City zones.
- Added Dreadsylvania zones.
- Added The Shore, Inc.
- Added KOLHS zones.
- Return false for all zones outside of KOLHS unless you've spent your 40 adventures in school.
- Fix false positives in Bat Hole zones if you pull sonars before actually getting the quest.
- Add new Degrassi knoll zones and fix URL for Degrassi knoll checks
- A lot of improved checks which reduce server hits. Server hits have been reduced for:
- The Enormous Greater-Than Sign
- Dungeons of Doom
- Nemesis Cave
- Fun House
- Fernswarthey's basement
- Whitey's Grove
- Haert of the Cyrpt
- Server hits were straight up removed for the following zones:
- All Friars zones
- All Pandamonium zones
- Both Cemeteries
- Road to White Citadel
- The Hidden Temple
- Both Bugbear Pens
- Haunted Conservatory
- Haunted Billiards Room
- Haunted Kitchen
- Goatlet
- Itznotyerzitz Mine
- eXtreme Slope
- Lair of the Ninja Snowmen
- I spent quite a while on this and improved various checks which I didn't note as I went and promptly forgot. Diffing to find them all would be really difficult now that I've completely reordered the script by zone, so I'll just conclude with a blanket "various other improvements". As of this writing, this script presently handles all known locations, and most of them correctly.
Since I've lost almost all control of this script, it remains to be seen whether this is a fork or not.
EDIT: Now requires that users have disabled zone warnings, as suggested by lost.
EDIT EDIT: Adjusted some of the URLs which are now redirects so this will play nicely from the relay browser, and added a v9 debug print for debugging redirects.
EDIT EDIT EDIT: script removed -- scroll down for latest.
Last edited:
Theraze
Active member
Just on a quick check, it loses the war check for the obligatory pirate cove. Guess that means I'll need to compare each area before replacing the current one... One of the joys of SVN is that if it doesn't work, we can always roll back. But I'm not replacing current until it's at least as good.
Edit: It's also missing a BUNCH of stat-checks... for example, the Menagerie is not always open, it's open based on your primestats... I'm going to have to work out how the current system does it, but I may just need to move those out of the 'always open' section.
Edit2: And yes, I know you can override it. But if you haven't set it to override, mafia will just loop wasting server hits forever. And we're talking about automation, not manual combat.
Edit: It's also missing a BUNCH of stat-checks... for example, the Menagerie is not always open, it's open based on your primestats... I'm going to have to work out how the current system does it, but I may just need to move those out of the 'always open' section.
Edit2: And yes, I know you can override it. But if you haven't set it to override, mafia will just loop wasting server hits forever. And we're talking about automation, not manual combat.
Last edited:
Theraze
Active member
Unless the script will override KoL's automatic warning, it shouldn't tell people that it will be available through a scripted adventure. We COULD override, but... I don't think mafia currently tracks KoL's override all, which is really what we'd want for ignoring stats. I'll stare at the stat checks later, but I need to consider that before publishing. Unless you want to dump a version with the stats back in. Not sure what partial script versions you have around.
And as said before, you and Bale SHOULD be able to update the SVN. But... eh, weird that it doesn't work. Least it gives us the chance to debug this before we screw players by breaking automation.
And as said before, you and Bale SHOULD be able to update the SVN. But... eh, weird that it doesn't work. Least it gives us the chance to debug this before we screw players by breaking automation.
zarqon
Well-known member
Telling people they can't automate when they really can is just as broken as the opposite. I think it's fair to inform users they need to disable the warning to use this script. Ideally we could detect it and only make the check if they have those warnings enabled, but as you say, we presently can't. If it's causing an endless loop though, that is indeed more broken, and if it hasn't been reported as a mafia bug it should be. I'll check that when I get home.
ETA: The "always open" section now includes a lot more locations, because they are always available if the zone is. Quite a lot of checks moved into the zone check. The Menagerie zone, which you mentioned, is available if you have the key, at which point all of its contained locations are "always open".
ETA: The "always open" section now includes a lot more locations, because they are always available if the zone is. Quite a lot of checks moved into the zone check. The Menagerie zone, which you mentioned, is available if you have the key, at which point all of its contained locations are "always open".
Last edited:
Personally, I would probably write the script to check that setting, and abort with a notification to the user if stat warnings are enabled (intentionally making the script unusable for anyone with stat warnings enabled). If that setting is disabled, then set a preference so the script never has to worry about checking it again.
Winterbay
Active member
One hit to check if the setting is set and abort (for those with it set) and one hit and then never again given that a preference gets set (for those without it set) doesn't sound like it would add to the burden of KoL's servers very much. In fact overall it may very well lower it since the users who have it set will then not go on to hit the server to find out if we can adventure somewhere, and if they change the setting a total of 2 server hits will be accrued for this.
zarqon
Well-known member
I updated the script in my above post to do as lost suggested. The script checks the property "ignoreZoneWarnings" and if it's 1, it proceeds. If it's 0, it hits the server and sets the property to the value used by KoL and then checks again. If it's still 0, it aborts with a message telling the user they need to disable zone warnings to use CanAdv.
Users could still run into trouble if they re-enable the warnings, since the script would not adjust the setting. Since this information is included in api.php, it would probably be pretty easy for mafia to track that setting, if someone felt it worthy of a feature request.
Users could still run into trouble if they re-enable the warnings, since the script would not adjust the setting. Since this information is included in api.php, it would probably be pretty easy for mafia to track that setting, if someone felt it worthy of a feature request.
I just had an infinite loop with BCCAscend because the warning was enabled but BCCA persisted in adventuring there anyway.
Since the state is included in api.php this would be a good FR. I will even try and look at it if no one beats me to it. (Although this looks to be a busy week so I expect to be beaten to it).
Since the state is included in api.php this would be a good FR. I will even try and look at it if no one beats me to it. (Although this looks to be a busy week so I expect to be beaten to it).
Theraze
Active member
If we detect the user's current state for ignoring the warnings, that means we can tell whether or not primestat is valid. Unless the areas actually appear and disappear there, I'd rather put in all the stat checks and simply make it return true if they've set KoL to not give warnings and evaluating them if they aren't overriding. Aborting if they happen to want the training-wheels/mis-click-protection of zone stat warnings isn't the right answer.
zarqon
Well-known member
I agree that the optimal method would be to make the stat check only if the user has warnings enabled (although some of the stat checks are necessary regardless of that setting).
However, while we wait for warning check information to be accessible in mafia, I disagree that it is better to be inaccurate for any users who have warnings disabled than it is to be accurate for all users, provided they disable the warnings. In other words, lost's solution which you deem "not the right answer" is still an improvement.
However, while we wait for warning check information to be accessible in mafia, I disagree that it is better to be inaccurate for any users who have warnings disabled than it is to be accurate for all users, provided they disable the warnings. In other words, lost's solution which you deem "not the right answer" is still an improvement.