CanAdv -- check whether you can adventure at a given location

zarqon said:
Here's a CanAdv that doesn't give any helpful warning messages for imprecise typed constants. I also tried to commit this to SVN but was unable to, alack!
Click to expand...

Those "helpful" messages you wanted are really running us ragged, eh?
 
Don't you wish the changes that broke CanAdv happened the day BEFORE I left on vacation instead of having the first break-commit while I was on the plane...? Ah well.

I'll be back in about a week. Won't commit zarqon's version of canadv because that removes the option of unlocking the guild, which is already behind a variable-wall and doesn't affect anyone that doesn't want to be affected and might have other features removed as well. Won't commit Bale's version of canadv because it will have complaints due to 12273/4 unless people want the script complaining but working.

When I'm back on a real computer, I'll try to figure out why permissions aren't working.
 
Oh right -- I posted my scripts/ copy rather than my svn/ working copy. My scripts version removes the ZLib var and does away with guild unlocking (it won't ever call "guild"). Really, adventuring to unlock zones was never within the scope of this script, and that should probably be eliminated. It snuck in when the guilds were revamped and suddenly the "guild" command used adventures.

Does anyone have that set to allow automatic guilding? I kind of doubt it. And even if they did, they could very easily insert "guild" into their calling script.

I've updated my post above with my working copy (retaining the ZLib var) in case that makes it easier for you to commit. :)
 
Personally, I do. :) As it's set, and it won't auto-clear, and I like having the guild unlocked...

It also helps that mafia keeps forgetting that the guild is unlocked sometimes and the command needs to be re-run again to make mafia aware that I can buy MMJ or whatever.
 
Theraze has all sorts of things that happen to him, and only to him. For example, he has repeatedly recommended that people refresh inventory because "Mafia gets out of sync with inventory". That kind of comment is completely valueless in helping us actually find and fix bugs.

I agree with lost: if Mafia is doing something wrong, then make a bug report with enough details to allow us to figure out how to reproduce and fix it. Do not stick "workarounds" into your script without having done that.
 
I would like to point out that Mafia does get out of sync with the inventory from time to time, especially while running autobasement (which is the reason for all the refresh-commands in there). I've never been able to figure out what the heck is happening in any reproducible way and so doing a bug report is pretty pointless.
 
I removed all the refreshes when I last ran autobasement. It ran 10 times faster and never screwed up for me.

Without a reproducible case - or at least an identified example - we can't debug KoLmafia.

I still stand by my position that putting workarounds in your script to get around KoLmafia bugs is the wrong solution - and, out of the blue, mentioning in the forum x-months later "oh, since Mafia screws up all the time" (without ever having mentioned the bug before) is simply rude.
 
The discussion on that matter has come up several times in the autoBasement thread over the last couple of months so it's not totally out of the blue. Do you have a disembodied hand that the script gets to use? Because that seems to be the most common point of where it gets confused when I run it.
 
Since I got a full telescope years ago (with the Relay Browser basement helper code that I wrote and refined as I was doing it :)), I have only run autobasement a handful of times since then. Until you made your "maximizer" version, I ran a customized version, modified by me. As a result, I haven't actually been reading the thread for quite a while - until you caught my eye by saying you were switching to the maximizer. Since I was just about to finish a L30 run, I figured I'd give it a try. Too bad it consumed some of my untradeable coinmaster tokens - as well as a handful of Crotchety Pine needles, which happened to be in my inventory. Well, I took the risk and I got burned. No biggie.

I have a disembodied hand, but I believe I've told the script to not use it.

If the inventory gets confused when things are swapped on and off the hand, I am not completely surprised - and that would deserve a bug report. With an example. :)
 
lostcalpolydude said:
Mafia tracks that in lastGuildStoreOpen. A bug report explaining what is being forgotten could be useful.
Click to expand...

I have a character that this periodically happens to -- a level 45+ PM whose guild has been unlocked for a very long time. The problem is I don't have any clue where to start searching for the bug. It seems to happen intermittently on login. I notice because UR starts notifying me between combats that I could purchase MMJ if I unlocked my guild. I type "guild" and the problem goes away for a while.

Just logged in with him, and it happened!

> ash guild_store_available()

Returned: false

> prefref lastguild

lastGuildStoreOpen (user, now '0', default -1)
Returned: void
Click to expand...

Typing "guild" fixed it, and the settings file now contains the correct value for lastGuildStoreOpen. But I've done that before, so I'm wondering what happens to make the property contain "0" rather than the default -1 or the correct ascension number?

@Theraze: Might you consider moving your call to "guild" into your login script -- with appropriate checks, of course? It would bring this script more in line with being an informational script rather than a turn-burning script. Incidentally, I made ZLib vars but I don't actually like using them unless they're absolutely necessary -- every time a script initializes one, it slows down every single ZLib script just a teensy bit more. I don't believe this one is absolutely necessary, which is another reason for my request.
 
The only way mafia would set that to zero would be if it believes you currently have completed zero ascensions.

Outside of never having ascended, the only way I could see that happening is if you have spurious "Ascensions" text on your charsheet that the string tokenizer is grabbing.
 
# of ascensions is something we parse from api.php. When we added support for api.php?what=status, we started taking all sorts of things from it that we previously got from the char sheet. Seems to me, we could stop parsing things from the charsheet that we also get from api.php.
 
zarqon said:
@Theraze: Might you consider moving your call to "guild" into your login script -- with appropriate checks, of course? It would bring this script more in line with being an informational script rather than a turn-burning script. Incidentally, I made ZLib vars but I don't actually like using them unless they're absolutely necessary -- every time a script initializes one, it slows down every single ZLib script just a teensy bit more. I don't believe this one is absolutely necessary, which is another reason for my request.
Click to expand...

I know variables slow the scripts down. After it's been added though, it's there. So...
Also, don't necessarily want to have it run as part of newLife. Want it to run after I actually get the right initial familiar. Which also doesn't include having my BCA familiar wiped. Ah well... my postAscension script wrapper fixes that after the updated nL munges it up.

Veracity, I try to not waste your time with lousy bug reports. Sometimes that means that workarounds get suggested when irregular items like the guild get re-locked or something similar happens. If possible, I try to gather information on what caused it, but... after the fifth (or twenty-fifth) time that dolphin whistle amounts get out of sync, I'll throw a refresh inv into my battle script.
 
The character has ascended 5 times and knownAscensions correctly contains "5". Even when lastGuildStoreOpen contained "0", my_ascensions() returned 5. I also noted a single "0" on the first line of the prefs file, in case that's relevant. I'll try messing with it next time, but I'm also about to leave for a weekend away.

@Theraze: My suggestion was login script, not postAscensionScript. You'd call "guild" at login if my_level > X and lastGuildStoreOpen < my_ascensions and !$strings[guildless paths] contains my_path(), and whatever other checks you want. It would just be insurance in the event that you didn't unlock the guild yourself during regular play.
 
But newLife runs my login script as part of its execution. :) And can't test for my_level > because of BIG.
 
You must log in or register to reply here.
Back
Top