New Content - Implemented New path "Actually Ed the Undying"

Am going to look at the Staff of Ed issues. Whilst calling it Ed's Staff of Ed and variations might work, I like the concept that they are the same item, and don't want to pollute that. As converting KoL to use itemId everywhere seems time consuming, I think I'll start by allowing modifiers.txt to use itemId's as Concoctions do, though maybe with an Item prefix (so Item[7961] for Staff of Ed) so we can expand it to other modifiers later without having to have separate modifier files for each modifier type. Would also change maximizer to use item Id's internally, but display to player as name (or possibly name (itemId)). Equipment.txt would also have to be able to use itemIds.

Note that this is only my thoughts before looking in the code, and even if successful there are probably loads of places where we internally work on name rather than Id to track down.

Mafia's Ka coin count didn't remove 20 Ka when I bought More Legs. Refreshing status didn't correct the count, and I had to close and reopen mafia to correct it.

darkcodelagsniper said:

Mafia's Ka coin count didn't remove 20 Ka when I bought More Legs. Refreshing status didn't correct the count, and I had to close and reopen mafia to correct it.

Click to expand...

r15443 - You'd have had to refresh inventory rather than status, as Ka is an inventory item that appears in status, rather than a true status thing. We could scrape the value from charpane to remain in sync, but refreshing status would have pulled new API, and that doesn't include Ka count.

Darzil said:

...

Click to expand...

Also, fuzzy item matching should probably know how to pick one or the other based on .. something? Otherwise "create staff of ed" would tell me that there are too many matches (see certain recent changes to kol's /go targets, especially crackpot mystic), wouldn't it?

This isn't straightforward. If I were starting mafia now modifiers would be properties of items, effects, instrinsics, etc, rather than a name indexed list of all of them.

At the moment I'm looking at storing all item data in that list as Item[xxxx] rather than itemname for Items, and as normal for the rest. ItemDatabase.getItemId will be updated understand Item[xxxx] and always return xxxx. At present I'm just adding getItemModifiers( itemId ) which will always return the right modifier, and looking to change item lookups to use that rather than getModifiers. Quite a bit of ItemDatabase is already based around ItemIds (mainly those bits not dealing with consumables), so a lot of the internal processing there already uses them.

This all does feel a little like opening Pandora's box, but I think that is worthwhile here.

Darzil said:

At the moment I'm looking at storing all item data in that list as Item[xxxx] rather than itemname for Items

Click to expand...

Please don't make the file completely illegible to humans by replacing unambiguous item names with id. If you want to add that syntax, please make it an additional syntax, not something that you impose on "ALL item data" (emphasis mine). If you want to tag all items, then either prefix the name with Item: or allow Item[name] - I don't care - but please allow us to still see the name for the vast majority of items whose names are unique within that namespace.

Darzil said:

This all does feel a little like opening Pandora's box, but I think that is worthwhile here.

Click to expand...

It's a huge change which needs planning and design rather than incremental bandaids. (which is not to say that I have not inserted incremental bandaids, myself: for example, the namespace used to be "canonical" names - lowercased, mostly - and when I noticed that we had items & effects with the same name save for capitalization, I changed that.)

As you said, there is a single namespace for modifiers - items, effects, passive skills, what have you. We do have "prefixes" on some of the names - Fam:, Throne:, Loc:, Zone:, etc.

Seems like we could start by doing a couple of things:

- tagging every name, adding Item:, Effect:, Campground:, Skill:, for example. Internally, we might give each of those categories a separate map from NAME -> MODIFIERS, for example, rather than a single namespace.
- for any category which has a natural "id" space, we allow a different syntax: Item:1234 would be item with id 1234. That item has a name, of course - and it is a lot clearer to look in the file and see the name - but this would handle the case of items in the same category that have the identical name. Such as the Staff of Ed.
- (for the above, you propose Item[ID] - or Item[NAME], I hope - rather than a prefix. That is fine.)
- So, for categories that have an "id" space, perhaps the map is ID -> MODIFIERS.
- A wrinkle is things like "Food" or "Booze", which have items and non-items (hot dogs, sushi).

For all of the above, we really need to always deal with things that have "ids" exclusively by that ID. Rather than passing around (ambiguous or aliased) item "names", always pass around the "id".

Quite a bit of ItemDatabase is already based around ItemIds (mainly those bits not dealing with consumables)

Click to expand...

Yes - because "consumables" are not always items, as I mentioned. Perhaps we really need ConsumablesDatabase.

In summary: lets figure this out before starting to make changes. Lets start with goals/specifications. Here are a few:

- The data file(s) need to be human readable & editable, as now (some of us depend on being able to look things up in modifiers.txt.
- Things which have a natural id-space - items, effects, skills - need to be manipulated internally strictly in terms of said ids. We will still need to display names for humans to look at, and will need to be able to accept names from humans (or KoL) and do our best to unambiguously map them to the right id. Fortunately, that is mostly typed input - for which we can prompt or report ambiguities or something - since things displayed in the GUI will, we assume, be objects with specific IDs.

Veracity said:

Please don't make the file completely illegible to humans by replacing unambiguous item names with id. If you want to add that syntax, please make it an additional syntax, not something that you impose on "ALL item data" (emphasis mine). If you want to tag all items, then either prefix the name with Item: or allow Item[name] - I don't care - but please allow us to still see the name for the vast majority of items whose names are unique within that namespace.

Click to expand...

My thinking was merely adding modifiers from modifiers.txt that match items in as Item[xxxx] rather than name, and those that are already Item[xxxx] going in as they are. When getting modifiers for items we can then use getItemModifier( itemId ) which would check for Item[xxxx] in the Modifiers database. I would certainly not be aiming to change modifiers.txt, other than that we can replace those names with Item[xxxx].

I do somewhat like the idea of adding Item:, Effect:, etc prefixes. It adds a lot of text of course, but does simplify some logic, and makes things clear. It also fits our current syntax for things that have been specified. We can use [ID] in place of names then to specify, only reason I was using Item[ID] was that I know we have at least one effect issue, which could be addressed by Effect[ID]. Item: [ID] is more consistent, as it means [ID] is a straight name replacement, as it is in concoctions.txt.

I think we'd need item:, thrall:, effect:, skill:, outfit:, statday:, food:, booze:, spleen:. I'd probably prefer capital as you've written, and we'd change the existing ones to match.

I'd suggest we change synergy/ to synergy: and mutex/ to mutex: for consistency. Not sure if we need item: or something else in front of items like campground, Clancy instruments etc. If we had things like that that could be equipped we would need them.

Ok, initial plan I think. Comments before I start implementing :

Store names in Modifiers.modifiersByName array with prefix: indicating modifier type (as we do now for Florist:, Loc:, Zone: and many others).
For items, store names in that array as Item: [ID], converting them after reading from modifiers.txt.
For items, lookup modifiers by Modifiers.getItemModifiers (itemId), which looks up modifiers with name "Item:[" + itemId + "]".
Where we look up item modifiers, use Modifiers.getItemModifiers(itemId) rather than Modifiers.getModifiers(itemName).
ItemDatabase.getItemId(itemName) will try to match [ID] as name to ID before trying anything else.

There are then three options, either:
A - Add prefixes to all modifiers.txt entries.
B - Make prefixes an initial data type field, and have three fields in modifiers.txt
C - Use other sources to calculate prefixes when not provided (eg ItemDatabase, ConcoctionDatabase, EffectDatabase etc).

Note, I'd probably do the same for Effects after Items, as we also have them listed by Id. As far as I can see we don't expose the name in the array except for debugging, and we always know the type of modifier we are looking for when using getModifiers.

Additional - I'm pretty sure maximizer and maybe equip/use commands will need to handle [ID], which may be trivial or even just work. Would be good if maximizer displayed that in a human friendly format however, even if submitting using [ID]. There will probably be some ash stuff too, but hopefully that can be implicit due to use of item, effect, etc types.

Veracity said:

Quite a bit of ItemDatabase is already based around ItemIds (mainly those bits not dealing with consumables)

Click to expand...

Yes - because "consumables" are not always items, as I mentioned. Perhaps we really need ConsumablesDatabase.

Click to expand...

I think I'll do this. It will handle inebriety.txt, fullness.txt, and spleenhit.txt and everything associated with that. it will not interfere too much with your plans, since it will - for now - just change the package various consumption-related methods are in.

Are you happy with the above approach, and if so any preference for A, B or C options? (My gut feeling says B)

I like B. Give every modifier name in modifiers.txt a "category" and have it a distinct field, rather than being glommed on to the name. Then, every place which looks up a modifier by name specifies which category it is looking up - "Item", "Effect", "Outfit", whatever - and it is up to Modifiers to find it.

It may be that it keeps all the modifiers in a single map and gloms the category and name together, separated by a colon, but it also has the option of having one map per category.

Revision 15444 does the ConsumablesDatabase thing, by the way.

A - I'll look at it, probably tomorrow.
B - Glom is a great word.

With r15447.

I purchased a mummified beef haunch from the shop in the Underworld. When I clicked on the "chew" link that appeared after purchase the item vanished from inventory but no adventures were gained.

Here is what appeared in the gCLI and session log:


I tried refreshing inventory but I had log out and then back in before the item appeared in inventory. After that I was able to consume the item from the relay browser.

This may be a limitation of being in the Underworld as I've noticed that I can't change equipment in the Underworld either. It is multi-consumable from the inventory page in the relay browser once the character is outside the Underworld.

With r15447 as "Ed".

I planted a Forest Friar plant in the Hippy Camp (Rutabeggar: +25 item drop) but it KoLmafia isn't reflecting the increased item drop in the zone.


The Rutabeggar's activities are reflected in the combat results in the relay browser.

Thanks for all these updates.
I'm poking around spading servant formulas. I just spent a while with my cat out and it looks like Mafia doesn't know servant weight caps at level 21.
I started the day with a lvl 21 cat, and after a number of kills, mafia showed it's level was 22. Going to the servants' quarters allowed mafia to show the correct level (level 21) again. The servants' quarter shows they are capped at 441 exp.

I'll reply again when I have more definitive data, but it's looking like the cat uses the fairy formula with weight = level.

Magus_Prime said:

purchased a mummified beef haunch from the shop in the Underworld. When I clicked on the "chew" link that appeared after purchase the item vanished from inventory but no adventures were gained.

Click to expand...

Yes, we should not generate use links when your limitmode is ED.

I tried refreshing inventory but I had log out and then back in before the item appeared in inventory. After that I was able to consume the item from the relay browser.

Click to expand...

Pretty much every time somebody says this, they are "refreshing inventory" by clicking the "refresh" button on the green sidepane - which refreshes status, but does nothing to inventory - rather than clicking the "refresh" button on the the Item Manager when you are looking at your inventory - which really does "refresh inventory".

However, I am not sure you actually CAN "refresh inventory" while in the Underworld; although that is done with an api.php call, not a visit to the inventory page, since you can't otherwise go look at your inventory, perhaps KoL suppresses it.

In any case, assuming you were really "refreshing inventory" by using the Item Manager, not the green sidepane (my money is on "no, you were using the green sidepane"), there should be no reason to "log out and then back in" - short of a KoL bug really hiding inventory items from your sight.

Cat spading at level 21 and 26 supports that it's a fairy with weight = level
http://kolspading.com/forums/viewtopic.php?f=2&t=457

ungawa said:

I started the day with a lvl 21 cat, and after a number of kills, mafia showed it's level was 22. Going to the servants' quarters allowed mafia to show the correct level (level 21) again. The servants' quarter shows they are capped at 441 exp.

Click to expand...

Thank you. I coded this before I had a level 21 cat, noticed it (supposedly) leveled to 22, but didn't go check the servant quarters. I expect switching to another servant and back to the cat should have fixed the XP & level, since that involves visiting the servants quarters, and we update all your servants every time you do that.

I'll reply again when I have more definitive data, but it's looking like the cat uses the fairy formula with weight = level.

Click to expand...

This would be nice. If so, I assume it kicks in at Level 7 - and the Maid is like a Leprechaun, starting at level 1.

I look forward to them implementing the Level 21 abilities; they sound like they would be a passive skill or something, but there is no message and no such skill appears on your charsheet.

Veracity said:

Pretty much every time somebody says this, they are "refreshing inventory" by clicking the "refresh" button on the green sidepane - which refreshes status, but does nothing to inventory - rather than clicking the "refresh" button on the the Item Manager when you are looking at your inventory - which really does "refresh inventory".

Click to expand...

I grant that your supposition is probably correct for the general case but not in this case. I actually refreshed both character status and inventory status and the haunch didn't reappear until I logged out and then back in.

Given my later experimentation I'd bet that if I had simply left the Underworld and then refreshed inventory it would have reappeared.