Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Adding bxt_hud_jumpdistance #340

Merged
merged 5 commits into from
Oct 8, 2022
Merged

Adding bxt_hud_jumpdistance #340

merged 5 commits into from
Oct 8, 2022

Conversation

khanghugo
Copy link
Contributor

Pretty primitive stuff given the fact that it is not using lots of things.

Ladder jump will not have green number because of this implementation but the distance is still there. I think the way they do calculate ladder jump distance in KZ is very different.

Mostly copy-pasted code from other function.

@khanghugo
Copy link
Contributor Author

This won't be useful in game like HL where speed matters more but it is good for CS1.6 KZ TAS recording that might tell something's up ahead.

jumpDistance = length(player.origin[0] - prevOrigin[0], player.origin[1] - prevOrigin[1]) + 32.0;

// +18f in case normal jump to duck
if (player.origin[2] == prevOrigin[2] || (player.origin[2] + 18.0f) == prevOrigin[2])
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this exact equality actually work in practice, especially with the + 18.0? Floats are pretty finicky...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does work. It makes the number goes green when duck before ground. How do you want to do this instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The number goes green means the jump is an actual jump on the same block height.

inJump = false;

// add 16*2 because of player size can reach the edge of the block up to 16 unit
jumpDistance = length(player.origin[0] - prevOrigin[0], player.origin[1] - prevOrigin[1]) + 32.0;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kinda weird, like jumping in place will already give you 32 units. How do the kz stats plugins measure it?

Copy link
Contributor Author

@khanghugo khanghugo Oct 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://kz-rush.com/en/article/calculating-distance

I did try using the value from bxt_ch_get_pos between the start and end of the jump and it reports the exact value of two places. It is what people might want to know how far they jump. But in practice, that would fall 32 units short in comparison with how other kz plugins work. There is another addition of 32 to make it "block jump", rather than just a normal jump.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh and about jumping in place, I guess that should be an edge case. It definitely can get checked if that is needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it only updates when above certain distance, that would be better, I guess.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If other kz plugins add the 32 then fine, although kinda weird because as that article points out, it's only correct for axis-aligned jumps and not for diagonal ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea that. Given what there is, calculating the distance of a diagonal jump would be really difficult too, at least without additional checking of other properties that custom_hud does not really need. But I from my limited mapping experience, making a significantly measurable diagonal jump block would be unnecessarily hard, especially doing the math. It is a possibility but I don't think any mapper will be willing to do that. Though, this is indeed interesting and I have to keep this fact in mind (as a suggestion for mappers to do uncanny jump).

Comment on lines 707 to 713
fadingFrom[0] = 0;
fadingFrom[1] = 255;
fadingFrom[2] = 0;
} else {
fadingFrom[0] = 255;
fadingFrom[1] = 0;
fadingFrom[2] = 0;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's weird that green/red color here will mean something different from the jump speed counter. Maybe we can use some other color here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Green means that jump is a normal jump, start and end are on the same height. Red will means that the jump is not landing on the same height. If this makes it looks too weird then I guess we can just do no color.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we eliminate the color code thing then we don't need to compare float like above.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do no color for now

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got that.

jumpDistance = length(player.origin[0] - prevOrigin[0], player.origin[1] - prevOrigin[1]) + 32.0;

// +18f in case normal jump to duck
if (player.origin[2] == prevOrigin[2] || (player.origin[2] + 18.0f) == prevOrigin[2])
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check will also fire if you standing-jump to a surface 18 units down.

Copy link
Contributor Author

@khanghugo khanghugo Oct 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is true. I don't really know what to do for that case because it would require the info of the player position such as on ground or in duck and stuffs. This is definitely a step down (hehe) but it is primitive, and the best solution I can think of right now without checking extras.

@khanghugo
Copy link
Contributor Author

Here is a small change that will check when to update the jump distance. I am still keeping the color thing because I am not sure how it should be proceeded. If there is no need for color, then all of the above concerns would be gone.

// add 16*2 because of player size can reach the edge of the block up to 16 unit
double distance = length(player.origin[0] - prevOrigin[0], player.origin[1] - prevOrigin[1]) + 32.0;

if ((distance > 150.0 && distance < 290.0) || CVars::bxt_hud_jumpdistance.GetInt() != 1) // from uq_jumpstats default
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this 290 limit ok for hl1 tho? BXT is hl1-first after all

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops. I guess no limit seems okay due to recent incidents of water move stuffs. This is generally just to prevent speed randomly gets overwritten.

@khanghugo
Copy link
Contributor Author

So I think about axis align thing, maybe there could be a little bit of trigonometry could be applied to properly scale the 16 units of box properly, depeneding on the displacement vector of the jump. Let me try this and see

@YaLTeR
Copy link
Owner

YaLTeR commented Oct 6, 2022

Nah I think that's even worse because it's unpredictable. When you're practicing lj on solid ground you don't want it to matter which direction you jump

@khanghugo
Copy link
Contributor Author

Okay, I guess this is final then.

@YaLTeR YaLTeR merged commit 172439c into YaLTeR:master Oct 8, 2022
@YaLTeR
Copy link
Owner

YaLTeR commented Oct 8, 2022

Thanks!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants