Feature - Implemented Monsters have an integer associated with them

This is on the wiki and can also be scraped from Monster Manuel. eg. <a name='mon554'>

I would like two functions:

• int to_int( monster )
• monster to_monster( int )

I do have a use for this. I'm currently making a choice relay override to filter my list of monsters in "Rainy Fax Dreams on your Wedding Day" to show only the interesting monsters. It would be easier if I had these functions.

No rush since this time I have an easy work-around. It's just a little bit more complicated than I would prefer. I can manage by finding the necessary monster numbers on that page and plucking them out for my own use, but it might become more necessary in the future.

Would definitely like it if there were a way to see these numbers for monsters that Manuel doesn't get factoids for (I don't feel that wiki guesses plus stuff Jick showed on Twitch once is a good guide for the future).

And I just realized another possible issue. Some monsters have the same name. Mafia actually disambiguates most of these, but the gremlins have two different numbers and mafia cannot tell them apart.

Darzil said:

Would definitely like it if there were a way to see these numbers for monsters that Manuel doesn't get factoids for (I don't feel that wiki guesses plus stuff Jick showed on Twitch once is a good guide for the future).

Click to expand...

Ah well, perhaps someday there will be a better way to identify monster numbers. This is not a essential feature for me today — it would merely be nice.

Bale said:

And I just realized another possible issue. Some monsters have the same name. Mafia actually disambiguates most of these, but the gremlins have two different numbers and mafia cannot tell them apart.

Click to expand...

This. What happens to these functions if mafia is in a fight with a gremlin, and does not know which one it is?

I can think of several immediate uses for those, most obviously the "monster" category of batfactors. Following.

Bump.

Revision 15497 has a new version of monsters.txt which has a column for monster id. (It also allows each monster to have multiple images associated with it). For now, only the elemental monsters from Dreadsylvania have an ID (and their three images). All other monsters have a 0 listed for the ID.

It will be a large effort to fill in that data for all other monsters. I'm willing to accept ID #s from Manuel, but not Wiki guesses. If I recall, when we added monster images (or was it item images?), some helpful person here ran a perl script (or something) to scrape the data and provided us with a fixed file. Hint, hint.

There is also no internal map from ID -> MonsterData, yet, so the to_monster() ASH function can't be done, yet. I did add proxy fields to the $monster type. Thus:

> ash $monster[ spooky bugbear ]

Returned: spooky bugbear
id => 1394
base_hp => 800
base_attack => 500
base_defense => 500
raw_hp => 800
raw_attack => 500
raw_defense => 500
base_initiative => 25
raw_initiative => 25
attack_element => spooky
defense_element => spooky
physical_resistance => 0
min_meat => 0
max_meat => 0
base_mainstat_exp => 62.5
phylum => beast
poison => none
boss => false
image => dvspookybear1.gif
images => aggregate boolean [string]
**dvspookybear1.gif => true
**dvspookybear2.gif => true
**dvspookybear3.gif => true
attributes => HP: [600+KW*200+ML] Atk: [400+KW*100+ML] Def: [400+KW*100+ML] Init: [15+KW*10] E: spooky P: beast

Click to expand...

I'll put in that map I mentioned and provide to_int() and to_monster(), by and by, but it won't be that useful until the data entry part of this project is done.

If I recall, when we added monster images (or was it item images?), some helpful person here ran a perl script (or something) to scrape the data and provided us with a fixed file.

Click to expand...

If only, I think I did it in Excel and had no end of weird formatting issues!
Would probably do it differently next time!

There might be a problem with several monsters corresponding to the same monster ID (Dread bosses and their hard modes, slime1-5, Ed the Undying (1-7), off the top of my head). Also, several monsters in Mafia correspond to multiple monster IDs (ancient protector spirit, tool gremlins).

I started working on modifying missingManuel.ash before realizing that I'd run into the above problems.

The below Google spreadsheet contains unobtainable monster IDs leaked during twitch events and a lot of educated guesswork. All numbers after the end of the spreadsheet are verifiable numbers that are readily accessible via folks with complete (at least 1 factoid each) Manuels.

https://docs.google.com/spreadsheet...dDhuUHlPM0piQnA1eVNpNldYSklQdGc&usp=drive_web

Yes, it isn't trivial, and I don't think we'll use it internally as we don't know the id's when fighting monsters, so it has little practical use for anything Mafia does. This is purely a thing for scripts, mainly I suspect ones that interact with Manuel. For issues like tool gremlins it would make internal handling potentially more complex, as we'll have to handle monsters with multiple identical names, without any way to disambiguate them. The monster to int and int to monster functions will have to both be one to many relationships and return arrays for the scripter to then handle, and the int will not be a unique key, unless we totally change how we handle slimes, ed, dread bosses etc.

A thought on this. If someone wanted to, I'd suggest adding a checkmonsters command, that'd only work on character with manuel, which would go through each manuel entry and compare the name, number and all other available details with the information in MonsterDatabase, with suitable exceptions and comparisons, and output lines in monsters.txt format where there are significant differences. It's a non trivial exercise, but would at least not add extra manual hits to Manuel and mucking around looking at source code manually every time KoL adds a new monster, which is otherwise required to make monster ids work.

That would at least make adding new monsters less work, rather than more, to support this feature.

I will not be doing this, as I am currently unconvinced that this feature is useful.

Darzil said:

Yes, it isn't trivial, and I don't think we'll use it internally as we don't know the id's when fighting monsters, so it has little practical use for anything Mafia does. This is purely a thing for scripts, mainly I suspect ones that interact with Manuel. For issues like tool gremlins it would make internal handling potentially more complex, as we'll have to handle monsters with multiple identical names, without any way to disambiguate them. The monster to int and int to monster functions will have to both be one to many relationships and return arrays for the scripter to then handle, and the int will not be a unique key, unless we totally change how we handle slimes, ed, dread bosses etc.

Click to expand...

We currently translate the many possible names of the GamePro Dungeon mooks into the single monster they can represent by looking at the location we found them.

We COULD have 4 different ancient protector spirits - "ancient protector spirit (The Hidden Hospital)", for example - and translate into the correct type, similarly. Since they have different combat stats and drops, that would be useful for decorating the monster in the Relay Browser, as well as scripts.

Tool vs. non-tool gremlins cannot be discerned - and I am sure that is one reason why KoL itself will never give the monster ID on the fight page; it would allow third-party tools to recognize right away which kind it is, rather than having to stasis and wait for the "tell" for the non-tool variety. Therefore, it would be almost pointless for us to have two MonsterData for each gremlin, since we can't tell from the initial encounter which one you have found. Well, I suppose we could have two, and switch from one to the other when we recognize the message in combat...

I don't know what you mean by "slimes and dread bosses". We already have "slime1" through "slime5" and both Count Drunkula and Count Drunkula (Hard Mode). Which is to say, we already have multiple monsters for those.

I am thinking of whacking the method which is used by AdventureRequest which uses the responseText to get the "encounter" to use primarily the image, with tweaks as mentioned above, to get a MonsterData object. Aside from simplifying and speeding up the code, this would have only minor benefits for us - such as decorating protector spirits, as I mentioned - but it should be more maintainable, I hope.

Unfortunately, consult scripts are given a string, not a $monster. However, if we are a little smarter with deducing the MonsterData - and actually have unique monsters for the 4 protector spirits, for example - they'll also see an improvement.

The slimes and dread monsters was referring to HeeHeeHee's comment.

I can see that translating images into monster is useful.

It's the grabbing monster Id I see as less useful, as we can never use it as a unique identifier.

(Incidentally, currently looking at converting to use Effect Id's rather than names internally, as they ARE unique identifiers, which are always available, so hopefully we'll find significant benefits from using them).

Veracity said:

I don't know what you mean by "slimes and dread bosses". We already have "slime1" through "slime5" and both Count Drunkula and Count Drunkula (Hard Mode). Which is to say, we already have multiple monsters for those.

Click to expand...

Right. I was commenting that Mafia thinks these are multiple monsters, but KoL considers them to be the same monster, so monster ID wouldn't be unique with the current system.

Darzil: Would converting to use Effect IDs internally have ramifications for ASH scripts that use $effect[effectname]? That might be a big issue in terms of backward compatibility.

heeheehee said:

Darzil: Would converting to use Effect IDs internally have ramifications for ASH scripts that use $effect[effectname]? That might be a big issue in terms of backward compatibility.

Click to expand...

I'll start a new thread for that, but short answer will be no, unless effectname has multiple matches.

Bump to remind me/us to think about the many to one and one to many monster/id cases.

Bump again since this is still open and the same issues are being discussed elsewhere...

Bumping this as I go through more Manual factoid hunting. Here is my current list of multiple / non-disambiguated monsters.

Also, a request to add multiple unique monsters for ancient protector spirit and clingy pirate. Not sure how to handle the others. Currently all monsters on this list have a Mafia monster.id=0.

Those ids are all in comments in the data file, it's just finding a way to add them at this point.

Revision 16163 adds the following monsters:

ancient protector spirit( The Hidden Apartment Building)
ancient protector spirit( The Hidden Bowling Alley)
ancient protector spirit( The Hidden Hospital)
ancient protector spirit( The Hidden Office Building)
batwinged gremlin (tool)
clingy pirate (female)
clingy pirate (male)
erudite gremlin (tool)
spider gremlin (tool)
vegetable gremlin (tool)
Ninja Snowman (Hilt)
Ninja Snowman (Mask )
bizarre construct (translated)
hulking construct (translated)
industrious construct (translated)
lonely construct (translated)
menacing construct (translated)
towering construct (translated)
animated nightstand (White 1)
animated nightstand (Mahogany 1)
animated nightstand (White 2)
animated nightstand (Mahogany 2)

We disambiguate clingy pirate into clingy pirate (male) and clingy pirate (female) based on the image.
We could disambiguate the ancient protector spirits from the zone you are adventuring in, but do not do so, yet.
We could disambiguate the El Vibrato constructs by whether you have a translator equipped, but do not do so, yet.
We cannot disambiguate gremlins.
We cannot disambiguate the two Ninja Snowmen.
The animated nightstands are obsolete content and will never be found in situ. Perhaps they are faxable, but I think we cannot disambiguate them during battle.

There will undoubtedly be some issues as a result of this, so I'm going to leave this open, for now, although I think it deals with all the currently known problematic monsters.