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

I was merely pointing that out as a counter to checking for my_level. :) I didn't say it wasn't possible, or even easy. Just that checking for my_level, as suggested, doesn't work properly in BIG runs.

And the point remains that anyone who has run canadv in the past year or two has the variable. And other scripts like Harvest throw out dozens of variables which stick whether or not the user actually uses Harvest in the future.

Eh, it's a feature, people can opt in for it if they want it, people like zarqon can remove it using SVN and still get their updates. Everyone is happy. Ish.
 
Since we are touching on interesting behavior that does not get repeated consistently enough to file a bug report, I just recently got into a situation running character A where it was pretty clear that mafia had loaded the preferences file for as different character. Very interesting since the Ascending character had the preferences of a never ascended character. (For the record I was not logged into two characters at once and I have a suspicion that Dropbox may have been involved but nothing that would allow me to debug the problem was obvious) Point being, however, that blanket statements about KoLmafia not doing certain things are based on the assumption that the preferences file is both correct for the character and correctly read.
 
I've tracked it down a bit more.

This particular character consistently gets debug logs on login:

Installing default certificate validation...
Validating login server (www.kingdomofloathing.com)...
Using data override: data/mallprices.txt
426 players online.
Sending login request...
Initializing session for <charname>...
Refreshing session data...
Synchronizing moon data...
Unexpected error, debug log printed.
Loading character status...
Adjusting familiar weight by 10 pounds
Retrieving character data...
Refreshing closet...
Click to expand...

containing a java.lang.NullPointerException at net.sourceforge.kolmafia.KoLCharacter.recalculateAdjustments(KoLCharacter.java:4395), and after finishing all the login operations, lastGuildStoreOpen contains "0".

api.php correctly specifies "5" for ascensions.

Theraze, when guild unlock tracking breaks for you, do you have the same debug log?
 
I'll check for my farming alt too. Every few weeks, she loses the ability to make superhuman drinks, due to having no still access. A quick visit to the still unlocks it, but would be interesting to see if there is a clear cause.
 
Could the intermittent quality of the error be tied to the moons? I note the debug log happened, at least in the CLI, right after "Synchronizing moon data..."
 
zarqon said:
I've tracked it down a bit more.

This particular character consistently gets debug logs on login:



containing a java.lang.NullPointerException at net.sourceforge.kolmafia.KoLCharacter.recalculateAdjustments(KoLCharacter.java:4395), and after finishing all the login operations, lastGuildStoreOpen contains "0".

api.php correctly specifies "5" for ascensions.

Theraze, when guild unlock tracking breaks for you, do you have the same debug log?
Click to expand...

Somehow KoLmafia.statDay is null when that should not be possible. Maybe the relay browser opens up and the charpane is parsed before other things are initialized? I'm not too sure what leads to calling KoLCharacter.recalculateAdjustments().
 
lostcalpolydude said:
I'm not too sure what leads to calling KoLCharacter.recalculateAdjustments().
Click to expand...
zarqon's debug log would tell us exactly what led to that call in his case.

Note that we could initialize KoLmafia.statDay to "None" and prevent the NPE - but the real question is, as you point out, that we should always have set it correctly before anybody depends on it.
 
Okay, bug report made, replete with debug log. CanAdv-specific conversation may return to this thread. For example, we could now debate whether we should add code to automatically adventure to unlock all the other zones, as well. It could all be behind one ZLib var, perhaps "CanAdv_burnturns" which would control what type of script this is -- an informational script or a turn-burning script.

Then after calling can_adv(any location), either 1) you would be out of turns, or 2) the zone would be unlocked!

And of course it would be recursive, like can_adv(ground floor) would check can_adv(basement) which would check canadv(airship) and so on. So can_adv(Hedge Maze) would basically do your entire run for you! Amazing! Little did we know the framework for an ascension script was in CanAdv all along! :P
 
zarqon said:
And of course it would be recursive, like can_adv(ground floor) would check can_adv(basement) which would check canadv(airship) and so on. So can_adv(Hedge Maze) would basically do your entire run for you! Amazing! Little did we know the framework for an ascension script was in CanAdv all along! :P
Click to expand...

That would be pretty slick. That said I would prefer a way to make a clear distinction between when CanAdv would burn turns and when it would not. A zLib variable and changing the existing Guild would be good first steps, IMO.
 
Okay, so... back to the "why does project permissions not work right" question. The canadv subproject is set to Admin/Admin, Create/None, Read/*anonymous, Update/canadv. The canadv permission group has balefull and zarqon in it and only the Read permission for the entire therazekolmafia project.

So... what am I doing wrong? :(
 
Ah... that's it. I apparently gave permission to the main files section, not to the SVN code. :) Thanks.

I've given the canadv group permission to write to the SVN, which should fix it.
 
Well, I've added create and moderate permissions to the canadv group as well. Maybe that will get it... Wish these made more sense. Ah well.
 
I'm still getting the same "forbidden" error message. :(

Could you take a screenshot of those two pages and show it to us? Maybe we'll notice an odd problem with the settings?
 
Okay. Groups are the groups, Permissions are the specific project permissions. As you can see, anywhere that the Developers group was given permission, I've put in the canadv group.
 

Attachments

  • Groups.jpg
    Groups.jpg
    63.1 KB · Views: 46
  • Permissions.jpg
    Permissions.jpg
    64.7 KB · Views: 51
I believe that on the base project page where you defined permissions for the group "canadv" you needed to grant it updating permission.
 
Huh. I kept trying to set permissions on that earlier and it never let me change those flags. For some reason, now it did. Okay, update granted.
 
Still no go? Grr... must be some combination that works. Slightly possible that it failed because I updated the script with the currently warning bits, so it wasn't actually trying to update anything anymore and that's why it failed?
 
You must log in or register to reply here.
Back
Top