l've added settings and increased the update step delay if no item is taken (or flying).

from item_drop.

I like it and I think the mod should as much as possible replicate the behavior of the original. Do you know if it's performance intensive?

from item_drop.

In comparison to simple picking it's performance intensive. But it's not a bottleneck, so it doesn't matter much l think.

from item_drop.

I see. Would the code be much leaner without that feature? Is that how you've wrote yours?

from item_drop.

I'd like it to be optional and disabled by default. Adding the animation makes it slow and laggy, and I see items fly around and getting missed from pickup. I'd rather see instant pickup myself.

If you do an animation, you should unconditionally pick up the item to the player after the "fly up", and not check again if the player is close enough.

from item_drop.

It sounds reasonable to keep animation but as an opt-in. What if we redid the pickup then, first the animation-free feature and later the animated version of that feature? In that case I believe @HybridDog already has the first version coded up, yes?

Please know that I'm not capable of coding those parts myself.

from item_drop.

There: https://github.com/HybridDog/item_drop/blob/master/init.lua
l don't have key configurations and the pickup radius and sound gain also can't be configured yet.
l agree with redoing the fly behaviour.

If you do an animation, you should unconditionally pick up the item to the player after the "fly up", and not check again if the player is close enough.

Then the item wouldn't follow you when you run away. A long time ago l ran away from items following me and couldn't escape them.

from item_drop.

Could you add the configuration variables and submit a PR? Then we could work from there on it.

Items only follow players if they were dropped by players, is this behaviour important?

I fail to see why this would be important, but perhaps I haven't thought of every scenario.

from item_drop.

Also, A lighter alternative to having the entities being animated when traveling towards the player could be to spawn som particles traveling towards the player instead. That would indicate to player(s) that a pickup was initiated without heavily animated entities.

from item_drop.

I fail to see why this would be important, but perhaps I haven't thought of every scenario.

When an item is dropped by e.g. a pipeworks pipe, it's not automatically picked up. Can l remove this behaviour?

Showing particles flying to the player doesn't work when the player moves (other than you spawn lots of individual short-living particles which causes lag) because of the client server asynchronicity.

What about following?
When item magnet is disabled, items inside pick_radius become instantly picked if they have zero velocity.
When it's enabled, items inside pick_radius are picked when they're tagged for collection.
 When they have zero velocity and are inside magnet_radius, they become tagged for collection.
 So after dropping an item you first wait until it falls down, then it becomes tagged and flies to you.

Where should items fly to, to the player's feet, trouser pocket or face?

from item_drop.

When an item is dropped by e.g. a pipeworks pipe, it's not automatically picked up. Can l remove this behaviour?

Yeah, to me it seems more logical that these items should be treated the same way by item_drop as any other. 👍

Showing particles flying to the player doesn't work when the player moves (other than you spawn lots of individual short-living particles which causes lag) because of the client server asynchronicity.

You're right, scratch that.

I disagree on the zero velocity part, because it's very handy to be able to catch items falling past the player that would otherwise end up in some deep hole or a lava pit.

To solve the problem with immediately picking up a thrown item the player could utilize either key activated pickups or a pickup radius smaller than the throwing distance.

I'd like it it if items went for the player pocket height 😃

from item_drop.

I'd like it it if items went for the player pocket height 😃

Shouldn't they fly to the center of the player since he could have another model than character.b3d?

from item_drop.

Shouldn't they fly to the center of the player since he could have another model than character.b3d?

Fine by me, since it's more or less the same. Towards the center it is.

from item_drop.

I disagree on the zero velocity part, because it's very handy to be able to catch items falling past the player that would otherwise end up in some deep hole or a lava pit.

You can't catch falling items reliably because the server may lag at any time.

from item_drop.

You can't catch falling items reliably because the server may lag at any time.

My server works great in that regard, I guess it depends on the size of the player base and such.

Let's add the zero velocity feature as opt-in then, that way single players and fast/small servers may get the best experience possible, yet slower/larger servers may opt for a more reliable experience.

from item_drop.

If some mod causes a delay while items fall through some player, they don't get collected, even if such a delay happens at almost no time. Players usually are not aware of this behaviour and expect items to not get lost this way.
Anyway, the problem is items get collected in an instant when dropping them. Another workaround (than zero velocity test) is collecting items when they have sufficient age. You could add a number setting to configure this delay, if it's set to -1 then zero velocity is used to detect whether items should be collected.
The problem of items falling in lava after digging a node can be avoided by doing the age test only if the item was dropped by a player.

In my version l made items become collected one after another because it sounds much better in my opinion. When taking a crowd of items, instead of a loud pop noise, the sound is played many times with short delays (similar to a machine gun with low fire rate). This only works with zero-velocity mode, are you fine with me adopting this behaviour to this repo?

from item_drop.

problem is items get collected in an instant when dropping them. Another workaround (than zero velocity test) is collecting items when they have sufficient age.

age test only if the item was dropped by a player.

This makes the most sense imo. Let's aim for this implementation.

items become collected one after another because it sounds much better

Agreed. Current behavior can be loud on the ears when collecting multiple items, especially when using headphones.

are you fine with me adopting this behaviour to this repo?

I don't quite follow. First, did you agree to add the zero velocity feature as opt-in?

from item_drop.

First, did you agree to add the zero velocity feature as opt-in?

Yes, l like to have this setting. When setting the age to -1, zero velocity mode is used.

I don't quite follow.

l just wanted to know if you approve this item picking, l don't think it's necessary to be able to enable the loud pop noise.

from item_drop.

Okay, sorry for the confusion. I'm all for it. 👍

from item_drop.

How should the settings for the magnet distance and inner distance be called?

from item_drop.

I've no idea honestly 🙂

from item_drop.

What about attraction distance and pickup distance? Or maybe radius instead of distance?

from item_drop.

Yes, attraction_radius (Or even magnet_radius!) and pickup_radius is better.

from item_drop.