You know those multitools? They can be open or closed.
A pockettool is a kind of thing. It is portable and openable and closed.
That’s what I’ve got right now. However, when I say
The multitool is a pockettool. it is closed.
Inform tells me it can’t be closed because I didn’t say it could be closed. Which is bulls*** because I just did!
And yes i also tried
the multitool is openable and closed.
it won’t let me open my items. #sadfaec
HOWEVER!
I solved it, sort of, but I’m open to better solutions! the reason will soon become clear:A pockettool is a kind of openable container. The carrying capacity of a pockettool is 0. A pockettool is usually closed.
Instead of inserting something into a pockettool, say "That can't contain things." instead.
The problem here is it says “You see a multitool (closed) here.” and i don’t want it to say the (closed) thing. And yes i know the [multitool] trick in the room description but it’s supposed to be kept in a portable holdall.
Also, tools are tricky business!
Before opening the TOOL when the player encloses the TOOL:
if the player is carrying something that is not the TOOL:
say "You put [the list of things that is not the TOOL carried by the player] in the satchel.";
-- move the list of things that is not the TOOL carried by the player to the satchel; --
if the player is not carrying the TOOL:
now the player is carrying the TOOL;
How do i dump whatever the player is holding into the satchel with the – move the list of things that is not the TOOL carried by the player to the satchel; – line? because the line itself doesn’t work.
and no, the – isn’t there in the code, it’s added for emphasis here
You’re trying to define the multitool as being closed, but as Inform points out, you haven’t said that it’s able to be closed. By default the open and closed properties are defined for only a few types of things, such as containers and doors.
The multitool can be open or closed. The multitool is open.
The multitool can be openable. The multitool is openable.
This seems strange, but if you’re familiar with other programming languages, you can think of it this way: a “can be” declaration is creating a member variable for a class. An “is” declaration is assigning a value to it. If you have one without the other, it’s something like this:
class Multitool{
public:
Multitool(){
openable = true;
open = true;
}
};
The compiler doesn’t know how “openable” and “open” should work for the multitool, because they haven’t explicitly been set up for that class.
the code thing made no sense to me but the top half helped a lot…
Just curious how I can force “something carried by the player” to be put into the satchel (the player’s hold-all). that would do a lot for me.
i can’t have them conflicting and the player should only be able to hold one thing at a time… ever.
taking something new should force the thing held into the satchel, and opening the tool should also lead to actively holding it (and thus putting anything else they were holding in the satchel).
The satchel is a player's holdall. The player wears the satchel.
Instead of taking off the satchel: say "This game will get very annoying if you aren't wearing the satchel."
The carrying capacity of the player is 1.
Before opening the closed multitool when the player does not hold the multitool:
say "(first taking the multitool)[command clarification break]";
try silently taking the multitool;
if the player does not hold the multitool:
stop the action.
Carrying capacity does the obvious thing: limits the number of things the player can carry. The player’s holdall kind should automatically take care of stuffing excess things into the holdall (see section 3.21 of Writing with Inform).
I haven’t tested this so it might be wrong somehow. Obligatory warning: Unless the inventory limit is really important to the mechanics of the game somehow, players may find messing with it very annoying even with a holdall.
Don’t be too sure about that. You want people to enjoy playing your game. I spent a lot of time in Scroll Thief just trying to make things less annoying: if you try to cast a spell straight from the book, you’ll prepare it first. If you don’t have the book with you, the game will tell you where you saw it last and allow you to navigate to that location in one command. Things like that. Players nowadays are less forgiving of the little tricks which were common in the old days, like non-Euclidean mazes, indistinguishable locations, hunger dæmons, unwinnable situations in general…but in this case I will leave that up to the discretion of your testers.
#sadfaec
