xKiv
Active member
It's not beta, it just doesn't support buggy servers.
(translating git to svn might be complicated, but it really shouldn't break simple updating)
Last edited:
Guide
- Thread starter Ezandora
- Start date
(translating git to svn might be complicated, but it really shouldn't break simple updating)
digitrev
Member
Slight issue. These lines
should be using item_amount instead of available_amount, since available_amount accounts for closeted items. Also, since pluralizeWordy(item) uses available_amount, you're duplicating some work here.
Code:
if ($item[bowling ball].available_amount() > 0)
line += "|Have " + pluralizeWordy($item[bowling ball]) + ".";
if ($item[bowling ball].available_amount() < rolls_needed)
{
if ($item[bowling ball].closet_amount() > 0 && $item[bowling ball].available_amount() > 0)
line += " (" + ($item[bowling ball].available_amount() + $item[bowling ball].closet_amount()).int_to_wordy() + " total with closet)";
else if ($item[bowling ball].closet_amount() > 0)
{
line += "|Have " + pluralizeWordy($item[bowling ball].closet_amount(), $item[bowling ball]) + " in closet.";
if ($item[bowling ball].closet_amount() >= rolls_needed)
line += " (take them out!)";
}
}
Last edited:
Whether available_amount() uses the closet depends on your settings, actually (Item Manager -> Creatable -> use closet, in the GUI, or under Item Acquisition in Preferences, or autoSatisfyWithCloset).
No, he has 4 in his closet, 0 in inventory. The 4 closeted are being double-counted because they are also in available_amount() for him, while they are not for Ezandora.
You closet them so you can use all 5 bowling balls at once, after you no longer have to worry about a monster banish running out.
I assume by "come up" you mean "won't automatically make its own frame". It's doing that in the latest mafia build for me.
I found out (through talking with Ezandora) that if you use Firefox and resize any frames before opening Guide that it won't do that. Before I figured that out, I had been opening it in a new window and putting that right next to the main window, so it was basically the same as having its own frame anyway.
In this case, though, it's probably because there's a bug:
Bad skill value: "Summon Candy Hearts" (relay_Guide.ash, line 10009)
Apparently the name changed to "Summon Candy Heart". After I fixed that line, Guide appeared as normal (and it stopped giving that error message every two seconds).
Bad skill value: "Summon Candy Hearts" (relay_Guide.ash, line 10009)
Apparently the name changed to "Summon Candy Heart". After I fixed that line, Guide appeared as normal (and it stopped giving that error message every two seconds).
wrldwzrd89
Member
Do you have the latest KoLmafia and Guide versions? This bug has been fixed. If all else fails try removing Guide and installing it again, after updating to KoLmafia 16.5 or a newer daily build.
Last edited:
Yes. The github servers are buggy; they don't do SVN update correctly, it seems.
fractalnavel
Member
FYI, did dad sea monkee earlier is this aftercore, then went back and did the colosseum fights for the hell of it, and now Guide thinks I can go do the temple as a gladiator. It doesn't seem to recognize either that the temple is empty now, or that it was completed earlier. Entering the colosseum seems to have overridden the prior tracking.
No big deal, just quirkiness in response to my own.
No big deal, just quirkiness in response to my own.
Changed the default click location for levelling to be the airport/magazine scaling areas, if they're available. I'm not sure, but I think those are almost always better now than the spookyraven zones? I know Bale asked for that feature originally. Also, small and tiny sizes now give slightly more space to the text.
That update bug is problematic. I could switch to another host for the release URL? Don't know too many. It seems as though the local SVN store becomes corrupted somehow? I wonder if a newer version of the SVNKit library would help.
That may be mafia's internal tracking being off, but I am not sure. Try running this command if this happens again:
If it's "done", then there's a bug in guide.
That update bug is problematic. I could switch to another host for the release URL? Don't know too many. It seems as though the local SVN store becomes corrupted somehow? I wonder if a newer version of the SVNKit library would help.
That may be mafia's internal tracking being off, but I am not sure. Try running this command if this happens again:
Code:
get merkinQuestPathIf it's "done", then there's a bug in guide.
xKiv
Active member
IIRC, this happened to me two times, and the local store was not really corrupted either time.
First time, a certain revision was presented by github's svn support as inherently broken (just running "svn log" ended in error unless avoiding that revision, and updating past that revision wouldn't work because of that). This ... seems to have been fixed?
Second time, I found conflicting changes in svn properties of some file (IOW, I found the .orig + .mine files that indicate unresolved conflict; mafia of course doesn't have tools for resolving conflicts, and I already updated my commandline tools to version that requires newer repository format, so the resolution was again delete/reinstall ...). I am reasonably sure I didn't change any svn properties on my side ...
roippi
Developer
FWIW this is on my list of things to do - SVN repos not being backwards-compatibile is a drag - but I'm on a leave-of-absence from doing mafia stuff for the next month or so. It will happen eventually.
Bale
Minion
Well then, whenever you get to this, I have one clue for you. When this happens, I find an extra file in the /relay directory called relay_Guide.ash.prej which contains the following lines:
Code:
Trying to add new property 'svn:executable'
but the property already exists.roippi
Developer
Hum. That's a svn properties conflict file - similar to the .mine and .orig files from a failed merge, but svn treats property merges differently (read: it doesn't do them).
I don't know what exactly is messing with svn properties - I doubt Ezandora is, most people don't even know svn properties exist, much less need to change them. It's probably just some weird git+svn thing. If you delete that .prej file it should fully resolve the conflict. There's probably some good way to automate that, but again I won't have time to look at it for a while.