Bale
Minion
After I scroll up I am sure.
Best PVP Gear - optimizes/balances for 8 mini-games
- Thread starter zekaonar
- Start date
After I scroll up I am sure.
ereinion
Member
Well, as I mentioned I can also see e.g. the results from the last combat before PVPBestGear is called above the "new output" of the script, so I guess it could have to do with the KoLmafia removing from the bottom of the buffer instead of from the top, but then I would expect it to remove one line at the time, and everything above that line to remain static? But as Bale says, it is not a huge problem, and cleaning the gcli window removes it, so I am fine with the true causes remaining a mystery 
xKiv
Active member
It (where it=java's code for handling the insides of the buffer) will remove as much as needed to keep the buffer small enough (measured in bytes, I think). It will do so whenever mafia prints anything into it and it's big enough to overflow the buffer.
Anything that prints entire page's modified html (or even decently large html tables) will use up kilobytes, or dozens of them. That's a lot when compared to lines logged from combats. I am not surprised to see even 40 combats disappearing.
What I am surprised to see is when it happens at the bottom of the buffer ... every time I printed large-ish html, either the top of the buffer was disappeared, or whatever I tried to print was immediately disappeared (because it was too big to fit in the buffer at all).
Crowther
Active member
I'll admit, I was sure this wasn't the Java bug, but I'm wrong, it is. You need to make your CLI very large to see it. Even on my screen it doesn't exactly match the Java bug, but I see multiple copies of the information, much like I do with other tables. The feature showing your current status should probably be removed for now.
Yes, I sorta asked for that to be displayed. What was really hoping for was predicted vs actual displayed together, so mismatches could be quickly noticed and fixed, but I didn't know that the mapping from item drop to it's mini wasn't known. Anyway, if you make your gCLI very large, you'll see it really is the same bug.
Yes, I sorta asked for that to be displayed. What was really hoping for was predicted vs actual displayed together, so mismatches could be quickly noticed and fixed, but I didn't know that the mapping from item drop to it's mini wasn't known. Anyway, if you make your gCLI very large, you'll see it really is the same bug.
Bale
Minion
There is that java bug also if you are using current java. Or if you are using java 7u55 like me, you will see only one the more mysterious bug and the table will look perfect.
Crowther
Active member
Oh, got you. No, I'm using the buggy Java, but I did see the other trouble before I updated. So it hits the double table bug and something else is wrong. Double trouble. I see know.
For some reason this was swapping to Stocking Mimic with Sugar Shield rather than Reagnimated Gnome with gnomish swimmers ears. (1 R rather than 2)
Am still getting the issue where if my best weapon is as good as my best offhand, it'll try to dual wield them even if I have only one.
Am still getting the issue where if my best weapon is as good as my best offhand, it'll try to dual wield them even if I have only one.
There are lots of HTML entities. No one has posted anywhere that I know of which ones KoL counts as the HTML entity and which ones are counted as the individual characters. That is the first step to anything being fixed.
Crowther
Active member
The problem is, it's PvP. I did some quick spading, decided what rules KoL used and patched my code. Is it perfect? I doubt it, but it's pretty close. Even though I'm not really trying this season, it's hard to put in the effort to share. The only time I've shared PvP code was when I didn't like a mini. I like this one. I just copied the code from nameLength() into lettersinname(). Arrr.
Last edited:
linguinelad
Member
Has this script been updated for the new pvp minis?
Crowther
Active member
Drat. I just did something similar this afternoon. I used a negative weight for 'L' also. I just used existing booze code. I also added the combat stuff, but I wanted to test it tomorrow as well. Maybe I'll post when I get home.
Fluxxdog
Active member
Bug:
If you try to equip multiple of an item, but some of it is in your closet, it'll take what you have equipped, unequip it, and re-equip it in a new spot. This is caused be mafia's retrieval order, so mafia's doing exactly as it's told. Since equipped items are higher on the list than your closet (if enabled), this will always happen. The problem comes in at line 356 in Crowther's version and 352 in digitrev.
Given that this is PvP, a lot of things are in the closet. In my case, it's 2 jam bands which both give 20% booze drops. I've got a modification to the if{} block that should help get that little extra:
This will check to see if the available you have is not in your inventory, if so then if you can get from your closet and have that available in your closet, pull one.
Then it goes to equip it. Since it's in your inventory, it won't unequip anything just to move it.
If you try to equip multiple of an item, but some of it is in your closet, it'll take what you have equipped, unequip it, and re-equip it in a new spot. This is caused be mafia's retrieval order, so mafia's doing exactly as it's told. Since equipped items are higher on the list than your closet (if enabled), this will always happen. The problem comes in at line 356 in Crowther's version and 352 in digitrev.
Given that this is PvP, a lot of things are in the closet. In my case, it's 2 jam bands which both give 20% booze drops. I've got a modification to the if{} block that should help get that little extra:
Code:
if (available_amount(i)-equipped_amount(i) > 0){
if(!(get_inventory() contains i)){
boolean raidCloset= get_property("autoSatisfyWithCloset").to_boolean() && closet_amount(i)>=1;
if(raidCloset){
take_closet( 1, i );
}
}
return equip(s, i);
}
else
return false;Then it goes to equip it. Since it's in your inventory, it won't unequip anything just to move it.
Crowther
Active member
Sadly Zekaonar has not logged on to KoL in a while. I found a bug in numeric_modifier2. The line that checks if a modifier is "> 0" should be checking if a modifier is "!= 0", because negative modifiers certainly exist. I've hacked up two scripts, because fame dumping seems to be very popular this season. Yes, they should be one, but I've no interest in supporting this script. Hacking is fun. Support is too like my work. Also, the weights I'm using are clearly not ideal for this season. It was as close as I was willing to put the effort into. I highly recommend you look at the output and choices and play around with different weights if you are really into PvP. For the conflicting minis, I chose the one with more letters, because letter of the moment.
Last edited: