Question Should objects of type furniture also act as containers?

I want to place items on tables or similar objects that would normally be classified as furniture - if anything at all. So a mug could be on a bar, a plate of food on a table, a lamp on a nightstand, etc. What would make more sense:

1) Making anything classed as furniture also function as a container that isn't closable. This would probably be the easy way out, but having a character "look in table" seems clunky.

2) Make a new object type of, maybe, "surface". It would act like a container, but would not be closable or takeable and "look mantel" would return the mantel's description, plus something like "this mantel seems to have items on it". And then "look on mantel" would return a list of the items on the mantel. Obviously, bookshelves would still be typed as containers.

What do you folks think?

I wouldn't do the container hack personally. Furniture/surface though seems sensible.

Exact optimal implementation is subjective ofc, I don't think there's a "best" route necessarily.

Like, you could have:

look table, always shows the same thing and isn't dynamic
and look on table, shows the things on it

I think exactly how you want it to work though is a nuanced scenario without 1 obvious best implementation.

Personally, I think adding a SURFACE type where the contents are listed to the room seems like the most interesting.

Main chamber
The room is lit by a bright light coming from the altar along one wall, so you are easily able to make out every fold of the flesh-like walls, the dripping viscera and the blood pools along the walls.
A bloody alter is here, stained by apparent decades of sacrifices ...It glows with a bright light
On the bloody altar you see a constrained, heartless body, a still-beating heart and a blood-dripping desert kris.

> examine altar
The altar seems to be made from a white stone, with grooves leading down to the blood pools on the floor.
It looks extremely heavy.
It glows with a bright light.
On it, you see:
- The constrained body of a willing peon, with its heart removed
- A still-beating heart, now just pumping air
- A desert kris, bloodied and left behind.

> get kris
You get the blood-dripping desert kris from the altar.

> get heart from altar
You get the still-beating heart from the altar.


In this example, the altar is a surface, with three items. The items are easily visible, and you can interact directly with them.
To make this work, there's quite a lot of code that needs to be adjusted, but it's a possible way to go.

That sounds cool, I guess I was trying to avoid overstuffing the room descriptions. But I do like the idea of making more things dynamic, instead of baking stuff into the room description.

This is a cool idea!

Having a quick look over oedit.c , ITEM_FURNITURE only uses one value for the maximum people sitting on it.
All objects can potentially have four values, they just need to be editable in oedit.

I'd approach it like this:
Using ITEM_FURNITURE still, extend oedit.c to allow one of the unused values to be the maximum item capacity of the surface. Pretty much a copy of the ITEM_CONTAINER behavior.

Then your furniture values would be:
GET_OBJ_VAL(obj, 0) // number of people sitting on furniture
GET_OBJ_VAL(obj, 1) // maximum people allowed
GET_OBJ_VAL(obj, 2) // number of items on surface
GET_OBJ_VAL(obj, 3) // maximum items allow

Then you can have the extra functionality without adding a whole new item type (which would be fine too!)

There would be other places to update the code too, off the top of my head: loading/saving objects, zreset commands, dg triggers..

Point taken on maximum items allowed (versus just a weight limit).

And of course now I'm thinking - taverns! If you get a plate of mutton, do you "eat mutton plate"? Are bowls containers or surfaces? Okay, maybe that is too much to think at this stage (dirty v clean plates!?)