This Week In Veloren 138

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:

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:

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:

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.

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 🤠

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:

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.

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 XP 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.