Feature - Implemented Incomplete monster data (for consistency)

Catch-22

Active member
So apparently a bunch of the monsters introduced in the bugbear invasion haven't been added to the monsters database. I know a lot of the spading is incomplete, but I think it's better to have incomplete data than no data at all.

I haven't looked at anything yet, but it appears if you encounter an unknown monster KoLmafia create a monster on the fly for you, for example:

Before encountering a black ops bugbear.
Code:
> ash $monster[black ops bugbear]

Bad monster value: "black ops bugbear" ()
Returned: void

After encountering a black ops bugbear.
Code:
> ash $monster[black ops bugbear]

Returned: black ops bugbear
base_hp => 0
base_attack => 0
base_defense => 0
base_initiative => 0
attack_element => none
defense_element => none
min_meat => 0
max_meat => 0
base_mainstat_exp => 0.0
phylum => none
poison => none
boss => false

The trouble is, this only lasts for the session, so it would produce inconsistent behaviour if you referred to a $monster[] not in monsters.txt in a combat consult script, as I did here.

I propose that, even if we don't know how much HP a monster may have etc. we should still be adding the data that we do know to monsters.txt, which would (at minimum) include a name. That way we can refer to the monster directly in ASH instead of having to do last_monster().to_string() == "black ops bugbear".
 

Theraze

Active member
I think the general policy is to put anything trusted as right in, rather than badly spaded/wrong data.

That being said, I'm pretty sure we're certain of the names, at very least. As you said. HP/Attack/Defense might not be spaded yet, but... hey, at least we can target them.
 

Catch-22

Active member
I think the general policy is to put anything trusted as right in, rather than badly spaded/wrong data.

Oh, yes, I agree. By incomplete data, I mean we put the data that we do know in, and leave the data that we don't know out.

For the bugbears, I think we can at least be certain of their name and phylum. This is probably the case for many of the zombie core monsters too, but I haven't had the chance to start zombie core yet.
 
Last edited:

Bale

Minion
It wouldn't be the first time that incomplete data was added since it wasn't fully spaded in a reasonable period of time.

I long for days of KoL past where you could find herds of spaders so vast that they covered the nearby plains as far as the eye could see, much like the buffalo before them.
 

Winterbay

Active member
WHAM would very much appreciate getting the names into monsters.txt so that it can stop having to convert the monster-name to string for all comparisons it does on the bugbear-monsters :)
 

Fluxxdog

Active member
Out of curiosity, why aren't overrides kept until the appropriate data files get the appropriate information?
 

Veracity

Developer
Staff member
Because years of experience has shown us that automatically writing override files will guarantee bug reports when, for some reason, for a handful of people, the stale override files do not get deleted.
 

Bale

Minion
I am terribly happy that we don't get those bug reports now that we stopped keeping override files.

We never could figure out why override files were sometimes not removed when the data files were updated. It was a terribly confusing situation we finally ended by simply eliminating the override files. And after a few months, finally, those bug reports ended.
 
Top