Guide

Even after a SVN update I keep getting a "Bad monster value: "clingy pirate" (relay_Guide.ash, line 14499)" error. Any idea why?
 
Delete the script and re-install it. Well known problem that svn repos on google code don't always update properly.
 
Ezandora said:
I remember seeing this before. It may be a mafia bug with that quest - questESpClipper being in a state that indicates it's in progress even if it is not. (get questESpClipper to check)

Click on the radio and keep listening to it. I think that clears out the flag as a backup.
Click to expand...

I'll check that next time that quest comes around.
 
Ezandora said:
I remember seeing this before. It may be a mafia bug with that quest - questESpClipper being in a state that indicates it's in progress even if it is not. (get questESpClipper to check)

Click on the radio and keep listening to it. I think that clears out the flag as a backup.
Click to expand...
It's actually a KoL bug, but as it clearly hasn't been fixed so far, we should change the way that quest gets set.

Basically the clippers are a combat item, and we set the quest started when we receive them. However, KoL has a bug where if you lose a combat item between combats, or for some types during combats, the first combat thereafter they still appear in the list of combat items. Mafia then notices that your inventory is different from the dropdown list, and 'corrects' your inventory. The examples I'm aware of are this, where it appears in the first combat dropdown after you complete the quest, and red buttons, where after you use and lose some the number in the dropdown list (and then Mafia) is wrong. I suspect KoL is building the dropdown list after combat rather than before it, or some such.
 
I'd said I'd check, but I suppose that's redundant now. I do indeed see the clippers in the combat items list in the first post-quest combat (but if I try to use them, it says I don't have any), and that does indeed set questESpClipper in such a way that Guide thinks the quest is active.
 
I'll have broken quest tracking for Nemesis quest again due to supporting new quest steps. You'll want to add 7 to step10 and above to make the old tracking work correctly.
 
Hairy said:
I've somehow managed to accidentally disable automatic refreshing for the guide. How do I reenable it?
Click to expand...

I've run into this as well. I used to be able to solve this by refreshing the frame as well, but it no longer works. Now, I have to manually refresh the frame every time.

I tried using a different browser, but got the same results. Deleting and reinstalling the script didn't help either. Maybe it conflicts with some other script? I have yet to try this solution, but will post here if I get any progress this way.

ETA: Just deleted every other script but this and results were the same: my Guide frame will not refresh unless I do it manually. Would someone else have any suggestions to troubleshoot this?
 
Last edited:
I'm glad to find that I'm not the only one who's run into this. I don't have any useful observations or ideas about what might be behind it; I simply noticed a few days ago that Guide wasn't refreshing as I played, which makes it much less useful. I've tried deleting and reinstalling but that hasn't helped.

I'd assumed I must have somehow changed a setting, as down at the very bottom of Guide's frame, it notes that "Automatic refreshing disabled.", so it would seem to be a thing that Guide monitors.

Running Windows 7, browsing with Opera 12.17.

Hairy
 
Last edited:
I installed Guide just to look at the code.

Code: 
string __relay_filename;
...
    __relay_filename = relay_filename;
...
    if (__relay_filename == "relay_Guide.ash")
        PageSetBodyAttribute("onload", "GuideInit('relay_Guide.ash'," + __setting_horizontal_width + ");");
    //We don't give the javascript __relay_filename, because it's unsafe without escaping, and writing escape functions yourself is a bad plan.
    //So if they rename the file, automatic refreshing and opening in a new window is disabled.
I don't understand the necessity of the last comment, but it seems like it's no longer getting the filename it expects - presumably because string comparisons are now case sensitive and, depending on your OS, filenames may or may not be case sensitive.

Guide can make itself OS-filename-independent by doing something like this:

Code: 
    __relay_filename = relay_filename.to_lower_case();
...
    if (__relay_filename == "relay_guide.ash")
(Technically, you could get away with only modifying the second line:

Code: 
    if (__relay_filename.to_lower_case() == "relay_guide.ash")
but why convert what is essentially a final variable to lower case every time it refreshes its pane?)

Try making these changes yourself and see if it fixes it for you.
 
I think you will need to include output from your browser's javascript console (Ctrl-shift-J in firefox), because as far as I can see, this can only happen when javascript aborts execution on the frame.

(ETA: and by that I mean that the message should be cleared out if javascript doesn't abort)
 
Last edited:
Veracity's suggestion did the trick. Thank you very much! And thanks to lost and xKiv for your suggestions as well!

It surprised me how much I've come to rely on this script, and this was really slowing me down. All back to normal now!
 
Code: 
    //We don't give the javascript __relay_filename, because it's unsafe without escaping, and writing escape functions yourself is a bad plan.
    //So if they rename the file, automatic refreshing and opening in a new window is disabled.
As I said, I don't understand that comment. In particular, ASH provides a function:

string url_encode( string )

which does the exact escaping that is necessary to put a string into a URL. So, why not:

Code: 
    PageSetBodyAttribute("onload", "GuideInit('" + url_encode(__relay_filename) + "'," + __setting_horizontal_width + ");");
 
Last edited:
Hmm, that explains it. Earlier I was testing various versions of Opera and couldn't track it down, but I was only using OS X and Windows XP, not Windows 7. Thought maybe there was an obscure javascript violation that I didn't take into account. Should be fixed in release?

Thank you for tracking it down.

Veracity said:
As I said, I don't understand that comment. In particular, ASH provides a function:
Click to expand...

Mostly that was to prevent arbitrary execution of javascript. Not that that makes sense, since that would entail changing the file name of guide... on the local computer... then the user running it. Habitual paranoia of unescaped strings? (probably didn't think/know of url_encode)
 
You must log in or register to reply here.
Back
Top