Pocketing is there to stop item carrying limit exploits, therefore if the game tries to give the player something, and the player doesn't have room in their inventory, yes, it gets dropped on the floor, which is better than putting the game into an unwinnable state.
If you use :create, then you avoid the floor dropping, but it bypasses the item limit check.
What other way of giving objects to players would you like to see?
You normally use pocket when getting an object that hasn't yet been created. The default pocket handling is wrong. If you try to pocket something and there's no room in your inventory, it should just tell you so, the same as if you tried to get it after it had been created. It should NOT drop it in the room, otherwise your precious ming vase that is normally broken when dropped is not broken, or the apple that falls out of the tree when dropped does not fall but somehow balances precariously on a branch, or the object that normally sinks to the bottom of the lake magically floats on the water, or the metal wrench that falls to the magnified floor can never be recovered, and so on.
In other words, if something is not possible, you just say so. You don't do something completely different. Your method can put a game into an unwinnable state. Giving a message doesn't.
I disagree with this, but you are absolutely free to use : CREATE in the circustance that you don't want to use POCKET. I think that testing for if the current item is pocketable every time you run a one time cut scene is a little too much work for the beginner coder. Yes, dropping a ming vase on the floor might be wrong, but it would be equally as wrong for a game to say that it gave you a vase, then you don't have one now, and if you talk to the person who gave you it, they now don't give you it. Equally as wrong too to have some text that shows that a character gave you a vase, and even to have to return to that character. It's a lot of work checking to see if something is conveyable and takeable every time one of these scenes occurs. I happen to think that POCKET is infinately preferable to expecting a first time coder to code something like this:
Advanced case:
: match "talk vicar" {
: if (has_not_created "vase") {
: if (is_can_carry "vase" == false) {
: print "I have a vase for you, but I can see you have your hands full";
}
: else {
: print "\"Here is that vase I spoke to you about before\"";
: create target="inventory"; // Creates without weight / item checks
}
}
}
Simple case:
: match "talk vicar" {
: if (has_not_created "vase") {
: print "\"Here is that vase I spoke to you about before\"";
: pocket "vase"; // creates in inventory if item or weight limit not exceed, or in room if it is.
}
}
Maybe I can make another command to streamline the first case, but I make no apologies for pocket.
P.S. I can't see if is_can_carry() is a function or not, not currently at computer.
You may disagree with me, but your rationale agrees exactly with what I was saying. If you try to pocket something and your inventory is full, you DON'T pocket it and you DON'T create it, you just say "Your hands are full." (or whatever the system message is) and nothing changes.
If you think your sample code is messy, you should see my code for 'Seeker of Magic' and 'The Witch's Apprentice', where I have to do this sort of thing over and over again. And I'm going to have to do it again for this one for 20 or so objects.
Yes, I understand what you are saying, but what I disagree with is that the overhead would be acceptable to beginners. The easy way of doing this, is with a swap command, if it is a swap (and there are no weight limits), but in the simple case that you want a cut scene not to happen until the player has room in their hands, then you have all of that code to write. I could write a simple function to try to semi automate some of this but I don't think it would be generic enough.
Adventuron Classroom is for beginners to coding, they don't want to think about rollback of a failed transaction.
Considering a command like this (not for this jam though), in the background it will issue the has_not_created logic, and the create commands too, and will not run the standard command unless hands are free. Needs more thinking about :
: receive {
receive = [key, lamp]
// Optional, if not provided then this command does nothing if we cannot receive
on_hands_full {
: print "Come back when you have some hands free, I have some things for you.";
}
: print "Here is the key to the shed";
}