Hearthling item memory for vending stands

[Pacho]

Vending stands are currently just about as useless as coins, which is mainly because players can't sell items to vending stands, only buy from them. I understand that J&L don't want the players to have a full item list available to them through the vending stand, so I was thinking that hearthlings should be able to remember all items that have gone into their inventories through their lifetime (and ancestors). Such items are available for setting in a vending stand to buy provided there is enough money in its coffers.

[jorb]

It's not just that, though. It's also the fact that we would have to design a UI that allows for the specification of any and all relevant variables pertaining to the item in question. I am a bit reluctant to do that, as I also want to increase the complexity of several item categories.

[loftar]

Well, it's not primarily because of the availability of a list of all items (though that's a major factor too, of course), but because of the lack of any reasonable way to define item identity usefully. In particular, the requisites for e.g. crafting recipes or building blueprints are not defined as "this kind of item", but rather some or another predicate that items that go into that slot must satisfy. It is far from obvious how to make any kind of UI for specification of such predicates in the clients, and of course, the matching process is only one-way, so individual items could not be mapped into predicates in any way to implement the specific idea in the OP.

[jorb]

Well, it's not primarily because of the availability of a list of all items (though that's a major factor too, of course), but because of the lack of any reasonable way to define item identity in any useful way. In particular, the requisites for e.g. crafting recipes or building blueprints are not defined as "this kind of item", but rather some or another predicate that items that go into that slot must satisfy. It is far from obvious how to make any kind of UI for specification of such predicates in the clients, and of course, the matching process is only one-way, so individual items could not be mapped into predicates in any way to implement the specific idea in the OP.

Nog är det grabb

[Granger]

Could a solution working kind-of like the keymolds solve this:

Translated to vending stands you would need to have one item of the type you want to obtain, then you can prime the slot with it to make it accept this type of object as payment (maybe have a setting for minimum quality accepted).

?

[loftar]

then you can prime the slot with it to make it accept this type of object as payment

As I said, the problem is with defining any kind of item identity that could be used that way. It may be possible to hack something together, but it would be an ugly hack at best, and unfixable when issues start arising.

[Granger]

then you can prime the slot with it to make it accept this type of object as payment

As I said, the problem is with defining any kind of item identity that could be used that way. It may be possible to hack something together, but it would be an ugly hack at best, and unfixable when issues start arising.

Do i get it right that you're just telling me that the moment i hold an apple in my hand your server has no idea that this is an apple?

Don't think so. Hence when i press an apple into the slot the vending stand should remember: i take apples for this

[loftar]

Do i get it right that you're just telling me that the moment i hold an apple in my hand your server has no idea that this is an apple?

Yes, that is quite right. You might say that they are items that talk like apples and walk like apples (to reuse the old Smalltalk idiom), but there isn't a whole lot you can look at to say that it is an apple. When I say that I could hack something together, I mean I could do something like save the correct sprite for an item, and then accept all items that use the same sprite, but you can probably see why that would be opening a can of worms.

[Granger]

Do i get it right that you're just telling me that the moment i hold an apple in my hand your server has no idea that this is an apple?

Yes, that is quite right. You might say that they are items that talk like apples and walk like apples, but there isn't a whole lot you can look at to say that it is an apple. When I say that I could hack something together, I mean I could do something like save the correct sprite for an item, and then accept all items that use the same sprite, but you can probably see why that would be opening a can of worms.

*cough*

Maybe you can give me a little glimpse of insight that i can understand how you build this (and through this the problem).

You created this with OO technology? Like having a class which describes an apple (and the interactions it can have) ?
Or - in case you created it somehow different - do you have at least some kind of ID which describes the idea of an apple (which stays with the object)?

Or did you use a property based system?

[loftar]

You created this with OO technology?

Nope. :) I am utterly unconvinced by Simula-style OO.

do you have at least some kind of ID which describes the idea of an apple (which stays with the object)?

There are two possible things that could at all be considered an ID of an object: The sprite, and the ID for locating the code which takes care of deserializing an object from its on-disk save-format. Both would work for extremely simple things like apples, of course, but break down with more complex objects. The sprite can both vary within the same kind of object/item (as for e.g. road signs or tree-planting pots) as well as potentially being the same between different objects/items. The same thing goes for the persistence ID as well, though in different ways. For instance, kilns, baking ovens, ore smelters and finery forges are all deserialized by the same function. The same goes for all kinds of crime clues, and for some other stuff as well. Not to mention the fact that there's nothing to display that ID with.

Apart from those, objects/items have no type. They do have various predicates they can satisfy, however. The crafting and building systems ask an item if it is an apple, a string, some common metal, if it is a container containing at least an amount of some substance, or something else entirely.