copper248 reports: when player dies with a charge ... #4229
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#4229
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
copper248 reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
this is closely related to #4217. the solution is probably to not add an arrow to the inventory if there is not a bow in the inventory that can be unloaded.
Can we disallow inventory movements for loaded bows?
short answer, no.
that will only disallow player-initiated movements - mods generally ignore inventory permissions. perhaps they shouldn't do that (i sometimes wish they didn't), but it's "normal" and common. and the semantics for checking whether and how much of an inventory move are allowed don't make sense in some programmatic cases (e.g. calculating the results of crafting, including replacements, and putting those things in the various appropriate inventories).
in my mind, i'd prefer to just get rid of the "loaded bow" mechanic entirely. i think player metadata should track when the player last fired a shot, and the next time the player left-clicks ("uses the bow"), it'll fire an arrow at the appropriate power. if shots are too close together (less than 1/20th of a second?), the bow should assume lag and not penalize the player, though shots 1/10th of a second apart will just fall on the ground. we can make use of the "full_punch_interval" mechanic to give players some sort of sense of when they can fire another shot from the bow, but it'll be purely an approximation.
this would have the undesirable side effect of letting players pick up a bow and immediately fire an arrow, if they haven't used one in a long time. ideally the game would have some sort of "on_wield" and "on_unwield" callbacks.
There are only so many bows a person can have loaded at once. Maybe not the bow should have that "loaded" distinction, but some globalstep
basically, in my mind, these are more-or-less the thing. no need to use yl_settings, this isn't data that needs to be published arbitrarily.