I have been making tests with GUI/Entity interaction, but something wasn't right. The ideia is: when the user clicks the button, the UI take the items from slot 1 and send a message with them to the source entity(the ID is being stored in "barrel.ID"), however, as I was testing, I found something bizarre: The item would be consumed, but the entity always received 'nil', so I changed the code to be sure. And I found this: the item is consumed but it isn't stored in the local variable, since whatever I did, the log would always say "I have nothing.". Is this a glitch or there is something I don't know about the function "world.containerTakeAt" (or another mistake)? Debug code: Code: function additems() local i = world.containerTakeAt(barrel.ID,0); if i == nil then sb.logInfo("I have nothing."); else sb.logInfo("I have " .. (i.name or "nothing?")); end end
Basically you're using the wrong function if you want item descriptor information(for placing elsewhere).
Sorry, but I didn't get it. "world.containerTakeAt" should give me the ItemDescriptor(like "containerItemAt", except that it consumes it on the process), according to the documentation. Also, I should make clear that, although I can find a workaround, I want the reason why it didn't work so I don't make the same error later.
I found out that using "world.containerItemAt" works, but why "world.containerTakeAt" doesn't? I belive the way GUI's Callbacks are handled is causing this. Just a theory though.
Hmm if what you're saying is accurate, then maybe the devs screwed up. Their code either isn't doing what it should, or their documentation is off. For curiosity sake, you could run a string search on the assets for world.containerTakeAt to see any cases of their code. See if they're using it in any way that would fail should the code not return a descriptor.
It does work when the function is run on the entity itself, however, if it's run on interface, it doesn't work. What I meant with "the way GUI's Callbacks are handled" is how and when they are called. In my theory, the function is called more than once before reaching the rest of the body, so "i" firstly gets set to the item and the first slot is cleared, but then the function is called again, going back to beggining, and "i" gets set to nothing, since there is no item on the first slot anymore.