your-land/bugtracker
your-land
/
bugtracker
44
20
Code Issues 2.5k Projects 2 Wiki

[testserver] y_bows: it's too easy to hit yourself #5974

New Issue
Closed
opened 2024-01-14 01:21:22 +00:00 by whosit · 31 comments
whosit commented 2024-01-14 01:21:22 +00:00
Member
Copy Link

It's very easy to hit yourself while moving forward (depends on the bow charge, but still too easy).

I also hit myself while sitting on a chair and looking around 45 degrees down.

Solving this by moving the spawning point of the arrow forward may allow shooting through thin objects...
Maybe better solution would be to ignore collisions with the "shooter" for some steps after arrow is shot?

It's very easy to hit yourself while moving forward (depends on the bow charge, but still too easy). I also hit myself while sitting on a chair and looking around 45 degrees down. Solving this by moving the spawning point of the arrow forward may allow shooting through thin objects... Maybe better solution would be to ignore collisions with the "shooter" for some steps after arrow is shot?
👍 1
whosit added the
1. kind/bug
 label 2024-01-14 01:21:31 +00:00
flux was assigned by whosit 2024-01-14 01:21:35 +00:00
flux commented 2024-01-14 19:21:25 +00:00
Member
Copy Link

there's no way to ignore some collisions but not all of them. but the distance where the arrow spawns w/ respect to the player could be adjusted based on player velocity and server lag. but that's not necessarily going to solve everything.

there's no way to ignore some collisions but not all of them. but the distance where the arrow spawns w/ respect to the player could be adjusted based on player velocity and server lag. but that's not necessarily going to solve everything.
flux added the
3. source/mod upstream
4. step/at work
 labels 2024-01-14 19:23:43 +00:00
flux added this to the flux's TODO list project 2024-01-14 19:23:49 +00:00
flux commented 2024-01-14 19:24:41 +00:00
Member
Copy Link

actually i could make it so that collide_with_objects is disabled on the first arrow step too, that'd help.

actually i could make it so that `collide_with_objects` is disabled on the first arrow step too, that'd help.
whosit commented 2024-01-14 19:56:18 +00:00
Author
Member
Copy Link

If projectile stores who launched it, then it should be possible to check in on_step() if the collided object in moveresult is the shooter? What happens if you just set_current_velocity(old_velocity)? (assuming engine updates it for you before calling on_step())?

I should experiment with it myself...

If projectile stores who launched it, then it should be possible to check in `on_step()` if the collided object in `moveresult` is the shooter? What happens if you just set_current_velocity(old_velocity)? (assuming engine updates it for you before calling `on_step()`)? I should experiment with it myself...
flux commented 2024-01-14 22:58:45 +00:00
Member
Copy Link

If projectile stores who launched it, then it should be possible to check in on_step() if the collided object in moveresult is the shooter? What happens if you just set_current_velocity(old_velocity)? (assuming engine updates it for you before calling on_step())?

I should experiment with it myself...

the thing is, the collision will still affect the projectile's velocity. i suppose we could use that to keep the arrow from punching the player and making a "ding" sound, but the arrow still wouldn't go very far. i made it so that arrows can't collide with objects on the first step, let's see how well that works before doing anything weirder. f67a2794df

> If projectile stores who launched it, then it should be possible to check in `on_step()` if the collided object in `moveresult` is the shooter? What happens if you just set_current_velocity(old_velocity)? (assuming engine updates it for you before calling `on_step()`)? > > I should experiment with it myself... the thing is, the collision will still affect the projectile's velocity. i suppose we could use that to keep the arrow from punching the player and making a "ding" sound, but the arrow still wouldn't go very far. i made it so that arrows can't collide with objects on the first step, let's see how well that works before doing anything weirder. https://github.com/fluxionary/minetest-ballistics/commit/f67a2794dff4c40be0065050c9e9edfb3e600a86
flux commented 2024-01-15 19:59:26 +00:00
Member
Copy Link

i made it so that arrows can't collide with objects on the first step

ugh this makes it so that "i can't hit this mob that's right in front of me if there's lag"

> i made it so that arrows can't collide with objects on the first step ugh this makes it so that "i can't hit this mob that's right in front of me if there's lag"
whosit commented 2024-01-15 23:15:05 +00:00
Author
Member
Copy Link

I think this will be just a limitation of using moveresult for collision.
It's called "tunneling" and the only way to avoid this problem is using ray tracing (or something even fancier) between server steps...

Basically what x_bows was doing. And also, it will be easy to check for collisions with the shooter.

I think this will be just a limitation of using `moveresult` for collision. It's called "tunneling" and the only way to avoid this problem is using ray tracing (or something even fancier) between server steps... Basically what x_bows was doing. And also, it will be easy to check for collisions with the shooter.
flux commented 2024-01-16 23:30:18 +00:00
Member
Copy Link

I think this will be just a limitation of using moveresult for collision.
It's called "tunneling" and the only way to avoid this problem is using ray tracing (or something even fancier) between server steps...

Basically what x_bows was doing. And also, it will be easy to check for collisions with the shooter.

yeah, the solution i was working on was using raytracing for the first step, then i encountered problems because i discovered the "estimated collision position" isn't working nearly as well as i thought it was. i'm wondering if i should give up on physical projectiles and move to pure raytracing. the problem is i'd need a way to interpolate the parabolic path, which i wanted to avoid.

> I think this will be just a limitation of using `moveresult` for collision. > It's called "tunneling" and the only way to avoid this problem is using ray tracing (or something even fancier) between server steps... > > Basically what x_bows was doing. And also, it will be easy to check for collisions with the shooter. yeah, the solution i was working on was using raytracing for the first step, then i encountered problems because i discovered the "estimated collision position" isn't working nearly as well as i thought it was. i'm wondering if i should give up on physical projectiles and move to pure raytracing. the problem is i'd need a way to interpolate the parabolic path, which i wanted to avoid.
whosit commented 2024-01-17 00:17:01 +00:00
Author
Member
Copy Link

What do you think the problems are with using Verlet integration for physics and assuming that arrows travel in straight lines between timesteps?

What do you think the problems are with using [Verlet integration](https://en.wikipedia.org/wiki/Verlet_integration) for physics and assuming that arrows travel in straight lines between timesteps?
flux commented 2024-01-17 03:38:37 +00:00
Member
Copy Link

What do you think the problems are with using Verlet integration for physics and assuming that arrows travel in straight lines between timesteps?

i've never heard of verlet integration before, i figured someone must have solved the problem but i hadn't found the solution myself. i'll dig into that, maybe tomorrow. part of me wants to take a break from coding projectile code to deep-think about it.

> What do you think the problems are with using [Verlet integration](https://en.wikipedia.org/wiki/Verlet_integration) for physics and assuming that arrows travel in straight lines between timesteps? i've never heard of verlet integration before, i figured *someone* must have solved the problem but i hadn't found the solution myself. i'll dig into that, maybe tomorrow. part of me wants to take a break from coding projectile code to deep-think about it.
flux commented 2024-01-17 03:40:12 +00:00
Member
Copy Link

Discretisation error

yeah this is exactly what i didn't want to derive myself. it still looks terrible, but not beyond me.

> Discretisation error yeah this is exactly what i didn't want to derive myself. it still looks terrible, but not beyond me.
whosit commented 2024-01-17 03:52:41 +00:00
Author
Member
Copy Link

https://en.wikipedia.org/wiki/Verlet_integration#Algorithmic_representation
Exact solution may not be necessary. Simple code similar to this example could be good enough for a game XD

https://en.wikipedia.org/wiki/Verlet_integration#Algorithmic_representation Exact solution may not be necessary. Simple code similar to this example could be good enough for a game XD
flux commented 2024-01-18 20:23:09 +00:00
Member
Copy Link

https://en.wikipedia.org/wiki/Verlet_integration#Algorithmic_representation

apparently the verlet method isn't appropriate when drag is involved - the drag calculations on the algorithm in wikipedia are deeply wrong. the internet suggests instead https://en.wikipedia.org/wiki/Midpoint_method

> https://en.wikipedia.org/wiki/Verlet_integration#Algorithmic_representation apparently the verlet method isn't appropriate when drag is involved - the drag calculations on the algorithm in wikipedia are deeply wrong. the internet suggests instead https://en.wikipedia.org/wiki/Midpoint_method
flux commented 2024-01-20 01:09:05 +00:00
Member
Copy Link

i spent today understanding the midpoint method well enough to code something, but it remains to be tested.

i spent today understanding the midpoint method well enough to code something, but it remains to be tested.
whosit commented 2024-01-20 01:46:10 +00:00
Author
Member
Copy Link

Would be interesting to see the difference between the two methods.
Midpoint will be more computationally expensive, if I understand it correctly? (if our step size = dtime...)
Of course, trajectories will differ because of error, but will it matter for the gameplay?
I would lean towards more simple method that just feels "good enough".

But this is just my guessing, better see the actual comparison.

Would be interesting to see the difference between the two methods. Midpoint will be more computationally expensive, if I understand it correctly? (if our step size = dtime...) Of course, trajectories will differ because of error, but will it matter for the gameplay? I would lean towards more simple method that just feels "good enough". But this is just my guessing, better see the actual comparison.
AliasAlreadyTaken commented 2024-01-20 01:54:24 +00:00
Owner
Copy Link

If one lags us significantly less than the other, while the other doesn't have a really big correctness (or other) advantage, then I'd prefer the less laggy one.

Ofc I'd also be interested in comparisons and benchmarks :D

Btw, the method currently on the testserver already looks quite nice, what's wrong with it?

If one lags us significantly less than the other, while the other doesn't have a really big correctness (or other) advantage, then I'd prefer the less laggy one. Ofc I'd also be interested in comparisons and benchmarks :D Btw, the method currently on the testserver already looks quite nice, what's wrong with it?
whosit commented 2024-01-20 02:02:56 +00:00
Author
Member
Copy Link

If one lags us significantly less than the other, while the other doesn't have a really big correctness (or other) advantage, then I'd prefer the less laggy one.

Ofc I'd also be interested in comparisons and benchmarks :D

What if additional lag it's not significant for a limited amount of projectiles? ;p

Btw, the method currently on the testserver already looks quite nice, what's wrong with it?

Besides hitting yourself - we need to have some irregular and large timesteps to see what may be wrong.
How can we get dtimes of 1.5 on the test?
/create_lag 1000000 3 (command from mesecons_debug) for 1/3 chance of 1 second lag.

> If one lags us significantly less than the other, while the other doesn't have a really big correctness (or other) advantage, then I'd prefer the less laggy one. > > Ofc I'd also be interested in comparisons and benchmarks :D What if additional lag it's not significant for a limited amount of projectiles? ;p > Btw, the method currently on the testserver already looks quite nice, what's wrong with it? Besides hitting yourself - we need to have some irregular and large timesteps to see what may be wrong. ~~How can we get dtimes of 1.5 on the test?~~ `/create_lag 1000000 3` (command from `mesecons_debug`) for 1/3 chance of 1 second lag.
whosit commented 2024-01-20 02:43:51 +00:00
Author
Member
Copy Link

With /create_lag 1000000 1.3 (75% chance of second lag) many arrows seem to disappear similar to how spears do....

With a constant lag I cannot hit a dolphin from up close... For a moment moveresult looked not too bad while shooting at walls... but hitting entities during lag just does not work it seems.

With `/create_lag 1000000 1.3` (75% chance of second lag) many arrows seem to disappear similar to how spears do.... With a constant lag I cannot hit a dolphin from up close... For a moment `moveresult` looked not too bad while shooting at walls... but hitting entities during lag just does not work it seems.
flux commented 2024-01-21 05:00:25 +00:00
Member
Copy Link

many arrows seem to disappear similar to how spears do

so far as i understand this currently, this is because the physical arrow collides with one thing, continues to move, collides with another, and then i try to guess where the original collision was. i need to try to retrace the path better if there's multiple collisions. i need to play around with that more, but it seems to be non-trivial. i really wish that the engine just reported the position of the object when it collided. this is one of the main things that make me think that i'll have to just give up on using physical entities and instead do a bunch of interpolated raycasting. ugh.

> many arrows seem to disappear similar to how spears do so far as i understand this currently, this is because the physical arrow collides with one thing, continues to move, collides with another, and then i try to guess where the original collision was. i need to try to retrace the path better if there's multiple collisions. i need to play around with that more, but it seems to be non-trivial. i really wish that the engine just reported the position of the object when it collided. this is one of the main things that make me think that i'll have to just give up on using physical entities and instead do a bunch of interpolated raycasting. ugh.
flux commented 2024-01-22 23:48:18 +00:00
Member
Copy Link

Midpoint will be more computationally expensive, if I understand it correctly?

it's not meaningfully more expensive, if at all - the algorithm is very similar.

With /create_lag 1000000 1.3 (75% chance of second lag) many arrows seem to disappear similar to how spears do

this is because my math to compute the estimated "collision point" doesn't work great with lots of lag, hence the need for something better.

the midpoint method estimation seems to work incredibly in practice. however, (1) projectiles under-shoot when there's significant lag (300ms server steps). that's not a bug with the midpoint method, though. (2) it goes nuts when the projectile is shot from or enters viscous nodes (e.g. water). i might leave fixing those things to a later release.

the code is currently in a bit of a messy state with tons of debug statements. i'll try to clean that up tomorrow, i've got to IRL now.

> Midpoint will be more computationally expensive, if I understand it correctly? it's not meaningfully more expensive, if at all - the algorithm is very similar. > With /create_lag 1000000 1.3 (75% chance of second lag) many arrows seem to disappear similar to how spears do this is because my math to compute the estimated "collision point" doesn't work great with lots of lag, hence the need for something better. the midpoint method estimation seems to work incredibly in practice. however, (1) projectiles under-shoot when there's significant lag (300ms server steps). that's not a bug with the midpoint method, though. (2) it goes nuts when the projectile is shot from or enters viscous nodes (e.g. water). i might leave fixing those things to a later release. the code is currently in a bit of a messy state with tons of debug statements. i'll try to clean that up tomorrow, i've got to IRL now.
flux commented 2024-01-23 01:54:02 +00:00
Member
Copy Link

i've got a limiter in the arrow drag logic that keeps drag from doing something stupid like making the projectile suddenly turn around. there's no direct way to translate that to the midpoint method's approximate integration, but perhaps decreasing the time-step by 10x or 100x when in a fluid node would solve the problem. but that could have a performance impact? will have to test it.

i've got a limiter in the arrow drag logic that keeps drag from doing something stupid like making the projectile suddenly turn around. there's no direct way to translate that to the midpoint method's approximate integration, but perhaps decreasing the time-step by 10x or 100x when in a fluid node would solve the problem. but that could have a performance impact? will have to test it.
flux commented 2024-01-23 01:59:12 +00:00
Member
Copy Link

i've got a limiter in the arrow drag logic that keeps drag from doing something stupid like making the projectile suddenly turn around.

actually, that might be the source of arrows not traveling as far as they should when the server is lagging? the code enforces that drag shouldn't cause a reverse in direction, but i think the solution is more complicated than that. it shouldn't be able to decrease the speed by more than some unknown but positive value.

> i've got a limiter in the arrow drag logic that keeps drag from doing something stupid like making the projectile suddenly turn around. actually, that might be the source of arrows not traveling as far as they should when the server is lagging? the code enforces that drag shouldn't cause a reverse in direction, but i think the solution is more complicated than that. it shouldn't be able to decrease the speed by more than some unknown but positive value.
whosit commented 2024-01-23 03:49:24 +00:00
Author
Member
Copy Link

(1) projectiles under-shoot when there's significant lag (300ms server steps). that's not a bug with the midpoint method, though.

Are you using substeps for integration, or just taking dtime? Maybe long step could be split into multiple shorter ones. Kinda like "catch-up"? Don't think there's a need for step/10, just a constant minimum "server step" maybe?

Also, looking at parabola and comparing tangents that Euler and midpont methods use - seems like euler will always overshoot and midpoint will always undershoot?

> (1) projectiles under-shoot when there's significant lag (300ms server steps). that's not a bug with the midpoint method, though. Are you using substeps for integration, or just taking dtime? Maybe long step could be split into multiple shorter ones. Kinda like "catch-up"? Don't think there's a need for step/10, just a constant minimum "server step" maybe? Also, looking at parabola and comparing tangents that Euler and midpont methods use - seems like euler will always overshoot and midpoint will always undershoot?
flux commented 2024-01-23 20:32:46 +00:00
Member
Copy Link

Are you using substeps for integration, or just taking dtime?

i'm using constant-sized substeps currently (0.09s, but i may need to decrease it to maybe 0.01 to deal with water). but the actual objects on the server are using dtime (see https://github.com/minetest/minetest/issues/12340 and the associated PR for discussion).

looking at parabola and comparing tangents that Euler and midpont methods use - seems like euler will always overshoot and midpoint will always undershoot?

https://indico.cern.ch/event/831093/attachments/1896309/3218515/ub_py410_odes.pdf

according to this (and some other things i found), euler tends to overshoot, and midpoint tends to be "more or less correct". if anything, midpoint is over-shooting in practice.

(red dots are the expected path according to midpoint method)
image

> Are you using substeps for integration, or just taking dtime? i'm using constant-sized substeps currently (0.09s, but i may need to decrease it to maybe 0.01 to deal with water). but the actual objects on the server are using dtime (see https://github.com/minetest/minetest/issues/12340 and the associated PR for discussion). > looking at parabola and comparing tangents that Euler and midpont methods use - seems like euler will always overshoot and midpoint will always undershoot? https://indico.cern.ch/event/831093/attachments/1896309/3218515/ub_py410_odes.pdf according to this (and some other things i found), euler tends to overshoot, and midpoint tends to be "more or less correct". if anything, midpoint is over-shooting in practice. (red dots are the expected path according to midpoint method) ![image](/attachments/9065fa05-815b-44f2-9fe6-ad7d2b2bb592)
image.png
216 KiB
flux commented 2024-01-23 23:19:01 +00:00
Member
Copy Link

w/ the latest commits to ballistics (and y_bows), this issue should be better.

w/ the latest commits to ballistics (and y_bows), this issue should be better.
flux added the
4. step/ready to QA test
 label 2024-01-23 23:19:16 +00:00
AliasAlreadyTaken added this to the 1.1.123 milestone 2024-01-24 04:42:04 +00:00
whosit commented 2024-01-26 04:36:37 +00:00
Author
Member
Copy Link

With /create_lag 1000000 1.3 (75% chance of second lag) many arrows seem to disappear similar to how spears do....

With a constant lag I cannot hit a dolphin from up close... For a moment moveresult looked not too bad while shooting at walls... but hitting entities during lag just does not work it seems.

Ballistics 2024-01-23: it's possible to hit mobs during lag 👍
(but particle trace becomes invisible)

Also much harder to hit yourself 👍

> With `/create_lag 1000000 1.3` (75% chance of second lag) many arrows seem to disappear similar to how spears do.... > > With a constant lag I cannot hit a dolphin from up close... For a moment `moveresult` looked not too bad while shooting at walls... but hitting entities during lag just does not work it seems. Ballistics 2024-01-23: it's possible to hit mobs during lag 👍 (but particle trace becomes invisible) Also much harder to hit yourself 👍
flux commented 2024-01-28 00:49:07 +00:00
Member
Copy Link

arrows are now totally non-physical and will not collide with their "source" (the object e.g. player who shot them).

arrows are now totally non-physical and will not collide with their "source" (the object e.g. player who shot them).
flux removed the
4. step/at work
 label 2024-01-28 00:50:04 +00:00
AliasAlreadyTaken added the
ugh/QA OK
 label 2024-01-28 12:08:44 +00:00
AliasAlreadyTaken added
ugh/QA NOK
 and removed
ugh/QA OK
 labels 2024-01-28 12:11:37 +00:00
AliasAlreadyTaken commented 2024-01-28 12:12:09 +00:00
Owner
Copy Link

QA

I can't shoot myself, neither with or without pvp.
However I can't shoot anyone else anymore, regardless of pvp state.

The arrows go straight through. Related to #6118 ?

grafik

QA I can't shoot myself, neither with or without pvp. However I can't shoot anyone else anymore, regardless of pvp state. The arrows go straight through. Related to #6118 ? ![grafik](/attachments/e1fc73df-1492-40ee-a9e5-abb3a9db66f2)
grafik.png
257 KiB
flux commented 2024-01-29 01:52:26 +00:00
Member
Copy Link

verified that i also cannot shoot another player currently. i can shoot petz just fine tho.

verified that i also cannot shoot another player currently. i can shoot petz just fine tho.
flux added
4. step/at work
 and removed
4. step/ready to QA test
 labels 2024-01-29 01:52:39 +00:00
flux commented 2024-02-04 00:22:42 +00:00
Member
Copy Link

i finally figured out why arrows weren't hitting players - players are non-physical. that's what allows other players to walk through you... fixed 509200a43e

i finally figured out why arrows weren't hitting players - players are non-physical. that's what allows other players to walk through you... fixed https://github.com/fluxionary/minetest-ballistics/commit/509200a43edeb37ef3a28ec816278ab70a3beec3
flux added
4. step/ready to QA test
 and removed
4. step/at work
 labels 2024-02-04 00:36:09 +00:00
whosit commented 2024-02-05 16:28:10 +00:00
Author
Member
Copy Link

ballistics 2024-02-04 on test:
Can't hit myself at all even when I'm trying.
Can hit other players as expected.

Turns out diamond armor can sometimes even one-hit kill a player without armor...

ballistics 2024-02-04 on test: Can't hit myself at all even when I'm trying. Can hit other players as expected. ~~Turns out diamond armor can sometimes even one-hit kill a player without armor...~~
👍 1
whosit added
ugh/QA OK
 and removed
ugh/QA NOK
 labels 2024-02-05 16:28:34 +00:00
flux added
5. result/fixed
 and removed
4. step/ready to QA test
 labels 2024-03-28 20:26:25 +00:00
flux removed this from the flux's TODO list project 2024-03-28 20:26:28 +00:00
flux removed their assignment 2024-03-28 20:26:30 +00:00
flux commented 2024-03-28 20:26:38 +00:00
Member
Copy Link

this is live

this is live
flux closed this issue 2024-03-28 20:26:38 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
1. kind/balancing

Depends on balancing

  
1. kind/breaking

something that alters or disables an existing game mechanic

  
1. kind/bug

Something is not working

  
1. kind/construction

A build needs fixing

  
1. kind/documentation

Needs proper documentation

  
1. kind/enhancement

New feature

  
1. kind/griefing

players despoiling builds or nature

  
1. kind/invalid

Not a valid report, e.g. created by mistake with no content.

  
1. kind/meme

issue is mostly a joke

  
1. kind/node limit

something which works for or against the node limit

  
1. kind/other

Something not within the other kinds

  
1. kind/protocol

something concerning how staff should react to player requests, or how players should treat each other

  
2. prio/controversial

not likely to happen w/out a lot of discussion

  
2. prio/critical

Very important

  
2. prio/elevated

something players are eager to have fixed

  
2. prio/good first issue

the resolution to this is could be done by a new minetest contributor, who doesn't yet understand the mod ecosystem

  
2. prio/interesting

one of us has real interest in getting this implemented or fixed. however, more research might be needed.

  
2. prio/low

Not so important

  
3. source/art

art needs to be created or found for this to exist. includes sound, 3d modelling, and in-game building.

  
3. source/client

Issue is with the minetest client, or with player client configuration or the technical details of their setup

  
3. source/engine

Issue is due to a bug or feature of the minetest engine

  
3. source/ingame

Problem and solution exist in-game, e.g. builds or player moderation

  
3. source/integration

Two or more nonbuggy mechanics conflict, or our attempts to rectify conflicting mechanics have created a new bug

  
3. source/lag

A problem which is caused or made worse by lag, due to server processing issues, client processing issues, or network issues

  
3. source/license

A licensing problem is involved

  
3. source/mod upstream

Problem is upstream (not engine/client)

  
3. source/unknown

   
3. source/website

Affects the website

  
4. step/approved

Alias has approved this feature, someone should implement it

  
4. step/at work

Being worked on

  
4. step/blocked

we plan to do this, but other work has to be finished first

  
4. step/discussion

issue is under discussion, a solution has not been dictated or agreed upon

  
4. step/help wanted

Need some help

  
4. step/needs confirmation

   
4. step/partially fixed

this is mitigated or partially solved, but more work needs to be done

  
4. step/question

More information is needed

  
4. step/ready to deploy

has been QA tested by another person. has no outstanding issues. might be installed on prod, but needs final testing

  
4. step/ready to QA test

the code is supposedly fixed, but needs to be tested.

  
4. step/want approval

Someone can quickly implement this if Alias approves the change/feature

  
5. result/cannot reproduce

   
5. result/duplicate

This issue or pull request already exists

  
5. result/fixed

problem is fixed

  
5. result/maybe

not planned currently, but maybe some day

  
5. result/wontfix

the reported issue won't be changed, whether it's intentional or not.

  
ugh/petz

yet another petz bugz.

  
ugh/QA main

That's something we can only wait and see whether it hapens again: On the main server

  
ugh/QA NOK

Fix didn't yield the expected results

  
ugh/QA OK

tested

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
Milestone
Clear milestone
No items
No Milestone
1.1.123
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: your-land/bugtracker#5974
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?