In I7 if you make a countainer edible and there is something inedible in the container, if you eat the container, you eat the other (inedible) thing to.
I wouldnât classify this as a bug. I7âs eating action is deliberately simple, because itâs a basis for you to build on. If youâre going to do wacky stuff like edible containers, itâs your responsibility to decide how that should work.
Edible containers could be a concept for a mini-comp. There are possibilitiesâŚ
If Kinder eggs are any indication, this should be a localisation issue: if American dialect is used, eating an edible container containing an inedible thing should make you die. Otherwise, the inedible thing just moves to your inventory.
Also, drinking hot beverages could be fatal.
In any case, itâs not hard to fix this âbugâ, e.g. like this:
"Yummy Cardboard" by Vyznev Xnebara
The Pantry is a room.
A white cardboard box and a brown cardboard box are edible containers in the pantry.
Some cookies are in the white box. The cookies are edible.
The list of found things is a list of things that varies.
Carry out eating a container:
now the list of found things is the list of things in the noun;
now all things in the noun are carried by the player.
Last report eating a container when the list of found things is not empty:
say "You find [list of found things with indefinite articles] in [the noun].".
Test me with "eat white box / eat brown box / eat cookies".
It seemed like a bug
There are a lot of situations that IF interpreters doesnât interpret like the programmer think is natural.
Firstly, it often makes sense to put a condiment like inedible mustard in a sandwich and then eat the sandwich without complaint. It also makes sense to put poison in food, whether other actors are doing it to your food or you doing it to an actors food. When you canât tell if Inform should allowed it or not, you leave it up to the programmer to decide what happens (by including something like "Instead of eating a container which contains something inedible, say âNo, you canât.â instead).
Secondly, a lot of these situations are too complicated to predict without writing a bloated framework. The Inform manual describes a scenario where the player circumvents an obstruction by getting in a box, and telling another actor to push the box in that direction. Yes, if you need this framework, you should make it, but it would bloat all IFs that didnât need it.
Thirdly, Inform is pretty primitive at places. Did you know that crossing an enterable chest counts as entering it? When you start looking for unnatural things, you can find all sorts of things. Thatâs why thereâs extensions and extension libraries.
It only becomes an actual bug if the interpreter either starts sending you error messages. (Try âpurloin all / i / drop allâ, for example.) I encountered a bug where the error messages themselves were corrupted (which I believe was fixed shortly after). Those are what actual bugs look like.
Well, sort-of; Iâm afraid that that perspective might encourage people to not always ask when they run into fishy behavior. While itâs true that error messages almost always indicate a bug, a bug need not imply error messages, so we generally use the official documentation to distinguish correct and faulty behavior. On bug 788, for instance, gnomon had no errors to report, but did cite two instances where the WI examples suggested a disagreement with the compiler. This case, however, falls under documented limitation'' rather than
bugââ because the Standard Rulesâ specification says that there are only two conditions on eating: that the noun be edible and that it be heldâthe edibility of sub-objects is not a listed criterion.