This week, we hear about improvements being made to the hitbox system. There are
also fixes for how your cursor works in-game, and some changes to the health
system.
– AngelOnFira, TWiV Editor
Contributor Work
Thanks to this week’s contributors, @juliancoffee, @xMAC94x, @zesterer,
@Slipped, @mehmetmalli, @XVar, @kimtinh, @James, @imbris, @anomaluridae,
@ubruntu, @Capucho, @Sam, @Pfau, @Bafon, and @GiocArt!
@Snowram did some minor things:
- Fixed the fact projectile initial spawn. They used to always spawn inside the
entity that fire them, now they spawn in front of it
- Added a box behind the debug text so that you can finally see it when it is on
top of a cloud (transparency level follows chat setting)
Hitboxes by @juliancoffee
It has been a long road since I started combat balancing. It started with my
love for shooting stuff with the bow because it’s arguably the most controllable
weapon in the game, and has quite a high skill cap. An issue came up when we had
the single player map with a desert almost at spawn. You just needed to glide
from the mountain and all of us love gliding, yes? One of the most frequent
inhabitants of the desert is camels. How do hitboxes relate to Camels, you might
ask? Well, look at this picture:
Camel hitbox
How does this happen? Well, the most obvious answer is that its hitbox is not
well defined, look at height for example. Actually, it isn’t defined at all, and
it is using fallback dimensions. That’s one of the fundamental problems we need
to solve, but there are other problems. Look at this picture with clay golem’s
hitbox:
Clay Golem hitbox from eye to eye
The height is ok, but some visual parts are clearly aren’t there, you can’t hit
the hands at all! Why it was defined like that? Well, for this we need to look
at another picture:
Clay Golem’s hitbox you’d see if if you were bird and playing
with debug hitboxes
You should start to see that something is wrong. This hitbox is very imprecise,
you can’t hit his hands, but if you just hit the air in front of him, you’ll
shoot him. That’s because our hitboxes are cylinders. So if you’ll increase the
radius to be able to cover his hands, you will increase the overall cylinder
radius. And you’ll say: “But no one is shooting Clay Golem like that! Just make
radius big enough!”. And I agree with you. But look at the next pictures.
Tail hitbox
If we will allow you to be able to hit Archaeos tail, its hitbox will become
just huge. So basically it says: “No matter how hard you try, hitboxes will
suck”. Which is very sad.
That’s what I was trying to fix. Why do we use cylinders? It’s fast and simple.
If you want to ask the question “is this point is inside or outside of the
cylinder?” you need to do two things. Compare z component of point and check
that it’s less than the top and more than the bottom and calculate 2d distance
between point and cylinder: if it is less than the radius, then the point is
inside. So we want something as simple which at the same time gives us the
ability to make our hitboxes better.
We’ve come up with capsule prisms. (I heard this idea from @zesterer). It’s a
prism with a stadium-like form as the base. This means it has the same form at
any height, contrary to spheres for example, which have a lesser radius on each
Z-slice.
The stadium-like form can be created by one segment and points around that
segment with equal distance. See? Equal distance, that’s what we love about
cylinders. Some also call it like sausage body ðŸ¤
Stadium where Archimedes beats Zeus
So now if you need to calculate distance from the point to our capsule prism you
need to check the z component in the exact same way as you do with cylinders,
and then compare the 2d distance between point and line segment. It’s more
complex than the distance between points, but it’s still 2d which is still quite
easy.
It becomes more complex when you need to answer the question what is the
distance between line segments, that’s where I wanted to thank @zesterer for
this formula and @imbris for some tweaks to the formula to make it more reliable
in edge cases. In the end, I would like to show a picture of the new hitboxes
for the camel and Cyclops:
Sausage boxes
This is a backend change to our physics, but we still need to make our hitboxes
good, stay tuned! If you read this on our weekly blog, the chances are that
Husks hitboxes aren’t that bad now.
The secret of cultist dungeons. Headless Husks!
Cursor Curmudgeons by @anomaluridae
Have you ever tried collecting a mushroom in a cave, but since you are holding
your pick axe, your cursor keeps detecting the ore (and not the fungi clearly
under your crosshairs)? Are you forced to un-equip your pickaxe first (a.k.a.
leave mining mode), in order to satisfy your fungi fanaticism?
Have you ever been in build mode, but still want to pull out your pickaxe and
start mining at the same time? Without leaving build mode? Have you noticed that
when you are trying to mine while in build mode, you often end up vaporizing
your precious ore (a.k.a. removing the block) instead of getting that loot?
Well, now you can!
The previous method did an order of precedence based upon a presumed preferred
action. It assumed building (when in build mode), was preferred over mining
(when holding your pick axe), was preferred over anything else.
The updated method takes an order of precedence based upon the nearest target
under your cursor. (It also does some refactoring to de-tangle a few things, and
separate concerns into separate abstractions.)
Big thanks to @imbris for his patience with this first-time Veloren contributor.
Health refactor by @Sam
I have refactored how health works. Some of you who peeked around the ability
asset files or looked into the code may have noticed that health was scaled by a
factor of 10 compared to the value you would have expected. This was originally
done to allow for more granular health changes than whole numbers as we keep
health an integer. However, it also had the problem that it could be tedious to
remember when changing abilities or reasoning about the total amount that would
change with buffs.
To solve this health will now only retain the scaling within the health module,
and functions that externally interact with health use non-scaled values.
Further, we opted to have all external interactions with health use floats
instead of integers as in practically all cases it is more convenient to do, and
it requires fewer casts between the two. The scaling was also changed from a
factor of 10 to a factor of 256 in order to make full use of the precision
offered by floats.
Now this change was meant to be purely a backend change, so ideally no one would
have noticed any difference after the fact, however, there were a few sneaky
bits that I missed in the conversion, such as exp reward calculations, the
health stat in the inventory menu, and damage values from lava, bombs,
campfires, and fireworks. A similar refactoring will happen and is in progress
for energy, and will be started soon for poise.
A sneak peak from @Snowram, @Slipped, and @Gemu. See you next week!
Support our devs!
Veloren Open Collective
