This Week In Veloren 86

This week we see a large number of visual changes. We hear from @Sam about their work on beam collisions and attack animations. @Slipped gives us an update on movement and models.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @Sam, @zesterer, @Slipped, @Henil, @Sharp, @scottc, @imbris, @droogmic, @Pfau, @martin-t, @Snowram, @xvar, and @xMAC94x!

This week, the stone golem was merged! This will give dungeons a proper boss. @Pfau has been working on many visual overhauls. @Sam has done a ton of work on keyframes, animations, and beam collisions. @AngelOnFira and @xMAC94x have been working on the preliminary steps for the evolution of Veloren's server infrastructure. This will first start with moving the game server to a Hetzner data center, and then exploring ways to host our many services efficiently.

@zesterer overhauled the format of Block. There aren't that many visible changes yet, but in time it'll allow more interesting underwater entities. It tracks fluids independently of terrain sprites so that terrain sprites can appear underwater without air bubbles.

PSA: Privilege Escalation Bug

This week the Veloren core developers identified a critical bug that permits privilege escalation to admin by unprivileged players on Veloren servers. The bug does not permit access to the underlying system the server is running on (your computer is fine, but people may gain admin privileges in-game) and does not exploit undefined behaviour. The bug affects multiplayer servers that have authentication enabled.

The bug has been patched on the master branch of the game. This bug affects all versions of Veloren from 0.5 up until commit 98c82408 (Tue Sep 22 16:27:04 2020 +0000). We advise anybody running their own Veloren server, public or otherwise, to upgrade to the latest nightly version. Those using the Airshipper launcher will automatically receive an update that fixes the bug.

If you run a Veloren server and would like more information on how to mitigate this bug, please message us.

We do not currently have knowledge of this bug being used in the wild. If you have information that suggests otherwise, please message us.

Animation Changes by @Slipped

This week, we merged some animation changes largely thanks to @Snowram putting in a ton of work to clean my mess. The gist is:

• The "critter" body is now deleted (it proved pointless).
• All those critters were given fresh new models and moved over to quadruped_small which is much more fleshed out (thanks to @Gemu).
• We also built in a pacing system for animals, only implemented on quadruped_medium for now. Now, instead of just jumping between two different run gaits at different speeds, they actually move through a full, proper sequence, with no hard transitions, a bit like the picture below shows.

Each leg/foot complex runs at an independent, controlled phase depending on the speed of the run. Basically, they start in a walk by moving lefts and then rights together, then go into a sort of cross gait, then they go full gallop with fronts then backs. All while also upping the amplitude of the movement itself with increased speed. This is so slow movement is gentle while fast movement is more intense.

The finer details are not super apparent because it's pretty subtle. But the general, visible result is it looks way more natural at varying speed, and also solves an old issue where the animal sorta studders in the transition between gait 1/2. So a good baseline is merged, and just needs a little ironing out in the coming weeks.

Attack Updates by @Sam

Thanks to @Sam we have keyframes now. Attack animations are now broken into buildup, swing, recovery stages. We can customize the animation duration of each, and because they're normalized we can simply change those durations and the animations will adjust themselves to fill whatever time we give them.

This also allows us to do things like change the attack speed of a different type of sword with no additional work. It will perfectly time swing sounds and swing movement in line with the actual damage portion of the attack, so that all feels correct without needing to fiddle with alignment to specific animation points (and then having it break if the attack parameters change). So keyframes are great. Keep reading to hear what else @Sam has been working on!

- @Slipped

The sword overhaul reworked how the original two abilities of the sword functioned, and also introduced a third skill to the sword.

The first skill previously was known as triple strike, and used to be on both the axe and the sword. It worked by progressing through three strikes, each increasing in damage. However, there was a lot that was hardcoded for this character state, and the extent of being able to modify it on weapons was adjusting the base damage, and determining whether you needed to hold down M1 or time your clicks.

Now as combo melee, it has become significantly more flexible. The most notable difference is that it supports more (or less) than three strikes. In addition to this, the damage of each strike is no longer determined by a hardcoded multiplier on the base damage, but can instead be individually modified.

In addition to this, other parameters such as attack duration, knockback, range, and attack angle can now be modified on a per strike basis. Further, combo melee allows for damage, attack speed, and energy regen to scale as you build combo while you remain in the combo melee state.

The second skill is still a dash. Though if any of you only recently started playing you may not have known it was supposed to be a dash. The dash broke some time ago with an update to how physics is handled since it initially stopped when it thought that it was touching an entity.

Now, aside from fixing the issue the previously dash had, I also changed how dash functioned. Dash now continuously drains energy based off of how long you are in the state, you can hold down M2 to dash as long as you have energy, and the damage and knockback scale to a maximum value in the first portion of the charge.

The third skill the sword has actually uses the same state that the axe M2 does, spin melee. However, it is modified so that it has a fixed number of spins, and can’t just be held down. In addition to this, forced forward movement was added to this spin (which the first and second skills also make use of). However, despite the slight changes made to spin melee to accommodate sword, you’ll still have the classic axe spin physics of ignoring gravity.

In addition to reworking or adding the skills to the sword, an additional change was made with all of the above abilities. Specifically, when you’re wielding a sword you can immediately cancel any of the above attacks with any other attack or a roll. This was done to bring combat using the sword closer to its intended theme of being relatively fluid in combat.

Beam Collisions by @Sam

The upcoming sceptre rework introduces a new system for dealing damage; the beam system. This system works by making a beam segment with a particular origin and orientation, and then projects a spherical wedge from the origin in the direction of the orientation. However, to do this I had to create collision code just for it, which was particularly tricky since every other system of collision detection in Veloren is either 2D, or one of the objects is a point.

Since entities are currently represented by a cylinder, I broke the code for spherical wedge-cylinder collision detection into 3 parts:

• Within the same z-range as the cylinder
• Directly above or below the cylinder
• Everything else

The first case, handling the same z-range as the cylinder, was the easiest to handle. I simply converted it to a two-dimensional case, and then checked that the cylinder (projected as a circle in 2D) was within the range of the beam segment, and then I did a check that any portion of the circle was within the max angle of the beam segment.

I then also needed to make a check outside the x-y plane so that you couldn’t aim above or below an entity and still hit it, and I just did a simple check in the r-z plane to see that any portion of the cylinder was within the angle of the beam’s orientation.

For the second case, handling collision above or below the cylinder, things became somewhat more complicated. I didn’t check exactly if the sphere center was directly above/below the cylinder, but rather if the line between the center of the sphere and cylinder passed through either endcap of the cylinder. From there the check to see if the cylinder was in range was simple.

Then, to check if the cylinder is within the max angle, I find both the angle between the lines from the sphere center to the point on the connecting line that passes through the endcap and the opposite edge of the sphere, and between the lines from the sphere center to the point on the connecting line that passes through the endcap, and the bottom edge of the cylinder. I then use whichever is largest, add it to the max beam angle, and then compare that new angle to the angle between the connecting line and the beam orientation. Although this does overestimate the angle of the beam to some degree, I considered it good enough.

For the third case, handling collision from anywhere else, things became even more complicated. The range check was done by using a point on the edge of an endcap on the cylinder closest to the beam origin, which was still relatively simple.

However, for the angle check, I would not only need to do the angle check I did for the second case, but also check for the angle between each of the two side positions on the endcap of the cylinder and the connecting line. This is because it then has the potential to be larger than the angle check I did in case 2. However, since it’ll be symmetrical I can just use half of this angle between the two side positions. I then use whichever of these three angles is largest, add it to the max angle of the beam, and compare it to the angle between the line between the sphere and the close edge of the cylinder endcap and the beam orientation.

In all of these cases, I only use a single position on the cylinder for the range check to avoid the same beam segment hitting the same entity multiple times. However, the angle check takes into account the whole cylinder. And with these three cases, we now have beam collisions!