New Content - Implemented Monster Manuel as monster spading tool

Veracity said:
We have the mechanism for handling that in monsters.txt: rather than saying the HP is 99999, record it as [99999] - anything in [] is an expression. We use that for scaling monsters, but a constant expression works too.

I expect so. Are you volunteering? :)
Click to expand...

The first point was a slightly off-topic "bug" (i.e. monsters.txt would need updating, presumably after someone else confirmed this).

For the second point, I should have a multi sitting around in aftercore; not sure if it's the right sign, but I can ascend if not :)
 
That was lots of fun, thanks everyone! I doubt I'll be any help at this point, but I did manage to spin this code into something else. The collectors here should find it useful.

I'm still bugged about the loss of information. I noticed a handful of monsters are probably 1/1/1 and the MM lists them as 1/0/1, so you can't tell if it's really 1/0/1 or 1/1/1. I do scientific data processing for a living. Knowing if I'm destroying or creating information is innate to me.

Thanks Veracity. Ash is a work of art and I'm still learning to use it well.
 
Last edited:
Crowther said:
I'm still bugged about the loss of information. I noticed a handful of monsters are probably 1/1/1 and the MM lists them as 1/0/1, so you can't tell if it's really 1/0/1 or 1/1/1. I do scientific data processing for a living. Knowing if I'm destroying or creating information is innate to me..
Click to expand...

Can we start compiling a list of monsters that might suffer from loss of information? I just ascended a character into a myst sign with the intent to check out the outskirts of Camp Logging Camp. Although now that I think about it, it's actually impossible to tell in any of these cases, since the dwarvish uniform likely gives the current value (i.e. base multiplied by 90%), and any statistical spading would also be affected by this problem. On the other hand... does ML scale defense with a 1:1 ratio or 1:0.9 ratio? That might be viable (for weak monsters, get their base defense to 10; for stronger monsters, get their base defense to some value without disambiguity).

edit: if my math's correct, then we have ambiguity whenever something ends in a 0 (it could end in a 1 instead). I think this is the only case.
 
Last edited:
heeheehee said:
if my math's correct, then we have ambiguity whenever something ends in a 0 (it could end in a 1 instead). I think this is the only case.
Click to expand...
Yes, I didn't notice that, but it's as simple as that. Any raw defense ending in 0 or 1 rounds to the same value.
 
Why do we even record "raw" defense? Is that number used for anything or does it merely exist for historical reasons? Now that KoL officially reports the 90% figure wouldn't it be better if we switched to it everywhere?
 
We add things such as your current moxie and +ML to it, then multiply by 0.9 to get the actual defense. All of that extra stuff could be multiplied by 0.9 first, but then there has to be a clear way of recognizing/identifying which part to multiply by 0.9 in the data file. Also, if we just record the raw value from Manuel, there will be points where adding on 0.9*(+ML) and then rounding (up or down, or even to whichever number is closer) gives the wrong effective defense. If we wanted to be completely accurate that way, we would need to store defense values with 1 decimal value, and then we're still left solving the same issue being discussed above.
 
Thanks. It seems much more complicated that way. Not insurmountable obstacles, but there's no good reason to surmount them. Especially since it appears KoL invisibly uses the "raw" defense value in calculations as indicated by round-off values.

I'm glad to know there's a good reason we do it this way.
 
I am still working on this. I am slowly but surely collecting monsters. I haven't touched the Sea, Hobopolis, El Vibrato Island, or any of the no-longer-available monsters in the Fax machine yet, so I have a long way to go, but it's fun.

A while back I changed the names of the monsters in the Clumsiness Grove to agree with KoL - The Suffering Juniper -> Suffering Juniper and so on. A recent bug report reminded me that the name needs to change in combats.txt, too.

I'm thinking of changing the other monsters where KoLmafia adds "The" or "Some" or whatever to the name but KoL does not. We will still have "The Man" and "The Big Wisniewski", but "The Astronomer" will become "Astronomer", for example. I'll do this, by and by, unless there is a cry of outrage here first.
 
FYI - I have a big data file of all the monsters, images, attack, defense, and HP in my Monster Manuel checker 2 script setup. All these values have been pulled directly from KOL Manuel pages, so they should be all correct.
Well... everything except those images for monsters who's images change. In that case, I just listed the "first" or most simple image. I can confirmed all the monsters I have in my manuel... I just don't have them all yet.

http://kolmafia.us/showthread.php?11282-Monster-Manuel-checker-2

You have casually researched 34 creatures.
You have thoroughly researched 35 creatures.
You have exhaustively researched 786 creatures.
 
There are two versions of the clingy pirate based on your character's gender. They have the same stats but different images (girlpirate.gif and pirate2.gif).
 
lostcalpolydude said:
We add things such as your current moxie and +ML to it, then multiply by 0.9 to get the actual defense. All of that extra stuff could be multiplied by 0.9 first, but then there has to be a clear way of recognizing/identifying which part to multiply by 0.9 in the data file. Also, if we just record the raw value from Manuel, there will be points where adding on 0.9*(+ML) and then rounding (up or down, or even to whichever number is closer) gives the wrong effective defense. If we wanted to be completely accurate that way, we would need to store defense values with 1 decimal value, and then we're still left solving the same issue being discussed above.
Click to expand...

Apparently +ML is no longer multiplied by 0.9. I saw this mentioned in /clan, so I decided to test it out. I fought a goth giant, which has a Manuel base defense of 117. I was running +145 ML, and the initial in-combat defense was 259. That fits 117 + 145 +/- 5, and it does not fit (130 + 145)*0.9 +/- 5.

I haven't started looking at any code yet, but it looks like we can just match Manuel defense and remove the 90% factor.
 
The crates in Noob Cave are a pretty good place to see that too. I wasn't going to post anything about it until I also figured out how the monster defense variation changed though. Removing the 90% factor might not be necessary, but moving the + ML() a couple parenthesis to the right in MonsterData.getDefense() should take care of the +ML change.
 
So my MonsterData.java line 201 (in getDefense()) has been
Code: 
return (int) Math.floor( ( defense + ML() ) * getBeeosity() );
for most of the last week, and with that in place, all of
Code: 
> ash monster_defense($monster[beanbat])

> ash $monster[beanbat].base_defense

> ash $monster[beanbat].raw_defense
return the appropriate values when monsters.txt has manuel's defense numbers.

I haven't touched the corresponding line in getAttack(), because there's not a .9 multiplication there to be removed. I also haven't been able to test is what happens in Bees Hate You. Do negative attack and defense numbers get multiplied and made more negative when monsters have "b"s in their name?
 
You must log in or register to reply here.
Back
Top