raidlog override a la Dr. Evi1

yohmanrules said:
Yup, theres a niffy warning in the village if I try to banish hot before I've banished cold that warns me that the cold banish might not work anymore if I want to banish hot first.
Click to expand...

Not that it's relevant to your point, but that was actually a KoL bug that has since been fixed, and that warning can be removed from this script.
 
Oh, so it doesn't matter which element I banish first?
Anyway, is it possible for what I requested to be done? Or would it complicate the script too much?
 
slyz said:
Actually, the script can adventure for you. If you choose Noncombats as your "Totals Table", you can right click each square to get a list of actions it can do for you.

Currently, the actions the script can do are the various banishes and Freddy gathering. I would love to see all the choices handled, since I use this feature quite a bit.
Click to expand...
You mean it doesn't show all the options? I spent soooo long typing that up, if I didn't commit it I'm going to kill myself.
 
slyz, you seriously need to update the script because it does a LOT more than that. At least I hope it will work for you once you update it...

bordemstirs, it does work for me. I've used the right-click menu to banish elements and monster types, get eau de mort and tarragon, make a ghost shawl and many other things.

The only thing that doesn't work on the menu is to use a key without selecting any choices...
 
Last edited:
I'm glad I posted :)

Apparently the version in /svn was up to date, but for some reason it wasn't being pushed to /relay. I blame the user.

Too bad I find this out on the same day that I got my last Dread drop!
 
bordemstirs said:
Having done that myself I'm surprised I didn't consider that as something people may want to do. I'll add that in when I get a chance.
Click to expand...

I think it has already been added, since there is an option for it. It just doesn't do anything when I click on it.
 
Bale said:
I think it has already been added, since there is an option for it. It just doesn't do anything when I click on it.
Click to expand...

When you click on it in its current state, you are saying "yes, I am agreeing that the action I perform may use a key" or, if already selected, saying nope, don't let me use one. Clicking it enables the options that would consume a key.

I suppose I'd make it also have an extra option to just go unlock the zone and then back out.
 
OH! I thought it would actually do something (specifically I thought it would unlock the zone and back out) just by clicking that. I did not understand that it was actually a safety lock. That explains why I had some trouble getting it to chose locked options a few times.

I thought "Use a key" meant to actually use it. Perhaps you should change the text to "Permit key use."
 
A request: Now that the mechanics for how the boss of a zone in Dreadsylvania is (more or less?) determined, could you possible put what's most likely the boss for the different zones into the picture for each of them once all the monsters in said zones are killed?
 
ereinion said:
A request: Now that the mechanics for how the boss of a zone in Dreadsylvania is (more or less?) determined, could you possible put what's most likely the boss for the different zones into the picture for each of them once all the monsters in said zones are killed?
Click to expand...

Since so many people have asked, I suppose I could do this for you folks. However, I am not aware of any such spading (and "more or less?" doesn't sound promising), so a link to a detailed (read: math) page on how this is determined would be lovely, since I cannot find this information on the wiki.
 
Each zone starts with 3 of one monster and 2 of another monster. If neither monster is banished, then you can look at which monster there has been more of (once enough have been killed). If one monster has been banished twice and the other monster has not been banished, the unbanished monster will be the boss. Most other scenarios are potentially ambiguous, though if all 1000 combats are a single monster (possibly from banishing both monsters twice to begin with) then that will be the boss. All that matters is the (randomly-determined) initial ratio and banishes, it doesn't matter whether you kill stuff before or after doing banishes, and if banishes bring it to an equal count (banishing the 3 monster twice and the 2 monster once putting them both at 1) then the boss is randomly determined.
 
lostcalpolydude said:
Each zone starts with 3 of one monster and 2 of another monster. If neither monster is banished, then you can look at which monster there has been more of (once enough have been killed). If one monster has been banished twice and the other monster has not been banished, the unbanished monster will be the boss. Most other scenarios are potentially ambiguous, though if all 1000 combats are a single monster (possibly from banishing both monsters twice to begin with) then that will be the boss. All that matters is the (randomly-determined) initial ratio and banishes, it doesn't matter whether you kill stuff before or after doing banishes, and if banishes bring it to an equal count (banishing the 3 monster twice and the 2 monster once putting them both at 1) then the boss is randomly determined.
Click to expand...

Okay, that's how I last had it described to me, and thus is the problem: the script doesn't know *when* banishes were performed. So in the edge cases (double vs none banish, or overwhelming monster majority and no banishes) the script has a decent chance at guessing but in the other situations... best guess is potentially way off, especially if banishes happened later in the run.

I guess I'll have to see if there's a mathematically sound way to best guess the other cases, and then decide from there. I'm guessing bayesian statistics would do it all.
 
On the plus side, those edge cases are liable to be the most common (people not bothering to control the bosses, and people ensuring the bosses).
 
Veracity said:
Why is that a problem? *when* the banishes are performed has nothing to do with determining the boss.
Click to expand...

It's important for guessing likelyhoods in ambiguous cases.
For example: two banished of A, two banishes of B, 1 monster left:
1) If it was banish 2*A, 999 fights, banish 2*B, then you could have seen
- with initial 3A, 2B: 66% of B, 33% of A, boss is A
- with initial 3B, 2A: 100% B, boss is B
2) If it was banish 2*A, banish 2*B, 999 fights
- with initial 3A, 2B: 100% A, boss is A
- with initial 3B, 2A: 100% B, boss is B
3) If it was banish 2*B, 999 fights, banish 2*A
- with initial 3A, 2B: 100% A, boss is A
- with initial 3B, 2A: 66% A, 33% B, boss is B
4) If it was 999 fights, banish 2*A and 2*B
- with initial 3A, 2B: 60% A, 40% B, boss is A
- with initial 3B, 2A: 60% B, 40% A, boss is B

60%:40% is not far enough from 66%:33% for observed rates to distinguish them; so you have the following groups, discounting the unambiguous "seen 100% of $AB -> boss is $AB":

group I:
66% B, 33% A, boss is A
60% B, 40% A, boss is B

group II:
66% A, 33% B, boss is B
60% A, 40% B, boss is A

So you still can't tell whether the boss is A or B, unless you saw 100% of one.
 
I think the kol's html changed a while ago. This page seems to no longer reference jquery. I noticed this when right-click menu didn't work.
Quick fix - I replaced line 1345 with
Code: 
if(m.find()) {
        write(m.replace_first("jquery-1.10.2.min.js"));
} else {
        writeln('<script language=Javascript src="jquery-1.10.2.min.js"></script>');
}

That probably puts it in the wrong place, and still misses some things (styles?), but right-click works again (for me, at least).
 
Thanks, xKiv! The missing styles bother my OCD (serif fonts in KoL just look WRONG), but the right-click menus not working is just darned inconvenient.
Your fix works for me. (At least until the whole thing gets fixed; which is hopefully a thing that happens.)
 
Sorry guys, I just noticed this (haven't played in a long while) and it too me a long time to figure out where the issue was. Should have started by looking here! Looks like the dev team took out the "http:" from the link, just updated the script to fix this.
 
You must log in or register to reply here.
Back
Top