So 3 months on we are now in Beta and the 2 event handlers have not been fixed and are pretty useless right now. If I take my watch and put it on the ground it fires Put even handler but if I put it back into items is doesn't fire Take nor does it fire if I pick it with default action from the ground. Why? because it goes into items straight away.

It is still broken

Yep, very frustrating. Please give this some attention, your developer community could do so much with this!

upvoted.

But maybe there is some obscure logic to it. Maybe we just need to know what that logic is.

There is no mystery. Put backpack down - event fires, take backpack up - event doesnt fire. The only mystery is why is it still broken?

I honestly can't believe this still hasn't been fixed! It's a pretty useful EH to a wide range of modifications. I can confirm the strange behaviour as well, it's not consistent at all.

It would also be nice if the EH returned the classname of the previous item as well as the new one.

Related: http://feedback.arma3.com/view.php?id=12834

^^ I trust your experiments. I left some room for mistery since these events suggest a biderectional, hence 2 places possible. Yet between ground, inventory, associated slot (and subcontainers), those make at least 3 distinct places. In theory the events can only distinguish so much.

The "PUT" EH fires for removing headgear but the "TAKE" EH doesn't fire for equipping it. There's quite a few situations I've found where either "PUT" or "TAKE" won't work but the other one will.

It would be really nice if this was resolved soon please.

events Take and Put have never been designed for community usage so we can't guarantee a full functionality. Anyway I'm going to take a look what I can do for you

There really should be a fully functional version for the community. Thank you for trying though, I think many developers will appreciate it. As long as it works in both cases for the main slots I think everyone will be happy.

events Take and Put have never been designed for community usage so we can't guarantee a full functionality. Anyway I'm going to take a look what I can do for you

Sorry dude, these EHs were announced in one of the SITREPs or SPOTREPs so I guess they were meant for community after all. Anyway, if you can fix it, I will buy you a beer :)

To keep it only two eventhandlers (Put and Take), one could condense them into...

PUT:

• item slot* TO inventory**
• subcontainers*** TO inventory

• inventory TO ground

• item slot TO ground
• backpack TO ground

TAKE:

• ground TO inventory

• ground TO item slot
• ground TO backpack

• inventory TO item slot
• inventory TO backpack

*item slot represents also weapon slots, magazine slots, NVG slot, Glasses/Goggles, etc.

• inventory represents combat fatigues like items
  • subcontainers represents carriers and backpacks like items

Basically the biderection would be:
PUT == inner TO outer
TAKE == outer TO inner

the scripter would only require to make an additional check onto which level (of 3 possible) the item was placed.

gammadust: many thanks for nice overview of Take and Put behavior ;-) I tried to cover your description in DEV. 110425(not in steam distribution yet).

In future I'm planning to extend Take and Put arguments by some additional information like (drag started from vest/uniform/backpack/body/weapon and was placed in ground/crate,... ) but now I have some other issues with higher priority to do

Ideally it'd return the new classname and the previous classname as well.

Big improvement yet still quite buggy.,

1. Backpack still doesn't register TAKE.
2. weapon to inventory doesnt trigger put but transferring it back triggers take
3. weapon items to inventory (not magazines) like weapon do not trigger put but do trigger take

Keep up a good work we are almost there! :)

Killzone_Kid: situations from your bug report has been fixed in DEV. 110480 and will be distributed soon ;-)

Is there any chance we could make this event handler allow or forbid take or put operations depending on event handler's code returned value (true of false)?

I don't think it's really a necessary feature for the EH. I scripted a 'restricted items' feature last night, it's really not that difficult.

I assume it just deletes item off player and creates it back in the container?

SaMatra:
sorry, but your solution could be really beneficial, but quite hard to implement. We would have to change the whole EH system, callers, etc.. so maybe some day in a future, but not now.

@japapatramtara LOL dev branch update notes say the fix is in today's build, but it is obviously not. Damn it would have been good weekend :)

japapatramtara, thanks for the information. Also isn't "HandleDamage" EH already does something like that with allowing mission designer to change damage behavior before actually applying the damage?

Thank you for taking the time to improve this EH, I think a lot of people will appreciate it.

In my opinion the EH should eventually return [unit,from container,to container,new item,old item].

from container - the slot/container the item was originally in
to container - the slot/container the item is now in
new item - the classname of the item moved
old item - if an item was replaced (ie a slot) then it returns the previous item's classname

Blocking the action with returning true/false would also be helpful.

Obviously these are simply ideas for the future when you have the time.

The fact that it doesn't return both the new and previous container is actually really irritating.

I've just tested both handlers, couldn't find any problems. Well done japapatramtara! I owe you a beer :)

The "Take" EH fires when reloading. Could reloading please be ignored by the "Take" EH?

I actually quite like the fact that you can now detect when player is reloading.

@PolarisUK use findDisplay 602 to filter TAKE. It will return display if gear is open.

Reloading really shouldn't fire this specific EH. That's not helpful though because items/clothing/equipment can be "taken" without the gear being open. I'm fine with there being a reloading EH but it shouldn't be part of the "Take" EH. The magazine is not changing container and isn't being taken or put by the player.

OK I found a little bug. Make a unit then kill it, open its inventory and drag compass or goggles or radio to your inventory. The first time take doesn't fire, if you drag it back, put is fired, if you take it again take is fired this time.

@Polaris Yes magazine is changing container, it goes from inventory to weapon item slot. Also when you take item and gear is not open, the container will obviously not be you, you can detect this as well.

Yes but the vast majority of the time the magazine isn't depleted so you're just showing the switching of two magazines.

Also I've been dragging handgun back and forth between myself and dead body and at one time take didn't fire. I also managed to dupe it and ended up with 5 handguns instead of 2

@Polaris the transaction takes place and it fires the event. I say works as intended.

That's like saying it should fire when you throw a grenade. It shouldn't.

Would be nice if it did.

OK Mr japapatramtara, it seems like taking an item (compass, map, radio, goggles etc) from the dead body for the first time doesn't fire take, be it dragging into inventory or directly into designated slot. Hope this helps.

Killzone_Kid: SP or MP? And do you have a 100% repro or it does sometime only? I'm trying to reproduce your steps(kill the man and taking his compass, radio, etc.. and/or switching handguns with him and all EH seems to be ok even with no dupes)

japapatramtara, not sure if this is the bug that Killzone_Kid mentioned but here is weapon duping bug that we found (works in last stable):

1. Have few mags and weapon in non-local vehicle.
2. Player that is non-local to vehicle first puts few mags into his inventory.
3. Then player right clicks on weapon which puts it into his hands and auto loads one mag while also leaves same weapon in container.

I think it was MP (or SP cant remember). Will do detailed repo for you tonight.

well about duping items.. I'm actually working on a big patch which could solve the worst duping cases like duping whole containers etc. So maybe it will fix also others duplicates but who knows. JFYI see http://feedback.arma3.com/view.php?id=14539 - I'm working on itemsdupe_repro and then bodydupe. So don't worry I have n't thrown you overboard ;-) but try to keep in touch with the thread topic so If anyone will find anything with dupes, please report it into thread above and all about EH into this thread.

@japapatramtara

OK issue is present in MP. I could not test it on local unit because as soon as you kill local unit it freezes the game: http://feedback.arma3.com/view.php?id=15119

So this is what you have to do.

Get my sandbox package: http://killzonekid.com/arma-3-local-dedicated-server/

When logged in spawn a player on the server, enter in server box:

bill = createGroup west createUnit [typeOf sb_caller, position sb_caller, [], 0, "none"]

Kill him
open his inventory
drag compass, radio, map etc to your inventory

No take fired

Drag all back

Put fired

Now drag all back to inventory

Take fires now.

ok, I'm so close to fix dupes bugs, but it is no as easy as it can look(I have one server and three A3 running instances at my PC and of course three debug development tools, which means, that my i7 is on fire :-) ) anyway, today I'm planning to take overtime to solve it.

japapatramtara, you are our hero! All these dupes are plague for our Wasteland mission which is heavily loot-oriented. I hope we can finally get rid of dupes onces and for all!

dupe items podcast: I made a progress but... I'm sure you know a sort of bugs in which we simply change one line of code or true to false flag and everything is ok. Well.. dupe items problem definitely not that kind of bug :-/

@japapatramtara any news on the fix of these EHs? We are so close. I have posted above the repro http://feedback.arma3.com/view.php?id=7824#c56521 have you tried it? It is still happening in today's build.

DEV. 110926:
http://feedback.arma3.com/view.php?id=7824#c56521 - Event handler from remote corpse should be fired now.

sorry for delay, I forgot on this task at all ;-)

Tested, it works now, thanks. Can be marked resolved.

Kudus japapatramtara! :)

but i noticed:

EH return when triggered ie.

[BIS_fnc_setObjectVar_object1,33a3b900# 164238: dummyweapon.p3d,"NVGoggles"]

and

allUnits return

[BIS_fnc_setObjectVar_object1]

side BIS_fnc_setObjectVar_object1

WEST

assuming this is as a consequence of the new implementation, isn't it a bit risky to let the auxiliary object show there? It is easy to exclude it from the list but some allUnits usage may not account for it.

Edit:

player == BIS_fnc_setObjectVar_object1

true

just noticed this is the player itself. Which probably points to this originating elsewhere.

(version DEV 1.03.110951)

Mass-closing resolved issues not updated in 10 days.