New Content - Implemented Summer 2015 Path: One Crazy Random Summer

heeheehee said:
I guess that's conclusive?
Click to expand...
I'd say so.

Revision 15843 now recognizes 1337 monsters.

Something I noticed:

Code: 
[586] The Hidden Hospital
Encounter: pygmy orderlies
Round 0: Veracity wins initiative!
Round 1: Veracity uses the rock band flyers!
Round 2: Hobo Grrl climbs up and sits on your shoulder, and hands you some Meat. Huh, where did he find that?
You gain 65 Meat.
Round 2: Hobo Grrl runs in circles around your opponent, tangling them up in the nasty child leash and dealing 14 damage.
Round 2: pygmy orderlies takes 14 damage.
You lose 23 hit points
Round 2: Veracity attacks!
Round 3: pygmy orderlies takes 110 damage.
Round 3: Hobo Grrl runs in circles around your opponent, tangling them up in the nasty child leash and dealing 13 damage.
Round 3: pygmy orderlies takes 13 damage.
Round 3: Veracity attacks!
Round 4: pygmy orderlies takes 105 damage.
Round 4: Hobo Grrl runs in circles around your opponent, tangling them up in the nasty child leash and dealing 12 damage.
Round 4: pygmy orderlies takes 12 damage.
Round 4: Veracity wins the fight!
After Battle: Hobo Grrl sits on your fallen opponent's body, blows a smoke ring, and winks at you.
You gain 612 Meat
You acquire an item: compression stocking
You acquire an item: pill cup
You gain 7 Beefiness
You gain 14 Mysteriousness
You gain 26 Cheek
Those were 1337. As you can see, we recognized it. But, notice that it says:

Code: 
Encounter: pygmy orderlies
Normally, we log the "Encounter" as exactly what KoL says it is, and only later do we use the disambiguated name for reporting actions in combat. It looks like we are stripping random modifiers just a little early. I'll investigate.

Edit: and revision 15844 does that.
 
Last edited:
Veracity said:
I did not add a numeric "Random Monster Attribute" modifier. Those 6 items have it, as does the Curse of Randomness status effect. I'm not sure why anyone would care, although, I guess you could choose to maximize on it if it exists. Why not, I guess...
Click to expand...
Actually, if we say that the path itself gives you +1 of that modifier, we can use that modifier to decide whether to do our Crazy Random monster disambiguation, not whether you are on the path. That should be easy enough. I'll do it.
 
Regarding the random modifiers, we probably should save them somewhere, since they can affect HP, Attack, and Defense. I'm personally not concerned about that since my only ascending character has Manuel, but for those that don't, we should display the stats as munged by the various attributes, not the base monster.

Seems like MonsterStatusTracker could initialize the healthModifier, attackModifier, and defenseModifier variables to take the various random attributes into account when FightRequest finds a new monster. Obviously, we'd need to save the attributes when we strip them out of the Encounter.
 
Yeah. I've thought about this more. Here's what I propose.

We currently look at the Encounter and save it. Later, FightRequest.updateCombatData will call MonsterStatusTracker.setNextMonsterName if it is round 0, which does this:

Code: 
		MonsterStatusTracker.monsterData = MonsterDatabase.findMonster( monsterName, false );
If Random Monster Attribute > 0, we then do this:

- clone the MonsterData object
- save the list of attributes in a new field of that object
- iterate over the attributes and override the fields in (hopefully) the same way KoL does:

- turgid, huge, etc. modify HP
- others modify attack
- others modify defense
- broke & solid-gold modify base Meat
- ice-cold, burning-hot, spooky, sleazy, and stinky change the elemental alignment

I'm not sure how it works with multiple incompatible modifiers. I saw a "tiny huge" monster. Did it first make it tiny and then double it, say? Is it even possible to have an "ice-cold stinky" monster, for example - and if so, what does that mean? First set alignment to Cold and then to Stench?

- and then set MonsterStatusTracker.monsterData to the cloned & modified object.

This will result in the "original" HP and attack and defense being set to whatever is appropriate to this monster

And then, ASH's "last_monster" function should return something which points to this specific MonsterData, rather than making a brand-new one from the "name" of the monster.

And and the $monster data type needs a "random_attributes" proxy field which is an array of those things.

I'll do the above, with the exception of modifying the attributes in the cloned MonsterData object, since, as you say, we need more data on what they do.
 
Revision 15847 does as much of the above as I am currently able to test, given that I am out of turns and cannot see a fight.

- Added "Random Monster Attributes" modifier. The dice items, the Curse of Randomness, and the One Crazy Random Summer path each give you +1 to that.
- Added $monster.random_attributes proxy field
- make ASH's last_monster() function make a monster value that points exactly to MonsterStatusTracker.monsterData, rather than the unmunged MonsterData object from MonsterDatabase.

What remains is stashing away the attributes when we parse the combat encounter and using them in MonsterStatusTracker.setNextMonsterName to clone and munge the base MonsterData for the random monster. I'll do that tomorrow, when I have turns again.

And then, once we have more spading, we can also munge the various base attributes in the monster to that people without Manuel and consult scripts and what have you can use the randomized attributes of this specific monster.
 
Veracity said:
I'm not sure how it works with multiple incompatible modifiers. I saw a "tiny huge" monster. Did it first make it tiny and then double it, say? Is it even possible to have an "ice-cold stinky" monster, for example - and if so, what does that mean? First set alignment to Cold and then to Stench?
Click to expand...

Order of application looks to be left-to-right. This insight was from observing a broke, solid gold monster with a high base meat drop (so set to ~5, then set to ~1000).
 
Revision 15848 clones the MonsterData and inserts the random attributes in it and then iterates over them and munges the base attributes according to the random attributes. The only ones it does so far are "broke" (meat = 5) and "solid gold" (meat = 1000). I don't even know if those are correct, but we can change it when more spading is available - as well as adding all the other ones.
 
Evidently monsters with procedurally generated names do not get adjectives. This is probably a KoL bug.

If this ends up getting fixed, then invisible and tiny procedural monsters will probably break monster recognition, since the actual image gets replaced in those cases.
Code: 
<img id='monpic'  crossorigin="Anonymous"  src="/images/itemimages/blank.gif.gif" width=100 height=200></div></td><td valign=center>You're fighting <span id='monname'>some invisible Mismatched Twins</span>
 
Code: 
[794] Tower Level 5
Encounter: short Shadow Hemi-Apprentice Accordion Thief
Round 0: Veracity loses initiative!
You lose 177 hit points
Round 1: Veracity uses the gauze garter and uses the gauze garter!
You gain 94 hit points
You gain 83 hit points
You lose 174 hit points
Round 2: Veracity uses the gauze garter and uses the gauze garter!
You gain 87 hit points
Round 3: Veracity wins the fight!
After Battle: A love cricket plays a jaunty tune for you. You tap your feet.
After Battle: Jung Grrl says, "the urge to dance demonstrates repressed feelings of inadequacy about one's psychoanalytical abilities," and does a little dance.
You gain 49 Strongness
You gain 53 Mysteriousness
You gain 113 Roguishness
You gain a Moxie point!
It didn't tell me what was doing the damage. I would have hoped it would translate "Shadow Hemi-Apprentice Accordion Thief" into "Your Shadow".

Edit:

Code: 
[809] The Naughty Sorceress' Chamber
Encounter: The untouchable Naughty Sorceress
Even with my astral shirt and my Crimbo Shrub and its prismatic damage, I came up far short over 30 rounds. Oops. :)
 
Last edited:
Three new modifiers: American, wet, hot. American overrides image via javascript, so that shouldn't affect Mafia handling.
 
PaladinWhite said:
Modifiers listed in var ocrs don't always match the adjectives in the monster's name. For instance, monsters with the adjective "shaky" have the modifier "shakes". The adjective "restless" matches the modifier "zoom".
Click to expand...

And this is already part of KoLmafia's code also.
 
Veracity said:
That's news to me!

Type "ash last_monster().random_attributes" into the gCLI after you've entered a fight with a crazy random monster and tell me if you still believe that.
Click to expand...
Ah! Sorry about that. I'm not really familiar with pulling fields from $monsters and the development in this thread has been a lot to keep up with.

Are $monster fields documented anywhere?
 
PaladinWhite said:
Are $monster fields documented anywhere?
Click to expand...

Do they need to be? They are easy to list in the CLI:

> ash last_monster()

Returned: Goth Giant
id => 174
base_hp => 240
base_attack => 220
base_defense => 207
raw_hp => 150
raw_attack => 130
raw_defense => 117
base_initiative => 200
raw_initiative => 40
attack_element => none
defense_element => none
physical_resistance => 0
min_meat => 120
max_meat => 180
base_mainstat_exp => 42.5
phylum => humanoid
poison => none
boss => false
image => giant_goth.gif
images => aggregate boolean [string]
**giant_goth.gif => true
attributes => Atk: 130 Def: 117 HP: 150 Init: 40 Meat: 150 P: humanoid
random_attributes => aggregate boolean [string]
**quacking => true
**1337 => true
Click to expand...

The only confusing thing in that list might be the difference between raw stats and base stats. The difference is that a raw stat is before adding +ML mods and so forth. The base stat is the monsters stat at the start of a fight, before any deleveling or other combat actions change it. If something else is confusing, please tell us so that we can explain it.
 
Bale said:
Do they need to be? They are easy to list in the CLI:
Click to expand...
That'll work fine - thanks for the info. I just would never have thought to get that information via the function. Since the function returns a monster data type, I figured the $monster fields would be documented independent of the function. Having to go through a function to find the data type's fields seems very convoluted to me.

For instance, I think it would be useful to let users know that they can check $monster[monstername].raw_initiative without knowing anything about the last_monster() function, in particular.

The monster data type does have a (currently very cursory) listing on the wiki... I'll add the field list when I have a chance, unless people think it shouldn't go there.

Edit: I suppose that most of these fields have associated accessor functions - $monster[].raw_initiative and monster_initiative(), for instance. But they don't all have functions - .random_attributes being a good example, which is why I had no idea it existed, even after searching the wiki. So I still think listing the fields on the data type documentation would be helpful.
 
Last edited:
PaladinWhite said:
That'll work fine - thanks for the info. I just would never have thought to get that information via the function. Since the function returns a monster data type, I figured the $monster fields would be documented independent of the function. Having to go through a function to find the data type's fields seems very convoluted to me.
Click to expand...

I'm sorry. I clearly mislead you. You do not need to use any function to get that information. You can request it directly from any monster data type. Here's another example:

> ash $monster[pygmy witch lawyer]

Returned: pygmy witch lawyer
id => 1434
base_hp => 225
base_attack => 230
base_defense => 222
raw_hp => 145
raw_attack => 150
raw_defense => 142
base_initiative => 160
raw_initiative => 40
attack_element => none
defense_element => none
physical_resistance => 0
min_meat => 140
max_meat => 210
base_mainstat_exp => 42.083333333333336
phylum => dude
poison => none
boss => false
image => pyg_lawyer.gif
images => aggregate boolean [string]
**pyg_lawyer.gif => true
attributes => Atk: 150 Def: 142 HP: 145 Init: 40 P: dude Meat: 175
random_attributes => aggregate boolean [string]
Click to expand...

You can use it easily like this:

> ashq monster m = $monster[pygmy witch lawyer]; print("Meat range for a "+ m +" is: "+ m.min_meat +"-"+ m.max_meat);

Meat range for a pygmy witch lawyer is: 140-210
Click to expand...
 
Bale said:
I'm sorry. I clearly mislead you. You do not need to use any function to get that information. You can request it directly from any monster data type. Here's another example:
Click to expand...
Thanks, I understood that. My point is that I searched the wiki for this information, didn't find an accessor function for the random_attributes data, and therefore assumed that the data wasn't tracked. Since it's apparently tracked, but not accessible through a function, I think the field itself ought to be listed on the wiki, so that anyone searching the wiki can find it.

TL;DR: The wiki currently only documents functions relating to this data type, and since not all fields have an associated funtion, the wiki's information is incomplete.

Not a world-ending issue - it's not to say that the information is totally undocumented. All I'm saying is that it can be documented in a much more helpful way (ie. both places). If we're going to have a wiki, let's tell it about everything, not just some things! :) Like I said, I'll edit this in ASAP.
 
You must log in or register to reply here.
Back
Top