A_TakeInventory does not function properly in zscript

[insightguy]

Code: Select all

override bool used(Actor user)
	{
		holdCounter++;
		A_GiveInventory ("WeaponInstall" , 1 , AAPTR_PLAYER1);
		if(holdCounter >= 100)
		{
			A_TakeInventory ("WeaponInstall" , 100 , AAPTR_PLAYER1);
			Super.touch(user);
		}
		if (user.player) { user.player.usedown = false; } 
		return true;
	}

A_TakeInventory ("WeaponInstall" , 100 , AAPTR_PLAYER1); does not take away the player's "WeaponInstall" but A_GiveInventory ("WeaponInstall" , 1 , AAPTR_PLAYER1); works perfectly fine. Is this supposed to be normal behavior?

COPY OF THE PROJECT

[phantombeta]

You're calling the function incorrectly. In non-action scopes the self pointer points to the real actor.
You need to use "Owner.A_TakeInventory ("WeaponInstall" , 100 , AAPTR_PLAYER1)" instead. A_GiveInventory works without that only because of the way the inventory is stored.

[insightguy]

You're calling the function incorrectly. In non-action scopes the self pointer points to the real actor.
You need to use "Owner.A_TakeInventory ("WeaponInstall" , 100 , AAPTR_PLAYER1)" instead. A_GiveInventory works without that only because of the way the inventory is stored.

Thank you! This fixed it.

@Mods, how do I lock this or move this away?

[Graf Zahl]

A_GiveInventory works without that only because of the way the inventory is stored.

It actually doesn't really 'work' because it gives the item the wrong owner which also could lead to unexpected behavior. This call should also be fixed.

This is one of those sloppy implementation details from old times which I unfortunately did not catch in time before making a release. But I think it's a good idea to let A_GiveInventory print a warning message, if it gets called on an owned inventory item. Remember: This is not defined behavior but merely a side effect of how the inventory chain is linked. So it's prone to getting broken, if stuff changes.

[phantombeta]

That's what I meant by "only because of the way the inventory is stored."
(I should probably have mentioned it's undefined behaviour, of course, since non-programmers probably won't realize that such a thing is undefined behaviour and a side effect of the specific implementation.)