Bow Shooting Takes Too Long about cataclysm-dda

[cosmo-naut]

It seems as though there are two separate issues:

A quiver taking longer to draw an arrow when there are many arrows, and shorter to draw when there is only one, is also a bug because it does not accurately reflect reality.

The bow being aimed fully and then having an arrow is a bug, because that is not how bows behave in real life.
Caveat: You could technically argue that a component of aiming is to first eye off the target before even raising your weapon, and I'm sure there are archers that could do this, however the common interpretation of aiming a bow is that there is an arrow notched and the string is drawn

Perhaps one of the inconsistencies is that bows are being treated somewhat similar to firearms

[Alm999]

It's not broken.

Thank you. The character tries to get all 52 arrows just to load one and then put the rest (51) back into the quiver.

Now I see that this is definitely broken. The calculated moves to draw an arrow should be per arrow, not for the whole bulk.

Also as I understand right now the character first aims the bow and only then!!! takes an arrow and loads it. How can anyone aim a bow without loading an arrow first? Does the bow just hang in the air in the same position while the character inserts the arrow?

[osuphobia]

It's not broken.
The main reason that it takes a long time to shoot is you put that many arrows in your quiver.

The reload time from your quiver(249) is even longer than from the ground(113).

If you left only one arrow in your quiver, the reload time also reduced to 53 moves.

Plus, the basic time needed to fire your bow is 95, so all the moves needed is 344.
The time needed to shoot didn't change, you just didn't notice you need that much time to shoot with a quiver.
Again, left only one arrow in your quiver, below is the time needed after the PR:

[osuphobia]

The calculated moves to draw an arrow should be per arrow, not for the whole bulk.

Well, if you consider it as broken, at least it was not broken by me :)

About the order of aiming and shooting, it's not that important if you see it as a whole. The real thing is, to change the function so you don't get every single move "refunded" when deciding not to shoot and walk away. But I didn't find a way to do it properly right now, so just did a port over. Might be less realistic, but still much more intuitive IMO.

[Alm999]

Well, if you consider it as broken, at least it was not broken by me :)

Yes, if anything, your patch hes helped expose weirdness in loading calculations.

I suppose, there is a code that adjusts item access time based on item size. And as 52 arrows are not really 52 individual items but rather a single "arrow" with 52 charges, this code "adjusts" the time based on the combined "item" mass/volume/whatever.

I believe this also affects staff sling and its "rock" ammunition.

[natsirt721]

I don't think the caveat holds here - presumably you're already eyeing down your target and have a loose range estimate on the order 10's of yards by the time you decide to draw on it. That's not something you're taking multiple seconds to assess, its going to be an intuition-based estimate that you start consciously assessing range from. Not to mention that range is not the only component of aiming, especially against a moving target. With auto-reaim on though, it seems unfair to penalize the character for drawing another arrow if the player's intention is to stop firing.

Frankly I don't see why bows can't be reloaded like any other firearm. All of them already have the two-handed fire flag, so it isn't unreasonable to assume that 'loading' the bow means 'arrow in hand' or even 'nocked but not drawn'. That would make this whole problem moot.

It does make archery mains slightly more annoying since you have to manually (r)eload after every shot but that seems like a reasonable tradeoff for consistent interaction.

[osuphobia]

@cosmo-naut
The way bow works before the PR:

1. Pressing f to choose the arrow and immediately reload with it.
2. Steady your aim or fire your bow, then the moves needed for reloading is consumed at once.
3. Not to shoot and quit the aim ui, with your bow unloaded immediately.

In step two, there were two bugs. The first one is, if you press f to enter the aim ui, then immediately quit it without any aiming action, you were supposed to get all the moves "refunded". The functions were wrote in that way, but failed to do so, thus you were losing moves by simply entering the aim ui. That's why auto re-aiming was banned for RAS weapon.
The second one is, if you aim at an adjacent tile and try pressing . to steady your aim, since that it can not be steadier, you just wait for one turn. Then, despite that there is an arrow notched, the moves needed for reloading is not consumed, firing your bow or quitting the aim ui will not consume the moves either.

Also, for all the other firearms without RAS flag, simply quitting the aim ui do not mean you give up shooting, nor is the aiming progress lost. All that things makes it annoying to fight with RAS weapons.

There were a lot of discussions about this issue, yet no one did move on and implement their plan. So I choosed an existing solution.
As I mentioned above, the actual order of aiming and reloading is not that important if you see it as a whole. Just need to change the function so you don't get every single move "refunded" when deciding not to shoot and walk away. I am trying to make it more consistent (it is way harder than I expected), but I don't think the situation at this point is worse than before. Like, many of you just didn't know exactly how much time is needed to shoot your bow, right?

[osuphobia]

Well, if you consider it as broken, at least it was not broken by me :)

Yes, if anything, your patch hes helped expose weirdness in loading calculations.

I suppose, there is a code that adjusts item access time based on item size. And as 52 arrows are not really 52 individual items but rather a single "arrow" with 52 charges, this code "adjusts" the time based on the combined "item" mass/volume/whatever.

I believe this also affects staff sling and its "rock" ammunition.

Maybe item_handling_cost is the function responsible?

Cataclysm-DDA/src/character.cpp

Lines 7286 to 7293 in 91763a3

	int Character::item_handling_cost( const item &it, bool penalties, int base_cost,
	int charges_in_it, bool bulk_cost ) const
	{
	int mv = base_cost;
	if( penalties ) {
	// 40 moves per liter, up to 200 at 5 liters
	mv += std::min( 200, it.volume( false, false, charges_in_it ) / 20_ml );
	}

This is 4-5 extra moves per arrow, some what reasonable I think, taking an arrow out of 50 arrows should cost more time. Cap it at like 50 moves for RAS weapon would be a solution.

[Alm999]

This is 4-5 extra moves per arrow, some what reasonable I think, taking an arrow out of 50 arrows should cost more time. Cap it at like 50 moves for RAS weapon would be a solution.

Yes, it seems that this function is the culprit. However, arrows in a quiver are not interlocked so there shall be little to no difference between getting an arrow from nearly full or almost empty quiver.

The main issue is "charges". Right now we do not have 52 arrows in the quiver. We have a single really big arrow with 52 charges and each time a character tries to get this arrow (s)he spends the amount of moves needed to fetch that big arrow.

Charges are causing a lot of issues and I believe this is one of them. Either the "it.volume()" function needs to be re-written to accept X amount of charges as an argument to correctly retrieve the volume of X arrows instead of all of the bulk, or arrows (and possibly other ammunition) shall be "discharged". The later will also fix character's miraculous ability to hold 125 rocks (or shall I say "rock (125)"?) in her/his hands like a juggler.

UPDATE

mv += std::min( 200, it.volume( false, false, charges_in_it ) / 20_ml );

Oh, maybe the function can already accept charges via charges_in_it argument… Maybe in this case this argument has to be set to 1 (because we are getting just one arrow to load).

[osuphobia]

When reloading, you need to obtain the ammo and reload it.

Cataclysm-DDA/src/item.cpp

Lines 11532 to 11534 in 5d07beb

	int item::reload_option::moves() const
	{
	int mv = ammo.obtain_cost( *who, qty() ) + who->item_reload_cost( *target, *ammo, qty() );

In item_reload_cost() everything goes well, qty is passed to charges_in_it to correctly calculate penalties.

Cataclysm-DDA/src/item_location.cpp

Line 720 in 5d07beb

int primary_cost = ch.item_handling_cost( *target(), true, container_mv );

But in obtain_cost(), or more exactly, when calculating obtain cost from container, qty is lost, so charges_in_it is -1, thus penalties is counted by the volume of the whole bulk.