These weeks in Veloren 250

Fri, 21 Nov 2025 00:00:00 +0000

Refresh your reflection, see what's been making waves, and pay respects to the sites of old.

- horblegorble, TWiV Contributor

Contributor work</h2>
Thanks to everyone who contributed to veloren these last weeks: @isse, @unii, @UncomfySilence, @Gemu, @horblegorble, @floppy, @anyone, @Supa, @do-no-van, @Necti, @srpapinha, @Sam113, @xMACx94, @tibbon1, and @imbris.
Thanks to the weblate translators who contributed these last weeks:

Language </th> Translators </th> </tr> </thead>

English</td> Harp | Axag | Limina</td> </tr>
French</td> Axag | Limina | Krafting | Marcoleric | TheCoolMan | jls | Nasleth | Nifou | sandraev</td> </tr>
Korean</td> neighborsbear | share | sungbinma | Bandalbox | figma | Zerothas</td> </tr>
Polish</td> maciej-klupp</td> </tr>
Russian</td> NaStiluse | Trauvel | evgenkot</td> </tr>
Spanish (Latin America)</td> guillermytho</td> </tr>
Swedish</td> Positron832 | IsseW</td> </tr>
Ukrainian</td> Harp | Witch</td> </tr> </tbody> </table>
Merged work</h3>
Be the change you want to see in yourself</h3>
The humble cauldron continues to amaze us with its ability to concoct a seemingly endless variety of beverages. Now, after brewing in the minds of @isse and @unii, a new recipe has bubbled up to the surface. It might push those simple vials to their limits, but you can distill the rejuvenating fire of a phoenix feather. So if you've got some spicy plumage to spare, and have been looking for a personal rebirth (without having to turn to ash first), go give it a whirl.
Your browser does not support the video tag. </video>

🔊 Not quite a Sailor Moon level transformation, but it does the job </figcaption> </figure>
There's often more to a name than meets the eye, but have you thought about its flavour in different tongues? Let's hear from @Limina on what it takes to cook up a tasty translation:
Recently, the HRT (Hastened Reformation Tincture</a>) potion was added, which lets us change body types! I'm a translator for French, and had worked voluntarily on Dauntless</a> before, so believe me when I say one of the (many) challenges in translation is acronyms – often times, they have to either be changed to fit the target language, or have their meaning slightly altered. Retaining the original intent can be a REAL headache, and that's what we try to stick closest to.
As soon as I knew the existence of that potion, I knew I had to find it a fitting name. And here for once, it came to mind almost instantly: in French, we have a completely equivalent acronym for this type of gender affirming care: THS, short for "Traitement Hormonal de Substitution", a basically perfect 1:1 translation already. It naturally came to be the Tisane Hâtive de Subversion™ in French!
</a>

Whether tea or tincture, it'll have your hormones down to a tee </figcaption> </figure>
If you're proficient in at least one more language than English, give translation a go! It's a great way to get better in both English and the language you're translating to (even if you're a native speaker!), and brings accessibility to people that may otherwise not have had the chance to play the game. And sometimes, you get to do silly things like naming a trans potion in your language. 💙🩷🤍
You can get started by reading the Veloren owner's manual, right here</a>
~ Cheers to all contributors to this amazing community. <3 
GitLab: !4926</a>
Pick out a new look</h3>
@Gemu has been diligently threading voxels, and is taking a well-deserved stretch after looming over four new styles. For us, it's time to clear out some wardrobe space and dust off those full-body mirrors for a fitting session. Newbies and smurfs alike can pick up something blue from their local trader, while those after a more rebellious aesthetic will have to steal their look. Just mind townsfolk getting tense from the latter fashion sense.
The logistics of going from workshop</a> to wearables was managed by @UncomfySilence, who's here to catwalk us through the latest outfits:
The More Player-Facing Armor branch has finally been merged, and with it a few more low to mid-tier sets: Adventurer</a>, Pirate</a>, Buccaneer</a>, and Witch</a> (T1, T2, T3, and T4 respectively).
</a>

A kit fit for adventure </figcaption> </figure>
More interestingly is the inclusion of previously NPC exclusive armor sets, like the Witch and Pirate armor. Given Veloren’s philosophy to minimize the differences between players and NPC, in attempt at grounding and immersing players into the world, we thought it’d be fitting to have some of the armor and items deliberately made for humanoids, yet unobtainable to players, finally be made obtainable!
</a>

Scrappy rags of rank and file pirates </figcaption> </figure>
</a>

Buck up for the big promotion </figcaption> </figure>
</a>

Don't worry, it's still certified to cauldron safety standards </figcaption> </figure>
This is the first of several planned player-facing armor updates in which sets you see in your day to day Veloren life, and more, are made accessible.
Eventually we’d also like to expand on the acquisition of certain sets to make them more interesting. For instance, whilst the witch set is currently obtainable from locked chests in their huts, we’d like eventually move the witch armor pieces to that of the Witch Apprentices’ and True Witch's inventories, with which you could trade them Ooky items they’d use for their dark magic rituals for a fancy, spooky witch set and learn to become a Witch Apprentice yourself!
Though, unlike a Gorgon's petrifying gaze, things may not be entirely set in stone and are subject to change ;)
If you're gearing up to spook and plunder, you'll need more than a toothpick to break those fabrics out of lockup. Hopefully you find enjoyment in one of the fiddlier jobs of a blacksmith, and don't mind getting picky</a> between copper, iron, and cobalt.
</a>

(➜) Pirate, Buccaneer, and Witch chests above common, iron, and cobalt lockpicks. </figcaption> </figure>
Savvy dungeoneers may notice that the common pirate has travelled a long way from the sea to nick their chests from some Adlets (presumably as bewildered as we are). However, it seems that in the heat of the heist, our swashbuckling crew broke the locks.
Oh, and a heads up – those greedy miners got their hands on witchy lockcraft for their front door.
GitLab: !4921</a>
Each to their own</h3>
Fresh-faced items get to make their own entrance into the world as @horblegorble wins back their personal space in a change to auto-stacking. After all, don't items deserve to be itemised? Well, not if they've been through your inventory it seems. The original purpose of the auto-stacker hasn't went away.
Your browser does not support the video tag. </video>

Not just a number </figcaption> </figure>
GitLab: !4892</a>
New tidings</h3>
Across study halls and field sites, Veloren's biologically inclined have been swept up in a wave of speculation. Hastily scribed opinion letters fill the academic record as everyone tries to stake their theory as the authoritative explanation for something truly unprecedented: evolution of life away from a crab. While classically-minded thinkers insist on holding out for more verified reports, it seems impossible to deny that the Tidal Warrior has shed its shell for scales, swapped out mandibles for a beastly jaw, and dropped its pincers for webbed digits. Dexterous enough now to wield a grand trident, sharpened well beyond ornamental purposes.
</a>

The old (left) getting flushed out by the new (right) </figcaption> </figure>
One hypothesis gaining traction is that this is a delayed metamorphosis, triggered by submission to Karkatha as new 'crankiest crab'. But not everyone is convinced, with some early-career scholars floating suspicions that something more fishy has went down. For them, the mutation of a Sahagin underling is decidedly more plausible. Though they do concede it's an open question of how aquatic specialists beat out terrestrial competence. Whether by mutiny or abdication, this 'identity theft' theory is still swimming upstream to establish legitimacy.
Meanwhile, many field biologists insist that it's better to see things for yourself, instead of blowing bubbles back and forth. To this end, some have taken to donning homemade Sahagin disguises to make discreet observations and uncover the real truth of the matter. They say this 'fins-on' approach to science is the only sure way forward – even if some of them don't make it back to shore.
Here on the sidelines, we'll be waiting to find out how well the Sahagin fortress can guard its secrets. For now, early studies suggest that this new Tidal Warrior belongs to the @Gemu genus, with behaviours that are notably @floppy-an.
GitLab: !4930</a>
Plugging the memory leak</h4>
After an upstream bug had people's RAM spilling out of their paddocks, @anyone came to rescue with a workaround fix:
Hello! So I did some testing regarding the crash. At first I could not reproduce any crashing, but I noticed steadily increasing memory usage when moving around the world. Also when loading different singleplayer worlds after each other or when generating a custom world I could get the memory usage up to about 26GB which finally made everything crash.
Using git bisect (as @nadja suggested) I arrived at d9291896</a> being the first commit that has the issue. Further I saw that mimalloc</a> is only used on windows so I removed and downgraded mimalloc (and libmimalloc-sys</a>) which both seemed to fix the memory issue.
</a>

That'll stick, right? </figcaption> </figure>
GitLab: !4936</a>
Safety first</h3>
Following numerous accounts of spontaneous disembarkment, the fleet managers at Airloren are hoping to kill the music on a bizarre dance trend that has had folks moonwalking off the back of airships. A safety review led by @Supa and @horblegorble has recommended the retro-fitting of fallback safety nets to keep our hands, feet, and selves onboard at all times. In simple terms: raising the railings on seating and observation decks. It will take more than a slippery boogie to slide over them now.
While early feedback from disco enthusiasts has been positive, some passengers more interested in sightseeing have lodged complaints about obstructed views of the landscape. When interviewed, one Airloren captain remarked "Well, it's better than a surprise close-up view." Hard to argue there.
So if you fancy throwing shapes high above the world, feel free to relax that glider instinct a little. Maybe shift focus to your oxygen levels instead.
Your browser does not support the video tag. </video>

Will these be tall enough to keep up with the stack of incident reports? </figcaption> </figure>
GitLab: !4911</a>
C-c-c-combo!</h3>
Break down the combo gates and go wild testing abilities, with a specialised buff courtesy of @do-no-van. Pop in a buildup rate and duration, then watch all your imaginary battles yield real attack tokens.
Your browser does not support the video tag. </video>

Save your weapon's polish for the big hitters </figcaption> </figure>
GitLab: !4901</a>
Gizmo gadgets</h3>
The navigation engines of NPCs have had their hoods lifted by @isse, allowing us a close look at the machinery in action. Through wayfinding eyes, watch the turning of mental gears as future-looking threads are woven through the world. Now any admin can leverage `/gizmos</code> to become a super solver for pathfinding bugs.`
`Your browser does not support the video tag. </video>`Connect the dots and solve routing mysteries. No corkboard required. </figcaption> </figure> GitLab: !4939</a> Teaching by doing</h4> @isse's audience got a surprise treat when free tickets to her lesson on beginner Rust wisdoms turned out to also be front row seats to Veloren development. In and around plenty of Q&A, she added a /buff</code> option to clear all current effects, as well as a flag to /repair_equipment</code> for including inventory gear. Your browser does not support the video tag. </video> Watch and learn </figcaption> </figure> GitLab: !4895</a> + !4896</a> Out of site, out of mind</h3> Another layer of git sediment was laid down into the archaeological record, marking the burial of ye old site code. Having been held in config stasis since version 0.11</code>, @isse arranged the funeral for its final rest. We look back now with fond memories of free-form architecture and sprawling farmlands. </a> Veloren of yore </figcaption> </figure> </a> Can these carpentry skills be re-learned someday? </figcaption> </figure> </a> Forget windows, it's all about getting a block or two above the neighbours </figcaption> </figure> </a> Playing for keeps </figcaption> </figure> </a> Alpine giants </figcaption> </figure> GitLab: !4908</a> More changes:</h4> settled down hat model hiccups in voxel and manifest files - @Necti - !4918</a></li> parry precision paired back to parity with backstabs - @srpapinha - !4917</a></li> hanging sign sprites updated to @Sam113's newly shaded model - @horblegorble - !4905</a></li> updates for crates - @xMACx94 - !4928</a></li> fix ups and touch ups for documentation comments - @tibbon1 - !4054</a></li> as part of Rust 2024 edition preparations (!4770</a>), reduced unsafe scope in EcsAccessManager</code> - @imbris - !4780</a></li> typo fix sent desert creatures back to their own biome - @horblegorble - !4920</a></li> merged non-starter lantern recipes into one and tweaked some pricing - @horblegorble - !4731</a></li> balanced fierce raze to be slower, with less poise damage - @unii - !4923</a></li> changed campfire and bed interaction texts - @horblegorble - !4929</a></li> fixed typo in name of punching bags spawned by /dummy</code> - @horblegorble - !4934</a></li> got a bigger ruler to measure distances in large worlds - @isse - !4943</a></li> cleaned up old build artifacts and set an auto-expiry - @xMACx94 - !4945</a></li> only one file used a header comment for credits, so removed them - @isse - !4937</a></li> </ul> Ongoing unmerged work</h3> Follow the crowd</h4> Do current affairs keep hitting you with waves of fear and doubt? Well sit back and go with a different flow, riding the relaxing ripples of an oceanic music video. Your browser does not support the video tag. </video> 🎶 Simply boidiful. 'Drifting Along' by DaforLynx </figcaption> </figure> This is an extension of @do-no-van's work on fishing, taking our scaly friends back to school to learn some bird-oid (boid)</a> movement. The idea is that each fish tries to align with and move towards the centre of a group, while still giving space to their neighbours. In doing so, they shift the group's centre and direction, and the process iterates to create the overall motion. Getting this all to run smoothly wasn't without its own turbulence. Clowning around with the underwater hustle and bustle led to some explosive growth in local fisheries. Your browser does not support the video tag. </video> @do-no-van's earlier efforts may have crashed the fish population </figcaption> </figure> The elephant in the room</h4> </a> Now this we have to talk about </figcaption> </figure> From @Gemu's wild modelling studio, the mammoth's much less hairy cousin is looking to migrate into Veloren. Once of course @do-no-van finishes clearing the path to give the final go-ahead toot. Hopefully we don't get stuck compulsively thinking of them until they arrive. At least they're not pink... Though there is one question worth pondering: will they be forever free spirits, or will especially intrepid trainers find a way to tame their hearts? Your browser does not support the video tag. </video> Stomping around — by @do-no-van </figcaption> </figure> GitLab: !4976</a> Community showcase</h2> Concept art</h3> First-hand accounts of various explorations in voxel space. A mix of things intended for use in-game, and more experimental ideations. </picture> </a> Could you coco-not? — models by @unii + @Gemu </figcaption> </figure> </a> Flower power — by @unii </figcaption> </figure> Legoom Lounge</h3> </a> Breaking containment — by @unii </figcaption> </figure> </a> Requesting precisely one good scritch — by @unii </figcaption> </figure> </a> A bold alternative for Veloren's cover photo — by @Sam113 </figcaption> </figure> Bombs away</h3> After some avid dungeoneering left @And_i with a dangerously large stockpile of coco-nades, they decided to put Mindflayer on blast with an exorcism by explosion. Viewers be warned: this video contains unhealthy levels of potion sickness, burning rapidly through stackables, and an application of sword & axe buffs that may nauseate members of the balance team. </iframe> </div> 🔊 Raincoats are advised for close-up views of splash damage </figcaption> </figure>The Gigas Aquatic</h3> </a> A bubble bonanza! </figcaption> </figure> Veloren's ecologists have another puzzle to contend with, as it turns out Frost Gigas are surprisingly amphibious for their mass. We have here observations recorded at Lake Hudar by @horblegorble, who couldn't be reached for comment afterwards. Our supervisor kept citing the insurance costs of approaching someone hot-headed enough to use a firestaff for drying out their own equipment. Your browser does not support the video tag. </video> 🔊 A different kind of combat music. 'Graceful Journey' by Tobias Thy </figcaption> </figure> You see right through me</h3> Veloren's philosophy of transparent development may be being taken a bit too literally, as @Necti demonstrates how to spy out enemies and oddities. With these powers of x-ray vision, nothing is truly opaque. </a> </a> </a> </a> </a> </a> </figure> The gruff and the graceful</h3> With all the time spent by campfires, you'd think Veloren would have more stories to tell by now. Well, maybe it's more a matter of putting them to paper. An effort that @c00k13777 has taken a stab at with their short story 'Never the same again'</a>, which looks at life after caving incidents. Be sure to clear out any butterflies from your stomach before reading – things go from bloody beginnings to strange encounters, and surprise participation in 'science'. PvP playbacks</h3> And now, a double treat for the armchair duelists among us. First off we've got sharp-stick showdowns from @unii, followed by @And_i's more long term perspective on combat. Don't forget to post a play-by-play analysis, and update your fantasy league PvP teams. </iframe> </div> 🔊 All sword, no play — by @unii </figcaption> </figure> </iframe> </div> 🎶 Dancing with the stars — by @And_i </figcaption> </figure>Events</h3> Pre-planned events hosted on the official server (server.veloren.net</code>). You can keep an eye out for future announcements on the discord channel</a>. Tournament of Time!</h4> Wind your clocks back to 2021... The hey-day of forgotten sites. Not an LoD</a> model to be seen. When a great equality was the rule, whether it be dungeon themes or skill tree variety. Gnarlings, still a purple-boxed glimmer of an idea, had yet to cut down their first giant tree. This was the world of version 0.10</code></a>. Chosen as the battlefield to host a PvP tournament for the ages. Or at least, that was the idea. Enter @Necti, our mastermind of party planning. She thought she had found the exemplar setting for a good old fashioned throw down: an island stranded from mainland abundances, a cultist armoury at the ready, and injury indemnity from @isse, mayor of the hosting server. But the key ingredient was lost in shipping – a hunger for winning. Instead of fighters, it was friends that arrived with an appetite to build, not brawl. So, paying little heed to best-laid plans, they worked from a different blueprint to construct just about everything except a finished arena. </a> Where it all happened — photo by @Dan113 </figcaption> </figure> </a> Welcome to Tourney Town — photo by @unii </figcaption> </figure> </a> My castle is my home — photo by @Necti </figcaption> </figure> </a> Leave all your worries at ground level — photos by @Dan113 </figcaption> </figure> </a> Panoramic views — photo by @Necti </figcaption> </figure> </a> All fun in the sun — photo by @unii </figcaption> </figure> </a> Stock up on potions at the Jubilant Jackelope — photos by @Dan113 | @Necti </figcaption> </figure> </a> Don't forget to say hi to Ribbit Rob — photo by @Dan113 </figcaption> </figure> Word is that a tournament was in fact held at some point in the midst of all this whimsy. Though there seems little doubt that the event will be remembered for its comradery, rather than its competition. </iframe> </div> 🔊 The final showdown — by @And_i </figcaption> </figure> </iframe> </div> 🔊 Building up and chilling out. Supposedly some PvP as well — by @Necti </figcaption> </figure>Screenshots</h2> </a> The hills have lights — by @Alley_Oop </figcaption> </figure> </a> A quiet corner for two passionate airships — by @merry_despair </figcaption> </figure> </a> Do you see them all, faces buried in the bushes? What are they up to? — by @olaf_ej </figcaption> </figure> </a> The side effects of using grass-green shingles — by @souffle </figcaption> </figure> </a> Keeping it chill — by @unii </figcaption> </figure> </a> Lingering light, or a visitor of the Min Min variety? — by @Hrom </figcaption> </figure> </a> Fresh from a glow up — by @souffle </figcaption> </figure> </a> End of day, end of land — by @Alley_Oop </figcaption> </figure> </a> Hammers strike at sunrise — by @Hrom </figcaption> </figure> </a> The PvP lineup — by @Necti </figcaption> </figure> </a> One-man eclipse from a wannabe Icarus — by @souffle </figcaption> </figure> </a> Freshwater Sahagin — by @Alley_Oop </figcaption> </figure> </a> This mountain runs on arch btw — by @Alley_Oop </figcaption> </figure> </a> Glorified landfill — by @Sam113 </figcaption> </figure> </a> Not a gradient for novice rock climbers — by @Dan113 </figcaption> </figure> </a> Charging up the rock lamp — by @Alley_Oop </figcaption> </figure> </a> Wahey's rural cousin — by @Alley_Oop </figcaption> </figure> </a> When chaos came to town — by @Necti </figcaption> </figure> </a> </a> </a> </a> </figure> </a> All the particles! And none at all. — by @Hrom </figcaption> </figure> </a> Under the moonlight — @horblegorble </figcaption> </figure> </a> Twinkle and trickle — @horblegorble </figcaption> </figure> </a> A spork in the road — by @Alley_Oop </figcaption> </figure> </a> Molten mycelium — by @Kycyka </figcaption> </figure> </a> Different ways to navigate vampiric airspace — by @Alley_Oop </figcaption> </figure> </a> Lovely little lake — @Gemu </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </a> Take a moment of remembrance, and hear this broken hearted plea from @Vagabond. </figcaption> </figure> These weeks in Veloren 249 Sat, 06 Sep 2025 00:00:00 +0000 Cozy up by the campfire, enjoy some animated story telling, and wind down for a rejuvenating slumber. Then refresh at breakfast with plenty of greens on the menu. - horblegorble, TWiV Contributor Contributor work</h2> Thanks to everyone who contributed to veloren these last weeks: @isse, @horblegorble, @drunicornthe1, @unii, @Supa, @Crabo, @hnrq, @DaforLynx, @imbris, @walpo, @do-no-van, @Caigh, @xMAC94x, @Owill0w, @MSGanesh23, @juliancoffee, @UncomfySilence, @Gemu, @Limina, @vickyfrenzy, @marcoleric, and @olaf_ej. Thanks to the weblate translators who contributed these last weeks: Language </th> Translators </th> </tr> </thead> Czech</td> Janez</td> </tr> English</td> evgenkot | Limina</td> </tr> French</td> Limina | Marcoleric</td> </tr> Korean</td> neighborsbear | sungbinma | Zerothas | Bandalbox | l3nemy</td> </tr> Russian</td> evgenkot | Arriona | LevmurDev | Trauvel | VVolsha | caesarrxx | Arflee | MBKenny | lucius_pilgrim | sspring | NaStiluse | PepegaSandwich | nekoedges</td> </tr> </tbody> </table> Merged work</h3> Take a seat by the campfire</h4> Having smouldered on the suggestions backburner for long enough, your most requested change to campfires has finally flickered into life. Waypoints are now set by sitting down at a fire, rather than simply feeling its heat. So douse your navigational fears and get warm without worry, thanks to @isse's firewood, with kindling from @horblegorble. Your browser does not support the video tag. </video> Hassle-free use of the central crafting stations </figcaption> </figure> Along the way was a detour in short story interface design, which promised to dispel all confusions and ambiguities. Surprisingly, this wasn't a smash hit in playtesting. Something about "I can't see a damn thing" or somesuch minor detail. </a> Stories told by the campfire </figcaption> </figure> GitLab: !4891</a> Get better with bedrest</h4> That latest journey left you with an open gash? Simply lay down, tuck in, and let the comfort of a good mattress sort it all out. This might sound like some kind of nonsense or unicorn magic at first, but that's Dr. Unicorn magic to you. In collaboration with @isse, here's @drunicornthe1 with your prescription: Merged in the ability to regen health while sleeping. This will also give the ability to have other blocks give effects while mounted. Just don’t look at the buff icon yet it’s going to be reworked later</s> Your browser does not support the video tag. </video> The right pyjamas make all the difference </figcaption> </figure> Demand has been high for these marvellously mellow mattresses, so unfortunately deliveries have only been made to forest towns so far. GitLab: !4838</a> Free up your footwork</h4> Save those ankle breaking flourishes for the dance floor, and bring the rest of your body into the swing of things. @unii made animation changes across many sword skills that bring some oomph to your strike, with no time to play footsies. Your browser does not support the video tag. </video> Before (left) and after (right) for riposte, heavy slam, and spiral slash </figcaption> </figure> GitLab: !4847</a> A farmer's life for me</h4> Lettuce be glad for the work of @Supa and @drunicornthe1, who've yielded a bumper crop of leaf-wrapped presents for us to open (away from townsfolk eyes). Unlike sprites of old, these now have separate models for before and after states, as well as for the collected item. This MR also leaves behind some internal cabbage baggage. </a> Time to get ahead (of lettuce) </figcaption> </figure> Your browser does not support the video tag. </video> Picking vs. unwrapping </figcaption> </figure> Now it's not all about the harvest. @Supa has been thinking ahead, and took the chance to plant some voxel model seeds for future farm work. </a> The right tool for the job </figcaption> </figure> </a> Crops need their gated communities </figcaption> </figure> </a> Hand rails for the ranch </figcaption> </figure> GitLab: !4835</a> UI Gooey</h4> Throwing shades of grey</h5> Contrast is in the eye of the beholder, so go ahead and use @Crabo's new opacity slider to tune things just right. And check out @Supa's touch-ups to PvP icons while you're there. </a> </figure> Your browser does not support the video tag. </video> It's bring-your-own seizure warning if you wanna go real fast </figcaption> </figure> GitLab: !4842</a> + !4894</a> The way back</h5> Adventures in Veloren can take you many places, including a long way from your waypoint on a good day. Among all the sights and sounds of the world, it's not always the easiest thing to recall. So @Crabo is here to help again, with an entry in the player menu (that's what a diary is for, right?). Cheers as well to @hnrq for adding translation keys. </a> For when that campfire isn't quite burned into your memory </figcaption> </figure> GitLab: !4802</a> + !4909</a> Change the channel</h4> Resident sound engineer @DaforLynx has been busy backstage at the studio, wrangling cables with minds of their own and keeping kira</a> in check. After far too many sample rates and the odd expletive, we get to enjoy the tidy fruits of his messy labour: I added a setting for how many audio channels are allocated for SFX. If you are experiencing lag in situations with a high amount of audio traffic, try setting this to medium or low. </a> How parallel can you run your hearing? </figcaption> </figure> GitLab: !4743</a> + !4916</a> Get your fix</h4> No more Ratatouille</h5> It's not unusual for a summon to hop on a shoulder for a ride, where they can feel like they're seeing the world through their boss's eyes (this may be startling to a greenhorn adventurer, but rest assured it's perfectly acceptable in dungeon culture). Now what is unusual was an upset in the hierarchy that had some upstart minions convinced they had been lifted above their station. No more taking orders - it was their turn to call the shots, and the big boss could take the back seat. As to why their superiors were inclined to humour this apparent rebellion, some analysts suspect that it was the allure of guaranteed schadenfreude. For it wasn't long at all before these ladder climbers made the humbling discovery that they had not read the manual on doing their boss's job. And boy, was there a lot to know. With such big shoes to fill, all they could manage was some plodding around. @isse had to climb up herself to cut the puppet strings and knock these over-influential shoulder parrots off their perch. Let's see if the so-called bosses can keep things in order this time. </a> Is that an angel or a demon on their shoulder? </figcaption> </figure> GitLab: !4860</a> Life and death logistics</h5> Speaking of bosses, does anyone know who's in charge of Veloren's rtsim</a> afterlife and reincarnation? Seems they'd left it on auto-pilot in the basic mode of instant respawns at reliable locations. Guess it comes with the pre-alpha territory. Though not everyone was complaining, with some players making efficient use of the opportunity for goods that fell from the sky. It is suspected they were suffering from a bad case of loot fever. Hopefully their temperatures start to come down with another fix from @isse, which introduces a mortality architect to ferry entities from one life to the next. That transition now takes some time, begging all sorts of metaphysical questions about life beyond the health bar. GitLab: !4833</a> + !4906</a> Iconic looks</h4> These clothes were made for working, and that's just what @unii did. A crease here, a smudge there, and those clean overalls finally get their 'well-loved' feel. </a> The workwear workover </figcaption> </figure> Bringing this work ethic one dimension down, @unii also polished off some icons that had started out as part of a personalised aesthetic mod. Shading, dithering, and that personal touch all give them a tasty flavour. </a> Left to right: original, draft, final | Top to bottom: info, artifact, mod </figcaption> </figure> GitLab: !4903</a> Voxel housekeeping</h4> Although they're made of blocks, it isn't hard for voxel models to become disorganised over time if you're not careful how you stack them. Taking up the task of tidying up our boxes was @Supa and @imbris, who faced no shortage of paperwork in changing a slew of names and addresses in the assets/voxygen/voxel/</code></a> directory. This primarily concerned the item/</code>, object/</code>, and sprite/</code> folders. So if you're playtesting or debugging with /give_item</code></a> and can't find an item's path, don't forget what's in your toolbox: tab completion from a hash (#) prefix and a search bar in the F7 menu (Admin Commands -> Give Items). For those in the modelling business, do check out the assets/voxygen/voxel/README.md</a> file that has been provided as a guide on the intended arrangement going forward. It wasn't all a re-boxing match - other work included cleaning up rusty (the bad kind) code structures, as well as mediating disagreements between visuals and physics for some sprites. With all of the voxel fort building</s> tactical logistics, it's important not to risk getting buried under a tumble. So the original effort was split across 3 merge requests, with 2 extras from @horblegorble to settle some of the dust kicked up in cleaning. GitLab: !4774</a> + !4826</a> + !4863</a> + !4864</a> + !4899</a> + !4913</a> More changes:</h4> resolved security warnings and a vulnerability + updated conrod_core</code> - @Crabo - !4907</a></li> updated badges and restored cover image in README.md</code></a> - @walpo - !4897</a></li> miscellaneous fixes to changelog entries - @Crabo - !4885</a></li> synchronised battlemode state with existing character data - @do-no-van - !4902</a></li> added and improved documentation for voxygen/src/cmd.rs</code></a> - @Caigh - !4900</a></li> more precise and well-formatted doc comments, plus some more descriptive variable names - @xMAC94x - !4910</a></li> decoupled stun duration from baked in attack speed modifier - @do-no-van - !4898</a></li> price reduction for gold and silver ore to better match rarity - @Owill0w - !4922</a> ✨</li> more badge updates in README.md</code></a> - @MSGanesh23 - !4915</a> ✨</li> </ul> Ongoing unmerged work</h3> Gone fishin'</h4> What's that tugging on the line? It's us, nibbling on the bait of @do-no-van's splash into fishing mechanics. Over the horizon there's the lure of rtsim</a> fisheries, but for now the net is cast close to shore on basic functionalities. Your browser does not support the video tag. </video> Cast, bubble, reel. The classic gameplay loop </figcaption> </figure> </a> Now this is a fish </figcaption> </figure> Discussions</h3> Pet projects</h4> </a> All saddled up for the road ahead </figcaption> </figure> It started with a suggestion</a> on the discord for pets to have unique abilities, including (but hopefully not limited to) carrying backpacks. From there, folks were busting open their chalk packs for an assault on the brainstorming blackboard. Across the pastel spectrum, the final scrawlings</a> featured @juliancoffee, @Gemu, @UncomfySilence, and @isse. With honourable doodles from @Supa, @Alley_Oop, and @horblegorble. For those after the big picture, this discussion was later followed up with by a summary</a> from @Gemu. But that's enough preamble, let's get into the (thematically embellished) details. It was a memorable bass line that played throughout: creatures come as they are. Some leather strap wound through a hunk of metal isn't going to transcend their existence into new realms of verticality. No, their trials shall be our triumphs. Their glories, our grit. Tracing the orbit of independent souls learning to turn together through the twists of fate. Bound in life, but not in mind. A choice at first, tended with care to blossom in time. The many finesses of cooperation weaving ever tighter the whats and whens of chosen tactics. With vigilance to crossed threads and slipped knots, dancing on to new patterns of harmony. Far and away from the discordant rhythms of summoner and thrall. Some world that is: command, control, expire. So not with thoughts in sync, but still things shared. Such as the physicality of body. We know well our own adornments, of all manner of utility and aesthetic. Do we forget these material crafts are best shared? Be it buttressing headgear, flowing fabrics, or a double saddle for the burly hearted. Then coming full circle to personal gear that blends trade-offs between player and pal. Now indeed, this light ahead may shine most brightly. But know well - it stands against the looming shadow of mortality. And from this darkness rise these spectres of doubt: Do all good pets go to heaven? Or do they share in our unyielding tethers to the world? What damages would be done to the relationship? Can such wounds be mended, or will things inevitably tear apart? Tough questions don't always have sound answers, so for the moment we have some tonics that may ease a disquiet mind: waypoint respawning (straightforward, but not ideal)</li> more nuanced downed states and revival mechanisms</li> downgrading of player-creature bond (and associated skills/controls)</li> soulstone item that needs transferring into a new creature of the same species</li> </ul> So that's what's been sketched out. As you ponder these various hues of thought, consider a closing thought from @Alley_Oop, who said what we've all been thinking: "giant bunny mounts when" Community showcase</h2> Concept art</h3> First-hand accounts of various explorations in voxel space. A mix of things intended for use in-game, and more experimental ideations. Sort it out</h4> Inspired by inventory management in other games, @drunicornthe1 made an expedition into the world of sorting controls for Veloren. Here's a demo of their findings</a> featuring a variety of modes with a single sorting button. Your browser does not support the video tag. </video> Could sort by colour be next? </figcaption> </figure> GitLab: !4807</a> Pirated goods</h4> @Supa went off treasure hunting in the #aesthetics</a> upload folder</a> to dig up some swashbuckling goodies. A quick dust off, some colour touch-ups, and they're as good as new. </a> Catch the wind in your sails — original by @Weightierharpy3 (2022) </figcaption> </figure> </a> Aye aye, cap'n — original by @Egzekutor (2020) </figcaption> </figure> Legends of Vintiry</h3> Forget orichalcum and sunsilk, we've got a legendary tier video trailer to feast our senses on. Whether French speech is close in reach, or only close in spirit, this server event will be the place to follow in this party's questing footsteps. Will their bonds of friendship stay warm through the icy chill of mountainous foes? Watch on, and heed the call of @marcoleric: I can now spill the beans. We cooked a little server for an event and we've been working on a logo + trailer for it </iframe> </div> Cry over artful cinematography, not spilled beans </figcaption> </figure> Credits go to @Limina for camera control and @vickyfrenzy for weather wrangling by, all to realise the screenplay of @marcoleric. Scored with music by jonathanymusic</a>. Lost in transit</h3> Fellow public transport enthusiasts can enjoy a game of connect-the-dots when planning their next trip, thanks to the regular geometry of maps and tables shared</a> by @olaf_ej. </a> The Airloren travel network </figcaption> </figure> Beat the heat</h3> Leaving all your armour behind is one way to stay cool under fire. But if it helps you feel the rhythm of combat, we can't argue with results. So get ready for some roly-poly tactics here from @unii. </iframe> </div> Your flight has been grounded </figcaption> </figure>Screenshots</h2> </a> Fungal foliage — by @And_i </figcaption> </figure> </a> A wild warmth looking for its hearth — by @Necti </figcaption> </figure> </a> Peak views — by @And_i </figcaption> </figure> </a> Farmlandia — by @Sam113 </figcaption> </figure> </a> Flying brooms, minus the witchcraft — by @Necti </figcaption> </figure> </a> Bandits in blue — by Avex </figcaption> </figure> Your browser does not support the video tag. </video> 'splosions in Sporia — @horblegorble </figcaption> </figure> </a> Stuck in the mud — by @Necti </figcaption> </figure> </a> Blowing up in wait for blossoms — by @purpur </figcaption> </figure> </a> Triathlon gliding course — by @Synis </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </a> @Crabo plays backseat pilot. Will the captain's patience last till the next flight? :) </figcaption> </figure> These weeks in Veloren 248 Fri, 13 Jun 2025 00:00:00 +0000 Let's hop back on the blog-wagon, loaded up with fixes, kits, and seasonal fun. Hopefully not too much luggage for catching the i18n train. - horblegorble, TWiV Contributor Contributor work</h2> Thanks to everyone who contributed to veloren these last weeks: @drunicornthe1, @Crabo, @unii, @juliancoffee, @isse, @horblegorble, @do-no-van, @walpo, @xMAC94X, @Knightress_Paladin, @coffee-compiler, @Caigh, @imbris, @floppy, and @srpapinha. Thanks to the weblate translators who contributed these last weeks: Language </th> Translators </th> </tr> </thead> Czech</td> Janez</td> </tr> English</td> evgenkot | Arriona</td> </tr> French</td> Limina</td> </tr> German</td> coffee-compiler</td> </tr> Korean</td> juliancoffee</td> </tr> Russian</td> evgenkot | caesarrxx | LevmurDev | MBKenny | Arriona | Trauvel | Manifure | LuckyCoin | Carrotism | lucius_pilgrim | VVolsha</td> </tr> Ukrainian</td> juliancoffee | Akumo33 | ministergoose | Sinari | Iced | lomkada | Karaya | DDmytroO</td> </tr> </tbody> </table> Merged work</h3> Chatty changes</h4> Are you a chatterbox that loves to have a bunch of conversations going at once, but the friction of switching gears is slowing you down? @drunicornthe1 knows the feeling - and what to do about it. For their first merge request, they got their hands into the grime of the gearbox to tune up the mode swap transmission. Now it feels like driving a race car, with spacebar as the snappy paddle shifter. Your browser does not support the video tag. </video> Clear up the clutter and stay on message </figcaption> </figure> GitLab: !4849</a> ✨ @Crabo has opened up the chat window for us to jump straight into Veloren's wiki: I added the /wiki</code> command. The idea came from a GitLab issue</a> created in September of 2020. It was easy to do because it uses REST to delegate the searching and redirecting to the wiki itself. I'm starting to see more people use it to point newcomers to the right wiki pages. I tell people to type "/wiki recipes" and "/wiki weapons" all the time. </a> Answers at your fingertips </figcaption> </figure> Do keep in mind that the wiki is community driven, and doesn't always keep up with the traffic of development. GitLab: !4823</a> Axe juggling</h4> A recalibration may be in order for your knife-on-a-stick playstyle, with lower combo for several abilities and changes to fierce raze. </a> Pulling off another balancing act </figcaption> </figure> Let's spell out the details of @unii's tweaks: combo reductions: bulkhead, capsize, execute, maelstrom, riptide</li> one-hand fierce raze: reduced damage</li> two-hand fierce raze: increased damage, reduced range, increased energy cost</li> </ul> Combo-related ability descriptions have also been updated to have their numerical values separate from i18n files. That's one less ball in the air for future jugglers. GitLab: !4850</a> Fixing up fonts</h4> If it felt like the voxel style of Veloren was being taken a bit too far with some languages, @juliancoffee would agree. The sight of all these blocks activated his mining instinct, and he swung the coding pickaxe to reveal their true forms: We've tweaked our fonts a bit. TL;DR: Complicated Latin languages like Norwegian or Czech can now be rendered properly. Arabic can be rendered now. You can't use convert_utf8_to_ascii</code> anymore, because we've removed it. </a> High fidelity pickaxe sculpting </figcaption> </figure> As for a more in-depth explanation, each language had 5 fonts attached: Alkhemikal</code>, super fancy font.</li> OpenSans</code>, super generic font.</li> Cyri</code>, which I believe stands for Cyrillic, is used as a regular font for most text you see on the screen.</li> Wizard</code>, unused.</li> Metamorph</code>, unused.</li> </ul> We've removed the unused Wizard</code> and Metamorph</code> fonts, and we've replaced OpenSans</code> with GoNotoCurrent.ttf</code>. The point of OpenSans</code> is to be a universal font for formal information where we want the most complete coverage, for example, in chat. Except it didn't cover a lot of languages, so we've replaced it with another font that now covers almost everything, except Korean. And, because this is the font that should be the same for all languages, it's added by default, you don't need to specify it in the language's manifest. Additionally, we've added EnterCommand</code> from Font End Dev, which is a bit different, but supports more Latin characters, so I take it as a win. Oh, and we set GoNotoCurrent</code> font as regular font for Arabic. How good is support for RTL languages is to be seen, I know it's not ideal, but at least we can render it now. Oh, and I've added ґ Ґ characters to our Cyri</code> font, I'm an artist now 👀 GitLab: !4875</a> No need to shout</h4> @isse has been a busy bee, patching up all kinds of quirks in the codebase. Town NPCs can save their voice with much more reasonable interaction distances. </a> Boombox -> voicebox </figcaption> </figure> Airships return to their normal docking positions, taking the pressure off of player's knees. </a> No more spring-loaded boarding process </figcaption> </figure> Caving is back to being a subterranean adventure, as their markers come out of hiding on the map. </a> Let's call it early practice for discoverable maps </figcaption> </figure> But wait, there's more! throwable items get a pickup sound</li> desert town NPCs can direct you to crafting workshops</li> waterlogged cave entrances are less likely to be marked on the map</li> using interpolated character positions make it easier to perform interactions at high speed, e.g. with sprites on airships</li> </ul> GitLab: !4851</a> + !4854</a> Kitting out</h4> If you're allergic to Nth-wall breaking narrations, turn back now. It's @horblegorble with the lowdown on loadouts: The /kit</code> emporium has expanded its catalogue of adventuring supplies to include a variety of new bits and bobs, outfits and bombs. Some are new to the store, while others are more bespoke bundles of existing products. As always, simply flash your admin badge at the door to unlock the unlimited shopping experience! New customers may wish to pickup an "Admin's Black Hole" bag before getting lost in the aisles. A complimentary one is included in the /kit debug</code> package. </a> Booty a-plenty </figcaption> </figure> For those curious about details further up the supply chain, here's a look at the adjustments to the specification and generation of modular weapons for kit and loadout configs. KitSpec::ModularWeapon</code> got split by suffix into Set</code> and Random</code> variants that generate (respectively) a full set of compatible weapons, or a single one chosen at random. The handling of handedness was adjusted to properly enforce the optional hands</code> argument across all primary and secondary component combinations. With these two changes, /kit pirate</code> could be set up to give two randomly selected one-handed swords. The hand compatibility also applied to ItemSpec::ModularWeapon</code> for loadouts, which got Grim Salvagers to stick to their spec of two-handed hammers. No more smuggling in a close enough one-hander and calling it a day. Cheers to @juliancoffee for advice on the coding process, as well as @Tarhun and @Sam for review feedback. On a housekeeping note (and where this merge request started off), the new multi-model metal armour sets now have consistent names and ordering in their .vox</code> files. This tidied up the .ron</code> manifests, and hopefully mitigates the re-occurrence of some index mixups that arose from copy-paste modifications. GitLab: !4798</a> Better beams</h4> @do-no-van had always heard it was advantageous to have a well-rounded skillset, but found that beam attacks were taking this advice a bit far. Specifically, it got funky when their radius was being added onto their nominal range. After a small trim, things lined up much neater. Your browser does not support the video tag. </video> Mind the gap </figcaption> </figure> GitLab: !4869</a> One iter to rule them all</h4> It began with the forging of the Great Data Structures. Fields were given to the Structs; immortal, simplest and pointiest of all beings. Variants to the Enum Lords, great matchers and unionisers of the double colon halls. And traits... Traits were gifted to the Race of Types, who above all else desire strictness. For within these structures was bound the memory addresses and assembly to govern each abstraction. But they were all of them deceived, for another abstraction was made. In the land of Ukraine, in the fires of Neovim, the Dark Lord @juliancoffee forged, in secret, declarative macros to enumerate all others. And into these macros he poured all his caffeination, his rust-fu and his will to iterate all variants: Ok, this is a super technical thing, but hey, it's a dev blog. Let me introduce you to a few macros I've been working on, with @imbris's help. Well, you [may] know you can define enum</code> in Rust: enum Dir { Up, Down, } </code></pre> Let's say you have some function that takes Dir</code> as output, so it'd be cool to automatically test it on all Dirs</code> and check that it doesn't throws errors or something like that. Except, you can't get all Dirs</code>, Rust doesn't provide such functionality... Except, you can write such functionality yourself with a bit of dark magic by rewriting Rust code at compile time. One such magical rewriter is the strum</code> crate, which we are using, which will generate a method iter()</code> that will do just that. Unfortunately, strum</code> can't handle anything more complex. Let's say you want to nest these enums: enum Boost { Health, Gravity(Dir), } </code></pre> You'd expect to get Boost::Health</code>, Boost::Gravity(Dir::Up)</code>, Boost::Gravity(Dir::Down)</code>, but strum</code> won't generate them, because ... it won't. So I made a macro that would generate them. And that's not all. What if you don't have just enum</code>? What if you have some struct</code> you want to iterate over? enum Species { Butterfly, Bird } enum BodyType { Male, Female } struct Body { species: Species, body_type: BodyType, } </code></pre> Well, that's another macro I've added which generates you all possible combinations of these Bodies</code>, which would contain male and female versions for Butterflies</code> and Birds</code>. And if we already have that, why don't we apply that to exactly such an enum in our codebase: Body</code>, which defines every possible "entity" we can have. By entity, I mean something abstract, but it includes everything from humanoids to rabbits, to even items and objects and airships. Not campfires though, which are entities as well, but well, special. So this MR adds Body::iter</code> function, which gives you a list of all possible entities. As a nice bonus, it will also generate some constants for you, like the number of kinds an enum has or if you ask it nicely, it will also give you all variants it can get. Unfortunately, the latter doesn't work with nested enums. enum_iter! { ~const_array(ALL) #[derive(Eq, PartialEq, Debug)] enum Shade { Good, Meh, Bad, } } // it is, in fact, three kinds, as you can see assert_eq!(Shade::NUM_KINDS, 3); // and these shades are really what you'd expect const ALL_SHADES: [Shade; Shade::NUM_KINDS] = Shade::ALL; assert_eq!(ALL_SHADES, [Shade::Good, Shade::Meh, Shade::Bad]); </code></pre> This is all done using so-called declarative macros or macros-by-example, which are powerful enough to achieve what I just showed you, but still not as convenient to write (or use) compared to more powerful kinds of macros: procedural macros. These ones don't just rewrite your code, they let you write the code to write new code. In the future, we plan to come up with alternative versions of these using procedural macros, and I'd personally want to release them to the general Rust ecosystem. GitLab: !4843</a> Making mug shots</h4> Whether you want to create wanted posters, a future bestiary, or establish the database for a surveillance dystopia - @isse's expansion of img_export</code> to NPCs has got you covered. </a> Pick your fighter </figcaption> </figure> Here's a simple example that'll give you everything at once: cargo run --bin img_export -- --all-npcs </code></pre> And another one with some of the bells and whistles: cargo run --bin img_export -- --all-npcs --filter traveler --seed 0 20 </code></pre> This will give you an image for all NPC paths that contain 'traveler', with a seed</code> value to control randomised characteristics. Note that the final positional scale</code> argument is applied to a 10x10 image, so the default of 20 gives 200x200 output. The command can be run from the top veloren</code> directory of a git repository</a>, with output saved in a img-export</code> folder. If you're looking for pixel-perfect results, be aware there's still some minor glitches</a> in the rendering at lower resolutions. GitLab: !4871</a> Don't git confused</h4> </a> Know your repo </figcaption> </figure> Mirror, mirror, in the cloud; why are my changes not allowed? Famed is thy git commit; but hold, this kitty is not it. Ears cannot hide the tentacle. Alas, vulpes vulpes is where you fit. A lash for thee, that heed not @walpo's note: Due to user feedback, @walpo and @xMAC94x have updated the mirror repositories on GitHub in order to mitigate confusion with real repositories. The changes are: New pull requests are automatically closed.</li> Some features of those repositories have been disabled to make them look "less real".</li> </ul> Remember folks, development takes place on GitLab, and not GitHub! GitLab: !4853</a> + !4857</a> + !4859</a> + !4868</a> + !4870</a> UI gooey</h4> With a light makeover from @Crabo, crafting scrollbars are feeling much more confident in standing out to their mouse crush. This also inspired the footer section to give up their barefoot phase and slip on a 'boot bar' for some tidy delineation of their own. </a> A bit of brightening up around the edges </figcaption> </figure> GitLab: !4801</a> All aboard the i18n train</h4> Dodging the bus factor</h5> </a> Based on a true story </figcaption> </figure> Headlight eyes cut through the night. A low roar rumbles up through radiator jaws. All barrelling down at you with 7 tonnes of fury. The star of the show is ready, but @juliancoffee wants out of this road-rage thriller: So there was a problem of bus-factor with our i18n system, in that, frankly, I was probably the only person who fully understood how it works and how to interact with it, so well, I decided to fix this problem. This guide</a> covers: all the i18n crates (or well, ones that do matter, I'm pretending that i18n-helpers doesn't exist, because)</li> best practices and how to properly make UIs localizable</li> a few simple examples</li> </ul> (Oh, and btw, I've added a section about fonts</a> to "Managing Weblate'", which is inspired by the post above.) !211</a> What shall I call thee?</h5> They have went by many names, floating between anonymities as boss after boss has called them to arms. After all these years of thankless, nameless service, @juliancoffee finally gives them something they can identify with. </a> A history of summons </figcaption> </figure> GitLab: !4883</a> Back in the bottle</h5> Some buffing items were overflowing with power, eager to info-dump into your inventory. Keeping them in line was @Knightress_Paladin, by removing a doubled up concatenation and separating out duration information. At least this work was easier than putting toothpaste back in its tube. </a> Don't cry over spilled potion </figcaption> </figure> GitLab: !4873</a> + !4877</a> All the other carriages</h5> localised some trade messages - @coffee-compiler !4862</a></li> changed "gigas frost" to "frost gigas" in English i18n - @Crabo - !4865</a></li> consolidated HUD .ftl</code> files that aren't yet components in weblate - @coffee-compiler - !4820</a></li> localised player names in the trade interface - @Caigh - !4880</a> ✨</li> localised /players</code> command - @Caigh - !4882</a></li> merged weblate translations - @juliancoffee - !4884</a></li> localised CommandResult</code> in voxygen - @Caigh + @juliancoffee !4893</a></li> </ul> New names, old stories</h4> Grab your marshmallows and settle in by the campfire. @juliancoffee has a yarn to spin: Ok, I don't even know where to start with this. We can now translate NPC names! 🥳 </a> The shortcut to getting a 'new' job title </figcaption> </figure> TL;DR For devs: in assets/common/npc_names.ron</code> the generic</code> field had been changed to represent an i18n key</li> in assets/common/entity</code> configs, the name now uses Translate</code> with an i18n key</li> </ul> For devs and translators: animals are now translated like this:</li> </ul> name-body-quadruped_medium-lion = .fem = Lioness .masc = Lion </code></pre> profession names and such are translated in an identical way:</li> </ul> name-custom-village-hunter = .fem = Huntress .masc = Hunter </code></pre> objects don't have any gendering information, so they only request one attribute: neut</code></li> </ul> name-custom-dungeon-cultist-turret = .neut = Possessed Turret </code></pre> And frankly, it was an MR [Merge Request] with a fairly small diff, only 1977 lines added and 665 removed. The internalization system saw bigger ones. But it's the one that brings me a lot of joy, because in some way, it is the last internationalization MR. A last internationalization MR. We've come a long way. A beginning</h5> When I joined the project around April 2021, a fair amount of work was poured into Veloren's translation, and most of the user interface could be translated via our in-house system of .ron</code> files (json</code>-like config files for Rust ). We even supported fallbacks if your current language didn't have all its strings translated (thanks to @Christof</code>). It worked fine, but obviously it had its limitations; after all, it's just a key-value store. You ask for translated "yes" and receive "Yes" in return. Or "Oui", or "Ja", or "Так", or "はい". You get the point. It becomes complicated when you want to pass some values or, even act slightly differently depending on these values, for example, you don't want to end up in a situation where an item costs "one coins". So, in early August 2022, we fixed it. We adopted a new format: Fluent</a>, created by Mozilla. It was similar enough in its flow to our existing system, but at the same time, it's super expressive, probably the most expressive format at that point and even today. You can read about it more in a blog post</a> about all that or in the RFC document</a>, which quickly describes how it all works. (I think that RFC is the cooler one, but you can decide for yourself 😉) Fluent is a cool format, and it's enough of a reason to adopt it, but there was more to it. First of all, there was an issue with the translation experience itself. At the time, if you wanted to add localization to your language, you had to go through the same procedure all developers use, create a Gitlab account, learn how to work with Git, create a Merge Request, potentially manage your branch in case it needed updating... it wasn't easy. So yeah, to solve that problem, we picked Weblate</a>. It's a web service that provides a more human-oriented interface and an improved management system. It took us some time to migrate, and I must thank @walpo</code> and @fnetx</code> for pushing through it; it wasn't easy. As well as the Codeberg</a> project for hosting. Right now, we're using it for all translations. The tale of two worlds</h5> We were working on creating and improving the internal framework for localization, but I must mention a significant limitation of said framework. You can only translate a message into a language, if you know what language to translate to. And while it would be possible to thread this information from the client you're using (and today, we do that to display server rules), it wouldn't be as convenient as you'd need to pretty much create two localization systems. Instead, we come up with the idea of delayed evaluation of messages. I could claim the idea here, but credit goes to @zesterer</code> when he implemented the Content</code> type while working on NPC messages. The process is simple: instead of giving the client the final string, we give it a key for a string and the required context to evaluate this key. What this meant is that now you can translate not only the user interface. Now you can translate everything. We started with translations for NPC messages, continued with server commands, items and finally, NPC professions and animal names. And at this point, we've translated pretty much all there is. Of course, there is stuff we forgot here and there, but it's a matter of someone going through beginner issues and implementing left-out pieces. You, dear reader, can do it as well</a>. Hit me up at Discord</a> or Zulip</a>, I'll probably be able to guide you. And if you're a translator and notice that something is missing from the game and there are no issues for that, feel free to create one (don't forget to add wg:translation</code> label). The future</h5> So what would be the next chapter for Veloren internationalization? With our near complete coverage, we need to fill small holes, probably also implement i18n for plugins, and focus on QoL improvements. Maybe even contribute to Weblate, who knows? But if I'd draw a big theme, I would say one word: Gender. It's a complicated topic, but that makes it even more exciting. And I think I'll share some thoughts on it with you all. To begin, we already have a (bit shaky) foundation to build on. Check out assets/voxygen/i18n/it/hud/chat.ftl</code>: hud-chat-connection_lost = { $user_gender -> [she] Connessione persa. Verrai scollegata tra { $time } secondi. [he] Connessione persa. Verrai scollegato tra { $time } secondi. } </code></pre> I don't read Italian, but I bet you'd have an even harder time with the Ukrainian example, so bear with me. You can see the power of Fluent</code> here, every message can not just splice passed arguments to it, it can act on them. Which is especially useful for numbers, as Fluent supports the whole Unicode standard</a> for them, but it can be used for other stuff as well. Almost all strings in chat have one or multiple arguments which specify the gender attribute of an actor in context. In this case, we check if the user's gender is masculine - we use one form, if the user's gender is feminine - we use another. (scollegata</code> vs scollegato</code>). (If we don't know, we default to masculine in this case, that is what </code> is for) And if you go to the beginning</a> of that file, NPC names follow a similar pattern, except here we employ a different tactic. The reason is that in both cases we 'match' on gender, but it's not the same kind of gender. There is more than one gender; in fact, there are more than two. As you can guess, hud-chat-connection_lost</code> in English has no matches. That's because English lacks the concept of grammatical genders almost completely. It has the concept of sex, and it has the concept of gender. After all, we have all the pronouns. Yet the word "left" is the same whether it's "she" who left, or "he", or "they" or even "it". There's no "scollegata" and "scollegato". And most importantly, while most languages have a similar concept of sex and gender, because it's not really a linguistic thing, the concept of grammatical genders can be wildly different, so we couldn't just expose one attribute to handle everything. By the way, if you're still wondering, what I mean by grammatical gender, let me very quickly explain it. In some languages, every word has a gender. In most European languages, it influences the article and the word's ending. So "cat" in German would be "die Katze", which declares cats are inherently feminine. In Spanish, "the red cat" would be "el gato rojo" while "the red flower" would be "la flor roja". And so on. Read the Wikipedia page</a> on it, if you want to know more. With all that, I define three concepts we need to consider. Sex, social gender, and grammatical gender. These are linked, and we're most interested in social (for names and such) and grammatical gender (for everything else). Unfortunately, at this point, we only have one: sex, which we in our codebase call the BodyType</code>, a binary enumeration for Male and Female. We need to extend this system, create the concept of social gender for players and NPCs and then figure out a way to infer or define grammatical gender. The challenge lies in the fact that grammatical gender rules are kinda totally different for every language, so it will be fun. I'll end it there. Feel free to jump to our Zulip</a> or Gitlab issues</a> if you have some ideas. GitLab: !4829</a> Zulip: [review] Name i18n !4829</a> More changes:</h4> updated sponsorship link on github - @walpo - !4852</a></li> re-oriented Level of Detail (LoD) model for Haniwa Catacombs - @horblegorble - !4844</a></li> solidified a floor of the Myrmidon dungeon - @floppy - !4855</a></li> updated item quality ratings for recipes, bombs, and medium potions - @horblegorble - !4867</a></li> the re-orient express chugged along with modifiers for ranged attacks - @srpapinha - !4861</a></li> reverted some duplicate commits for a cleaner history - @juliancoffee - !4876</a></li> fixed armour manifest entry for dwarven guard hands - @horblegorble - !4878</a></li> limited git lfs</code> checks to correct use of pointers - @imbris - !4879</a></li> replaced string arrays with enums for diary sections and skill trees - @coffee-compiler - !4888</a></li> rotated totems summoned by Gnarling Chieftain to face their target - @horblegorble - !4887</a></li> </ul> Ongoing unmerged work</h3> (Re)trial by fire</h4> </a> The hypercritical steam engine — by @Necti </figcaption> </figure> @do-no-van's coding and @Necti's balancing was put through the crucible of combat in round 2 of Spicy Gigas playtesting. The big fella faced up against players and NPCs alike; thankfully all the commotion didn't cook @isse's server. </a> Pyretic pillars — @horblegorble </figcaption> </figure> </a> Travellers gang up on Gigas — @horblegorble </figcaption> </figure> Discussions</h3> Begun, the storage wars have</h4> @Knightress_Paladin has penned the latest chapter</a> in the Veloren RFC anthology, with an ode to bags, banks, and boxes. Given the different roads to travel, they've charted and articulated a course to travel, along with hazards of the terrain. All to reach one destination: a place for all things, be they necessity or novelty. Let's take a look inside: Per player, town based persistent storage at 'bank' structures</li> Can transfer between characters via stashes</li> Map UI toggle to show active stashes</li> </ul> </li> Motivations Can dedicate your inventory to a particular outing, freeing space to grab shiny new things</li> Dethrones inventory bag size from being the top stat</li> Developers get some freedom to add items without encumbering players</li> </ul> </li> Site shuffles automatically transfer stashes to their nearest town Done at time of player login, to avoid drifting over multiple shuffles</li> Possible courier system to alleviate work of relocating items after site shuffle</li> Differentiating between underground and above-ground settlements in the future</li> </ul> </li> Open questions How to decide which towns have storage? e.g. requires an airship dock</li> How do NPCs interact with the storage system?</li> Should there be theft from storage and couriers?</li> </ul> </li> Future possibilities Upgrades of storage at each town (capacity, security?) Could range from one-time fee(s) to embedding with a quest system</li> </ul> </li> Faction / sentiment influences Out of scope for the moment, but likely to influence things in the future</li> Alignments between towns could scale courier costs</li> Various settlements could have their own pricing systems and rates</li> Non-friendly alignment might mean upfront/time-based costs for storage</li> Hostile settlement should not receive items after a site shuffle</li> </ul> </li> </ul> </li> </ul> Although landing a persistent storage feature would provide the staging area for weight based inventories</a> (or other inventory nerfs), it is not desired for these to take place before matters of storage are properly unboxed. Wouldn't want to end up with the worst of both worlds. Counting critters</h4> The open sky breaks through the canopy's shade as you step into the open glade. Before you now, a sight to perplex the ecological mind: half a dozen wolves, packed up against a flock of sheep. Neither with a care in the world for the other. As it has always been, but maybe not in futures yet to be seen. Rather than wildlife as islands unto themselves, what other geographies might be possible? A grand RTSIM</a> archipelago would be the straight road guess, but could make quite a mess of the tracking budget. So instead of a world-scale game of "this little piggy", taking a more zoomed out view could avoid slimming down the CPU's piggy bank. The Pangea Project is leading an expedition into this game design space, with a recent brainstorming session</a> on linking up regionally tracked populations. In attendance amongst the crowd of khaki was @Neura, @zesterer, @isse, @juliancoffee, @Gemu, and @Knightress_Paladin. Here are their ideas so far: Wildlife spawns based on population counts that are tracked by region/chunk Terrain permitting, these populations diffuse and spread between adjacent regions</li> Entity interactions lead to a kill, death, or retreat that is tallied up against the population</li> </ul> </li> Dynamic predator/prey modelling (simple</a> or complex</a>) running alongside gameplay interactions With enough fudge in the numbers (sounds yummy!), this should lead to stable systems</li> There's a few different ways to split up wildlife categories for tracking Species, body kind, ecosystem role (prey, (apex) predator)</li> </ul> Clamping effects and repopulation mechanics may be necessary to avoid global extinctions e.g. a local extinction may trigger the re-seeding of the population elsewhere</li> </ul> </li> Since post-apocalyptic settings are all the rage, could always let players roam free and annihilate everything - we love seeing that our actions have consequences, right?</li> </ul> </li> A follow up point</a>: NPCs could maintain sentiments towards particular species of wildlife (rather than individuals), communicating this to other NPCs and feeding into a quest generating system.</li> </ul> A questing checklist</h3> You there, traveller! Fetch me 10 randomly dropped Gnarling bracelets and I shall grant you full gameplay immersion. That sounds realistic, right? @isse begs to differ, and reckons the recipe for quests is gonna be more than some microwave meal: Just to name a few properties we want of the top of my head: It has to be implemented in rtsim</a>, our world simulation, and have effects on that.</li> Quests should be based on actual needs the npc/faction has. If there has been a cyclops attacking recently they could generate a quest to slay that. (We lack a lot of simulation for the needs of more interesting quests though).</li> We want a global tracker for quests, but each quest should have an actor/faction that gave the quest to also return to to complete it. And an actor/faction that received the quest.</li> Since quests are based on needs, that means they're also somewhat time based as needs can be fulfilled. Someone else could kill the cyclops, or the quest taker took to long so the npc decided to do it themselves etc. And the quest system should be able to handle this, in some way.</li> Not needed for first iteration, but quests should be able to handle cases where the original npc that gave the quest died. And migrate the quest to potentially another npc that npc knew.</li> Also not needed for first iterations, but since a huge majority of a veloren world's population are npcs, they should be able to take on quests too.</li> </ul> Community showcase</h2> Concept art</h3> First-hand accounts of various explorations in voxel space. A mix of things intended for use in-game, and more experimental ideations. </a> Go, go, slimer rangers! — by @GoodMan29 </figcaption> </figure> </a> High altitude headgear — by @Supa </figcaption> </figure> </a> Pipe dreams — by @Supa + a recolouring by @Dan113 </figcaption> </figure> This is the way</h3> Airships are great for travelling fast, but a good map is what you want to travel smart. To help us plan out our commutes, @Limina swapped hats from translator to tool builder, taking a blog driven development approach to the task: After seeing the full map of airship routes by @Froggy in devblog 245</a>, I took it upon myself to fulfil the comment under it: "Now we just need a trip planner app." </a> </figure> Ask and ye shall receive! The Veloren Trip Planner for Veloren's official server is available at itch.io</a>, all on the web - no download required! Code is over at github</a>, under the GPLv3 license. I'll update any incorrect paths I come across - feel free to let me know if there are any I missed! For those that want more details, read on - else, you can just skip to the next section. I won't judge (much). Your browser does not support the video tag. </video> </figure> The tool was made with Godot</a> 4.1.1, as it's my preferred engine to work with (and it's open source, too!). It uses A* pathfinding</a> to figure out the shortest path between cities - paths are hardcoded, since we know all of them. They're easy enough to swap out though: each "town" is a node that hold a list of every other city it's connected to. That came especially in handy when I noticed some of the paths had changed since @Froggy's map was made! Currently, it recreates paths every time we ask it for one - admittedly, I could skip that step and just generate it once, but it doesn't matter much given the amount of paths is quite low. That would also allow for dynamically ignoring cities or even adding/deleting them at runtime if we want to - although that's not a thing yet. :P Once we know the starting and ending cities, we can just use the paths that are created with the A* algorithm, and voila, we have a path! I don't really have a to-do list, so any suggestions are welcome - or even pull requests if you so wish~ Weave got a new challenger</h3> Looming over the competition is a new entry from @Moaaswell to the previously featured</a> carpet challenge. Taking us beyond the simple square, will this stretch the fabric of the contest? </a> Think outside the box. Be an even bigger box! </figcaption> </figure> Explosive new meta</h3> Get ready to have your mind blown by @Necti's feature of the throwable bomb meta that is blasting away all other playstyles. Learn about shockwave proofing your loadout, dig into make-your-own trench warfare, and stick around for some charming tips on dealing even more damage. </iframe> </div> Not hard to imagine an aerial bombardment support role </figcaption> </figure> Veloren's coconut farmers are greedily rubbing their palms together in anticipation of increased demand. But time will tell if player's appetities are lasting, and whether these would-be profiteers will survive the fallout. Phoenix fireworks</h3> After converting their inventories into dedicated bomb factories, the players of Sporia faced a shortage of velorite and coconuts that threatened to derail their regularly scheluded fireworks display. To fill in for the local pyrotechnics shortfall, some resourceful individuals decided to import a brand new light show. @horblegorble brings us a photographic account of the family un-friendly event that followed. Identities and profanities have been redacted to protect the (not so) innocent. </a> Reel 'er in </figcaption> </figure> </a> Lighting up main street </figcaption> </figure> </a> Recipes for disaster </figcaption> </figure> </a> Waned enthusiasm </figcaption> </figure> </a> Here comes the rain </figcaption> </figure> </a> A new sun rises </figcaption> </figure> </a> Getting upstaged </figcaption> </figure> </a> Arrow time </figcaption> </figure> </a> Bird's eye view </figcaption> </figure> </a> A crispy aftermath </figcaption> </figure> Events</h3> 'twas the season of springtime sillyness in Veloren, when familiar tricksters and treasure eggs popped into play. But this year also threw an unexpected curlball into the mix. April fools</h4> We'll let @Necti do the grand reveal, with this inside scoop on Veloren's newest celebrity. </iframe> </div> Pay no heed to false leads — by @Necti </figcaption> </figure> The master has arrived</summary> The Pigmaster</a> is a swine to swoon over - at least, that's what their possy of rats will tell you if you ask them about forming this leaning tower of trouble. Finish off the smolest one (without losing track of it) for a chance at getting a Rat Tail</a> of your own. </a> Master, rat, small, tiny, mini, smol — @horblegorble | @Alley_Oop | @Crabo </figcaption> </figure> This stack of suprises was smuggled</s> bundled into a package of 'small changes'</a> by @isse, along with collaborators unknown. </details> Exciting as it all was, the new buzz didn't steal the whole show. Folks got up to a lot of the usual unusual April Fools</a> fun. </a> Hop, skip, and a roll to get to the concert on time — by @Supa </figcaption> </figure> </a> An annual tradition — by @souffle </figcaption> </figure> </a> They get themselves into all sorts of tricky spots — by (➜) @souffle | @horblegorble x3 </figcaption> </figure> </a> Blazing trails — @horblegorble </figcaption> </figure> </a> @Necti blends in to lead the band — @horblegorble </figcaption> </figure> </a> A curious potion turns the tables on @horblegorble </figcaption> </figure> </a> Rooftop rats — @horblegorble </figcaption> </figure> Easter</h4> Although slightly overshadowed by the fresh excitement of foolish festivities, players were still keen to hop into the Easter</a> event. After all, you don't get to throw around surprise eggs for the rest of the year without stocking up first. </a> Ear ye, ear ye! — by @souffle | @horblegorble </figcaption> </figure> </a> @souffle woke up to find out the tooth fairy was helping with Easter deliveries this year </figcaption> </figure> In the wild</h3> There and back again</h4> Let yourself be carried away by the narration of @Gbone, as they regale us a tale of marvel and mishap. Will this band of adventurers conquer all, or will the world conquer them? See them face up against wolves, caves, dungeons, and even airships and town NPCs - as well as unintentional levels of friendly fire. All in good fun as they find their way back home. </iframe> </div> Fame, fortune, glory, and tomato salad! — @Gbone </figcaption> </figure>Screenshots</h2> </a> We've only got the one bridge, so it better be sturdy — by @isse </figcaption> </figure> </a> Small worlds make for big parties — by @Alley_Oop </figcaption> </figure> </a> Demonstrating the value of all those neck stretches — by @unii </figcaption> </figure> </a> Inviting aromas — by @isse </figcaption> </figure> </a> Catching a ride — by (➜) @Val | @Limina | @horblegorble </figcaption> </figure> </a> Flying into fresh dawns — @horblegorble </figcaption> </figure> </a> Volcanaurora — @Alley_Oop </figcaption> </figure> </a> Valley of light — @horblegorble </figcaption> </figure> </a> Foraging for honey-root — @horblegorble </figcaption> </figure> </a> Boing boing boing... — @Trentus </figcaption> </figure> Your browser does not support the video tag. </video> Vibing — @Limina </figcaption> </figure> </a> Did I find Atlantis? — @isse </figcaption> </figure> </a> Sahagin envy — by @Alley_Oop </figcaption> </figure> </a> Foggy humps — by @Sam113 </figcaption> </figure> </a> Living the well-shaded life — by @term_junkie </figcaption> </figure> </a> Pining for a new day — @horblegorble </figcaption> </figure> </a> Late nights on the beachfront — by @Sam113 </figcaption> </figure> </a> Pointed reflections — by @Sam113 </figcaption> </figure> </a> Highrise district — by @Alley_Oop </figcaption> </figure> Heard you like silly scribbles</summary> </a> Surprised tower-chu face </figcaption> </figure> </details> </a> 'bigflyingrock' — by @Supa, named by @Sam113 </figcaption> </figure> </a> Grave of the flying hero — @horblegorble, found by @Alley_Oop </figcaption> </figure> </a> Definitely some kind of cave entrance — @DaforLynx </figcaption> </figure> </a> Extra spicy shrooms — by @Alley_Oop </figcaption> </figure> </a> Liminal lines — by @And_i </figcaption> </figure> </a> Sparkling spelunking (say that five times fast) — by @And_i </figcaption> </figure> </a> Chillwater cliffs — by @Limina </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </a> The lost legoom contemplates a darker path. Let's hope they find their way back to us :) </figcaption> </figure> These weeks in Veloren 247 Fri, 02 May 2025 00:00:00 +0000 You may experience some slight turbulence as a volley of new throwables, tunes, and banter fill the air. Here we go! - horblegorble, TWiV Contributor Announcement</h2> Whether you're a casual snapper or full-on shutterbug, we want you to take a shot at this photo contest being organised by @walpo: </a> Veloren of yore </figcaption> </figure> We are looking for a new cover image for the README file</a> of Veloren. If you think you have a cool picture to share with the community, feel free to post it in the Discord</a> or Zulip</a> submission threads! Rules: Submissions are open from now until Thursday, June 12 at 21:00 UTC (about 1 month and a half). Any content submitted later will not be included.</li> You are free to use our current (textual) Veloren logo</a> on your submitted images, but it is not mandatory.</li> Your submitted images must have a minimum height of 600 pixels and have a 16:9 aspect ratio.</li> Each participant can submit up to three images. If a participant has submitted more than three images by the time the submission window is closed, we will ask them privately which images to include in the voting phase. If the participant does not reply in a timely manner, we reserve the right to choose the three most recent images by default.</li> After the time window for submissions is closed, we will decide on a voting system for our community to pick their favorite. Emoji reactions on Discord do not count towards the vote.</li> You must be the copyright owner of the submitted image. This implies you cannot use generative artificial intelligence (GenAI) to create part or the whole image (currently, a legal grey area).</li> You agree to share your submissions under an open licence. For example, some licences in the Creative Commons suite</a>.</li> If your image wins the contest, our team will contact you to discuss what licence you want to share your work with and how to handle attribution.</li> </ol> Contributor work</h2> Thanks to everyone who contributed to veloren these last weeks: @do-no-van, @Supa, @Gemu, @floppy, @Joe_Cool, @Crabo, @isse, @juliancoffee, @Synis, @srpapinha, @zesterer, @souffle, @unii, @imbris, @Tarhun, @UncomfySilence, @Nikophos, and @violetwillow. Thanks to the weblate translators who contributed these last weeks: Language </th> Translators </th> </tr> </thead> Czech</td> Janez</td> </tr> English</td> Janez | EatherBone | ministergoose</td> </tr> French</td> Limina | sandraev</td> </tr> German</td> coffee-compiler | CodeVlogs | Benny | Virtex | fnetX</td> </tr> Polish</td> K0RR</td> </tr> Russian</td> EatherBone | aleeo | lucius_pilgrim</td> </tr> Swedish</td> IsseW</td> </tr> Ukrainian</td> ministergoose</td> </tr> </tbody> </table> Merged work</h3> Sparkling action at a distance</h4> Unable to wait for the bow rework, @do-no-van took projectiles into their own hands with a hefty refactoring. Best have your eye protection ready as sparks fly across town. Your browser does not support the video tag. </video> 🔊 All kinds of light shows. Music by @Crow </figcaption> </figure> And hope that nothing ominous has been waiting for "the day that dummies fly". GitLab: !4593</a> Oud and a lute</h4> What started out as a remodelled Lute</a> in @Joe_Cool's first foray with MagicaVoxel, became a catalyst for the arrival of the new Oud</a> instrument. @Supa was the supervising chemist for this reaction, mixing together voxels from @Gemu and audio from @floppy. You can hit up the crafting bench to enjoy the silver linings in these new notes. </a> The newcomer (left) and their restyled cousin (right) </figcaption> </figure> Your browser does not support the video tag. </video> 🔊 New strings attached </figcaption> </figure> With his lab coat still on, @Supa continued with some instrumental tinkering: The icy talharpa instrument now faces the correct way in the inventory</li> Sprite image sizes for instruments are changed to be consistent with each other</li> Small recipe tweaks for banjo and kora</li> </ul> GitLab: !4778</a> Friend or foe</h4> Whether you're looking to pick a fight, or keep the peace, @Crabo's changes to the player list take the guesswork out of battlemode negotiations and moderator status. Sword icons were supplied by a secretive arms dealer that looked an awful lot like @Supa. </a> Your duelling career is but a click away </figcaption> </figure> GitLab: !4790</a> Mise en place</h4> With the prep-work done on tile-able sprites, @isse got to cooking up a system for piecing together furniture mosaics: The way we place composable sprites in site2</code></a> is an extension trait for Painter</code></a>, which is what we use to define how blocks are placed for site2</code>, and as sprites are blocks it includes those. On this I have created both helper methods for placing generic tiled sprites and functions that directly refer to some configuration of sprites creating a bigger thing, like a bed. There are different kinds of generic helper methods. Right now I have a one dimensional and a two dimensional. The 1D one, which is called tileable1</code></a> takes a side sprite and a middle sprite, it also takes parameters for position, facing direction, and width. This assumes that the sprite with the maximum position has to be mirrored. Some ASCII+ to demonstrate this: width: 4 blocks < □ □ > center sprite: □ 2 blocks < > side sprite: < mirrored: > </code></pre> The 2D one is called tileable2</code></a>. This needed a bit more arguments so it takes a struct Tileable2</code></a> to define it. Which stores a rectangle and an altitude to define position. A center sprite, side sprite and a corner sprite. Both the side and corner sprites can vary by which side/corner they're placed on. It also has it's own direction to rotate the whole construct. For a table where all corners and sides are the same this looks like: +y size: 5x3 blocks (x by y) ⭡ center sprite: □ ╵ ┌ ∧ ∧ ┐ side sprite: < ╵ < □ □ > rotated/mirrored: > ∧ ∨ ╵ └ ∨ ∨ ┘ corner sprite: └ └ ─ ─ ─ ─ ─ ⭢ +x rotated/mirrored: ┘ ┌ ┐ </code></pre> For a bed it looks like: +y size: 3x2 blocks (x by y) ⭡ side sprite: ∧ | ∨ ╵ ╔ ∧ ┐ (-x) corner sprite: ╚ | ╔ ╵ ╚ ∨ ┘ (+x) corner sprite: ┘ | ┐ └ ─ ─ ─ ⭢ +x </code></pre> Because there are different corner sprites used for the diagonals that face -x</code> and +x</code>. There are also helper methods like chairs_around</code></a> which places sprites around a specific bounds. And specific ones for sprites that don't fit any generic pattern we have, for example lanternpost_wood</code>. When there are more sprites that need that specific pattern more generic methods will be created. </a> A tiling of tile-ables </figcaption> </figure> GitLab: !4799</a> Turn down the heat</h4> @juliancoffee understands that, like a good vegemite sandwich, you only want a bit of spread. So now when you're campfire moshing with mates, the chance of lighting each other up scales with time and buff strength of the source. And when the heat does catch on, it'll only be the world to blame. A relief to town guards that've been busy dousing feuds between hot-headed neighbours. Your browser does not support the video tag. </video> Their new release is a real slow burner </figcaption> </figure> GitLab: !4832</a> More vertical progression</h4> No, not that kind. The other one. Yeah, climbing. Anyway, @Synis has heard the feedback on their recent changes, and put together the next shift-to-release-candidate version. This lets you overcome fear to drop straight out of climbing, and also features the return of uphill bounding. Other changes include a persistence of wielding state, as well as fixes to energy cost calculations and infinite wall jumping. Your browser does not support the video tag. </video> Sliding down and scooting up </figcaption> </figure> GitLab: !4811</a> War of the names</h4> And on the seventh day, the user made a typo in naming their new world. Luckily, @juliancoffee let them rewrite history: You can now change the world 🏔️ name even after it is generated ✍️ Your browser does not support the video tag. </video> Somebody once told me </figcaption> </figure> GitLab: !4830</a> Worldly estimates</h4> Watching water boil, grass grow, paint dry, or waiting for the next tick in the erosion process for a new world. These are universal expressions for wearing down the soul. But there is now relief for the latter, with updates from @isse to put your mind at ease: Added some additional info when generating worlds, it now shows more fine grained progress and a time estimate for how long erosion will take </a> Might be able to sync up with a New Year's countdown </figcaption> </figure> GitLab: !4834</a> Jungle jumble</h4> @juliancoffee went around the colour wheel to spin up a remix of our tropical ambience: Jungles look a bit more like jungles now. I in collaboration with @Gemu changed their colour scheme to make their bark darker and more recognisable. </a> Rainforest Red -> Botanical Brown </figcaption> </figure> GitLab: !4831</a> All spin and no swing make Jack a dizzy boy</h4> After some coaching sessions with @srpapinha, your not-so-friendly dance partners have learned to get some step in their rhythm. A broad set of melee orientation modifiers have retired their aim-botting 'robot' routines. Your browser does not support the video tag. </video> 🌪️ 🤢 Round and round we go </figcaption> </figure> GitLab: !4803</a> Same sprite, different loot</h4> No doubt we've all heard the expression "You shouldn't judge a sprite by its voxels." It's a sound bit of wisdom that @juliancoffee has put it into practice for wordgen: Ok, it finally happened. We merged an MR that allows you to override the default loot for sprites when you place them. Currently, the way containers/pickables work is via SpriteKind::default_loot_spec()</code> method (previously known as SpriteKind::collectible_id</code>), which is a big list of sprites and their corresponding loot tables. That's fine and even desirable for 70% of sprites. When you pick up an Apple, you don't want anything else. And chests in boss rooms in our new breathtaking dungeons greatly benefit from stylistic conformance with the environment. But we have a lot of generic containers like crates and barrels in towns and caves and, most importantly, spots, which inevitably forced to have the same boring loot tables. Well, not anymore! Look at the spot config for the Saurok altar: #![enable(implicit_some)] #![enable(unwrap_newtypes)] [ ( specifier: "world.structure.spots.saurok-altar", center: (10, 13, 3), custom_indices: { + 11: SpriteWithCfg(DungeonChest0, ( + loot_table: "common.loot_tables.spot.saurok_altar", + )), 105: Filled(GlowingRock, (r: 161, g: 255, b: 133)), 113: Filled(GlowingRock, (r: 139, g: 245, b: 104)), }, ), ] </code></pre> This line allows us to override the default chest with DungeonChest0</code> and its own loot table! For those who are new to the spot system, spots are usually small pre-made models that have specific blocks which we re-interpret using custom indices from MagicaVoxel palette. 0-16 are pre-defined, and 11 stands for the default chest, but you can override those. And you can do that in virtually every situation if you can place a sprite along with SpriteConfig</code>, which includes caves, towns, procedurally generated spots, dungeons, et cetera. At the moment, the MR only enables such functionality and we need balance people and testers to make the world truly alive using this system 🙂 </a> Ground zero, one, and two for the new loot setup </figcaption> </figure> GitLab: !4354</a> Mark my words</h4> They say locals always know the best place in town, but they've been tight-lipped on sharing tips. @zesterer has loosened their tongues enough to at least point out the local landmarks. If we keep playing our cards right, they may yet tell us where to get the best sunflower ice tea. Your browser does not support the video tag. </video> Can't always navigate the skyline at ground level </figcaption> </figure> GitLab: !4750</a> Busy with battles and barter</h4> Rather than see everything in life through a trading window, @souffle has given merchants some clarity in expressing their preoccupations. </a> Trading hits vs trading bits </figcaption> </figure> GitLab: !4814</a> You know a good spot?</h4> What do cleaning products and Veloren have in common? Spot testing is good practice. And even easier now with some polish from @juliancoffee: Oh, and I also extended /spot</code> command to work with all spots (these mini-sites, like gnarling totem). /spot</code> command was originally created by @isse , but worked only for spots defined in .ron</code> files. Most older spots aren't defined in .ron</code> files, so we needed to fix it. Bonus point: now it teleports you 100 blocks above the spot, so get your glider ready and fly! Your browser does not support the video tag. </video> Just dropping by </figcaption> </figure> GitLab: !4836</a> + !4839</a> Big cow evicts old milk</h4> Cheese merchants have been setting up shop in Minotaur's colosseum, and that bull is no fan of dairy degenerates. But he felt trapped in the ring as a mere franchise manager, having butted heads with Myrmopolis™ management before. This behooved the great Minotaur to enlist the representation of @unii, who was well received by corporate. @floppy was dispatched to patch things up, with their testing sidekick @Supa helping to iron out some of the repositioning kinks. Your browser does not support the video tag. </video> Cheese on a platter, not by the player </figcaption> </figure> GitLab: !4783</a> Throwing their weight around</h4> From bovine negotiations to safety inspections, @unii swapped hats to remind us of the gravitational hazards involved in setting entity mass: I've reduced the mass of Frost Gigas's summons (Boreal Warriors), so that they're less vulnerable to collision/fall damage as a result. This mostly impacts the encounters where elevation differences come into play. Your browser does not support the video tag. </video> Gonna need a lot more snow to break that fall </figcaption> </figure> GitLab: !4827</a> More changes:</h4> addressed a TODO fix in hostile npc feeling speech - @souffle - !4813</a></li> damage tweaks to left mouse attacks for sword and axe - @unii - !4806</a></li> buff icons for skills swapped to the respective skill where possible - @Supa - !4821</a></li> window size saving logic was moved - @imbris - !4819</a></li> window saving was disabled if it is zero size in any direction - @isse - !4825</a></li> added detection for stuck airships along with remedial actions - @Tarhun - !4822</a></li> removed old mining tool check for directly lootable sprites - @juliancoffee - !4837</a></li> switched to fluent upstream - @juliancoffee - !4840</a></li> 'PlotKindMeta' used instead of just 'PotKind' for npc directions - @isse - !4848</a></li> small fixes, definitely nothing serious - @isse - !4828</a></li> </ul> Ongoing unmerged work</h3> This Gigas on fire</h4> Now might be the time to refamiliarise yourself with local wildfire response plans. What was dismissed as a drifting haze has become distant but visible flames. The molten menace is preparing to erupt. Let's take a look through the geological record</a> to see where it all began. </a> Plans of attack — by @Gemu </figcaption> </figure> </a> This is no spectator sport — by @Gemu </figcaption> </figure> Your browser does not support the video tag. </video> Roleplaying as a very hot potato — by @do-no-van </figcaption> </figure> Your browser does not support the video tag. </video> ♪ I fell into a burning ring of fire ♪ — by @do-no-van </figcaption> </figure> {{ imgzoom(width=718, height=689, caption="Assembling the ashen arsenal — by @Gemu", src="https://s3.eu-central-2.wasabisys.com/veloren-blog/cdn/247/2024-12-02_Gemu_ashen-warrior.webp", ) }} Your browser does not support the video tag. </video> Today's forecast: rolling heatwaves — by @do-no-van </figcaption> </figure> </a> The streaming hot playtest debut — by @Necti </figcaption> </figure> </a> Fiery fallout — by @And_i </figcaption> </figure> GitLab: !4638</a> Throw ALL the things!</h4> Ballistic bottles and flying flasks were on the radar of @UncomfySilence's prototyping efforts</a> to extend the range of the throwables refactor. But why stop at potions? These hands were made for hurling, so let's get things airborne! Alas, the existing controls and item definitions aren't quite as dextrous for the task at hand. So conversation</a> turned to juggling the dynamics at play: equipping, throwing, consuming, and whacking. From hotbar slots and special inventories, to utility belts and radial menus; there were a lot of ideas in flight. Eventually air traffic control was called in to setup a dedicated airspace within a Request for Comment (RFC)</a>. The lofty goals remain for just about every item to be something you can pickup, throw, and swing around. </a> Don't catch a cold </figcaption> </figure> GitLab: !4846</a> Discussions</h3> Who's next?</h4> Clowns to left of me, jokers to the right - who do I punch first? We know that NPCs aren't the ones to ask; they love to play trivial pursuit in a game of whack-a-mole. But if we took off the blinders and cleared their minds, could we teach these old dogs some new tricks? When @James put this question on the table, he was painting a bulls-eye for brain cannons on himself. It wasn't long before the discussion</a> was firing off on a few trajectories: A threat/aggro index for each target entity could be used to make prioritised decisions. Some fuzzy logic and coarse-grained updates might keep it from thrashing or getting too expensive.</li> Should the personality and saviness of an entity have an influence on how they choose their battles, get into position, or pick their loadout? Perhaps they've a logistical mind to notice and take out players that give buffs and support.</li> Sprinkling in some unpredictability may be helpful to feel like we're fighting beings of awareness, rather than walking algorithms. The experienced among them could even have the agency to mix together their own combat ingredients.</li> Can all this be pulled off in a system that allows for varying depths of complexity? From Gnarlings to Gigas, and solo fighters to team players.</li> </ul> </a> Target acquired </figcaption> </figure> Brewing up a storm</h3> After the ideation concoctions of @Nikophos overflowed the cooking pot and town cauldron, he went for a short stay retreat at a (conveniently vacant) witch hut. Free to steep in the potent, unventilated ambience of basement broths and cauldron fumes, the real distillation could begin. What bubbled up</a> to the surface</a> was an 'essence' based system for crafting potions. </a> Cause and effect — by @Nikophos </figcaption> </figure> </a> The essential ingredients — by @Nikophos </figcaption> </figure> </a> A mixologist's cheat sheet — by @Nikophos </figcaption> </figure> </a> Alchemical alternatives — by @Nikophos + @violetwillow </figcaption> </figure> @violetwillow, the partner in slime, arrived after these brainstorming batches to help infuse fresh thoughts into an octagonal blender concept</a>. Various quantities of ingredients would take you around the segments to create different potions. A rarer cocktail might have a narrow target to hit, while the region for a more common potion might span across several segments. </a> Will it blend? — by @Nikophos </figcaption> </figure> Community showcase</h2> Out goes the tide</h3> Knowing the Sahagin warrior isn't much for words, @unii devised a shell-breaker activity for them to open up to. </iframe> </div> Beware the hidden fees on charges </figcaption> </figure>Doom-loren</h3> @horblegorble drilled down past the lava biomes of their screenshot folders to fire up just the right mood with @souffle's logo design. </a> Is this the future of an unstoppable Gigas? </figcaption> </figure> Mastering the forge</h3> With the right moves and a steady rhythm, who even needs armour? Certainly not @And_i. </iframe> </div> Hot temper meets cool tempo </figcaption> </figure>Picnic at goblet rock</h3> </a> The postcard that started it all — by @Supa </figcaption> </figure> The story began like any other in Veloren. Your standard affair of airships, dungeons, and general gallivanting about. It was when our band of misfits got wind of a unique rock formation that things went off script into some voxelated production of the Motley Crew and the Holy Goblet. Rumours spiralled and reason was lost - it was said that drinking of its snowmelt would let you see the worldgen seed. Whatever the soundness of their minds at this point, the mission was clear. How to climb the darn thing was a bit more clouded. Yet altitude sickness and buffeting winds were just extra spice for the ascent, and a mutual mix of encouragement and slander got the whole party to the top. Now at last atop Goblet Rock, they found fantastic views, outstanding acoustics, and joyous jubilation. But no matter how much snow they ate, the great wisdoms were not granted to them. Perhaps the real treasure was indeed the friends made along the way. After recovering from their over-eager hydration, the gang decided to embark on vampire ventures at the nearby Zaluj Keep. What lay inside were trials of teamwork, much spilled blood, and quite a lot of nonsense. Many shenanigans and one viola later, a very unrelated discovery was made: their coconut cavalry could be converted into holy hand grenades. It was promptly agreed that Zaluj was no Camelot, and the town below of Ochreseaux was where they could get up to rather silly things. Most records of what happened next were turned to ash, and what survived was badly singed. Though much evidence was destroyed, it was no mystery who the chief troublemaker was. Here is the adventure album from @horblegorble. Do you like silly scribbles?</summary> </a> Visitors tolerated </figcaption> </figure> </details> </a> </a> </a> </a> </a> </a> </figure> </a> </figure> </a> </figure> </a> </a> </figure> Your browser does not support the video tag. </video> Dropdown drama </figcaption> </figure> </a> </a> </a> </a> </figure> </a> </figure> Your browser does not support the video tag. </video> Bloodmoon battle </figcaption> </figure> </a> </figure> </a> </a> </figure> </a> </figure> </a> </figure> Your browser does not support the video tag. </video> Snail squadron </figcaption> </figure> </a> </a> </a> </a> </figure> Your browser does not support the video tag. </video> Nefarious Necti </figcaption> </figure> Gigas gladiatoris</h3> A colossal crab pot. Becomes an ice rink. Catching frosty prey. </a> Now playing: The Real Stadium Blues </figcaption> </figure> Your browser does not support the video tag. </video> 🔊 Front row seats at the gig </figcaption> </figure> Screenshots</h2> </a> Vibrant sky, shimmering waters — by @Indragedall </figcaption> </figure> </a> Something special — @Retromaster </figcaption> </figure> </a> A mote of stardust — @horblegorble </figcaption> </figure> </a> Spores under Sporia — by @Supa </figcaption> </figure> </a> Some very buoyant crops — by @isse </figcaption> </figure> </a> Airflow arrangements — @horblegorble </figcaption> </figure> </a> Do these echoes make my voice sound cold? — by @Sam113 </figcaption> </figure> </a> Don't forget to check the forecast — by @Supa </figcaption> </figure> </a> Torrential temples — by @juliancoffee </figcaption> </figure> </a> ♪ I'm flyyying in the rain, oh flyyying in the rain ♪ — by @Sam113 </figcaption> </figure> </a> Under the weather — by @Sam113 </figcaption> </figure> </a> Tolerating strangers vs riding with the squad — by @Crabo + @Supa </figcaption> </figure> </a> Diving for the deepest blacks — by @Muerto </figcaption> </figure> </a> Screaming into the void, staring into the abyss - where do ravines fit in? — by @And_i </figcaption> </figure> </a> Moving on from mushrooms — by @Sam113 </figcaption> </figure> </a> Not so tall now, are we? — by @juliancoffee </figcaption> </figure> </a> Airshippin' around — @horblegorble </figcaption> </figure> </a> The beginnings of a smog problem? — by @Sam113 </figcaption> </figure> </a> Melodies of dawn, ft. The Songbirds — @horblegorble </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </a> @Supa and friends queueing up for their favourite ride. Don't miss the next flight :) </figcaption> </figure> These weeks in Veloren 246 Thu, 17 Apr 2025 00:00:00 +0000 Hold onto your hats for this leg of our journey through time, as we experience the highs and lows of airship travel, race for mushrooms, and step into the mirror-verse. - horblegorble, TWiV Contributor Contributor work</h2> Thanks to everyone who contributed to veloren these last weeks: @isse, @Supa, @Tarhun, @Gemu, @UncomfySilence, @unii, @juliancoffee, @souffle, @JimmyDdotEXE, @xMAC94x, @imbris, @floppy, @DaforLynx, @FERIIXU, @horblegorble, @alerty264, @pat36, @GeekyGami, @hnrq, @Crabo, @fnetx, @NeuralModder, and @MStarK3002. Thanks to the weblate translators who contributed these last weeks: alxr1795, Axag, Benny, Carrotism, celestineprower, Daxik2x, Diamons, Dinariossa, DiXiao, EatherBone, Endoril, evgenkot, fnetX, Furrior, jls, LagerJack, lucius_pilgrim, marcelodemonn, MaxSoniX, ministergoose, muhaaliss, nekoedges, Paw, pivoezhka, Positron832, RuGod, Schmarotzer, tdehtyar, Virtex, and andVladisSlave. Merged work</h3> Eyes on the flightpath</h4> It has been brought to the attention of Airloren management that some of our captains have, at times, been somewhat distractable from their piloting duties. We understand that reports have been made of impulsive steering, anger management issues, and an outsized fear of fireballs. While these claims are likely to be exaggerations of hesitant flyers, this is a good time to remind our passengers of Airloren's total commitment to flight safety. To ensure that any extent of un-captainly conduct remains grounded, we engaged the services of behaviour expert @isse to resolve these matters. Our patrons can rest assured that Airloren remains the safest cross-map transit system in all of Veloren. Any rumours of crashed airships have no documented connection to the Airloren fleet. Your browser does not support the video tag. </video> 🔊 Two very different (alleged) flights </figcaption> </figure> </a> When lofty freedoms met untethered guidance — by (left to right) @Supa, @Froggy, @horblegorble, @Supa </figcaption> </figure> Alongside her consulting services to Airloren, @isse also delivered some updates to the moral and monetary navigation systems of other NPCs: Saving a downed NPC will improve their sentiment towards you, but they won't tell other NPCs about it (perhaps out of embarrassment or bruised honour).</li> New pricing formulae for traveller hiring, where adventurer level</code> goes from zero (greenhorn) to three (experienced): day = 60 * 2 ^ (adventurer level)</code></li> week = 300 * 2 ^ (adventurer level)</code></li> </ul> </li> </ul> GitLab: !4760</a> Sky-bound sprites</h4> Those long airship cruises are now a lot easier on the eyes and bum, with comfy new sprites from @Supa. For the utility-minded amongst you, there's also a helm and rope for all your aeronautical needs. </a> Do you dare to find out what lies under public transport seating? </figcaption> </figure> </a> If the captain is getting weary, be ready to tie them to the wheel </figcaption> </figure> </a> Lantern lighting to get hooked on </figcaption> </figure> GitLab: !4762</a> + !4812</a> Deck the hulls</h4> Pre-dawn light is only just beginning to colour the shapes of the town below. Your scrunched eyes make out the form of some busy-body scurrying about the street as they make an overly enthused start to their day. Perhaps they find a special joy in filling the void of these early morning hours. You do not. But, there are some thing that promise chase of a different joy - a Frost Gigas sighting just outside a city some leagues away. Only a couple of weeks ago this would have meant an even earlier rise, and a relentless pace through all manner of terrain to arrive with some degree of timeliness. So, while cold, your feet are thankful they only have to stand at the docking port of an airship tower. Their gratitude does not hold up against a chilling fog that rolls in, and you shuffle back to the meagre shelter of some stacked crates, peeking over to watch for your ship's arrival. At very long last it comes into view and settles in to dock. You jog a little on the spot to shake off the morning thaw, and head over to jump onto the wing. You begin with the awkward clamber and claw up to the rear deck, followed by a stub of the toe as you try to find a seat in the poor lighting. At least now you can rest and maybe catch a nap, in the comfort of a narrow wooden chair that tilts ever so slightly to the left—wait, isn't this the one you were losing cards in at the tavern last week? Halfway into the flight, the captain yells out a sighting of a cult-ish looking person down below, who was probably-definitely the one that killed their uncle's sister's niece's dog. Your chair goes from slight tilt to forward lurch as the ship pitches down into a nosedive. You do not reach the Frost Gigas fight. Well friends, you can breathe a sigh of relief as this harrowing tale retires into memory with the completed renovations of the entire airship fleet. Their updated design is sporting all kinds of nifty features: Direct wing-to-hull boarding, prototyped by @Tarhun and refined by @Gemu</li> Rear viewing platform to take in all the scenery, courtesy of @Gemu</li> Warm and cozy seats and lights, jointly installed by @Tarhun, @Supa, @isse, and @Gemu</li> Brand new decking to give that bit of character, laid down by @Gemu</li> </ul> To maximise passenger comfort, @Tarhun also made some bespoke cruising speed adjustments to match your most pleasant gliding experiences. </a> Step by step, the sun sets on the old </figcaption> </figure> A spokesperson for Airloren denied rumours that the remodelling of its fleet is part of any re-branding efforts, and is unrelated to recent media reports of captain misconduct. GitLab: !4775</a> + !4794</a> Metallic makeovers</h4> Forging new fashions, the one-man armoury that is @Gemu has pumped the bellows to bring in a complete refresh of the metal lineage of armours. The trend-setting orichalcum set also gets some shiny new embroidery in its cape. So get your head in the game, with helmets now available across the board. And don't worry, this gear can tank the barrage of admiring looks you're sure to get. </a> Heavy and dull, but it can take a punch. </figcaption> </figure> </a> Sturdy and unyielding, across ages of war. </figcaption> </figure> </a> The metal alloy plates provide better protection and comfort. </figcaption> </figure> </a> Ornamental and impenetrable, the metal will never dull. </figcaption> </figure> </a> Forged to preserve life, at the cost of another. </figcaption> </figure> </a> An ancient alloy. Myths remain of heroes who wore this metal. </figcaption> </figure> Lugging around all these voxels was more than an all-the-grocery-bags-at-once scenario. Shipping and handling was sorted out by @UncomfySilence, with @unii providing stat redistributions and @juliancoffee advising on localisation. GitLab: !4765</a> + !4786</a> Mirror, mirror, in the code</h4> A sprite is just implemented as a special kind of block, right? Well, some of them have been yearning to live outside the box. In a case of breaking up to break free, woodland town furnishings went under the knife of surgeon @Supa to prepare for a more composable future. You may have seen the corner cases of this operation while the stitches were assembled to bring them back together. Here are @isse's reflections on developing the mirrored modularity for that recovery: In preparation for more tile-able sprites I added an attribute for sprites to be able to mirror them. At first I had an issue with the sprites turning inside out when mirrored. </a> </figure> But got it working with some clever shader code</a>. </a> Clever girl </figcaption> </figure> If you played the game this last month you might've noticed that chairs were rotated wrong, beds and tables were just one corner... That's because we updated most of the town sprites to be tile-able, but hadn't updated the code yet. Which was the next thing I started working on, expanding our system to generate composed sprites from when I added the lanterns earlier. I added some methods for placing both one, and two dimensional tile-able sprites. Examples of one dimensional are benches, wardrobes and bookshelves. And two dimensional are tables and beds. </a> </figure> I got some interesting beds while coding this. </a> </figure> But got it working eventually. So try our new beds with a "roommate"! </a> </figure> GitLab: !4758</a> + !4768</a> Bed and bookfest</h4> Books and bodies can rest easy with new furniture models from @unii. In light of the sprite mirroring changes, they have all been sliced and diced into tiled pieces. See if you can spot the seams. </a> Hard, soft, wood, stone. Could start counting choices to fall asleep </figcaption> </figure> </a> Bookshelves: where they go to sleep between being read </figcaption> </figure> GitLab: !4764</a> Instrumentally, my dear Watson</h4> New sounds of triumph have been filling the chambers of demoted bosses, and joining in the concerts and parades of victory back in town. Meet the latest additions to your boastful ensemble: Starlight Conch</a>: a honking great idea from @floppy, with @Gemu's model touch ups</li> Viola Pizzicato</a>: hand plucked by @DaforLynx, modelled by @floppy and recoloured for a blood-red vibe by @Supa</li> Timbrel of Chaos</a>: what began as a tambourine by @floppy, @Gemu transformed into the Mindflayer's instrument of pain</li> Rhythmo</a>: keys, lights, and banger boops by @floppy - do you reckon it could run DOOM?</li> </ul> Your browser does not support the video tag. </video> 🔊 Beat-ing bosses </figcaption> </figure> GitLab: !4772</a> + !4816</a> Paving the way</h4> @isse had always heard plenty of advice about watching where you step, but nothing on what to do when you don't like what you see. So she took her own ideas to the town planning hall for a much prettier outcome. Plazas and paths play by the new rules in all towns, though mesa/cliff ones are skipped in these photos for brevity. </a> Some will miss the impromptu mud baths on a rainy day </figcaption> </figure> </a> Much easier to sweep away the latest sandstorm </figcaption> </figure> </a> If the earth is good enough for building, it's good enough for walking </figcaption> </figure> GitLab: !4749</a> Change what you can control</h4> Though Veloren has been developed with keyboard and mouse front of mind for the most part, we hold no grudge against our gamepad compatriots. @JimmyDdotEXE opens that door a little further by making their controls easier to navigate. Your browser does not support the video tag. </video> No illusions of control here </figcaption> </figure> GitLab: !4436</a> You asked, they answered</h4> Cracking into the archives, @xMAC94x went digging for questions asked of the Tutorial bot on the official server in days gone by. These forgotten lessons have been passed on to a new generation of 'proper' NPCs. See if you can catch them in a chatty mood. </a> Wisdoms of the crowd </figcaption> </figure> GitLab: !4771</a> Going places</h4> Ever catch the travel bug, but the thought of all that planning just makes you feel sick? Don't worry, @souffle has got a solution for your impulsive fancies: There now exists a /goto_rand</code> command available to admins to teleport to a random position. Your browser does not support the video tag. </video> Mind the terrain </figcaption> </figure> GitLab: !4698</a> Getting the message</h4> Say no to character screen FOMO, with a message queue implemented by @imbris that will catch those previously fugitive chat entries. </a> Finishing each other's haiku </figcaption> </figure> This was created as one part of the arsenal deployed in a manhunt for an elusive /tell</code> notification that was never quite sure who wanted to talk to who. A search party of additional logging eventually tracked down the filtering accomplices, who gave up the notification to be humanely 'removed' from the codebase. Whispers of fear have become audible in the open issue list as marshal @imbris counts up yet another successful pursuit. GitLab: !4777</a> Keeping the flames in check</h4> Any experienced Veloren player will know that the dramatic effect power (secret stat) of a shockwave is all in the timing, so @Supa was surprised to see that two of the heavy hitters in the Dwarven Mines were jumping the gun. After taking them back through drama class lessons, they were quick to catch on (but not too quick now). Your browser does not support the video tag. </video> Before (left) and after (right) for Flamekeeper (top) and Forgemaster (bottom) </figcaption> </figure> GitLab: !4805</a> Zoomies, chill out</h4> @FERIIXU arrived with their first MR✨ to fix an issue</a> raised in mid-January by @imbris. While either on-screen buttons or the +</code> and -</code> keys do the job of mini-map zooming, the latter would show up with much more enthusiasm to the job. Your browser does not support the video tag. </video> Well behaved click buttons, and their (previously) cheeky keyboard cousins </figcaption> </figure> The behaviours of both methods are now aligned with the more well-behaved approach, along with clamping guard rails. Improved logging and some comments for future developers also leave behind some tasty breadcrumbs. GitLab: !4761</a> More changes:</h4> orientation and movement modifiers added to each stage of melee abilities, for future balancing - @srpapinha - !4753</a></li> readability improvements were (carefully) made to physics code - @xMAC94x - !4763</a></li> sword's bloody gash ability no longer gives energy regen - @unii - !4745</a></li> soldier crabs scuttled out from under the sahagin dungeon floor - @horblegorble - !4729</a></li> fixed game crash caused by slicing multi-byte characters in non-English languages - @alerty264 - !4755</a>✨</li> broken matrix user count badge removed from readme - @JimmyDdotEXE - !4623</a></li> typo fix in economy testing code - @pat36 + @xMAC94x - !4766</a>✨</li> lints can now be configured across the entire cargo workspace - @imbris - !4769</a></li> credits and licensing added for @GeekyGami's music tracks - !4767</a></li> removed old toggle_keybinding_mode</code> from voxygen - @hnrq - !4773</a>✨</li> large horn added to NPC trading stocks - @Crabo - !4754</a></li> improvements for new inventory methods - @imbris - !4757</a></li> fixed "Uid was not mapped to any entity" client error; included airships in rtsim ID map - @imbris - !4776</a></li> added find_unused</code> binary to check for unusable loot tables, loadouts, items, or recipes - @isse - !4779</a></li> applied most compatibility lints in preparation for moving to rust 2024 edition - @imbris - !4770</a></li> fixed up syntax changes that could have caused server crash, with new tests added - @isse - !4785</a></li> various improvements to the sever event system - @imbris - !4782</a></li> de-aliased a conflict in NPC translations - @fnetx - !4788</a></li> fix for Cargo.lock</code> - @NeuralModder - !4800</a></li> fixed hot reloading warnings caused by rust 2024 edition changes - @isse - !4791</a></li> added check for git LFS pointers in CI job to resolve recurring issue - @MStarK3002 + @imbris - !4797</a></li> window size update limited to window resize event - @isse - !4810</a></li> well-fed bear config moved: common.entity.wild.peaceful.bear</code> -> common.entity.spot.bear</code> - @souffle - !4809</a></li> wolves got faster and tougher - @Supa - !4804</a></li> new message-of-the-day variations for singleplayer worlds - @horblegorble - !4815</a></li> </ul> Ongoing unmerged work</h3> Fresh shoots on the bow skill tree</h4> Spring is beginning to arrive for the bow as its skill tree starts to leaf out in full colour. The new season brings on-the-fly arrow modifications and a variety of formations to draw from. You can look back at where the discussion started</a>, then checkout the Gitlab bow</code> branch</a> to see what @Sam has honed in on. We look forward to the final fletching. Your browser does not support the video tag. </video> Bow and tell with neighbourhood 'volunteers' </figcaption> </figure> </a> Notching up a mood board </figcaption> </figure> This is the fourth of the weapon skill tree reworks, and the first of the ranged weapons. Discussions</h2> Translation migration</h3> Winds of a different kind of season change have been blowing across the Discord plains as of late. Getting ahead of the weather, the translation working group has moved its operations over to Veloren's Zulip server</a>, specifically the #wg-translation</code></a> channel. If you're new in town, feel free to drop into this #New contributors</code></a> thread first. And for folks hesitant to try out Zulip, the #new-contributors</code></a> channel of our discord is still a good runway for your translation take-off. Airship evolutions</h3> A new RFC has docked at our Gitlab</a>, ready to load up on your well-considered feedback. @Tarhun lays out the charts for all things airships: Docking infrastructure and local destination maps</li> Destination and route distributions, to meet the needs of a public transportation network</li> Finding the right fleet numbers, including multiple ships on extra long routes</li> Resolving matters of turbulence and friction to make it safe to move about in-flight</li> </ul> </a> Notable offsets relative to the captain </figcaption> </figure> As mentioned in an earlier section, progress has already been made on matters of boarding and airspeed. You can also join in the discussion</a> on Discord, which has so far covered air resistance and player vs airship interpolation. Locking on to what matters</h3> @GeekyGami prompted a discussion</a> on having lock-on mechanics, which brought in @Sam to spell out</a> some of the core 'tenets' of combat in Veloren. Here's the short and sweet: Preparation is key: scouting the layout, enemies, and hazards of an area, then picking the right gear and strategy to go with</li> Players are not special from other humanoid NPCs: capabilities, strengths, and weakness are shared by all</li> The power gap between early-game and 'end-game' characters is not very large</li> Most combat choices have some inherent trade-offs: a benefit has a downside, or takes from a fixed budget</li> </ul> Community showcase</h2> Concept art</h3> First-hand accounts of various explorations in voxel space. A mix of things intended for use in-game, and more experimental ideations. </a> Not a child-friendly sand pit — by @Gemu </figcaption> </figure> </a> A high-res iron chakram — by @SrKStarK </figcaption> </figure> </a> Arboreal artistry — by @Gemu </figcaption> </figure> </a> Of brew and bottle — by @unii </figcaption> </figure> Carpet challenge</h3> Calling all rugged adventures! Sheath your sword, grab a cuppa, and take a seat at the voxel loom - @Supa has an artistic call to arms for you to meet. Flex your skills of symmetry by weaving together colours for a tiling carpet design. You can download this .vox</code> file</a> as a reference, but don't feel it has to constrain your aesthetic ambitions. Here is the display room so far: </a> Target practice for a sleepy head — by @Sam113 </figcaption> </figure> </a> New crosshair designs perhaps? — by @Joe_Cool </figcaption> </figure> </a> Fractal form over function — by @Jachobi ✨ </figcaption> </figure> Having some fun</h3> </a> Doom and gloom — by @souffle </figcaption> </figure> </a> The latest in legoom fashions — by @unii </figcaption> </figure> </a> Intellectual property infringement, or baby Danari in a mech suit? — by @Dan113 </figcaption> </figure> Events</h3> Pre-planned events hosted on the official server (server.veloren.net</code>). You can keep an eye out for future announcements on the discord channel</a>. Shroom Cup 2</h4> </a> Mush! Mush! — by @Hrom </figcaption> </figure> Spores of racing fever were in the air as the day warmed up for the 2nd Shroom Cup. A downhill slope from Primore took drivers through treacherous mesa terrain before levelling out to a stretch of undulating dunes to reach the finish line at the Bridge of Blodelic. Competitive spirits were fired up with passengers free to use any weapon against opposing vehicles (or terrain). To keep things from getting into too much truffle, the races were officiated by @Gemu as the overhead umpire, who was piloting the aptly named 'Flying Dutchman'. </a> Morning shadows kept shifting the starting line — @horblegorble </figcaption> </figure> </a> In the heat of the moment — by @Gemu </figcaption> </figure> </a> View from the referee's sky cam — by @Gemu </figcaption> </figure> </a> Now that's pile driving — by @Gemu </figcaption> </figure> </a> The much calmer, post-racing lineup — by @Gemu </figcaption> </figure> To let off pre-sprint steam, some drivers took turns behind the wheel of a 'safety' cart, putting its all-terrain features to the test across desert dunes and mesa cliffs. A few brave riders clung on behind in the 'very-much-not-safety' trailer. The many twists and twangs of the tether eventually came to a rest at the foot of what seemed to be a regular old savannah tree. But history will remember it well as the birthplace of Veloren's space program. Some have raised doubts about the capabilities of a supercharged trailer-trampoline to achieve orbital velocity, while proponents claim that further cheese and player testing will prove out the technology. </a> Bounce for the stars! — @horblegorble </figcaption> </figure> Screenshots</h2> </a> Before the shroom cup, Primore's peaceful panorama — by @Iskava </figcaption> </figure> </a> No time to chill out — by @Gemu </figcaption> </figure> </a> Almost a whole tree — @horblegorble </figcaption> </figure> </a> On the wing to Waoubi — by @EatherBone </figcaption> </figure> </a> Looking in on tavern tales — @horblegorble </figcaption> </figure> </a> The night lines of Venton — by @souffle </figcaption> </figure> </a> Some honest branding — @horblegorble </figcaption> </figure> </a> Fall before the throne — by @Alley_Oop </figcaption> </figure> </a> Sun-rise living — by @Supa </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </a> A very well fed @Crabo. Stay hungry for the next one :) </figcaption> </figure> These weeks in Veloren 245 Thu, 03 Apr 2025 00:00:00 +0000 The time warp continues, as we look back on the arrival of some of the most anticipated updates to Veloren. - horblegorble, TWiV Contributor Contributor work</h2> Thanks to everyone who contributed to veloren these last weeks: @steanne, @DaforLynx, @NeuralModder, @phoenix13032005, @GeekyGami, @unii, @UncomfySilence, @do-no-van, @horblegorble, @Tarhun, @zesterer, @xMAC94x, @isse, @floppy, @Synis, and @Supa. Merged work</h3> Airships are go for launch!</h4> Having taken off back in December of last year, @Tarhun's uplifting changes finally make their landing: The age of Airship travel has arrived! For more than a few weeks, I've been working, diligently but mostly slowly due to inexperience with the game design and the language, to automate Airship movement and travel between Sites with docks. Thanks to @zesterer for guidance and the many code reviews. Thanks to @isse for assistance and to everyone else that offered encouragement. </a> </figure> Airships now travel a network of routes between dock sites. Every Site with an Airship Dock now has two to four routes connected to the same number of other sites. Airships stop at the dock for about 90 seconds, then lift off and fly to the destination site while following the terrain. There's still work to be done on smoothing out the ride, so it's best for now to jump on and take a seat, then zoom out and look around. Your browser does not support the video tag. </video> 🔊 ⏩ The world suddenly feels a whole lot smaller. Music by @Zakru </figcaption> </figure> To not spoil the fun of exploring the Airship route network, I'll just say that the destination site from any particular docking position is always the same. The rest is up to you! GitLab: !4671</a> -> !4709</a> + !4738</a> Now we're talking</h4> @zesterer gives NPCs the gift of the gab, unlocking big ambitions down the road: For the past few weeks I've been slowly working on a much-awaited feature: two-way dialogue! It's in the early stages, but you can already use it to ask NPCs how they feel about you, who they are, where you are, and even temporarily hiring NPCs (if you're playing singleplayer, this might be useful!). Thanks to @Pfau for his work on the UI: although it's still a work in progress, it's already looking great. </a> A name destined to wear the chef hat </figcaption> </figure> Dialogue is passed all the way through to rtsim, allowing for dialogue sequences as part of long-running behaviours. The most exciting part, for me, is that this feature unblocks work on a lot of future things such as: Questing</li> Factions & politics</li> Story-telling and exposition</li> NPC hiring and groups</li> </ul> Your browser does not support the video tag. </video> 🔊 Talk is cheap, so keep some coins on hand to be persuasive </figcaption> </figure> GitLab: !4686</a> + !4739</a> + !4747</a> Towns and dungeons play musical chairs</h4> The tunes are a changing, with three new soundtrack additions and a reshuffle of dungeon music. First up is a delicate dance through snowland choreographed by @phoenix13032005. </a> </figure> Your browser does not support the audio element. </audio> 🔊 Where Frost Played — @phoenix13032005 </figcaption> </figure> Striking a more jubilant tone, @phoenix13032005 also gives fresh energy to the sunshine of coastal and savannah towns. </a> </figure> Your browser does not support the audio element. </audio> 🔊 Fill The Mugs — @phoenix13032005 </figcaption> </figure> And for the bloodthirsty adventurer, a much more sinister vibe from @GeekyGami will echo through the halls of vampire castles. </a> </figure> Your browser does not support the audio element. </audio> 🔊 Still Heart's Coffin — @GeekyGami </figcaption> </figure> @phoenix13032005 also played umpire for a dungeon themed round of musical chairs. When the beat stopped, here's where the sounds landed: Dungeon </th> Tracks </th> </tr> </thead> Gnarling Fort</td> Jungle Ambient</td> The Undergrowth</td> </tr> Adlet Stronghold</td> Mysty Temple</td> A Heart's Ice-Cold Protection</td> </tr> Sahagin Island</td> Sacred Temple</td> Thrumming Waters</td> </tr> Haniwa Catacombs</td> Cobbled Halls</td> </tr> Vampire Castle</td> Vast Onslaught</td> Still Heart's Coffin</td> </tr> Sea Chapel</td> Mysty Temple</td> Ruination</td> </tr> Myrmidon Dungeon</td> Sacred Temple</td> Vast Onslaught</td> </tr> Cultist Dungeon</td> Sacred Temple</td> Ruination</td> </tr> Terracotta Ruins</td> Jungle Ambient</td> </tr> Dwarven Mines</td> Dank Dungeon</td> Cobbled Halls</td> </tr> </tbody> </table> GitLab: !4712</a> Bouncing off the walls</h4> Obstacle course architects will have to rethink their designs in light of new climbing mechanics from @Synis. Make sure your climbing boots and chalk are in good nick. Your browser does not support the video tag. </video> Parkour Pete gives us some demos of new techniques </figcaption> </figure> GitLab: !4734</a> Towning around</h4> That bumpy, unlit road in town now gives a smooth, lantern adorned ride all the way to the remodelled tavern. Courtesy of @isse: </a> </figure> Lately I've been working a bit on our towns, both just generation wise, and adding sprites (blocks with extra details, beds, chairs etc.) from @Supa and @unii . With these changes we've also started using a lot more "tiled" sprites. Which are sprites that take up many blocks to have better colliders, and we can do some composition with the different tiles without needing to create voxel models for each variation. The first example of these were the lantern sprites. These are built from three parts, a base, a top and the lantern. And if you look closely you can see where the separation is because the light level is different if the lantern is lit. </a> Example of how it can be composed, with some issues still in the model </figcaption> </figure> Also added a basement to tavern buildings and changed their generation a bit. </a> </figure> Our roads between towns didn't play well with our site rendering code, so I updated that. </a> Previous (left) and new (right) </figcaption> </figure> In earlier versions we've had some issues with plazas and roads ending up underwater, and houses being a whole lot higher up. This is because when placing the house we use an approximated altitude that's based on a per chunk altitude value. And when placing the plaza we used a method to replace the top most blocks of the loaded terrain. I changed plazas and roads to instead behave more like other plots (building generators). And if any corner of the plaza would end up under water I instead place a wood platform at an appropriate altitude. </a> </figure> GitLab: !4748</a> Hammer tweaks that haft to happen</h4> @UncomfySilence has brought the balance hammer down across the skill tree, with changes to damage, timing, energy, and more. If you've been getting into the swing of things, you may need to switch up your tactics. </a> An artist rendition of the balancing process </figcaption> </figure> GitLab: !4721</a> Holding on to let go</h4> While the misadventurous among us have appreciated the second chance of recovering from a downed state, there were an unfortunate few that 'jumped' to an early conclusion. But fret not, for @isse has heard your feedback, and she is giving our trigger fingers some breathing room. Your browser does not support the video tag. </video> How much do you really miss your campfire? </figcaption> </figure> GitLab: !4759</a> More or less</h4> For those that can't wait till New Years for a good countdown, @do-no-van gives you the chance to experience the suspense of a boss fight in full. A new checkbox toggles the abbreviation of health points to the thousands. Have to wonder if we'll get imperial values some day... </a> What a unit </figcaption> </figure> GitLab: !4736</a> Upgrading Kira</h4> Marking another notch on the dependency doorway, @DaforLynx and @NeuralModder help Kira grow up: We upgraded the version of Kira (the new audio framework) to 0.10. This may help with performance in some cases, thanks to newly using sample buffers, but let us know if you experience performance problems that were not present in the past month. GitLab: !4727</a> + !4740</a> Paint the town in sprites</h4> @Supa has been crafting up some more additions to our palette of town sprites. </a> Look into the mirror to complete the headshot hat-trick </figcaption> </figure> </a> Small, medium, and large. The lesser known Three Basketeers </figcaption> </figure> </a> It was an open and shut chest </figcaption> </figure> </a> Plenty of seats at the table </figcaption> </figure> </a> They can all hold water, one just not as long </figcaption> </figure> </a> @Supa stays warm by the bonfire </figcaption> </figure> GitLab: !4751</a> Digging up the past</h4> @Synis has completed the excavation of code for the old cave system. To remember times gone by, we go on a nostalgic delve through a cave in the old eastern forests, known as 'Miist Tunnel'. </a> </a> </a> </a> </a> </a> In and out, with a whole lotta mobs in-between </figcaption> </figure> Your browser does not support the video tag. </video> 🔊 Green is good </figcaption> </figure> Your browser does not support the video tag. </video> 🔊 Dances with giants </figcaption> </figure> The adventurous reader can explore the old world at commit 61573a7800</code>. GitLab: !4742</a> More changes:</h4> capitalised sentence beginning for directional hint from NPC - @steanne - !4724</a></li> minor potion, velorite fragment, plain cloth glider, and black lantern all moved to default recipes - @unii - !4720</a></li> plugging up a drip in the security pipeline - @NeuralModder - !4726</a></li> stun resilience/resistance info in UI updated to use entity stats - @do-no-van - !4725</a></li> terracotta statue's blast attack made more manageable - @horblegorble - !4728</a></li> poise bar is now shown by default - @horblegorble - !4732</a></li> bloodmoon relic rotation fixed to face forward - @horblegorble - !4733</a></li> purple geode returns to the loot tables, now from basilisks - @horblegorble - !4730</a></li> toolchain update (happy valentine's day edition) - @xMAC94x - !4737</a></li> a series of fixes for airship dock signs - @isse + @floppy + @horblegorble - !4663</a></li> matching up pub const DIAGONALS</code> ordering with similar enums - @horblegorble - !4741</a></li> subtraction overflow fixed in network code - @xMAC94x - !4746</a></li> velorite and velorite fragment models updated to match multi-hit mining - @Supa + @horblegorble - !4735</a></li> standalone code for researching better movement algorithms - @xMAC94x - !4756</a></li> </ul> Ongoing unmerged work</h3> (Blood)steeling a look at armour models</h4> The crackling whoosh of a bellow-fed flame, heavy clangs of a striking hammer, and what witnesses swear were intermittent screams of agony. These were the sounds of @Gemu's voxel armoury as he forged the first of a new set of metal armours. </a> Forged to preserve life, at the cost of another. </figcaption> </figure> Discussions</h2> Fire it up!</h3> Time to rekindle those brainstorming circuits - @Sam has put out the call to share your burning desires: With bow soon approaching completion, we can begin thinking about the fire staff rework. Fire staffs are intended to be themed around fire (obviously), heat, smoke, and other related things. It's primary niche will be a weapon with medium range that has high burst potential, though potentially with some consequences from extended use. The rework of fire staff will also come with the introduction of a temperature system, where higher temperatures (and lower temperatures, though fire staff won't help you get there) will have various effects on you. Suggestions for fire staff abilities can be made in the form here</a>: </a> </figure> Once your own fire is burning, you can check out some of the discussion so far</a>. Quest objective: speak to the manager</h3> @zesterer and @Pfau have been mulling over</a> the concept of an 'architect' that handles the surfacing, progression, and completion of quests. Rather than a classic mix of static roles and objectives, these quests would emerge from ongoing dynamics between entities and their alliances in the game world. This would build upon the RTSim (real-time simulation) system's ability to handle a lot of moving pieces, to being able to move the big picture as well. The devil will be in the details of course, particularly with avoiding loose ends being scattered about. As done before, many ideas here are gratefully borrowed from work done on Dwarf Fortress. </iframe> </div> A casual talk on emergent narrative dynamics in a game world </figcaption> </figure>It's all in the grip</h3> Jack of all trades. Counter attack specialist. Mobility maximiser. What do you see as the role of the versatile sword in Veloren's combat? @UncomfySilence spelled out</a> some of their thoughts in a discussion with @Gemu, wondering how to have all the ingredients of its skill tree work better together. Complicating factors included dual-wielding, finding the right place alongside axe and hammer, and the differences between PvP and PvE. An important point was made that the sword was first of the melee weapons to be reworked, during a time of multiple significant changes to rolling mechanics. Community showcase</h2> Veloren's first public transport map</h3> Taking @Tarhun up on their invitation, @Froggy ferried himself all over the world to map out the new airship routes on the official server. To save himself some jet lag, a few of the routes were taken by other players that phoned in their findings. Getting the route colours to behave themselves was another matter. </a> Now we just need a trip planner app — by @Froggy </figcaption> </figure> The Veloren Daily</h3> The printing press winds down as @phoenix13032005 sends out the last issue of The Veloren Daily for this season. We wish them all the best on their journeys, and hope to read more headlines about their own endeavours in the future. </a> A farewell concert and underground marvels </figcaption> </figure> There's Waldo (Merchant)</h3> As promised, here we deliver the solutions to last issue's</a> search party. If you didn't find all these characters, feel free to have another crack at it before uncovering them. Don't forget about Waldo the merchant. Click to see original puzzles</summary> You can click on each image to view it in full. </a> Savannah swim day </figcaption> </figure> </a> Desert denizens </figcaption> </figure> </details> </a> Waldo reunion </figcaption> </figure> Click to reveal solutions for Savannah Swim Day</summary> You can click on the image to view it in full. </a> Savannah swim day secrets surfaced </figcaption> </figure> </details> Click to reveal solutions for Desert Denizens</summary> You can click on the image to view it in full. </a> Desert denizens discovered </figcaption> </figure> </details> Concept art</h3> First-hand accounts of various explorations in voxel space. A mix of things intended for use in-game, and more experimental ideations. </a> Lovely lily pads in bloom, grown by @Supa </figcaption> </figure> </a> A few species of ideas were planted by @unii: (left to right) | Rafflesia | Passiflora | Jungle reeds | Modular moss </figcaption> </figure> </a> Orange leafy plants from @FBI873, to sprout in the jungle sprite overhaul </figcaption> </figure> </a> @Sam113 got into the woodworks, with a new bookcase and updated shading for hanging signs </figcaption> </figure> </a> Mahjong fans @Hrom and @unii prepare a sales pitch for tavern owners </figcaption> </figure> </a> Veloren's armoury didn't have quite the right aesthetic, so @unii maid his own </figcaption> </figure> Screenshots</h2> </a> Not that kind of red light district — by @Necti </figcaption> </figure> </a> Myrmidons amidst mist — by @unii </figcaption> </figure> </a> A 'scuba stag' waits for an unsuspecting traveller — @horblegorble </figcaption> </figure> </a> The many colours of erosion — by @James </figcaption> </figure> </a> Playing it cool — by @Alley_Oop </figcaption> </figure> </a> A rowdy upstairs housemate — by @unii </figcaption> </figure> </a> The chosen goblin — @horblegorble </figcaption> </figure> </a> Roleplaying as a crystal — by @FBI873 </figcaption> </figure> </a> They always were inclined towards farming — by @DaforLynx </figcaption> </figure> </a> Yes, we have an opening for you — by @isse </figcaption> </figure> </a> They say holding grudges will bring you down — by @Sam113 </figcaption> </figure> </a> Brain freeze — by @Alley_Oop </figcaption> </figure> </a> Now this is a captain with an upwards attitude — by @isse </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </a> @Gemu came across a very lost legoom. Maybe they'll find us in the next devblog :) </figcaption> </figure> These weeks in Veloren 244 Thu, 27 Mar 2025 00:00:00 +0000 In this second flashback episode of TWiV, we look at combat's rolling remixes, shiny new goodies, plus some puzzles and newspapers. - horblegorble, TWiV Contributor Contributor work</h2> Thanks to everyone who contributed to veloren these last weeks: @isse, @crab, @NeuralModder, @xMAC94x, @Gemu, @Necti, @Supa, @unii, @do-no-van, @floppy, @UncomfySilence, @phoenix13032005, @fnetx, @Imbris, @souffle, @Crabo, @srpapinha, @Nikophos, and @Hrom. Thanks to the weblate contributors who contributed these last weeks: alextecplayz, almostabsent, Axag, bov, brucekomike, Diamons, Endoril, fnetX, iming_forge, ioutora, Janez, jls, K0RR, and raresmac. Merged work</h3> Roll cancelling gets un-cancelled</h4> From the mind of @Necti and the coding hands of @do-no-van, roll cancelling makes a comeback to your combat repertoire. Before this change, the remainder of an attack's duration was added to the warmup section of a roll, leaving you 'stalled' and vulnerable. Now, rolling during an attack will almost immediately put you into the roll, but with a much higher energy cost. To signal this difference during gameplay, @floppy cooked up a new sound effect. Thanks as well to those that tested and gave feedback to get this changed tuned in. Your browser does not support the video tag. </video> 🔊 Stalled rolls with regular sound effect </figcaption> </figure> Your browser does not support the video tag. </video> 🔊 Attack-cancelling rolls with new sound effect </figcaption> </figure> GitLab: !4683</a> Bloodmoon lighting, and smoke on the horizon</h4> Sink your fangs into a new lantern and get that blood-red glow. See your local Bloodmoon Heiress for details</a>, but don't expect a warranty for belt stains. </a> Voxel models and @Necti modelled voxels </figcaption> </figure> Embers carried on the wind herald the approach of the Fire Gigas to Veloren. In preparation, @Gemu brings us next season's smoking hot fashion. </a> Start practicing your smouldering gaze. </figcaption> </figure> Frost Gigas and Fire Gigas. Polaris and Crux. Veloren's future is full of symmetries. </a> When will the Fire Gigas emerge from its molten slumber? </figcaption> </figure> There's a few pieces in the puzzle of adding new items like this into the game, and it often takes a team to bring it all together: voxel modelling - @Gemu</li> armour stats - @Necti, with input from @UncomfySilence and @unii</li> in-game positioning - @Necti</li> flavour texts - @UncomfySilence</li> bookkeeping - @Necti + @floppy</li> </ul> GitLab: !4705</a> + !4707</a> Sheeny shiny ingots</h4> @Supa has been throwing the best kind of shade at ingot models to give them a polished look: Ingot sprites have been redone to reflect subtle colours, and now look much cleaner up-close. Next step is to use them as decoration or as lootables in the world. Your browser does not support the video tag. </video> 🗘 Before and after, before and after, yada yada </figcaption> </figure> While jealous at first, wooden logs also got a share of the spotlight. GitLab: !4702</a> Training for dummies</h4> After deciding that it was tired of its old build, the training dummy entered into the tutelage of @do-no-van to pursue a re-spec into vitality. Despite losing some of its debuff immunities, it now feels ready to face the world head on, with an orientation fix to its voxel model. </a> Two very different 'face-first' mugshots </figcaption> </figure> GitLab: !4703</a> Striking the balance</h4> Cleavers and cripplers may need to adjust their footing with some balancing changes: slight damage reduction for sword M1 and axe cleave - @unii - !4701</a> + !4711</a></li> halved duration for crippling debuff - @srpapinha - !4704</a></li> significantly reduced multipliers for crippling debuffs - @do-no-van - !4722</a></li> </ul> Woodn't you know it? More sprites!</h4> Loading the barrels of future town updates, @Supa brushed up on his carpentry skills to fashion a suite of workshop sprites. But don't sweat getting them all around town - @unii rolled in with a hand-drawn cart. We thank the trees that made all this possible. </a> You did your safety induction, right? </figcaption> </figure> </a> We all love a good box. But what if, they had wheels? </figcaption> </figure> </a> For all your stacking, barrelling, and bellowing needs </figcaption> </figure> Lit up by some wikipedia inspiration</a>, @Supa also assembled a couple of modular street lanterns. </a> Don't lose the instruction manual </figcaption> </figure> GitLab: !4718</a> Sprite asset semi-automator spreadsheet</h4> While building, colouring, and shading models is most of the process, Veloren doesn't wander around finding wild voxels to gobble up. To get them into the game, they need to be plated up with some configuration garnishes. Thankfully, chef @Supa is willing to share some of his cooking tips with us, in the form of a semi-automator spreadsheet that guides you through adding a sprite model into the game files. You can download it as a .xlsx</a> or .ods</a> file. </a> Time to cook up your own spread of tasty sprites! </figcaption> </figure> A different kind of compiling</h4> The ambitious ideas and broad contributor base of Veloren mean that its future is chock-a-block full of things to juggle. It can be a lot to keep all in mind, so why not write some of it down? @Gemu and @phoenix13032005 have done the work of compiling todo lists to help coordinate efforts on models and sounds. </a> Sprite modelling for a jungle biome overhaul, compiled by @Gemu </figcaption> </figure> </a> Various sound effects for categorised entities, compiled by @phoenix13032005 </figcaption> </figure> More changes:</h4> rust toolchain update - @isse + @crab !4694</a></li> update continuous integration cache image - @crab - !4700</a></li> dependency updates - @NeuralModder - !4699</a></li> cargo package updates - @xMAC94x - !4708</a></li> hotfix for release build - @NeuralModder - !4710</a></li> parsed and localised text is converted to ascii to fix a parsing failure - @imbris - !4714</a></li> kelpies now swim faster in water - @souffle - !4717</a></li> straw hats are now sellable and stocked by merchants - @unii - !4716</a></li> dwarven cheese added to greedy miner loot table - @Crabo - !4719</a></li> </ul> Ongoing unmerged work</h3> Beware the bonk</h4> On reflection, perhaps it does seem odd that a few voxels of steel can negate the impact of a giant's crushing blow. To bring some extra challenge to your David vs Goliath combat, @do-no-van is experimenting with unblockable attacks. Your browser does not support the video tag. </video> You're gonna need a bigger shield </figcaption> </figure> GitLab: !4706</a> Getting comfortable</h4> After a long adventure of beast hunts and dungeon raids, your weary legs finally bring you back to town. They carry you through the doors of 'The Cheeky Legoom', where all your senses are welcomed into its cozy atmosphere. The soft crackle of a simmering fire, dancing shadows of candlelight, and boisterous conversations carried in the air - all under the gaze of the courteous but discerning barkeep. @Supa sets the scene for a space to socialise and recharge, with a tavern's worth of sprites in the works. </a> </figure> </a> </figure> Discussions</h2> You've thread all this before</h3> Sailing through the brainstorms that happen across our discord channels can put ones navigation skills to the test, so it's always appreciated when things get brought into calmer waters. @Nikophos collated various potion ideas</a>✨, ranging form buoyancy and bottle wind, to homesickness and gender change. Food and alchemy were on @Supa's mind, as he placed some old ideas into new threads</a>: Food: Should there be a hunger system?</a></li> Food: What stats should food give?</a></li> Food: How to add more nuance to cooking?</a></li> Food: What food-related items should be added/adjusted?</a></li> Alchemy: What stats should potions give?</a></li> Alchemy: How to add nuance to potion-making?</a></li> Alchemy: Should the potion vial return to the inventory after use?</a></li> </ul> Playing your part</h3> The players. They jostle, quarrel, and bicker. A shared consternation of unmet contestation. Looking for a banner to rally them. Yearning for more than /join_faction</code>. It's time to take matters into their own hands. Kicked off by @Hrom, there was a wide ranging discussion on faction role-playing as a gameplay element layered on top of Veloren's out-of-the-box experience. Ideas included factional quests amongst players and PvP skirmishes at towns to determine territory control, all overseen by guilds with leaders, treasurers, and regular members. A summary of the proposed ideas was written up</a> by @phoenix13032005. </a> Thinking of a world divided — by @Hrom </figcaption> </figure> Although the war room deliberations didn't arrive at a concrete plan of attack, there's plenty of material up on the drawing board to revisit another time. Community showcase</h2> Where's Waldo, Veloren edition</h3> The famous puzzle book makes an unlicensed expansion into the world of Veloren, with two sunny scenes each hiding Waldo (Merchant) and six other sneaky stars. Directed by @Hrom. </a> Savannah swim day </figcaption> </figure> </a> Meet the Waldos </figcaption> </figure> </a> Desert denizens </figcaption> </figure> Solutions will be posted in the next edition of TWiV. Extra! Extra! Read all about it!</h3> Armed with their keen senses and a trusty notepad, @phoenix13032005 was on assignment these weeks to document the various dramas unfolding on Veloren's official server. These are the stories told so far, in The Veloren Daily. </a> </a> </a> </a> </a> </a> </a> </a> </a> </a> </a> </a> </figure> Events</h3> Pre-planned events hosted on the official server (server.veloren.net</code>). You can keep an eye out for future announcements on the discord channel</a>. PvP war</h4> </a> The usual suspects, extended line up — by @Vagabond </figcaption> </figure> Lakeside residents of Sporia were recently witness to a kind of reverse-Atlantis event, when a mini-city island rose up from the waters. Deserted but intact, with an architecture unknown to modern Veloreans, it holds untold promise for historical study. What better to do with this archaeological miracle than wage all-out PvP warfare. So now, Battlemode Productions™ brings you another combat extravaganza! This time in a geared up, strat maxed, team based format. Big cheers to @unii for besting Poseidon to raise their arena from the lakebed, @Necti for promoting the event, and @Hrom for putting the teams together. </a> Warmup lighting — by @Necti </figcaption> </figure> </a> A front page, bruised-eye witness account from @phoenix13032005 </figcaption> </figure> @Necti was back in the hot seat with in-the-action commentary and comms. It's subtle, but she might be a fan of the new rolls. </iframe> </div> Mind the puddle of leaked meta </figcaption> </figure> </a> A conga line from @Sam113 turned bizarre attempt to measure the arena in 'body count' </figcaption> </figure> Screenshots</h2> </a> Who knows what lurks between the shades of grey? — by @unii </figcaption> </figure> </a> Casual Friday attire looks very different in these neighbouring towers — by @Supa </figcaption> </figure> </a> A tribute to the Town Musicians of Bremen — by @And_i </figcaption> </figure> </a> All about the journey, not the destination — by @Alley_Oop </figcaption> </figure> </a> Could almost imagine your own sunset in a lantern — by @game_r/dev </figcaption> </figure> </a> To pack: 🗹 glider ☐ life jacket — by @Alley_Oop </figcaption> </figure> </a> Last moments of an unburned retina — by @Necti </figcaption> </figure> </a> Frost Gigas tries their hand at some urban (re)planning — by @cookiengineer </figcaption> </figure> </a> These Adlets are digging their heels in against climate change — by @Alley_Oop </figcaption> </figure> </a> A melting pot of cave flavours — by @unii </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </a> @Froggy was tempted to ride this heatwave. Catch you on the next one :) </figcaption> </figure> These weeks in Veloren 243 Thu, 20 Mar 2025 00:00:00 +0000 Step into the time machine, as we begin a series of catch up posts to bring ourselves up to speed with what's been happening in Veloren. It's been a relatively busy few months to start the year, with contributors new and old bringing their energy to the project. Some longer running works have also been making their debuts. Today's menu includes new mounting possibilities, pixel and voxel art updates, as well as screenshots galore. - horblegorble, TWiV Contributor Contributor work</h2> Thanks to everyone who contributed to veloren these last weeks: @xMAC94x, @unii, @IBotDEU, @DungeonLord, @fnetx, @zesterer, @isse, @Hrom, @horblegorble, @allucaneat, @Froggy, @Anawan, @srpapinha, @crab, and @Crabo. Thanks to the weblate contributors who contributed these last weeks: ArDu, Bandalbox, bov, fnetX, Jungso, l3nemy, NeoSlugman, Paw, Raskm, sungbinma, Tibo-Mouss, and Zerothas. Release... the party!</h3> Before we see what's arrived with the new year, let's look back at how we closed out the last one. </a> Much of the usual shenanigans, with some new faces — @horblegorble </figcaption> </figure> </a> All together now! — @horblegorble </figcaption> </figure> </a> In true zen fashion: a snail's pace migration — by @Hgrebnewdnav, @Necti, @unii, @horblegorble </figcaption> </figure> </a> An after-party boat ride — by captain @souffle </figcaption> </figure> Veloren officially</a> turned 0.17 on Dec 28th, 2024. You can check out the live stream</a> of the release party, which was again hosted at @Hannibal's zen island</a> that debuted at the 0.15 release party. Merged work</h3> Iconic Hammer skills</h4> Placeholder icons by @Sam finally get the bonk as new ones swing into action. Heavy lifting was done by @allucaneat, with touch ups from @Froggy to bring things over the line. </a> The hammer skill tree, now in its full pixelated glory </figcaption> </figure> GitLab: !4450</a> To mount or not to mount</h4> Get yer collars and cowboy hats ready folks! @isse just rode in from a multi-merge-request code rodeo. Let's see what she's wrangled for us. Riding capabilities are now determined mostly by mass, shepherding in a wider variety of mounts for players. However, dreams of Hirdrasil riding remain fanciful, as a few exceptions remain. Something without exception is the results of an intense game of offset catchup, with every entity getting a tailored mount point. A local tavern owner spectating @isse's performance reckons they'd be a champion at the local pin-the-tail-on-the-donkey tournament. </a> @Dan113 always wanted to level up from tree-hugger to tree-rider. </figcaption> </figure> As is to be expected when striking out a new path in the world, it wasn't all smooth ground to cover. Things caught a spooky snag in the form of a kind of 'ghost of merge request past'. Your browser does not support the video tag. </video> A short-lived Veloren reboot of Ghost Rider, starring @Sam113 </figcaption> </figure> Now don't think playing ghostbuster was the only fix at work here: voxygen updates mount animations first to prevent the rider lagging behind</li> squished a bug with mounting in water that kept playing swimming animations and water noises</li> other animations now work better in combination with mount movements.</li> </ul> Phew! What a mountain of mounting changes. Your browser does not support the video tag. </video> Some fun along the way, as @isse takes a fresh approach to rebuilding the Tower of Babel </figcaption> </figure> Though maybe the real changes were the command line fixes made along the way: crustacean</code> added to entity list for /body</code> and /spawn</code></li> tab completion fixed for sub-commands</li> /outcome</code> get parsing for its options</li> </ul> GitLab: !4689</a> + !4695</a> + !4691</a> It's a whole new (default) world</h4> Our map seed hunters have returned from another expedition, so that Veloren's default worlds may be reborn. Cooking up the final touches, from their kitchen was heard a grand chorus of excited back and forths, terrain and biome seed blending, and what this observer could only discern as a demand for pirate icebergs. The final dish was served fresh so as to bypass the small matter of voting from before. </a> new singleplayer (left) and multiplayer (right) default maps </figcaption> </figure> GitLab: !4679</a> Control and interaction UI updates</h4> Sometimes it feels like everyone wants to know "where is my bag?" but no one is asking "why is my bag?". @Anawan brings us an answer to this age old question with a name change for controls from 'Bag' to 'Inventory'. Accordingly, the default keybind has been updated from [B] to [I]. </a> Time to relearn some muscle memory... (or maybe go and change the keybind) </figcaption> </figure> GitLab: !4692</a> ✨ Ever find yourself adjusting the floor lighting while your valuable loot lies not more than a step away? Or does your mount insist on your attention when you're trying to pick it some apples? Never* fear facing these frictions again, with @crab's new patented* Interact-O-Matic system! Now featuring: multiple interaction targets, with each control resolved amongst them</li> prioritisation of interactions, e.g. item pickup before entity petting</li> </ul> </a> Perhaps time to retire our keyboard wrestling belts </figcaption> </figure> * statements pending approval from our legoom legal team. GitLab: !4693</a> Admin glider goes vroom!</h4> @zesterer lives up to his name by bringing some extra flavours to the vroom glider. These visual and acoustic updates are perfect for giving that extra bit of flare to your squadron's next airshow. </a> The night becomes his canvas </figcaption> </figure> Your browser does not support the video tag. </video> 🔊 A combination light show </figcaption> </figure> GitLab: !4685</a> Balancing acts for sword and axe</h4> Sword and axe went up on @unii's scales of balance: I've rebalanced most sword and axe skills, with supervision/feedback from @Necti and a few other players. The general changes can be summarized into: M1 skills for both sword and axe had their damage significantly increased.</li> Fine-tuning the damage of most sword's adaptable skills for more consistency among them.</li> Many sword finishers have a lower combo requirement, with some tweaks (mostly nerfs) to their effectiveness to compensate for this fact.</li> Pommel Strike now deals additional poise damage if the target is blocking.</li> Most self-buffs received a nerf to their potency. In addition to this, the axe ones have received an increase in their duration.</li> A couple of axe skills that granted additional combo per hit (namely, Plunder and Rising Tide), now (partly) do so if they meet certain conditions.</li> Defiance's strength was reduced, with Hammer's Tenacity receiving a similar nerf to not overshadow the former for the time being.</li> Fracture's debuff strength was halved.</li> Axe finishers have received a slight increase to their damage output.</li> Cleave grants 1 less combo per fully-charged hit, but charges up slightly more quickly in compensation.</li> </ul> GitLab: !4673</a> + !4682</a> Shield and sword go see the animation doctor</h4> Your character's wrists can breathe a little easier after animation treatments from @srpapinha. Your browser does not support the video tag. </video> Front over flank, is what my trainer always said </figcaption> </figure> Your browser does not support the video tag. </video> Guess it was possible to over-stick a landing </figcaption> </figure> Your browser does not support the video tag. </video> Sharp toward enemy </figcaption> </figure> GitLab: !4688</a> A few more sprites get freshened up</h4> Hot on his own heels from the last devblog</a>, @unii brings us fresh updates to the airship sign, cauldron, and forest house windows. </a> Don't make any sudden movements... </figcaption> </figure> GitLab: !4675</a> More changes:</h4> Size and maximisation state of game window now gets saved, by @IBotDEU !4097</a></li> Language-specific fluent</code> terms removed from translations, by @fnetx !4677</a></li> Previously featured</a> work on barns at the outskirts of towns got merged, by @DungeonLord !4672</a></li> Realignment of tree and entrance for Haniwa Catacomb sites, by @horblegorble !4681</a></li> Vampire castle chests now have the same loot as in Haniwa Catacombs, by @Crabo !4696</a></li> Updated description for hammer's pommel strike, by @unii !4697</a></li> </ul> Ongoing unmerged work</h3> Talk of the town</h4> The future is looking much more talkative, with an in-progress branch by @zesterer that lets NPCs explore their more conversational side. </a> With this newfound voice, travelers may well be looking to put their combat skills to work </figcaption> </figure> GitLab: !4686</a> Heightened alert</h4> After hearing one too many reports of trolls and ogres 'sneaking up' on townsfolk, @James has been constructing watch towers to give guards a better view. </a> Will this put the town at ease? </figcaption> </figure> Community showcase</h2> Frost Gigas sightings</h3> Seasoned Gigas hunter @Hrom has compiled a heatmap of 96 sightings on the official server's previous map. </a> A heatmap that's cool to the touch </figcaption> </figure> Concept art</h3> First-hand accounts of various explorations in voxel space. A mix of things intended for use in-game, and more experimental ideations. </a> (left to right) | hulusi instrument concept by @Sinari | terracotta lamp by @Supa | ice staff concept by @phoenix13032005 | coin stacks concept by @unii </figcaption> </figure> Events</h3> Pre-planned events hosted on the official server (server.veloren.net). You can keep an eye out for future announcements on the discord channel</a>. Geared PvP tournament</h4> Duelists of Veloren pulled out all the stops in a full-gear, (almost) no holds barred 1v1 double elimination tournament. The action took place in a hand-crafted arena from @unii, featuring castle towers and a fighting moat. @Necti handled marketing and event streaming, and in the end emerged as the tournament champion. Speaking after the fighting, with an opponent's blood still fresh on her face, @Necti announced a swap from melee to mic for the next PvP event. Here's to a captivating career in commentary as Veloren's 'Fighting Voice'. </a> Spectators watch on under vibrant lighting — by @Iskava </figcaption> </figure> Your browser does not support the video tag. </video> @unii runs through the pre-fight checklist </figcaption> </figure> </iframe> </div> 2 hours of PvP action </figcaption> </figure> Word is @unii has been cooking up his next tournament map, so stay tuned. Screenshots</h2> </a> A valley vista catches the sun's last rays — by @Hrom </figcaption> </figure> </a> Could this be Veloren's first ocean megafauna? — by @Alley_Oop </figcaption> </figure> </a> Nestled at the foot of a mountain, this woodland town endures the rain — @horblegorble </figcaption> </figure> </a> A soft breeze carries savannah air into the jungle — by @Sam113 </figcaption> </figure> </a> Gnarling's called a truce with this giant tree — by @Alley_Oop </figcaption> </figure> </a> Who knew gliders made such good picture frames? — by @VorTechnix </figcaption> </figure> </a> Site generation delivers us an ambitious skate ramp — by @Necti </figcaption> </figure> </a> Tavern views in evening lighting — @horblegorble </figcaption> </figure> </a> Last year's merry moon gazing — by @And_i </figcaption> </figure> </a> Another impromptu band takes the stage in Sporia — by @unii </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </a> An artistic sendoff from @Defo's elven character. Stay jolly out there :) </figcaption> </figure> These weeks in Veloren 242 Wed, 25 Dec 2024 00:00:00 +0000 The last few weeks we've been busy preparing for the release party, so here's a recap with everything that's happened in veloren during this time. - Crab, TWiV Contributor Contributor work</h2> Thanks to everyone who contributed to veloren these last weeks: @miocore, @DaforLynx, @Vaga, @do-no-van, @Necti, @uniior, @Hrom, @DungeonLord, @floppy, @isse, @crab, @Tarhun, @NeuralModder, @Hgrebnednav and @horblegorble. Thanks to the weblate contributors who contributed these last weeks: @Alerty, @ArDu, @Blesk, @bov, @crab, @fnetX, @Janez, @jecasadiego, @Jungso, @l3nemy, @loglizzy, @NeonLife, @Positron832, @spartan195, @StartaBafras, @sungbinma, @ttanesque, and @Zerotha. Merged work</h3> Downed State, by @isse</h4> As preparations for the ongoing respawn rework RFC (linked here</a>), humanoids will now enter a 'downed' state instead of being killed. In this downed state, entities are still vulnerable and can only move slowly while being unable to attack, interact, or make any inventory modifications. Nearby NPCs or players can help downed entities out of this state again. Your browser does not support the video tag. </video> </figure> GitLab: !4656</a> Snow Sprite variations, by @Green12 @Hrom and @do-no-van</h4> @Green12 made a set of snowy sprite variations, which @Hrom created a MR for and @do-no-van added an attribute to the existing sprites to define whether to use the snowy or non-snowy variant. The snowy sprites rendered in MagicaVoxel. Note: The hanging tree leave sprites couldn't be implemented yet. </figcaption> </figure> GitLab: !4605</a> Attack timing balance and Frost Gigas summon rework, by @Necti</h4> The Frost Gigas will now spawn 2 (larger) summons instead of a bunch, which got a reworked skill set and attack AI. This MR also slowed down the attack recovery duration for most entities, which should make it easier to land more hits between dodging and blocking incoming attacks. GitLab: !4666</a> Sprite model updates, by @uniior</h4> Another nice set of updated sprites: The updated crate model rendered in MagicaVoxel </figcaption> </figure> The updated anvil model, the easter egg is still present ;) </figcaption> </figure> </figure> GitLab: !4665</a> + !4660</a> Adding a sprite attribute to determine fence adjacency, by @DungeonLord</h4> Instead of there being one separate sprite for each possible fence adjacency, there is now only one fence sprite with an adjacency attribute defining which model to use. This should make it easier to add more sprite style variants in the future too. GitLab: !4661</a> Banjo instrument, by @floppy and @Sinari</h4> A new crafted instrument, model by @Sinari and the audio by @floppy: </figure> GitLab: !4658</a> Make empty town generation less likely, by @Tarhun</h4> Most towns will now generate an initial plaza, which should remove many cases where towns don't generate with any buildings at all. There are still a few edge cases but we are working on getting rid of those too 🛠️. GitLab: !4646</a> Add an indicator on learned recipe items, by @Hgrebnednav</h4> To no longer accidentally trade a recipe you already know from a merchant or player, recipes will now indicate if you have or haven't learned a recipe yet in the item hover tooltip: </figure> GitLab: !4652</a> Upgrading iced</code> and other dependencies in Airshipper, by @NeuralModder</h4> Airshipper received many dependency updates, including iced</code>, which should fix a few graphics issues some people were having with the launcher. In addition the caching system now automatically removes images which are no longer needed to save disk space. Note that these changes haven't been included in an Airshipper release yet, but they will hopefully soon be. GitLab: airshipper!164</a> Fix being unable to cast abilities when wallrunning, by @miocore</h4> Instead of getting stuck in an equip-unequip cycle when trying to use abilities while wallrunning, you can once again use abilities as one would expect. GitLab: !4662</a> Item price and availability balance, by @uniior</h4> Merchants will no longer sell late-game materials such as sunsilk, diamonds and other high tier gems. In addition the price of other materials has been rebalanced to better fit the recent loot changes. GitLab: !4657</a> More changes:</h4> Fixing a typo and the flurry ability icon not showing when not in agility stance, by @Vaga !4670</a></li> Legoom sounds, by @GeekyGami and @DaforLynx !4655</a></li> Fixing the hammer/axe block animation, by @miocore !4669</a></li> Updating rustls</code> and idna</code> to address RUSTSEC advisories, by @crab !4668</a></li> Updating dependencies, by @NeuralModder !4653</a></li> Fix RTsim NPCs dying permanently, by @crab !4650</a></li> </ul> Ongoing unmerged work</h3> @DungeonLord is working on a new Barn structure: </figure> </figure> @Tarhun is making airships actually dock at docks: Your browser does not support the video tag. </video> </figure> @uniior is working on balancing Axe ⚖️ @do-no-van is working on a fishing mechanic. Still awaiting some #game-design discussion, but here's an early preview: </figure> RFC discussions</h3> As a result of a few cyclic arguments in the game design chat, we're trying to move most game desing discussions off to RFCs. Here are the ones which were discussed this month (more to be opened soon): Respawn rework, by @isse rfcs!46</a></li> DRAFT: Removing/Deprecating the general combat skill tree, by @DaforLynx rfcs!45</a></li> </ul> Events</h2> @Necti hosted a sword PvP tournament on the official server in an arena made by @uniior. The beautiful arena made by @uniior </figcaption> </figure> And the winner was 🥁 Necti, who would've thought... </figcaption> </figure> More events will follow up soon ;) Screenshots</h2> Cheap rng creating some patterns again... </figcaption> </figure> Distant town LoD </figcaption> </figure> </figure> </figure> meow :3 </figcaption> </figure> </figure> An adlet hideout in the wild </figcaption> </figure> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. The christmas event started again! See you in the next post :) </figcaption> </figure> Veloren 0.17 Release Wed, 25 Dec 2024 00:00:00 +0000 0.17 Release</h2> Veloren is finally releasing 0.17! It has been 9 months since 0.16 was released so there has been a lot of work put into this version. If you're reading this before 18:00 GMT on December 28th, make sure to join the release party. On the side, you can also watch the release party dev stream</a>, where we'll be chatting with devs about what went into this version. To join, you can download the game for free at veloren.net</a> and create an account</a>, then launch the game and hop on the default server. See you there! New in this release</h3> Here are some of the changes in this release: Hammer skill tree rework.</li> Recipe system.</li> New enemies: Hydra, Karkatha, Cactids, Goblins and Legooms.</li> Dungeon reworks completed: Cultist, Myrmidon, Sahagin.</li> New worldgen structures: Terracotta, Dwarven Mines and Vampire Castle dungeons; farm plots, more airship docks, glider courses.</li> Plugins can now define NPCs.</li> Airshipper will now display the player counts on the server browser.</li> Switched audio framework to Kira.</li> Many balance improvements.</li> </ul> Changelog</h3> As always, there are always more changes than we can add to a single post! You can check out the full changelog here</a>. Thanks to this versions contributors (in random order): HEIEnthusiast, Hrom, Benoît du Garreau, Christof Petig, Tomodachi94, uniior, floppy, daniel, walpo, Uniior, xmac, NeuralModder, Skygrango, Sam, Vaga, Isse, Matthew Searle, crab, Kira Lu, ryan necti, fnetX, Thibagon, Gemu, DungeonLord, Jungso, Treeco, James Melkonian, DaforLynx, crab, Dmitry Kashitsyn, Imbris, coffee-compiler, Necti, zesterer, Aidar Shaikhiev, LunarEclipse, Tarhun, Hgrebnednav, do-no-van, Papinha, miocore, Thomas S, ArDu, horblegorble, Janez, Sylv and fotkurz. </blockquote> Thanks as well to all the weblate contributors who contributed to this release (in random order): fnetX, nwildner, Kretka, walpo, zerocraft, Janez, Blesk, polauf, Positron832, Karaya, GGTheTranslator, bov, Jungso, Tibo-Mouss, NeoSlugman, ArDu, LS-Localicows, ttanesque, perospirone, nokoe, coffee-compiler, metamuffin, CodeVlogs, hurzelchen, Enlive, 2b33rs, fvasco, Zughy, kanym, l3nemy, Zerothas, sungbinma, kurtinge, loglizzy, Thiagod86, dyegomb, PurpleDev, FelipePardim, arthuradolfo, rmorettibr, RyanOrigins, evgenkot, lucius_pilgrim, masta0f1eave, emberman, MaxSoniX, Furrior, Daxik2x, Paw, Sovenok-Hacker, LagerJack, NeonLife, Alerty, Alderador, spartan195, crab, jecasadiego, guillermytho, vilmasvensson, StartaBafras, Sinari, Akumo33 and Witch. </blockquote> Support the project</h3> As always, feel free to support the project on Open Collective. It allows us to keep our servers running, and launch great release parties like the one for this release! These weeks in Veloren 241 Fri, 15 Nov 2024 00:00:00 +0000 There have been many changes this month, most notably: Switching audio frameworks, myrmidon rework, procedural glider courses, water splashes, farms, cactids, legooms ... yeah this is getting a bit long, just read the blog :P - Crab, TWiV contributor (and since recently a Core Developer too 🦀) Contributor Work</h2> Thanks to everyone who contributed this month: @daniel, @Sam, @uniior, @isse, @imbris, @zesterer, @horblegorble, @DungeonLord, @necti, @crab, @floppy, @do-no-van, @DaforLynx, @James, @Hgrebnednav and @fotkurz. Thanks to all translators who contributed to weblate this month: @StartaBafras, @Positron832, @Zerothas, @l3nemy, @bov, @Janez, @Thiagod86 and @Vilma ! Merged work</h3> New themed airship dock variants, by @floppy</h4> Towns other than the default settlements now have their own airship dock variants too. As airship captains haven't learned to actually land on them yet, the docks have temporary 'Service Interrupted!' signs. A few sample screenshots: A desert airship dock </figcaption> </figure> A clifftown airship dock </figcaption> </figure> GitLab: !4643</a> Procedural glider courses, by @James</h4> After a long wait in the review queue, the glider courses have finally been merged! Initially part of a manually placed release party event, glider courses will now generate procedurally near mountain peaks and are a fun gliding challenge :) Your browser does not support the video tag. </video> </figure> GitLab: !4568</a> Swapping Audio Frameworks, by @DaforLynx</h4> In the past week or two I've been working on porting the audio framework Veloren uses from Rodio to Kira. There are a few reasons for doing this: Rodio has a few bugs, like spatial sound glitching out</li> Rodio is not built explicitly for games, meaning we have to build a lot of systems in our own janky way</li> Rodio is incapable of handling DSP effects in a dynamic way</li> </ul> Kira has turned out to be very good as a game audio framework, chiefly because that's what it was built to be. At first, when I decided on doing this a year ago, this endeavor was going to be a simple port - wherever Rodio calls are made, replace them with Kira calls, that sort of thing. However, after experimenting with Kira on my own, I quickly found out that it would not be so simple. Rodio vs Kira</h5> Rodio is very simple, at least from my reading. You read sound data, perform alterations such as effects, and append them to a sink's queue. Each sink has a separate queue with its own volume and state. Each sink feeds into a single stream which is then output through cpal. Kira is markedly different. Cpal is still used as a backend, but the framework around it is more complex. It's sort of component-based. A manager is responsible for playing sounds through either a track or an emitter. Tracks can be routed to other tracks, but all tracks and emitters are eventually routed to one main track. A single track can output multiple sounds at a time, but has effectively no control over each sound. Additionally, sounds are routed to a destination per sound. Additional data can be held by an individual sound, including its amplitude and looping parameters. Every component - sound, emitter, track, manager, and more - should be tracked by Voxygen's systems. Nearly every function in Kira uses a tween. This allows the audio to be shaped over time, instead of instantly. For example, when you stop()</code> a sound, you can have it happen instantly, or fade it out over a duration. Tweens make things much easier and simpler, but their lack of transparency can lead to problems. Kira requires some rewriting</h6> These features, and many more, mean the entire audio system has to be pretty much rewritten if I want to take advantage of them. All the handles for things like tracks, sounds, effects, etc. must be tracked. Our current "channel" structure is actually perfect for this - they are abstract structures which the engine uses to allocate sounds. I have each channel "hold" a track (they only really store the handles; the actual data is held by Kira's manager) routed to the main track, as well as all the needed handles. I have to construct sounds in a way that allows them to be play</code>ed by the manager, instead of the channel, as well as potentially be altered while playing. Therefore, I make it so, as with the current system, each channel can have one sound at a time routed to its track, and holds the handle to its sound. Instead of our bespoke Fader</code> system, I can simply use adjustable tweens to smoothly control volume. Sounds cannot be easily appended to each other any more, so I have to rewrite our looping and transition systems. Luckily, Kira has yet more features to replace these. You see the picture forming? The scope of the experiment has ballooned from simply making things play through Kira, instead of Rodio, to rewriting the audio system to take advantage of Kira's game-focused features. This means my dream of making Voxygen's audio system completely framework-agnostic is trashed, but I think that's a worthy sacrifice for cleaner and more performant audio code. In any case, the audio module as a whole can still be completely swapped out for a new one if a developer chooses. Among the rewrites, I updated the way some Voxygen features work: Ambience does not have to be just looping audio. This means the thunder sounds that correspond to lightning are now controlled by the ambience volume slider, instead of the UI volume slider. Yes, thunder was technically a UI sound before.</li> Instead of performing DSP on sounds before they are played, I route their outputs to a track with dynamic effects. This means ambience is now affected by the filter as well, and longer sound effects can be filtered while playing. In the future, there is great potential to have spatial reverb (courtesy of Kira) based on the camera's position (this is probably what I'm most excited to implement).</li> Looping audio such as ambience is handled entirely by Kira, meaning no more awkward split-second gaps between the sound ending and beginning.</li> Instead of the length of the gap between music tracks being decided when a track is played, it is now decided when a track ends. The entire music transition system was rewritten, and as such it doesn't really...work that well. I plan on fully rewriting it soon. So as of now combat music is disabled (not that it would play anywhere as of recently when all the legacy dungeons were removed).</li> </ul> On that note, here are some of my plans for features coming soon™: Redo the river ambience system to be less bad, mainly by making it ambience instead of spatial sfx.</li> Redo the music system so 1) it actually works as intended and 2) combat music is less scuffed. After that I can work in music layering for the full combat music system.</li> Also, dynamic music. Things like pausing/fading down when diegetic music is playing, stopping and starting new tracks in certain situations, maybe even changing entirely how music is categorized.</li> Listener-based reverb and occlusion. I've been researching modern methods of doing this sort of thing, but it'll be difficult implementing it for a non-static procedural game such as Veloren. The current methods are for games with set level design with defined room volumes...never mind. But the possibility exists now!</li> </ul> But you can expect these to be implemented in anywhere from two months to four years. Huge kudos to @crab for implementing sound streaming and @isse for refactoring and fixing my code. GitLab: !4627</a> (fixes and follow-ups: !4649</a> + !4641</a> + !4639</a>) Stealing items owned by villagers, by @isse</h4> Taking resources from the village inhabitants who worked relentlessly to obtain them (no they didn't, lazy bunch of rtsim npcs</del>) will now get mad at you for committing thief. Your browser does not support the video tag. </video> </figure> GitLab: !4637</a> + !4642</a> Water splashes and river particles, by @isse</h4> Your browser does not support the video tag. </video> Splish splosh! </figcaption> </figure> GitLab: !4640</a> Toggle to show all recipes in the crafting menu, by @Sam and @isse</h4> A common problem with recipes was new players no longer being able to decide whether an item was worth keeping by checking which other items could be crafted with it by searching input:item name</code> in the crafting menu, if not all recipes have been obtained yet. The newly added toggle allows using this feature without limitations again. GitLab: !4601</a> Myrmidon rework, by @floppy</h4> And with that, the last old style dungeon has been removed from the map 🎉 Unlike other reworked dungeons, this one went with more of an open design, which created some beautiful results :) </figure> The underground maze of the myrmidon dungeon </figcaption> </figure> GitLab: !4606</a> Enabling cactids, by @floppy</h4> Cactids have been present in the codebase for a long time it seems, but they weren't set to spawn in the world. Thanks @floppy for finishing- and giving them a loot table ♥️ The cactid model </figcaption> </figure> GitLab: !4631</a> Farm plots, by @DungeonLord and @zesterer</h4> A plot we missed a lot from site1</code>, farms are back once again! A legoom at a sunflower farm :legoom: </figcaption> </figure> GitLab: !4567</a> Legooms and Goblins, by @Gemu and @floppy</h4> To balance out the large pool of late game enemies in the game, @Gemu and @floppy have been working on adding various smaller opponents more balanced for new players, here being some of the latest examples: Goblins can be found in caves and plains </figcaption> </figure> Legooms spawn in newbie areas such as temperate woods, plains and rainforests </figcaption> </figure> GitLab: !4622</a> + !4626</a> Overhaul stat scaling of armor, by @uniior</h4> Player armor stats were rebalanced to closer match the recent balance changes done to weapons. GitLab: !4494</a> + !4648</a> Tracking health of entities in RTSim, by @isse</h4> RTSim entities now remain at the same health percentage when loaded/unloaded, this was done in preparations for reworking our spawn system (still under discussion). GitLab: !4644</a> Halloween event tweaks, by @crab</h4> I introduced a new event item for halloween, Scarlet Spectacles, which turn your eyes into a red glow for a bit of extra precision power: Scarlet Spectacles </figcaption> </figure> </figure> This change also made Bloodservants and Strigoi from the Vampire Castle spawn in the wild during the event, which I thought would be quite fitting :) GitLab: !4614</a> Changes made due to recent moderation incidents, by @crab</h4> This month hasn't been short on ✨interesting and new✨ moderation incidents, most notably: We got hit by an automated spam attack on the official server. To counter this, the 2 year old IP banning MR !3363</a> a combined effort by @zesterer, @imbris, @isse and @crab) was rebased, the remaining comments addressed and merged, finally! More mitigations against future spam attacks are also on the way (see 'email verification' in Ongoing unmerged work</a>) A few other changes that were implemented to mitigate and help moderate client-authoritative physics abuse: Improvements to the client-side physics anticheat !4611</a></li> Silent spectator mode for moderators !4608</a> Allows moderators to log on silently without emitting any login/logout messages or appearing on the player list. If you moderate any server and want to make use this, add the following environment variable in Airshipper VELOREN_CLIENT_TYPE=silent_spectator</code>, don't forget to undo this when you want to play normally again!</li> Persisting server authoritative physics !4211</a></li> Expose the duration of bans to clients !4616</a></li> </ul> Mindflayer fight rework, by @floppy</h4> After being moved into the new dungeon, the old mindflayer attack patterns were not very fitting anymore. With testing help from @necti a new strategy was created which was better adapted to the new environment. The video for this one was lost, sorry :( GitLab: !4625</a> More changes: Improvements to sprite models, by @uniior and @Supa !4635</a></li> Ensuring every house has a bed, by @fotkurz !4609</a></li> Riposte and defensive stance balance, by @necti !4634</a> and @do-no-van !4526</a></li> Making sceptres use the default equip/unequip SFX, by @horblegorble !4628</a></li> Make Iron Tempest (Hammer ability) multi-target, by @necti !4633</a></li> Adding missing changelog entries, by @horblegorble !4624</a> + !4615</a></li> Various cheesing fixes, by @floppy !4621</a> + !4620</a></li> Adding a deletion timeout for all sprite summon abilities, by @horblegorble !4630</a></li> Fixing the mod badge location in group and faction chats, by @Hgrebnednav !4636</a></li> Removing the code used to render old dungeons, by @floppy !4613</a></li> </ul> Ongoing unmerged work</h3> @floppy is working on a Fire Gigas. Your browser does not support the video tag. </video> </figure> @Tarhun is working on reducing the chance for towns to generate without any plots. !4646</a> @uniior is working on an updated fence (gate) sprite. </figure> @crab Is working on adding email verification to authentication servers. This has been long overdue, but comes with a few challenges such as requiring a captcha for account creation. On the bright side, once this is implemented, password resetting can be implemented too! @floppy, @Supa and @Gemu have been working on creating a consistent set of themed sprite variants for all town kinds. @GeekyGami is working on custom SFX for legooms. @Supa is working o updating the pumpkin sprites. </figure> PvP event on the official server</h3> @necti will be hosting a Bow PvP event on the official server at 19:00 GMT this Sunday (2024-11-17) in a custom arena. For more info check the discord announcement</a>. </figure> Screenshots</h2> </figure> The new coastal town airship docks </figcaption> </figure> </figure> A neat bridge found on the official server </figcaption> </figure> </figure> </figure> Radio voice: Heavy rainfalls have caused floodings in the nearby Myrmidon site, please ensure you are carrying appropriate equipment before entering the facility... </figcaption> </figure> </figure> These NPC dialogues sure sound menacing... </figcaption> </figure> meow :3 </figcaption> </figure> Scary fish in veloren seas </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Pool party at the main town. See you in the next one! </figcaption> </figure> These Weeks in Veloren 240 Tue, 15 Oct 2024 00:00:00 +0000 This month has been very active with many contributions from many contributors! The blog post is being published a bit delayed but hopefully you still enjoy reading the recap :) - Crab, another TWiV editor Contributor Work</h2> Thanks to everyone who contributed this month: @uniior, @isse, @skygrango, @Gemu, @Supa, @isse, @fnetX, @floppy, @horblegorble, @Papinha, @imbris, @xMAC, @crab, @do-no-van, @Christof and @Thibagon ! Thanks to all translators who contributed on weblate this month: @fnetX, @Janez, @polauf, @bov, @Jungso, @nokoe, @metamuffin, @CodeVlogs, @Enlive, @coffee-compiler, @2b33rs, @Zughy, @kanym, @evgenkot, @lucius_pilgrim, @Paw, @guillermytho, @Positron832, @Sinari and @Akumo33. Merged work</h3> Vampire Castles, by @floppy</h4> A new vampire-themed T4 dungeon, the worldgen is impressive as always :D </figure> </figure> GitLab: !4473</a> Transform on death effect, by @crab</h4> NPCs can now be configured to transform into another entity on death, the vampire castle boss and fake terracotta cursekeepers are already making use of this for multi-stage bosses! GitLab: !4581</a> LoD object rotations, by @isse</h4> Originally intended to be used for procedural glider course LoD models, this allows rotating LoD models in steps of 90 degrees. Currently only trees are randomly rotated, but we also want to make other plot LoD models rotate correctly in future, such as the Haniwa dungeon wich is one of the most notable ones. GitLab: !4589</a> Jet engine model, by @horblegorble</h4> The Vroom admin glider added by @juliancoffee finally has it's own model now! </figure> GitLab: !4452</a> /spot</code> command, by @isse</h4> Another command making testing changes easier 🎉. It works similar to the /site</code> command, but as spots are not named this command takes a spot kind instead and teleports you to the nearest one. GitLab: !4597</a> Hardcore characters, by @do-no-van</h4> Think veloren is too easy and want something more challenging? This is for you! Players can now choose to make new characters hardcore, dying now means loosing your character. GitLab: !4571</a> Kora instrument, by @floppy and @Supa</h4> Model of the new Kora instrument </figcaption> </figure> GitLab: !4585</a> /kit recipes</code> command, by @uniior</h4> This command mostly helps with testing, but if you're playing on singleplayer and aren't satisfied with the recipe system you can use it there too. Other ways of obtaining recipes that don't require grinding dungeons are also being discussed :) GitLab: !4598</a> Karkatha, by @floppy and @Gemu</h4> The Sahagin dungeon got a new boss, Karkatha 🦀. Tidal Warrior was moved one floor below and is now a miniboss with a reworked skill set. Karkatha waiting for its prey in the sahagin dungeon boss room </figcaption> </figure> Karkatha's summons, Soldier crabs </figcaption> </figure> Tidal Warrior got downgraded to a miniboss :/ </figcaption> </figure> GitLab: !4590</a> Player counts in Airshipper, by @crab</h4> As announced in an earlier blog posts</a>, Airshipper has now released player counts in the server browser! This should make it easier to find a server geographically near you with active players. There's still a handful of server which haven't activated the new query system on their servers yet, if you're a server owner on the server browser list reading this, please check out the blog linked above. GitLab: airshipper!160</a> Overriding game assets from Airshipper, by @juliancoffee</h4> I've added a special field in Airshipper settings that allows you to set VELOREN_ASSETS_OVERRIDE (https://book.veloren.net/players/env-vars.html#veloren_assets_override</a>) to make it more visible and hence useful to more people. Additionally, you can now click on a little book icon near this text and environment variables field to go to the link I put above. GitLab: airshipper!162</a> Beam collisions, by @Papinha</h4> A neat trick to make it appear as if particles collide with terrain, only enabled for beam particles for now due to the cost of having to do one raycast per-particle. Your browser does not support the video tag. </video> </figure> GitLab: !4562</a> Entity balance, by @necti</h4> Improved the balance of most dungeon entities, as well as sword, axe and hammer abilities. Welcome @necti as our new Balance Lead 🎉 GitLab: !4586</a> Golemite armor set and loot table balancing, by @necti</h4> A new armor set was added, crafted with items dropped from Terracotta and Haniwa enemies. Loot tables were also rebalanced to no longer allow easily skipping progression. The new golemite armor set, shown with the weapon of a terracotta enemy </figcaption> </figure> GitLab: !4600</a> NPCs in plugins, by @Christof</h4> Another great addition from @Christof to make plugins more useful! Entities, their models and animations can now be defined in plugins. Here's an example plugin making use of this: plugin/examples/anim</a>. GitLab: !4351</a> Require multiple hits to mine gems and ores, by @crab</h4> This was already announced a while ago, and has finally been merged. Thanks a ton to @Gemu and @Supa for the models, and to @floppy for creating the new pickaxe SFX! Every ore/gem now has a specific number of hits it can take before breaking, every one or two hits (depending on the quality of the ore) the sprite will go into a next 'stage', changing the model and having a chance to drop an extra item (increased by the corresponding mining skill). Your browser does not support the video tag. </video> </figure> GitLab: !4266</a> More changes: Adding missing changelog entries, by @horblegorble</li> Cheesing fixes for the Vampire castle, by @floppy !4588</a></li> Dependency upgrades, by @xMAC !4580</a> + !4582</a></li> Taiwanese translation work, by @skygrango !4592</a></li> Fixing errors in translation files, by @Thibagon and @fnetX !4528</a> + !4576</a></li> Fixing server crashes caused by the /buff</code> command, by @crab !4594</a></li> Updating tracy-client to the latest version, by @imbris !4578</a></li> Fixing how buff strength is displayed, by @horblegorble !4574</a></li> Updating the contribution guidelines, by @isse !4529</a></li> Improvements to the sprite manifest, by @imbris !4577</a></li> WGPU fixes and re-enabling shaderc optimizations, by @imbris !4579</a> Fixes an issue on some windows systems with AMD graphics using the Vulkan backend, if this caused any regressions please open an issue on GitLab</a> or report it in the discord.</li> </ul> Ongoing unmerged work:</h3> The myrmidon dungeon is getting a rework: Reworked myrmidon dungeon, by @floppy </figcaption> </figure> @juliancoffee is working on adding LootSpec</code> to SpriteCfg</code>. This will allow specifying separate loot tables for the same sprite kind in worldgen, making it easier to handle keys or other special drops in dungeons without creating more sprites !4354</a> @do-no-van is reworking throwables, they can now be equipped and used like other weapons! !4593</a> Your browser does not support the video tag. </video> </figure> @Hromina is working on adding @Green12's snow sprites into the game </figure> Screenshots</h2> Gliding at the release party map. Speaking of, when release party? </figcaption> </figure> Someone's having fun playing around with experimental shaders! </figcaption> </figure> An animation bug creating very large floating arrows </figcaption> </figure> A very nice bridge found by @isse </figcaption> </figure> The architects clearly weren't very experienced when they built these... </figcaption> </figure> </figure> </figure> Bloodmoon bat in the Vampire castle, the form of the first boss stage </figcaption> </figure> Jamming at the central town </figcaption> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. The stage is back, see you in the next one! </figcaption> </figure> Preparing to release server queries in Airshipper Mon, 07 Oct 2024 00:00:00 +0000 Read this if you own a server on the servebrowser list! Player counts have been a long-requested feature for the server browser in Airshipper, and we're finally close to releasing them! The query server, which allows for clients to query status information about a server, was already merged 5 months ago. Soon, Airshipper will also make use of it do display more accurate ping information, player counts, version information and the global battlemode. Player counts, server version and battlemode displayed for the servers which already have queries enabled </figcaption> </figure> Important info for server owners</h2> While this feature is enabled by default for new servers, it requires a bit of manual work for existing servers. If you own a server on the serverbrowser list, please read the following issue on gitlab for more information: https://gitlab.com/veloren/serverbrowser/-/issues/103</a> You will find a short guide explaining how to enable the query server, please add your comment once it is enabled! - Crab. Three Weeks in Veloren 239 Sun, 15 Sep 2024 00:00:00 +0000 These weeks, we share beautiful monster photos. - Christof, TWiV editor Contributor Work</h2> Thanks to last three weeks' contributors @coffee-compiler, @xMAC94x, and @a1phyr, @james, @isse, @do-no-van, @horblegorble, . The merged work includes marking Plain</code> messages explicitly, renaming spellbook</code> to diary</code>, proper ring</code> initialization and an assets manager update, a bag vs exit dialog fix, a critical quinn update, better recipe tooltips, Hydra 🐲🐲🐲, permadeath character option, more detailed potion descriptions, and translation updates. </figure> Ongoing (unmerged) work is happening on figures in plugins, bow rework, stopping beams at terrain, moon phases, farming, entity to terrain tethers (grappling hook), gamepad bindings, a sewer styled dungeon, glider loops, improved climbing, hired NPCs in groups and vampire castle. Translation work</h2> Translators included in MR 4575</a>: @coffee-compiler, @evgenkot, @fnetX, @Furrior, @GGTheTranslator, @hurzelchen, @Javier Pérez, @Jungso, @Karaya, @LagerJack, @lucius_pilgrim, @Paw, @perospirone, @polauf, @Sinari, @Sovenok-Hacker, and @2b33rs. Thanks to the translators, as well as to @fnetX for again compiling this lists of contributors. Development discussions</h2> @James created more informative tooltips on recipes: </figure> Also @James uploaded a nice video of flying a glider course Your browser does not support the video tag. </video> </figure> There is ongoing discussion in admin channels on how to cut down the number of trading bots spamming the chat. The motivation is to avoid the impression to newly joining players that NPCs in the world act weird. </figure> @DungeonLord revived the farming land around towns</a>. See some nice pictures: </figure> </figure> </figure> </figure> End of August the new airshipper deleted screen shots</a> at start and upgrade, as these images were stored in the game folder. This is now fixed again. </figure> @Synis is continuing the work on a sewer themed dungeon. @khannibal already created some prototypes thirty months ago: </figure> </figure> @unii found that sword animations get more complex when combined with moving</a>. </figure> @Supa and @khannibal talked barns and cathedral design</a> and shared interesting concepts. </figure> @xMAX94x found an old Veloren 0.1 binary</a> which is still operational: </figure> Last but not least we got plenty of Hydra star photos: </figure> </figure> </figure> </figure> Airshipper call for testing</h2> Announced on Sep 10th by @xMAC94x: Hey folks, anyone here that wants to test the new windows-"an update is available from gitlab"-feature ? Steps: Download airshipper.exe</a></li> This airshipper.exe when started should detect that there is a new update available.</li> If you click install you should be able to successfully install airshipper 0.13.0.</li> Next time you start (the system installed) airshipper, the 0.13.0 should run.</li> </ul> </figure> Note: Windows only (Linux and MacOS dont have this feature, don't need tests)</li> The provided download ALWAYS thinks there is a new update, that's not a bug, it's a feature to test this (the final version will not have this behavior and only update when there is a newer version).</li> It might make sense to install an older Airshipper from github</a> to verify that the install update, really installs 0.13.0</li> </ul> </figure> </figure> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Riders on the storm. See you next time! </figcaption> </figure> Three Weeks in Veloren 238 Sat, 24 Aug 2024 00:00:00 +0000 These weeks, we learn about upcoming art events and a complex airshipper failure. - Christof, TWiV editor Contributor Work</h2> Thanks to last three weeks' contributors @srpapinha, the very prolific @coffee-compiler, @uniior, @crab, Weblate users, @matsuuii, and @isse. The merged work includes freezing potion and effect cancelling, repair button activeness, chat clear command, remove help window, trade request limitations, updated sword animations, trading fixes, a translation update, cmd_doc_gen</code> update, command description translation, chat message length limits, control window translation, case-sensitive admin commands, more server command translations, test-voxygen</code> build fixes and translating map shapes. Ongoing (unmerged) work is happening on a winit</code> update, glider parcours, melee combo recovery fixes, a moderation database, adding beds to houses, gamepad bindings, Hydra, nebulas, constellations and moon phases. Translation work</h2> Translators included in MR 4552</a>: @CodeVlogs, @coffee-compiler, @dyegomb, @emberman, @evgenkot, @fnetX, @GGTheTranslator, @Jungso, @l3nemy, @loglizzy, @lucius_pilgrim, @masta0f1eave, @perospirone, @polauf, @Positron832, @Thiagod86, @Vilma Svensson, and @zerocraft. Thanks to the translators, as well as to @fnetX for compiling this lists of contributors. Development discussions</h2> @Synis worked on an updated sewer like dungeon: </figure> </figure> @Gemu posted some inspirational pictures for sewer content here</a>. @And_i posted a dwarven mine video </iframe> </div> </figure> @Papinha created a video of stopping particles at terrain blocks: Your browser does not support the video tag. </video> </figure> @Isse worked on a reworked night sky: </figure> @unii created a set of single-handed stone starter weapons: </figure> Art events and new self-subscription role by @khannibal</h2> Hello Velorians, We are happy to announce the creation of a new role on our discord: @MeetingPingSquad. It will be used for the announcement of events and gatherings to avoid tagging everyone. In order to receive the role, go into ⁠#rules-and-info</a> on our discord and react to the user role message with the corresponding emoji (🧑‍🤝‍🧑 ). A bimonthly art event will be announced soon after the release of this blog, so make sure to check it out on discord by selecting the @MeetingPingSquad! Participants of all skills are welcome, this will not be a contest, it will be a social event centered around voxel/pixel art! The goal is to help creativity by providing helpful feedback to our artists! Keep an eye for announcements! Cheers! </figure> Airshipper Bug analysis by @xMAC94x</h2> We had a sequence of issues:</a> The update was timed right before the weekly build, which was in theory perfect. However I messed up the Port (it changed from 8000 -> 8080). I fixed that quick and dirty by adjusting the deployment.</li> The Webhook from gitlab ran, however our prune job deleted ALL but 1 ID, (we wanted all but 1 GROUP BY arch,os,channel ). Due to that people couldn't download the latest version. (there were around 10 people online at that time).</li> I corrected the Port in the meantime by adjusting the helm chart.</li> I retried the Webhook from gitlab's side, however there was a WARN without any further details that gitlab gave us an invalid json.</li> After enhancing the logs I could see that the message 401ed, as our token was invalid. I figured out that our token should be something different but didn't know why it was broken. I fixed that by manually setting the gitlab token. Now the code ran again, and I could trigger the webhook again.</li> I figured out the reason for the wrong token, a job in infrastructure repo is failing which caused prod</code> to be not what master</code> is. I manually overwrote that. I am going to check now if there is some token that needs to be rotated</li> Seemed a token got invalid which caused prod</code> to not update to master</code></li> </ol> Assorted screen shots from the game</h2> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Gathering with friends. See you next time! </figcaption> </figure> Three Weeks in Veloren 237 Sat, 03 Aug 2024 00:00:00 +0000 These weeks, we look at partial downloads in Airshipper. - Christof, TWiV editor Contributor Work</h2> Thanks to last three weeks' contributors @coffee-compiler (most of these merge requests), @Sam, @muphblu, @Tomodachi94 and @xMAC94x. Special thanks to @xMAC94x for reviewing and merging most of these patches!🏆 The merged work includes to recommend openGL instead of DX11 in panic message, arthropod animation restructuring, unification of module and binary file names, translation script fixes, localize item amount, single player server name and invites, fix modular weapons crafting instructions text flow, localize skill window texts, fixing black minimap, localization of pseudo recipes, fix UI flickering in crafting, a translatable message on give_item, fixing a crash on server list removal, a repair UI rework, fix wrong button highlight in interface settings, preventing empty server list entries, removal of unused translation keys, correcting the NixOS Wiki link and partial archive upgrades in airshipper. Ongoing (unmerged) work is happening on new sword animations, potion rework, glider courses, a winit update, repair UI overhaul, a chat clear command, new translations, gamepad bindings, updated contribution guidelines, riposte, hydra, and mud/swamp. Translation work</h2> No translations have been merged in these weeks. Development discussions</h2> @Isse is working on Hydra and @unii created a video Your browser does not support the video tag. </video> </figure> @unii posted</a> interesting videos of how to combat a mindflayer more safely with a shield. @zesterer found procedural running on YouTube and is tempted to implement this in Veloren </iframe> </div> </figure> Airshipper Partial Download by @xMAC94x</h2> Ever wondered why Steam updates are so fast and Airshipper requires you to redownload 390MB each week? That's because Steam has differential updates, they know what files don't need to change and only update what is necessary. Veloren on the other hand didn't have this feature, our updates were meant to re-download the complete game and replace the old folder with the new one. This will change with the next Airshipper version 0.12. We will enable differential updates by default with a fallback to full updates. This will increase download speed, and also enable us to validate game files for corruption. The following article will deep dive into what improvements we can expect and how the new differential updates work. Improvements</h3> Veloren's differential updates, work on a file-by-file basis, which means that if a file changes (either slightly, or completely) it needs to be re-downloaded. To understand the benefits, we need to understand Veloren's files and how they change. Inside our Veloren installs folder, you will find 2 executables: veloren-server-cli.exe</code> and veloren-voxygen.exe</code>. Being ca, 180MB and 250MB in size. Compared to other games, in Veloren everything is compiled into a single executable, so we don't have any .dll</code> files at all. That means, each week, those files will be updated, and thus, will require a re-download. But wait, 180MB and 250MB is already bigger than the 390MB, how does that work? During download, the files are ZIP compressed, and luckily our binaries can be compressed down to around 100MB in ZIP. So what are the other 290MB? ASSETS! In fact, 250MB out of it are audio files, because audio is already encoded space-efficient, it cannot be further compressed by ZIP. This is where differential updates shine, as most of the large assets, will rarely change, we can keep them, and only download the files that change. So you can expect updates in the future to be much smaller, around ~150MB instead of 390MB! How does it work?</h3> The old download method had a local config file where it stored the local version, it did a lookup to Veloren's servers and compared both versions. When there was a diff, it downloaded a single ZIP file (with all of Veloren's content) unzipped that and updated the local config. The new algorithm does the differential updates on the same ZIP, but instead of downloading the complete zip, it only downloads part of the Zip file. We make use of 3 technologies here: Zip files store a List of all contained files at the end, so we can peek into it, without downloading the whole file</li> Within Zip, each file is compressed separately, which means, we can extract a single file, without reading other files</li> HTTP allows using the RANGE header, which will instruct a server only to send a partial file</li> </ul> Our new algorithm does a lot of work now: It peeks into the Veloren Update Zip, and tries to get a list of all files, there is a checksum for each file.</li> It verifies the checksum of those files locally and generates a list of updated files</li> It only downloads those files, with the help of RANGE requests</li> </ul> There is a drawback with this method, we need to do multiple HTTP calls, and many small calls take longer than a single large call. That's why there exists some fallback logic, in case too many files change at once, Airshipper will fall back and re-download the whole zip. Another drawback is that we need to read all local files to get their CRC checksum, however, with modern SSDs, this is quite fast (~2s) and gives us free, integrity checks. So when Airshipper v0.12 will be released? Unfortunately, it will still take a few weeks to prepare everything, but we hope to bring this awesome feature to you, to save you a few GB of monthly downloads :) This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Do you also see the monster with the yellow eyes over there? See you next time! </figcaption> </figure> Three Weeks in Veloren 236 Sat, 13 Jul 2024 00:00:00 +0000 These weeks, we look at photos and videos. - Christof, TWiV editor Contributor Work</h2> Thanks to last three weeks' contributors @uniior, @neura, @horblegorble, @james, @sam, and @xMAC94x. The merged work includes armor pricing, updated dependencies, new noise patterns, recipe pricing, charm recipes in crafting, display learned recipes, a toolchain update, new sword animations, harvester, wood golem and chieftain rework, and windows build fixes. </figure> Ongoing (unmerged) work is happening on vampire castle, NPC animation in plugins, NPCs going to bed at night, fixing a black minimap, armor scaling, updating winit, new potions, and gamepad bindings. Development discussions</h2> @necti created a guide for mindflayer solo combat: </iframe> </div> </figure> and @unii provided this alternative strategy: </iframe> </div> </figure> @uniior reworked the sword animations. You can watch a lot of videos of these animations in #veloren-art</a>. Your browser does not support the video tag. </video> </figure> @necti combined Veloren and Minecraft </figure> </figure> </figure> @kHannibal created this centaur </figure> @supa biker created bounty posters</a> for the city centre </figure> @Stefan created many of the screen shots in this issue. Thank you! More Screenshots</h2> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Drifting away, see you next time! </figcaption> </figure> Two Weeks in Veloren 235 Sat, 22 Jun 2024 00:00:00 +0000 These weeks, we muse about conflict resolution. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @Sam, @floppy, Codeberg translators, @uniior, @muphblue, and @James. The merged work includes poise fixes, large bird route fixes, animation restructuring, wood log price fixes, item image export fixes, animation fixes, and a vertical scaling crash fix. Ongoing (unmerged) work is happening on glider courses, charm crafting category, item reorganization, more instruments, vampire castle, admin glider, mage towers, a PvP button, social name display, the new voxygen UI, and TLS fixes for srv. Translation work</h2> Translators included in MR 4503</a>: @CodeVlogs, @evgenkot, @fnetX, @Karaya, @karinator, @loglizzy, @lucius_pilgrim, @Positron832, @PurpleDev, and @Thiagod86. Thanks to the translators, as well as to @fnetX for compiling this lists of contributors. Development discussions</h2> There seems to be some unfortunate TLS QUIC interaction reported by @HostEZ.io, see this thread</a> for more details. The learnable recipes now have a Wiki page</a> detailing what each scroll unlocks and where to obtain it. @xMAC94x resumed the work on partial downloads, see this thread</a> and this older thread</a> for more details. @James is working on glider courses: Your browser does not support the video tag. </video> </figure> </figure> @And_i found Veloren on a banner ad in Minetest, among other open source games: </figure> Disagreement and conflict resolution</h2> Several long term developers got into an argument with each other in a discussion about instruments and sounds. This spiraled into misunderstanding, misattribution and hurt feelings. The repercussions of this conflict lead to some soul-searching among the developers and moderators. During this many day process the following statements were created to summarize the consensus reached: </figure> Helpful tips and things to know for contributors</h3> ① Team leads have veto power. Typically, we work so all contributions can be merged in some state if the original contributor is willing to work with team leads and other contributors. Don't take it personally if a team lead vetos your idea. If you are willing to compromise, open a dialogue and work together towards a better Veloren. ➁ Some community members have a tendency to comment on anything and everything without context or investigation. This isn't helpful and generates lots of less than useful feedback. Often this is paired with strong opinions that could use some softening. It is important to remember that not all feedback needs to be acted on. However, it is also important not to completely ignore people, especially when they are trying to be helpful. ➂ The existence of community feedback and the behavior mentioned in ➁ requires contributors to be able to sift through feedback for what may actually be helpful and ignore the rest. This requires being able to tolerate some degree of unhelpful feedback. ➃ Veloren is a community project open to all kinds of people. This practically guarantees that some people will not act how any given individual wants them to. As a contributor one has to learn how to resolve conflicts. It is one of the many challenges expected when working with a diverse, global team. We believe the benefits of working together far outweigh the challenges. ➄ If someone in the community has a problem with specific actions from specific individuals, they need to report it. It is unfair to the admin and moderation team to expect grievances to be addressed if they are never described and reported. That said, we always strive to keep people invested in our community and would rather use teachable moments to better all of our interactions than ban people. More Screenshots</h2> </figure> </figure> Gliding in up-draft by @Oguz: Your browser does not support the video tag. </video> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Brighter days exist, see you next time! </figcaption> </figure> Two Weeks in Veloren 234 Sat, 08 Jun 2024 00:00:00 +0000 These weeks, we get a preview of vampire castle. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @Neura, @xMAC94x, @ResidentFurryArchUser, @NeutralModder, @SrPapinha, @floppy, @Sam, @crab, @uniior, Codeberg translators, @James, and @horblegorble. The merged work includes cultist dungeon loot balancing, macOS fixes, internationalization of prompt dialogs, changelog corrections, parried debuff rework, Dagon AI corrections, finisher combo fixes, the new Sahagin dungeon, overflow fixes during pick-up, projectile code rework, a RusTLS update, debuff balancing, modifier stat splitting, new chest models, Gnarling attack speed corrections, updated translations, more macOS fixes, world boss AI fixes, kiddo dependency update, learnable recipes📜, hammer balancing, hyper dependency update, a fix for the give command, and two DB migration fixes. Ongoing (unmerged) work is happening on armor balancing, web tokens, new myrmidion dungeon, and menacing AI. Translation work</h2> Translators included in MR 4487</a>: (estimated credits, there might be an overlap with the adjacent MRs) @Positron832, @Karaya, @bov, @fnetX, @CodeVlogs, @karinator, @Thiagod86, @PurpleDev, @loglizzy, @evgenkot, @lucius_pilgrim, @MaxSoniX, @Furrior, @Daxik2x, @masta0fleave, and @Kretka. Thanks to the translators. Development discussions</h2> The new trailer was a bit hidden between other updates in number 232</a>, so if you haven't watched it, it well is worth it. Make sure to turn on the sound as the video is aligned with the rhythm of the music. Also seeing this large host of players roam the world communicates the team spirit of Veloren exploration. Well done, @Necti! Your browser does not support the video tag. </video> </figure> In the same issue we mentioned that @zesterer is porting Super Mario 64 to the gameboy advance, here is a status update </iframe> </div> </figure> @floppy shared screen shots from the vampire castle: </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> A new CI image was installed, see this thread</a> for details. @Fotkurz plans to add NPC sleeping habits and filed unreachable houses</a>. More Screenshots</h2> </figure> </figure> </figure> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. There is a fish in the tree! See you next time! </figcaption> </figure> Two Weeks in Veloren 233 Sun, 26 May 2024 00:00:00 +0000 These weeks, we look at the new Sahagin dungeon and hammer animations. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @James, @TheBest and @Neura, @xMAC94x, @fotkurz, @Christof. The merged work includes new Rock Snapper attacks, making curious potion naming consistent, fixes for newer toolchains, plugin load optimization, switch to Rust nightly 2024-05-14, and many dependency updates. Ongoing (unmerged) work is happening on figures in plugins, cultist dungeon tweaks, a new Sahagin dungeon, parrying, the mage tower and more. Translation work</h2> No updated tranlations were merged these weeks. Development discussions</h2> @ResidentFurryArchUser created support for Feral GameMode</a> and MangoHUD</a> into airshipper (the game launcher). The implementation was discussed and is still unmerged as of today. @horblegorble reworked the admin glider to look like an accelerating glider type: </figure> </figure> @kHannibal created another impressive voxel model: </figure> @Gemu created a castle miniboss, the strigoi </figure> @VGrunner created a video showing the new hammer animations: Your browser does not support the video tag. </video> </figure> 00:00.00 solid smash 00:04.03 wide wallop 00:08.70 scornful swipe 00:11.35 tremor 00:14.00 vigorous bash 00:23.88 spine cracker 00:25.79 breach 00:28.81 thunderclap 00:30.82 seismic shock 00:35.53 iron tempest 00:39.42 upheaval 00:41.76 heavy whirl 00:43.40 intercept 00:45.39 pile driver 00:46.39 lung pummel 00:47.69 tenacity 00:49.87 helm crusher 00:50.88 rampart 00:55.39 judgment </code></pre> Earth shaker Your browser does not support the video tag. </video> </figure> and retaliate Your browser does not support the video tag. </video> </figure> You can also see these on the Wiki</a> @Green12 refined the ice covered vegetation </figure> @floppy created the new Sahagin dungeon and provided some screen shots, more here</a>. </figure> </figure> </figure> </figure> More Screenshots</h2> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. A magical night, see you next time! </figcaption> </figure> Two Weeks in Veloren 232 Sun, 12 May 2024 00:00:00 +0000 These weeks, we can't stop watching the new trailer. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @necti, @Isse, @horblegorble, @Gemu, @crab, @floppy, @fnetX and many Weblate contributors, @allucaneat, @xMAC94x, and @uniior. The merged work includes orichalcum recipe tweaks, tree crowding fixes, change log fixes, forgemaster room fixes, server player stats, a fix for orichalcum helmet with orcs, translation updates, new mesa city furniture, server info examples, hit point balancing, and a new cultist dungeon look. Ongoing (unmerged) work is happening on the new voxygen UI, rock snapper attacks, the admin glider, civilization simulation, a toolchain upgrade, parrying, mage tower, UPnP registering, new hammer skill icons, vampire castle, figure animation in a plugin, gamepad binding UI, and moving moderation info into a database. Translation work</h2> Translators included in MR 4453</a>: bov, CodeVlogs, Daxik2x, evgenkot, fnetX, Furrior, hurzelchen, karinator, Kretka, lucius_pilgrim, masta0f1eave, MaxSoniX and Positron832. Thanks to the translators, as well as to @fnetX for compiling this lists of contributors. Development discussions</h2> There is ongoing discussion about how to properly implement jumping in this thread</a>. You can follow @DungeonLord's path to implement (corn) fields in this thread</a>. See this thread</a> for a preview of @allucaneat's new hammer icons. @Isse is working on a new UI, here you can see a hierarchical radial menu: Your browser does not support the video tag. </video> </figure> @Green12 worked on frost covered vegetation: </figure> @Treeco reworked tree generation again: </figure> Meanwhile @zesterer started writing another game in Rust</a> - Super Mario 64 for the GBA. @allucaneat completed the hammer skill icons </figure> @khannibal created a ghost ship model </figure> @James created a new AoE attack for the rock snapper Your browser does not support the video tag. </video> </figure> @allucaneat finished new furniture for mesa located buildings </figure> </figure> New buff and debuff icons by @LoxSmithEhsan </figure> New videos by @Necti</h2> A Guide to the dwarven mines: </iframe> </div> </figure> and a new Veloren trailer created for RustNL: Your browser does not support the video tag. </video> </figure> Studies on the new cultist dungeon look</h2> </figure> </figure> </figure> </figure> </figure> More Screenshots</h2> </figure> </figure> </figure> </figure> </figure> </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Even rainy days look good in Veloren, see you next time! </figcaption> </figure> Two Weeks in Veloren 231 Mon, 29 Apr 2024 00:00:00 +0000 These weeks, we learn about tree and furniture development. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @necti, @Isse, @crabman, Codeberg users, @Treeco, @miocore, @floppy, @Sam. The merged work includes abyssal rings, sprite offset fixes, model changing attributes, a skating fix, trading fixes, translation updates, redwood and oak tree tweaks, controls setting via mouse keys, loot protection fixes, test server fixes, dwarven mine, hammer skills and crafting search in multiple languages. Ongoing (unmerged) work is happening on ore damage, event server tweaks, rock snapper animation, torvus, balancing, fighting AI, gamepad bindings, vampire castle, learnable recipes, removing outdated items, jumping for non-humanoids, network improvements, the new UI, and effective hit-point balancing. This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Development discussions</h2> @Treeco used tree_density</code> to make standalone trees more bushy and dense trees more straight. </figure> </figure> Later @Treeco created more complex fir tree code. </figure> @floppy, @Gemu and @crabman have continued the work on the dwarven mine. They created new models and reworked the code. @UncomfySilence reported problems found in testing. And … it was merged. Multi-hit mining example by @crabman Your browser does not support the video tag. </video> </figure> New models by @khannibal: Hanging gardens </figure> and a pyramid </figure> See this thread</a> for discussions about temperature effects. Kitchen furniture by @allucaneat </figure> </figure> Magic candles by @allucaneat </figure> Orichalcum helmet and shield </figure> and a newer, less bulky, version </figure> @crab upgraded iced to 0.12 for airshipper, this should fix issues on Wayland and Windows. See this thread</a> for details. @Sam wrote a good explanation</a> of recipes: "This branch introduces learnable recipes to veloren. Starting off, new characters will not know how to craft most items and will need to learn them by finding recipe scrolls through adventuring, trading, or exploration. Scrolls will usually contain knowledge on multiple crafting recipes, and using the scroll will cause it to crumble to dust as its knowledge is learned." @Gemu and @Purple worked on a ferret model </figure> @crab was able to compile airshipper with a stable toolchain, see MR-122</a>. @Isse continued their work on a new UI, see here for an update: Your browser does not support the video tag. </video> </figure> @crab added a way to query the number of active players for servers, see this thread</a> for details. @uniior continued his work on hit point balancing: "Experimented with a generalized (approx.) +100% HP increase on T3Bs, +60% on T3As, +20% on T2s and +10% on the T1s with higher values, though I'll get around to test these changes once I finish my break from the game. Keep in mind that the new EHP values should still be considerably lower than the ones on master as a result of the overall nerf to NPC armor items." @allucaneat created more elaborate icons for the hammer skills. See all of them here</a>. </figure> @Sam started reworking jumps in MR-4441</a>. @Treeco looked into colored stars for constellations </figure> @Sam asks for bow skill ideas</h3> With hammer rapidly approaching completion, it is time to begin thinking about what the bow rework will entail. The bow is intended to provide a more skirmisher oriented playstyle ensuring you have ways to keep some distance between yourself and your enemies. You will also be able to coat your arrows with some items if you have them in your inventory, which will provide some extra effects to your arrows. Suggestions for bow abilities can be made in the form here</a>. </figure> Feature list for moderation tool by @crab</h2> I'll just put up a list of required features for the moderation panel in case anyone is very urged about us stopping to log messages to eViL Discord and is willing to do a bit of coding (I'm aware some of these are already (partially) implemented, ty xmac): Chat-like scrolling through global and regional messages (with features such as scrolling to the last read message).</li> Filtering messages by channel (/world, /say, /region) and players (I'm deliberately not saying username, as those can be changed now).</li> Permanently (not just 30 days or for whatever duration messages are kept currently) linking to a message and all it's surrounding context.</li> Some way to moderate usernames, by either display all new unseen ones or showing a list of the most recent ones (replaces /players</code> on torvus)</li> Good UX please</li> Ask all other currently active moderators (ie. @necti @UncomfySilence @isse @C ᪲ ) if they have something to add to this list.</li> </ul> </figure> Apart from the moderation panel: A history-less bridge for normal player usage (and moderators, to ie. calm down chat or give warnings). Even after this is done, anyone could be running a torvus-like bridge (which requires no special permissions whatsoever) without someone knowing, pushing all messages sent in global chat to some online service. Global chat is in fact, 'global', and you should expect anyone with an internet connection to have access to it.</li> </ul> See the full discussion here</a>. More Screenshots</h2> </figure> Translation work</h2> Translators included in MR 4434</a>: @arthuradolfo, @bov, @dyegomb, @evgenkot, @FelipePardim, @fnetX, @Furrior, @GGTheTranslator, @Kretka, @loglizzy, @LS-Localicows, @nwildner, @Positron832, @RyanOrigins, @Sovenok-Hacker, @Thiagod86 Translators included in MR 4439</a>: Daxik2x, @dyegomb, @evgenkot, @fnetX, @Furrior, @hurzelchen, @loglizzy, @lucius_pilgrim, @MaxSoniX, @nwildner, @Positron832, @rmorettibr, @Sovenok-Hacker, @Thiagod86 Thanks to the translators, as well as to @fnetX for compiling these lists of contributors. Fiery encounter in the depth of the mine, see you next time! </figcaption> </figure> Two Weeks in Veloren 230 Sat, 13 Apr 2024 00:00:00 +0000 These weeks, we learn about tags for code documentation and many ongoing development activities. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @gamer-kold, @ThomasS, @crabman, @Dmitry, @zesterer, @horblegorble, @srpapinha, @newclarityex, @Treeco, @necti, @walpo, @lunareclipse and @uniior. The merged work includes a Rodio (audio crate) update, sign and lantern translation enabling, a rope panic fix, Easter egg and April fool's calendar items, NPC movement planning, miscellaneous post-party cleanup, more ambient light in at dawn and dusk, bombs and fireworks in higher level chests, translation updates, lower parrying costs, petting animals, a Rodio panic fix, Brinestone armor repair costs, Tursus and Wendigo balancing, Troll armor, Code ownership documentation, material price corrections, NPC walking path computation fixes, amd more furniture sprites. </figure> Ongoing (unmerged) work is happening on Dwarven Mine, calendar selected shaders, Hammer skills, moving moderation info to a database, friend groups, documentation cleanup, separate character behavior and posting state updates, Mage Tower, worldgen outside the map, trading fixes, a pet rework, hit point rebalancing, entity to terrain tethers, code documentation tags, merging the book into the main repository, merging Torvus into the main repo, better parrying, and translations. This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Development discussions</h2> If you want to read into the pathfinding bug hunt and solution genesis take a look into #programmers</a>. Entity to terrain tethering by @crab features promising previews: Your browser does not support the video tag. </video> </figure> @zesterer started a discussion on a much improved level of detail implementation in #worldgen</a>. The discussion about quests really took off in MR-1970</a>. You can follow the discussion about the petting animals in #pets-and-mounts</a>, here is a video Your browser does not support the video tag. </video> </figure> Similarly for blocking in #combat/V4416</a> Your browser does not support the video tag. </video> </figure> @Gemu is currently designing a low level foe </figure> @uniior is designing new furniture for Veloren, see #veloren-art</a> </figure> @Treeco and @xMAC94x work on upgrading to a newer Rust tool chain, see #meta</a> for problems and their potential solutions. @xMAC94x and @crablet discuss torvus and future moderation tools in #V4159 "Merge torvus"</a>. @horblegorble plotted the health and armor of overworld entities, as a tool for future balancing work V4422 "Various tweaks to entiti…"</a>, e.g. </figure> and (effective hit points vs damage per second inflicted by player over progression) </figure> Hammer skill progress in #combat</a>: </figure> </figure> Code documentation tags by @zesterer</h2> MR-4423</a> explains the new code documentation tags, this is still work in progress: So I've got an idea for a docs thing that I want to try implementing and I'd like some feedback to those that feel like they're still relatively new to the codebase (or, at least, feel like there are large areas that are still a bit of a mystery to them). The name I'm giving it is the 'tag system'. We'd introduce a little macro, like the following: tag!(my_tag_name) </code></pre> What this does is associate the location it's used in with some higher level docs about a particular concept. For example, you might tag code that handles entity Alignment</code> and damage calculations with a section of the docs that explains how all of those pieces fit together like tag!(alignment)</code>. Tags would need to be declared up-front in a common place (mostly to aid casual discoverability and reduce the chance of two tags accidentally being created for the same concept). </figure> The goal is twofold: Firstly, the tag name is easy to search throughout the codebase. Secondly, the macro will - internally - create a unique type associated with that tag so you should be able to right click on it and use your editor's built-in 'find references' or 'go to implementation' feature to navigate through associated parts of the codebase (I need to first double-check that this actually does work through a macro, but I think it should). Hover over tags to get documentation, works</li> Find other uses of the same tag by 'Find references', works</li> Actually write the tags and use them in appropriate places, not done yet</li> </ul> The tag macro can now be invoke like this: tag!(@tag1, @tag2, ...)</code>, the reason I decided to add a @</code> before each tag is to make them grep-friendly, as tags are usually very common words. Tags are defined as modules in common/src/documentation/tags/</code>, the module-level documentation is what will show up when hovering over a tag. This unintentionally allows for subtags too, which can simply be defined as submodules of tags and referenced with tag!(@tag1::submodule::subsubmodule)</code>. This MR also contains videos showing code navigation using Helix Your browser does not support the video tag. </video> </figure> and VSCode Your browser does not support the video tag. </video> </figure> . Design document links</h2> The #game-design channel</a> contains several pinned messages which link to design documents. As @DaForLynx just pointed to one of them, here are some links to interesting Google-docs (incomplete list): Veloren High Level Design Plan</a></li> Material Progression/Soft natural biome progression</a></li> The folder containing these</a></li> Related: Voxel Model folder</a> posted in #groups-and-links</a> (Archive)</li> There is also the newer gitlab based roadmap</a> in The Book</a>.</li> </ul> </figure> More Screenshots</h2> </figure> </figure> </figure> </figure> Translation work</h2> Translators included in MR 4411</a>: @aleeo, @Caddis, @Dinariossa, @DiXiao, @evgenkot, @fnetX, @fvasco, @GeroinEX, @GGTheTranslator, @Ixniyevonn, @karinator, @Kretka, @kurtinge, @leca, @loglizzy, @LS-Localicows, @mapemka, @Paw, @Positron832, @Sinari, @Sovenok-Hacker, @tdehtyar, @TheESN, @Thiagod86, @walpo Translators included in MR 4427</a>: @bov, @FelipePardim, @fnetX, @GGTheTranslator, @Kretka, @kurtinge, @loglizzy, @LS-Localicows, @nwildner, @Positron832, @Sinari, @Thiagod86, @Witch Thanks to the translators, as well as to @fnetX for compiling these lists of contributors. Hi(gh)jacking a ship, see you next time! </figcaption> </figure> Three Weeks in Veloren 229 Sat, 30 Mar 2024 00:00:00 +0000 These weeks, we show visual improvements and the new Web UI. - Christof, TWiV editor Contributor Work</h2> Thanks to last three weeks' contributors @fnetX and @juliancoffee, @gamer-kold, @fvasco, @xvar, @ThomasS, @Isse and @Christof, @uniior, @Hrom and @crabman, @xMAC94x, @walpo, @zesterer, @Synis, @Treeco, and @KayHemme. The merged work includes many updated translations, an updated Nix flake, a database index optimization, more specific NPC dialogs, loading plugins from the server, spots in plugins, removing pillars from Sahagin and Myrmidon dungeons, loot table balancing, a web UI for the server, ChangeLog spelling fixes, revised cacti, roll balancing, dependency updates, revised general skills, CI caching, shader improvements (cloud, horizon, LoD), cave biome updates, many new LoD models, friendly fire and PvP auras in desert city arenas, label adjustments in trade dialog, a new single-player world, and finally the 0.16 release. Ongoing (unmerged) work is happening on terracotta boss tweaks, NPCs in plugins, test server fixes, sprite attributes, friend lists, loot exporting, fluid dynamics, ore damage counting, durability tweaks, attack AI fixes, a Rodio update, more efficient network encoding, a new Veloren logo, a new UI technology, and spawning voxel models. This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Miscellaneous</h2> @juliancoffee and @crab are working on sprites which change appearance based on their state (lantern on or off and growing plants, or later open and closed chests) MR 4359</a>. Debug Window update: The new UI developed in this thread</a> really generates interesting proof of concept images: </figure> Server Web UI: Your browser does not support the video tag. </video> </figure> @juliancoffee: "We rolled out some buffs. Now all characters start with maxed HP, energy, and roll skills. Additionally, roll energy penalties during interrupts don't apply anymore, instead remaining recovery jumps to roll buildups, and iframes only apply during movement stage." @Treeco: "I made some improvements to LOD objects which hopefully will be merging before freeze" (Update: They were merged in time) </figure> </figure> </figure> </figure> More Screenshots</h2> </figure> </figure> </figure> </figure> </figure> </figure> Translation work</h2> Translators included in MR 4376</a>: @bov, @fnetX, @FruityHarriott, @karinator, @loglizzy, @Positron832, @Sinari, @walpo Translators included in MR 4386</a>: @bov, @dyegomb, @fnetX, @FruityHarriott, @fvasco, @juliancoffee, @karinator, @Positron832, @Sinari, @valebest26, @walpo, @Witch Translators included in MR 4397</a>: @aleeo, @bov, @Caddis, @Dinariossa, @DiXiao, @evgenkot, @fnetX, @FruityHarriott, @fvasco, @GeroinEX, @GGTheTranslator, @Ixniyevonn, @karinator, @leca, @mapemka, @Paw, @Positron832, @Quini98, @Sovenok-Hacker, @tdehtyar, @thatevilman, @TheESN, @walpo </figure> And by Language</h3> Contributions since February 19th, DevBlog 227</a>: Dutch: Quini98 (13), FruityHarriott (5), thatevilman (2)</li> English: fnetX (63), walpo (60), GGTheTranslator (2), Positron832 (1)</li> French: fnetX (132), bov (126), Dutchy5 (101), GGTheTranslator (42), Nylux (8), Nifou (5), thomas-babord (2), AldanTanneo (1), Vallley (1)</li> German: fnetX (771), karinator (53), Jasmia (1)</li> Italian: fvasco (110), valebest26 (2)</li> Portuguese: loglizzy (6)</li> Portuguese (Brazil): Thiagod86 (2), dyegomb (2)</li> Russian: evgenkot (257), Paw (36), aleeo (20), Sovenok-Hacker (19), DiXiao (13), Ixniyevonn (8), tdehtyar (4), GeroinEX (2), TheESN (2), Caddis (1), mapemka (1), leca (1), Dinariossa (1)</li> Spanish: walpo (2116), juliancoffee (4), Vybearz (2)</li> Swedish: Positron832 (854)</li> Ukrainian: Sinari (118), Witch (52)</li> </ul> A Big Thank you!!! from all the players playing Veloren in a non-English setting. 0.16 Release</h2> On March 30th the 0.16 release party took place, see the release stream at </iframe> </div> </figure> </figure> </figure> </figure> Sandy dune vibes, see you next time! </figcaption> </figure> Veloren 0.16 Release Mon, 25 Mar 2024 00:00:00 +0000 0.16 Release</h2> Veloren is finally releasing 0.16! It has been 9 months since 0.15 was released so there has been a lot of work put into this version. If you're reading this before 18:00 GMT on March 30th, make sure to join the release party. On the side, you can also watch the release party dev stream</a>, where we'll be chatting with devs about what went into this version. To join, you can download the game for free at veloren.net</a> and create an account</a>, then launch the game and hop on the default server. See you there! We'll also be having a vote on Discord for the new map to use for the official server in the coming days. Be sure to check that out! New in this release</h3> Here are some of the changes in this release: New axe skill tree.</li> Two new dungeons, haniwa catacombs and terracotta ruins.</li> Some new structures: airship docs, taverns and desert arenas.</li> We got a cool new mesa biome, where the mountain towns are built now.</li> Caves got a really cool update, with new cave biomes, be sure to check them out!</li> We are finally using a new wgpu version which allows people to run the game using OpenGL.</li> Plugins have gotten updates and it's now supported for servers to have plugins which are shared with the client when joining.</li> Map generation UI for singleplayer in voxygen.</li> Many balancing changes.</li> New models and shader changes so the low level of detail terrain will look a lot better.</li> While gliding you can now encounter updrafts.</li> </ul> Changelog</h3> As always, there are always more changes than we can add to a single post! You can check out the full changelog here</a>. Thanks to this versions contributors (in random order): Laura, Monty Marz, Yusuf Bera Ertan, Animoe, Gemu Peachems, Talha Qamar, BigKhan, Xiretza, Keegan-JW, Marcel Märtens, Tim Vincent, Woeful_Wolf, Youssef Fahmy, Pybit, Uniior, Haijo7, TelepathicWalrus, Treeco, JimmyDdotEXE, Benoît du Garreau, Dmytro Kovalchuk, Froggy, Hugo Famechon, Neras, Illia Denysenko, HEIEnthusiast, Joshua Barretto, Javier Pérez, Sorann753, JCoxeye, David Fisher, danielkenji83, Syniis, crabman, Igigog, Jaroslav Lichtblau, Francesco Vasco, Darren Salt, Otto Richter, Py bit, Thomas S, flo666, Justin Shipsey, Dominik Broński, Marcel, Avi Weinstock, Ben Wallis, Raul Wagner Costa, Stefan Glorch, Nadja von Reitzenstein Čerpnjak, Isse, Gaxrodi, walpo, Sam, Joaquin Tornello, Christof Petig, PopeRigby, nectical, RunRobDog, jshipsey, juliancoffee, Hrom, tygyh, Samuel Keiffer, Youser Nayme, Michal Sroczynski, Evgen Kot, UncomfySilence, 心慌慌脸红红, Brandon Dyer, uniior, James Hiew, laundmo, Sanctorum Thomas, do-no-van, Imbris, evgenkot, Scott Bronson, flo, João Capucho, DaforLynx, Jeffrey Cox, James Melkonian, Michał </blockquote> Since the last release we have started using Weblate for translation contributions. Those contributors are listed here (in random order): tidare, Vuizur, juliancoffee, AldanTanneo, guillermytho, Paw, marcelodemonn, Nylux, Vybearz, 5Litt, DiXiao, ezamux, Jasmia, Timm, thomas-babord, zoli111, leca, Renkal, macintosh, zerocraft, GeroinEX, RyanOrigins, Vallley, mapemka, tdehtyar, alextecplayz, Nifou, Axegaik, jadedctrl, loglizzy, Sinari, Dutchy5, aleeo, DominicF96, FruityHarriott, evgenkot, Witch, alexjhr, valebest26, fvasco, karinator, walpo, bov, jiangyi, Sovenok-Hacker, thatevilman, fnetX, SomeTr, Ixniyevonn, mozz, Positron832, dyegomb </blockquote> Support the project</h3> As always, feel free to support the project on Open Collective. It allows us to keep our servers running, and launch great release parties like the one for this release! Two Weeks in Veloren 228 Sat, 09 Mar 2024 00:00:00 +0000 These weeks, we learn about glider physics, Weblate preference and plugin architecture. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @uniior and @crabman, @imbris, @danielkenji83, @floppy, @necti, @do-no-van, @fvasco, @Synis, @juliancoffee, @otto.splvs, @walpo, @neras. The merged work includes more beginner balancing, shaderc optimization fixes, attack blocking, terracotta tweaks, glider buffs, sword vs speed buff balancing, more sword balancing, translation updates, cave updates 💎, more flexible asset autocompletion, a bunch of Weblate translations, generating worlds from the command line, body transformation, translation fixes, enemy balancing in terracotta ruins, lots of translation enhancements, chat window updates, glider fixes, gliding travelers, admin broom improvements, beam aiming fixes, dependency vulnerability fixes, loot table simplifications, dropped item merge, better character loading debugging, admin glider, and pets for NPCs. </figure> Ongoing (unmerged) work is happening on learnable recipes, vampire castle, spots in plugins, loading plugins from the server, quadtree LoD tiling, animated NPCs in plugins, attack balancing, bitcode for more efficient network communication, dwarfen mines, NIX script updates, sword animation, structure data loading, sprite attributes, a new voxygen UI, hammer skills, mage tower, attack radius, further cave changes, aabb_in_circle</code> refactoring, rock snapper animation, test server fixes, inventory overflow, aerodynamics, loot table in structure rework, loot table balancing, merging torvus and more Weblate translation updates. Phew, there is a lot of coding going on at the moment! </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Miscellaneous</h2> Mushroom spores Your browser does not support the video tag. </video> </figure> The community voted</a> to keep "energy" over "stamina" in descriptions. </figure> The discussion about using a different or even creating a custom UI crate for veloren rekindled</a>. Tweaks, fixes and additions to air content by @juliancoffee</h2> Glider physics</h3> So, remember the update to the glider which left some people upset? Well, sorry, although we did buff it later, so I guess it's fine now :). But I'm here to announce a new change, more like a bugfix, to be honest. Two things: Actual wind. We missed it in the client-side calculation of gliding, this update enables it, and it's much cooler now. Your gliding ratios will naturally be affected by it, if you fly into the wind, your horizontal velocity will be lower, while vertical one is the same, which means you will cover less distance until you touch the ground. But the same is true if you follow the wind, in that case, your velocity is buffed by it, which means you can cover more distance until you touch the ground! Whether the wind goes where you want to go or not might be the question of luck, yes, so ... I wish you all good luck!) </li> Ridge lift. Here @Treeco might add more (he was responsible for fix in this MR), but conceptually, the more steep the terrain is, the bigger lift you get, because the wind pushes into the ground and bounces from it. If it pushes into the mountains, the only way it can go then is upward, so you get a massive boost there. Here is the video during the strong storm. (Note, air velocity and actual upward gliding velocity). </li> </ul> Your browser does not support the video tag. </video> </figure> NPC Gliding AI</h3> For a while, humanoid NPC with gliders did equip the glider when reaching the velocity limit soon after which they would receive fall damage, but the way they controlled their glider was wrong, and they did stall very frequently. Now, this problem is fixed, as they are using their glider maybe even better than Voxygen's automatic glide feature. </figure> Admin tools</h3> For a while, we had The Broom in /kit debug, it resembles the legends of witches using them to fly, but the actual implementation and visuals were close to non-existent. So I did improve things a little, by adding better particles and orientation. There's an intermediate state shown in the video below, and since then we have improved things to change orientation based on velocity (so now the animation also changes depending on whether you fly up or down) and better particle positioning, which can be seen if you try to fly straight down. Your browser does not support the video tag. </video> </figure> And, for a long time, I was working on Admin Glider. The goal was revamping internal ability systems, as for now we only can have them on weapons, which is limiting, we want to do more. Also, it's a chance to experiment with the glider itself and explore different gliding physics effects. Here is a very short demo. Your browser does not support the video tag. </video> </figure> Here is the recorded video: </iframe> </div> </figure> In the future it allows us to be more flexible with where our abilities come from, so we can implement things like fishing, better mining, armor abilities, fist fighting and so on. Comments by @Treeco: So, ridge lift isn't a new feature, and in fact we've made it weaker than before, but previously it applied in the wrong places. It's meant to represent horizontal wind being deflected upwards by hillsides, generating updraughts, however we were calculating steepness incorrectly, such that plains were maximally steep, and a sheer cliff faces were considered horizontal. This lead to unexpected, random, strong thermals while travelling, and was generally just confusing. It seems to work more as expected now. Animated characters in plugins by @Christof</h2> This figure has a separate idle and running animation </figure> I have a working animation inside a plugin, connected via WIT</a> (so I could also write the animation in C++, java script or python), hot reloading for plugins isn't working, yet, but it is already very cool! Plugin source code</a> And these are the most amazing features of all: you can compile the plugin with only a copy of the wit, no veloren sources are required</li> you can debug the plugin in chrome, single step into Rust independent of veloren:</li> </ul> </figure> </figure> The output of the tested function: </figure> And the JS test harness</a> import {animation, events} from './anim.js' import {getBody} from './veloren/plugin/actions.js' events.load('single-player'); let bodyidx = getBody("lizard"); let body = new animation.Body(bodyidx); let dependency = { velocity: [1.0, 2.0, 0.0], ori: [0.0, 0.0, 0.0, 1.0], lastOri: [0.0, 0.0, 0.0, 1.0], globalTime: 0.2, avgVel: [1.0, 2.0, 0.0], state: 'run', }; let skeleton = body.updateSkeleton(dependency, 0.1); console.log(skeleton); </code></pre> Important translation announcement by @juliancoffee</h2> TL;DR from now on, Weblate is the only accepted way to get your translations into the game. Now, if I may, a little history. For some time, we used a simplistic internationalization system via config files. Our game is written in Rust and for config files, we use .ron</code> files. If you know what JSON is, you get the idea, but simply put it's a way to represent common data structures like numbers, strings, lists or objects, using a strictly defined format. Our data structure for translations is an object that maps localization keys to the translated text. </figure> /// WARNING: Localization files shall be saved in UTF-8 format without BOM /// Localization for "global" English ( string_map: { // SCT outputs "hud.sct.experience": "{amount} Exp", "hud.sct.block": "BLOCKED", }, vector_map: { } ) </code></pre> The snippet above defines two keys: hud.sct.experience</code> and hud.sct.block</code>. There are some disadvantages to using it, and I think you will figure them out for yourself. However, the main disadvantage is that this format is only used in Veloren, so there is no tooling for it. We could build this tooling ourselves, and we tried, but what we ideally need is some production-ready solution we and our translators (yes, I'm looking at you, the person behind the screen :3) can use. So we started by changing the underlying format to Fluent, a localization format by Mozilla. We could go with something older like gettext, but we decided that Fluent will serve us better, as we're building the game, and we need more modern features. </figure> hud-sct-experience = { $amount } XP hud-sct-block = BLOCKED </code></pre> This is the same snippet, much easier to write and read, don't you think? That solved a lot of problems but didn't solve the main one: You still need a lot of expertise to get your translation into the game. The only way to get anything into the game is by committing it to the git repository, which means you need to at least know what that is, and then how to use it. Ideally, we prefer you also wouldn't burn out in the middle of doing all of it. That's where Weblate steps in. It's a web interface, you can open it in your browser, just go to https://translate.codeberg.org/projects/veloren/#information</a>. After you log in, you can start suggesting translations, simple as that. Then, either your translation is reviewed by dedicated members of the translation team, or you get three upvotes from the community and soon after that, the next time you get the update from Airshipper, it will include your work! Check our translator documentation for more: https://book.veloren.net/contributors/translators/game-translation.html</a> For better or for worse, I'm here not to tell you the story, but to share a decision we made. In the past, the only way to get your translation in the game was to open a Merge Request on GitLab and get it reviewed and merged. It was unnecessarily hard for non-programmers, and we introduced Weblate as an alternative way. </figure> Recently, we focused our attention on Weblate and made it the recommended way to translate. Weblate helps us with the organization of the translation team, we can define per-language reviewers, and if not we have escape-hatch in terms of community voting, multiple people can work with the same language at the same time, which wasn't possible with git-based workflow, it provides a lot of useful stats, it even has some automated checks. There are downsides to it, as it makes the feedback loop much bigger, but there are some ways to make it shorter. Also, it's a bit longer to review contributions in Weblate, but we believe it can be solved in the future. That said, git isn't happy when multiple entities touch the same part of the project and requires careful coordination of workflows, which puts a lot of work on maintainers, so we needed to choose, and we have chosen Weblate. If you contributed via GitLab in the past, reach out to us, there is a high chance we will give you a reviewer role in Weblate, leave a comment on your accepted GitLab MR, so we know that's you. Screenshots</h2> </figure> </figure> </figure> </figure> Paradise Island? See you next time! </figcaption> </figure> Two Weeks in Veloren 227 Mon, 19 Feb 2024 00:00:00 +0000 These weeks, we finally thank the many weblate translators, announce 0.16 release schedule and look into the cave rework. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @xMAC94x, @brons_glb, @juliancoffee, @naddl, @crabman and @uniior, @Isse, @laundmo, @zesterer, @Christof, @imbris, @fvasco, @evgenkot, @y.hfahmy, @floppy, @james. The merged work includes a Rust tool-chain update, weapon crafting hints, a chat display fix, server command extensions, many dependency updates, SRV DNS lookup, critical chance RON cleanups, separate event busses, wind affect on gliders, aiming tweaks, WIT based plugins using wasmtime, removing debug output, a metal shader fix, Italian translation updates, loot localization, entity deletion fixes, more signals for shutdown, beginner balancing, terracotta ruins, shader optimizations, contagious burning, and Phoenix tweaks. </figure> Ongoing (unmerged) work is happening on character gender change, bank storage, shader improvements (horizon, cloud, LoD), loading plugins over the network, ore damage count, network connection improvements, civilization simulation, sword balancing, snakes, and a server GUI. This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Miscellaneous</h2> @juliancoffee proposed an onboarding documentation at https://gitlab.com/veloren/veloren/-/issues/1944</a> and is looking for feed-back. @xMAC94x modernized the Rust compiler version and many dependencies, therefore merge request should rebase on master before push to reduce the load on CI servers. An update on steel drum design </iframe> </figure> A 3D modelled Veloren character </figure> New treeant sapling attack Your browser does not support the video tag. </video> </figure> Psychedelic colors by @ThatOneMonkey369, see this discord thread for explanation and code</a> </figure> Bug report: Floating houses </figure> Updates by @juliancoffee</h2> We now have /into_npc</code> command, which is similar to /make_npc</code>, but instead lets you transform into the required NPC which may be useful when adding one … or just for fun! It doesn't support alignment and group manipulation, but it can be added later. The following picture shows this functionality in action: </figure> And … grandiose update to our gliding mechanics, we now have wind simulation, and your glider will behave differently depending on some conditions. We already did post about in devblog-212</a>, and now it's finally going live. We did tune it to our usual gliding capabilities, yet don't worry, we didn't nerf it too much, and you can still get the wind which will even lift you upwards if you're lucky :). See also the video in the previous issue. Oh, and Admin Glider sneak-peek, which may or may not be actually live when people will see this post. </iframe> </div> </figure>New airshipper by @Isse</h2> I published the newest Airshipper version on crates.io</code></a>. Which means that doing cargo install airshipper</code> is now possible to do. I will also be maintaining this with newer versions of airshipper in the future. One issue I ran into while doing this was that the max compressed package size on crates.io is 10 MB. But trying to publish Airshipper it was 14 MB. Most of this size, 11MB, was from a font we used for the server browser where we need to support most unicode symbols. What I ended up doing is using the system font for the crates.io package instead, meaning that on some systems it might look a bit different from the Airshipper builds we produce. Translation updates by @walpo</h2> The translation team has updated the documentation for translators, featuring Weblate as the recommended method to translate the game. https://book.veloren.net/contributors/translators/index.html</a> The translation workflow is defined better. The current workflow is attached. </figure> Car racing event by @Vagabond and @necti</h2> </figure> </iframe> </div> </figure>0.16 release on March 30th by @xMAC94x</h2> The 0.16 release is on Saturday, 2024-03-30 18:00 UTC As usual, there will be a feature freeze starting from 2024-03-23 18:00 UTC. We recommend submitting critical and large MRs for review now, before the feature freeze. This release will also have a stress test event between the feature freeze and the release. We will be sharing further details of this later. </figure> Getting your large MR merged before feature freeze</h3> Please mention @xMAC94x in the ⁠0.16 release MRs thread</a> with a short summary with the following details (the more, the better): What is complete</li> What needs to be done</li> Can your feature be partially introduced to master in its current state (as multiple MRs)?</li> Do you foresee any issues with your MR and if so, which ones?</li> Why should this feature be in 0.16?</li> </ul> This is required to align our testing and review strategies to ensure a smooth release. </figure> Schedule</h3> 2024-03-23 18:00:00 UTC Feature freeze — No new feature MRs will be merged. 2024-03-25 18:00:00 UTC Stress test event. 2024-03-29 10:00:00 UTC Total freeze — no new merges will be introduced unless they're critical. 2024-03-29 16:00:00 UTC Release build will be compiled. 2024-03-30 18:00:00 UTC Release party! </code></pre> Cave rework by @Synis</h2> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> ContentDeliveryNetwork switch</h2> </figure> Previously we used direct links to the images posted in Discord from the devblog. Now the links got an expiry date and people saw long delays in loading them we switched to Wasabi. A huge shoutout to @walpo for driving this transition and fixing all the links after uploading the material. </figure> Translation attribution</h2> I had trouble find a proper way to attribute the countless contributors to our translations in weblate, @walpo helped out with a proper link: https://translate.codeberg.org/projects/veloren/#reports</a>. I am still looking for a good way to present this, but here are the contributions from the past 14 months. Thank you! To all people involved! </figure> Arabic (Saudi Arabia): walpo (22)</li> Basque: walpo (38)</li> Belarusian: walpo (38)</li> Bulgarian: walpo (7)</li> Catalan: walpo (37)</li> Chinese (Simplified): walpo (38), mozz (10), jiangyi (5), zerocraft (4)</li> Chinese (Traditional): walpo (22)</li> Czech: walpo (38), 5Litt (1)</li> Dutch: walpo (34)</li> English: walpo (20), fnetX (4)</li> Esperanto: walpo (36), jadedctrl (1)</li> </ul> </figure> French: Nifou (51), walpo (40), fnetX (30), DominicF96 (11), ezamux (8), Timm (4), Vallley (1)</li> German: fnetX (183), walpo (39), Vuizur (3)</li> Hungarian: walpo (38), zoli111 (3)</li> Italian: walpo (37)</li> Japanese: walpo (36)</li> Korean: walpo (39), l3nemy (1)</li> Norwegian Bokmål: walpo (34)</li> Polish: walpo (39)</li> Portuguese: walpo (22), loglizzy (3)</li> Portuguese (Brazil): walpo (38), RyanOrigins (4)</li> </ul> </figure> Romanian: walpo (38), alextecplayz (12)</li> Russian: tdehtyar (46), walpo (39), DiXiao (33), Paw (15), GeroinEX (15), Ixniyevonn (6), Sovenok-Hacker (4), aleeo (3), leca (2), Axegaik (1), mapemka (1), evgenkot (1)</li> Serbian: walpo (38)</li> Spanish: walpo (50), macintosh (27), TestVelorenAccount (2), alexjhr (1)</li> Spanish (Latin America): walpo (39), marcelodemonn (24), guillermytho (3)</li> Swedish: walpo (39)</li> Thai: walpo (39), tidare (4)</li> Turkish: walpo (37)</li> Ukrainian: walpo (38), SomeTr (23), Renkal (11), juliancoffee (7)</li> Vietnamese: walpo (38)</li> </ul> </figure> Name</th> Count total</th> Edits total</th></tr></thead> fnetX</td> 245</td> 5833</td></tr> walpo</td> 1087</td> 5816</td></tr> Nifou</td> 51</td> 2884</td></tr> DiXiao</td> 33</td> 862</td></tr> tdehtyar</td> 46</td> 711</td></tr> macintosh</td> 27</td> 378</td></tr> Renkal</td> 11</td> 294</td></tr> GeroinEX</td> 15</td> 292</td></tr> marcelodemonn</td> 24</td> 221</td></tr> Paw</td> 15</td> 196</td></tr> guillermytho</td> 3</td> 153</td></tr> juliancoffee</td> 7</td> 133</td></tr> SomeTr</td> 23</td> 114</td></tr> mapemka</td> 1</td> 93</td></tr> evgenkot</td> 1</td> 84</td></tr> Ixniyevonn</td> 6</td> 60</td></tr> aleeo</td> 3</td> 57</td></tr> ezamux</td> 8</td> 53</td></tr> Timm</td> 4</td> 52</td></tr> Sovenok-Hacker</td> 4</td> 37</td></tr> TestVelorenAccount</td> 2</td> 22</td></tr> leca</td> 2</td> 21</td></tr> alexjhr</td> 1</td> 20</td></tr> DominicF96</td> 11</td> 19</td></tr> Vallley</td> 1</td> 19</td></tr> alextecplayz</td> 12</td> 0</td></tr> mozz</td> 10</td> 0</td></tr> jiangyi</td> 5</td> 0</td></tr> RyanOrigins</td> 4</td> 0</td></tr> tidare</td> 4</td> 0</td></tr> zerocraft</td> 4</td> 0</td></tr> loglizzy</td> 3</td> 0</td></tr> Vuizur</td> 3</td> 0</td></tr> zoli111</td> 3</td> 0</td></tr> jadedctrl</td> 1</td> 0</td></tr> Axegaik</td> 1</td> 0</td></tr> l3nemy</td> 1</td> 0</td></tr> 5Litt</td> 1</td> 0</td></tr> </tbody></table> Northern shores. See you next time! </figcaption> </figure> Two Weeks in Veloren 226 Mon, 05 Feb 2024 00:00:00 +0000 These weeks, we marvel at the new colorful trees, and talk about aiming and grammatical gender. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @floppy, @dsalt, @timvinc, @keeganjw, @Sam and @crabman, @evgenkot, @donovan, @zesterer, @jcoxeye, @juliancoffee, @Isse, @synis, @christof, @fvasco, @kHannibal, @Treeco, @woeful, and @Animoe. The merged work includes an adlet elder sword fix, many many translation updates, kill_npc targeting pets, enter/return equivalence in chats, battlemode time fixes, digging tooltip fixes, recipes for charms, sword balancing, toggling lanterns on ground, item tiering fixes, more price entries, no cursor jump when un-grabbing, updated furniture models, terrain persistence crash fix, better network compression of sprites, sea decor block fix, weather optimization, better tab completion for items, hot reload fixes, random colored trees, new LoD tree types, WGPU 0.18🥳, better aiming, inventory overflow logic, more cursor position fixes, proper grammatical gender in chat messages, and item tooltip size. </figure> Ongoing (unmerged) work is happening on item reinforcement, Mammoth AI, mining ore with multiple hits, separated event systems, snakes, hammer skills, flight aerodynamics and wind effects, a chat rework, item merging, LoD shader improvements, better balancing of beginner progress, learnable recipes, dwarven mine, poise based blocking, more NPC commands, an active glider (admin only), loading plugins over network and supporting WASI 0.2 components as plugins. </figure> This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Interactible lights by @zesterer</h2> As a demonstration of the new sprite representation overhaul and sprite attribute system, I added an attribute to lamp-like sprites specifically (lanterns, street lights, etc.) that allows them to be toggled on and off. Players can interact with them as they can other sprites to toggle this attribute. </figure> Also, you can read more about plans for moveable sprite parts in this discord thread</a>. Over the shoulder aiming by @Woeful</h2> After being unsatisfied with the third person camera whilst using ranged weapons I decided to make a change. My first issue being unable to properly see what I was aiming at due to the player character obstructing the view. The second being projectiles weren't actually going towards where you were aiming! To address the first issue I reworked the camera in third person to allow horizontal and vertical offsets, allowing for over-the-shoulder style camera gameplay. This is also completely customizable in the gameplay settings menu, where players can configure these offsets in any way they like. Your browser does not support the video tag. </video> </figure> But the problem now with moving the camera - the ranged projectiles no longer go where you are aiming! This is due to how the projectile spawning system works; projectiles are spawned at a specific position relative to the player body, and then fired forward, simply copying the player's look direction. Due to the camera now being offset, where the camera crosshair is positioned and where the player is looking is now different! To fix this I needed to rework how the player's look direction is calculated; instead of just copying the camera rotation, we need to have the player look at where we believe the camera crosshair is pointing. To do this we cast a ray from the camera's position forwards and look if we intersect the terrain or any entity and return the closer point. (This required me to create a new basic entity ray cast method to check for intersections with entity hit boxes). Your browser does not support the video tag. </video> </figure> Once we have this point where the camera ray is hitting something, we can determine the direction from the player body's projectile spawn point to this camera hit point. This direction will now be our new player's look direction! This ensures that now matter where the camera is offset and positioned, the player will always look and aim to where the crosshair is pointing! And handily enough, this new aiming system fixes my second issue mentioned initially as well! New configurable camera features and more crosshair accurate projectiles - two birds with one stone! I can answer any questions or clarifications needed for this new "QoL" ranged camera WGPU update</h2> @Isse's update across ten full versions of our GPU library WGPU finally merged. You should get it automatically with the next weekly release this Thursday. From then on DX11 support is history, but even older graphics cards should now be supported thanks to openGL. And newer graphics cards with Vulkan and DX12 drivers likely get a speed boost. </figure> Please note that the related transition from shaderc</code></a> to naga</code></a> will happen in a separate merge. This will finally get rid of some compilation dependencies like a python interpreter. Similarly migrating to 0.19.1 should be a low risk later update. </figure> Multi-hit mining by @crabman</h2> </iframe> </figure> Your browser does not support the video tag. </video> </figure> Chat tweaks by @Synis</h2> Your browser does not support the video tag. </video> </figure> Terracotta updates by @floppy</h2> </figure> </figure> </figure> </figure> </iframe> </figure> Various beautiful screenshots</h2> </figure> </figure> </figure> </figure> Synchronized lightning (now fixed) </figcaption> </figure> Your browser does not support the video tag. </video> Thermal glider lift </figcaption> </figure> Destruction in Lagrad </figcaption> </figure> </figure> Translation updates by @juliancoffee</h2> There are many ways to contribute to Veloren and the least technical one is to join the translation team. We do need both people who want to translate the game and people who want to review other people's translations, as well as just people in general who can give us a special perspective of their language concerning translation internal systems. We had @Translator</code> role, but it was somewhat generic, yet at the same relatively difficult to gain. For that, I want to make a special announcement, we now have a @TranslationPingSquad</code> role that you can self-assign in #⁠rules-and-info</code>, and get pings about different translation-related activities and discussions. </iframe> </div> </figure> The next portion of translation news is going in, the biggest change is gender handling, grammatical gender to be precise. If your language has the concept of grammatical gender, you already have a glimpse of how complex this problem is, yet it's even more complex than you can imagine. But complex problems shouldn't scare us! </figure> In a previous blog, we proposed the idea of passing two variables, first for "he or she" and second for animacy, but later we decided to make very small incremental step and expose only player gender, which we derive from the character's sex, and expose it only in chat UI. This MR was mainly targeted at Slavic languages, as they have a verb-noun agreement, which means that you need to pick the right verb depending on the gender of the actor who 'executes' the action this verb represents. Here is an example. hud-chat-died_of_pvp_buff_msg = .burning = { $attacker_gender -> [she] [{ $attacker }] спалила [{ $victim }] живцем [he] [{ $attacker }] спалив [{ $victim }] живцем } </code></pre> </figure> Let me unpack it. (I assume that you've seen Fluent already, but if you haven't, this declares message hud-chat-died_of_pvp_buff_msg and its attribute, burning, which says what should we display on death from Burning debuff) First, we match on $attacker_gender</code>, because it's PvP defeat, we do know[1] the gender of both $attacker</code> and $victim</code>. The first branch is [she]</code>, which means that the attacker was feminine, and if you know Ukrainian, or at least can read Cyrillic, here we use "спалила", which is a feminine variant of the word "палити" in Past Tense, or "to burn". The second branch is slightly more complicated, it declares a masculine branch and default branch, hence </code> mark at the beginning, It means, that if, for some reason, you get an unexpected gender to match, you will default to the masculine branch. Other than that, it's simple, you use the same template, except now you use "спалив", which is the masculine form. Important note, you only have $attacker_gender</code> with PvP-like notifications. For PvE-like notifications, it's much more complicated and we intentionally didn't add it yet, you only have $victim_gender</code>, which is always the player. </figure> Now, the asterisk. We do know the gender of both $attacker</code> and $victim</code>. That was a lie, we do not know. We derive it from the character's gender, which may or may not match the gender of the player, but it's a character you picked. This also means that we don't know the gender at all if you don't pick the character. In other words, when you join the server, and then instantly log out, without entering the world or if you did join the world but used Spectator mode, we can't provide gender to translators, and they should handle it with the default branch if possible, i.e. fallback to current behaviour before this MR. hud-chat-offline_msg = { $user_gender -> [she] [{ $name }] вийшла з серверу [he] [{ $name }] вийшов з серверу [any] [{ $name }] оффлайн } </code></pre> </figure> We do want to handle this better by providing a special UI where you can pick the real gender you want to associate with your account, and if you want to implement this feature, please reach out to us! That's not all, there is also a small MR, that slightly improves the experience of translators when it comes to translating NPC messages, namely npc-speech-tell_site</code> and npc-speech-tell_monster</code>. It's the message that was combined from multiple different messages, and it was unclear which went where. The answer is that these messages use npc-speech-dir</code> messages, npc-speech-dist-</code> messages and npc-speech-body-</code> variables from body.ftl</code> component. We now explicitly guarantee that these messages are used ONLY for npc-speech-tell_site</code> and npc-speech-tell_monster</code>, which means that you should place all "helper words" like articles or any others on corresponding words, like that. </figure> body-npc-speech-generic = some creature body-npc-speech-biped_large-ogre-male = an ogre body-npc-speech-biped_large-ogre-female = an ogre body-npc-speech-biped_large-cyclops = a cyclops </code></pre> and npc-speech-dir_north = to the north npc-speech-dir_north_east = to the north-east npc-speech-dir_east = to the east npc-speech-dir_south_east = to the south-east npc-speech-dir_south = to the south npc-speech-dir_south_west = to the south-west npc-speech-dir_west = to the west npc-speech-dir_north_west = to the north-west </code></pre> Please reach out to us, if you still have problems with translating these strings or any other strings! There's also some cool stuff in the review stage, unrelated to translations, but more on that later. Autumn trees and cherry blossom by @kHannibal</h2> </figure> </figure> 🐊 Patiently waiting for lunch. See you next time! </figcaption> </figure> Two Weeks in Veloren 225 Sat, 20 Jan 2024 00:00:00 +0000 These weeks, we look at Haniwa tombs, WGPU testing, item i18n and more sprite IDs. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @imbris, @dsalt, @jtornello, @Pybit, @yusdacra, @Isse, @the_dimasmith, @hrom, @juliancoffee, @crabman, @walpo, @zesterer, weblate contributors, @fvasco, @alphyr, @floppy. The merged work includes more efficient screenshot conversion, shader fixes, a day length slider for singleplayer, more potions, system dispatcher optimizations, and nix build script updates, cave entrance fixes, Ukrainian translation, twig shoulder rename, buff extension command, unstacking buffs, removing twitter, server rules at login, item internationalization, a modernized character selection menu, updated translations, a large sprite rework, an update of the assets manager dependency, Haniwa tomb dungeon, and a sword nerf. Ongoing (unmerged) work is happening on event system diversification, loot export, drowning in terrain, beginner balance tweaks, a much updated WGPU version, wireshark decoder, more price entries, item tiering fixes, loading plugins over network, more options for kill NPC, dwarfen mine, and a digging tooltip fix. This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. </figure> WGPU testing by @Isse</h2> We're currently trying to upgrade our graphic backend and need your help. In the new version DirectX11 is no longer supported, but OpenGL is. So I'm mostly looking for people to test on Windows, but other people testing is helpful too, to be able to catch any bugs. OpenGL is supported on Linux in this new version too. There is a form here to go through, and there are download links in the form. And any question can go in the thread of this message. Form link</a> In case you want to try the binary before starting any feed-back form, here are direct links to the binary downloads: Windows</a> Linux</a> MacOs x86</a> MacOs aarch64</a> - but please keep in mind that we created this blog-post specifically to receive your early feed-back about this significant change. Haniwa updates</h2> </figure> </figure> </iframe> </figure> </iframe> </figure> </iframe> </figure> </iframe> </figure> Tree burning event</h2> </figure> YouTube live link</a> </figure> </figure> </figure> </figure> </figure> </figure> </figure> Wiki update</h2> Updated: For some time, loot tables on the wiki were out of date and did not support multi-loot. These now generate from exported data, with collapsible grouping in drop tables. Examples below are the Yeti drop table and Rugged Hide source table. </figure> </figure> </figure> Miscellaneous</h2> There is also a new MR which extends /buff</code> command to be used with complex buffs like polymorphed, so you can transform yourself into a bunny :3 Strange bugs (enable sound to experience what goes wrong here): Your browser does not support the video tag. </video> </figure> A new way of fighting a Frost Giga resulted in a lot of traffic until the bug was fixed: </figure> </figure> A collection of nice photos </figure> </figure> </figure> Copious metal resources: </figure> </figure> </figure> Shield blocking by @Papinha Your browser does not support the video tag. </video> </figure> Proposal to make giant trees great again </figure> You can run veloren on Android … using a Windows emulator</a> Server rules by @zesterer</h2> @crabman and I spent the last few days working on a menu that displays server rules when players first connect to a server. Accepting server rules is mandatory, and happens on first connection (or for subsequent changes to the rules). Rules can be customised by server owners and fully support localisation. See here</a> for more information. </figure> @juliancoffee: By the way, for an official server, we do accept translations of official rules, as I understand ⁠server.veloren.net rules transl…</a> or ⁠new-contributors</a> if you don't have permissions A new character selection by @zesterer</h2> I've also been working on overhauling the character selection screen. The (very old) placeholder backdrop has been removed, and your character(s) now appear on an Airship, hovering over the world. The terrain beneath corresponds to that of the world you're about to join. </figure> Item internationalization by @juliancoffee</h2> What and why this MR does. First, "cosmetic" things. We created a new veloren/common/i18n crate that hosts Content type, that previously was in the common::comp::chat module. Because Content is general enough, it needed its own module anyway, by putting it in its own crate, we can significantly reduce the compilation time of veloren/client/i18n crate which depends on Content. </figure> Additionally, Localization::get_content has better docs (cut from !4236 (closed)). And using random in i18n is explicitly discouraged, yet not completely deprecated. Read #1655 for more. Now, the reason you're reading this — item localization. This MR deprecates Item.name() and Item.description() methods along with the corresponding ItemDesc methods. Instead, we use the ItemL10n manifest (like item_image_manifest.ron, but in common) that maps ItemKey to the i18n identifier. </figure> Important note: if an item has a different ItemKey it has a different i18n identifier, which means two things. All modular weapons have different i18n identifier, we don't use concatenation magic. </li> Some modular weapons have the same i18n identifier (like Staff with Heavy core and Light one). We only differentiate by hand-ness and primary component. That's how ItemKey works and that's what we do with voxel assets. </li> </ul> Import note no. 2: we deprecate these methods, not remove them. There are a number of systems that rely on these. Plugins can't use i18n yet.</li> CSV import/export.</li> Inventory sorting (by name) is server-side, which is unfortunate.</li> Crafting UI ordering and filtering. This is probably easiest to solve because all data is available, but I think that should be done in follow-up MR, this one is big enough.</li> There was also dependency on the English name in the sfx.ron config, but it's fixed in this MR.</li> </ul> After we solve all these issues in follow-up MRs, we can remove Item::name/description. (as well as ItemKind::Ingredient::descriptor). oh, almost forgot, it also changes /kit all, which now really gives you all items, that's why Admin Bag is now enlarged. </figure> On the topic of translations, that's still a concept, but we want to start handling grammatical gender. I want to start with hud/chat.ftl</code> and expose a few of the variables there. First is what I call gender, in our case it's an answer to the question "he or she?", and we check it from Body.body_type</code>. Second is animacy, which is roughly an answer to the question "is it sentient or no?" and roughly corresponds to what the English language calls "it". That allows us to do things like that for Slavic languages that require agreement with the gender of a noun. hud-chat-online_msg = [{ $name }] { $user_gender -> [he] зайшов на сервер [she] зайшла на сервер } </code></pre> Because we use body.body_type</code>, for a moment, your gender is derived from the sex of the character you play with. I showed the example from Ukrainian, what about other languages you would ask? Well, it's probably impossible to cover every rule of every language, but we want to try, so if you see some problems with how we handle your language or some requests, please reach out to me on Discord, @juliancoffee. Sprite identifier rework by @zesterer</h2> These two weeks started quietly and then a lot of changes came in over the past days. Another one of these is @zesterer's change to expand sprite identifiers: Over the last few days I've been working on overhauling the way we represent sprites, the small-scale voxel objects you find around the world like grass, crafting tables, and doors. This is an internal change that's been needed for a long time, but the fact that we recently started to approach the existing limit of 255 sprites was concerning and something needed to be done. As a happy side-effect, this overhaul should open up a lot of opportunities for more interesting sprite behaviours! </figure> A little context</h3> In Veloren, each block is represented as 4 bytes (where each byte is 8 bits, i.e: 256 possible values). The first byte is the 'block kind': this tells the game the overhaul type of block. Examples of block kinds include Stone</code>, Wood</code>, Grass</code>, Ice</code>. For these so-called 'filled' blocks (i.e: that get rendered as a coloured cube), the remaining 3 bytes specified the RGB (red, green, blue) colour. However, block kinds can also be 'unfilled' such as Air</code> and Water</code>. In these cases, we don't need to use the remaining 3 bytes for the colour, since these blocks have no colour (water colour is hard-coded elsewhere and can't change on a per-block basis)! As such, we use the 3 extra bytes to represent sprites. Previously, we chose the first of these to represent the 'sprite kind'. Like the 'block kind', this tells the game what type of sprite is present. We have sprite kinds like LongGrass</code>, CraftingBench</code>, Pumpkin</code>, WildFlax</code>, etc. You've no doubt encountered these sprites on your adventures. However, there's a problem! A byte can only have up to 256 possible values. Since one of them is used to represent the lack of a sprite (Empty)</code>, we can only have a maximum of 255 possible sprites! That might sound like a large number, but Veloren is an ever-growing project with ever-more sites and features that demand a wider variety of sprites. Within the last few weeks we've come very close to the limit, so it was time to do some work to expand that number. </figure> The people demand sprite attributes!</h3> The old approach was quite inefficient. We only used just one of the 3 extra bytes, so we can do better. However, there are more things we'd like to be able to do. In particular, for a long while we've wanted to be able to give sprites additional attributes that change their behaviour. Here are a few examples of attributes we might want to give sprites: The orientation of the sprite</li> The growth stage of plants</li> Whether a lantern/lamp has been turned on or off</li> Whether a trapdoor or gate it open or closed</li> The level or quality of loot in a container</li> Whether the sprite has snow covering it</li> Whether a pot/planter has a plant in it, and the type of plant</li> The specific objects that a cupboard or shelf has on it</li> The material of an item of furniture (colour of paint, stone/metal/wood, etc.)</li> The colour or design of a flag/banner</li> etc.</li> </ul> </figure> The solution</h3> To accommodate all of these needs, I've overhauled the way we represent sprites. Now, the first of the three extra bytes corresponds to the sprite 'category', a new idea introduced with this change. The category of a sprite tells the games which bits in the remaining two bytes are used to store which attributes (or whether those attributes even exist at all!), along with the sprite ID (which, together with the category, gives you back the sprite kind that we mentioned earlier). By placing things in categories, we can isolate the attributes above to those categories. We might want plants to store their growth stage, but we don't want to be wasting those bits for sprites that can't grow at all! Therefore, only the category containing plant sprites gets allocated the growth stage attribute. This new design is immensely more flexible. In addition to allowing for many sprite attributes, it also allows the sprite ID to inhabit as many as all of the remaining 2 extra bytes (i.e: 16 bits). That means we can have up to 65,536 sprites per-category! Needless to say, I think it'll be a long while until we need to think about upgrading our sprite representation again! Express deliveries (not yet in game). See you next time! </figcaption> </figure> Two Weeks in Veloren 224 Wed, 03 Jan 2024 00:00:00 +0000 These weeks, we show images of how snow and illuminations transformed the world of Veloren into a winter wonderland for ten days, read a travel report and peek into the ongoing Haniwa tomb work. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @Christof, @crabman, @Froggy, @jcoxeye, @floppy, @DaforLynx, @ErnestoSev, @GeekyGami, @Thy, @Sam, and @dsalt. The merged work includes re-enabling Christmas decorations and hats, gitlab tagging fixes, armor offset fixes, correct small leather pouch salvaging, taming crustaceans, re-enabling kelp and corals in the sea, drop fixes, beam sound effect fixes, new music tracks, removing dead combo melee code, more efficient screenshots, and airship piloting fixes. Ongoing (unmerged) work is happening on world boss compass, dwarven mines, more price entries, converting spots to sites, item reinforcement, NPC personalities, nix scripts, translation updates, terracotta ruins, vampire castle, and Haniwa tombs. This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Christmas event images</h2> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> Meanwhile on the party map</h2> Because the party map was hand-designed by @Hannibal and not procedurally generated it isn't covered in snow. But it still looks pretty enough to regularly become popular for photo shootings. </figure> </figure> </figure> </figure> </figure> </figure> Dodge on top of shenlong </figcaption> </figure> Travel report by @Dodge</h2> the very first day in veloren i got some leather armour and headed into eleokvan </figure> regretted so bad i was so unprepared died so many times to sand sharks raptors but funny enough i killed a aracheos in eleokvan w the help of villages went to moskh to meet some new friends and since i knew i was so unprepared i went back to wreau </figure> after which i asked people in the chat to suggest me a town where i could start to journey people mentioned ornerd but well haha ornerd was already very less populated by merchants and villagers and looked like it went so much i decided its not enough and yea i killed just two hunters two merchants and two travellers with help from Rai and emotional support via flute performance by atenea then i headed for the south areas so i went to some high up places in the mountains to take in the view </figure> and flew down to alaubrord wasnt too much interested in it then went to spolm pretty normal village as wel the nicest part was climbing the mountain and looking at the world and gliding down back Bolvarr was also pretty much like other villages then i got some advice that i need to find pincers in order to make good frostwood weapons from froggy and horblegorble so i went out to search for crabs this is where the real journey began someone mentioned there were a lot of crabs near the central lake so i set out to bichriel </figure> i was scared of antlions or i couldve hunted them and the spiders instead so i was like i already killed some crabs and got pincers and they were pretty easy to kill so uhh yea but good news is i didnt kill more than 5 crabs perhaps got most of it from merchants :) so yea back to the story , someone mentioned again that its near the desert area so i set out to that side and somehow ended up walking along to the savannah lands saw my first ever savannah village mpizozi i thought it was like any other village but oh boy the tunnel system was SO COOL like so many rooms connected via tunnels so so cool 👍 then i was like why not journey to every town and find it out? so i set out to go to every town in this map! </figure> most of the villages werent that interesting but i totally enjoyed abelen, it had such good atmosphere gotta say one of my fav villages is abelen shoutout to abelen! and i reached valing, by that time i knew this one is going to be a long journey this map is VAST as hell this is the final screenshot of the early days part, where i started from valing and ended at ordodraic </figure> again nginsu was a savannah village and the other villages were like wreau but the most interesting one of all is ordodraic i will never forget how deserted that village was not a single soul even Ayialrad which was also cut off and didnt have any sort of transportation routes had a lot of people but this village was suuuper deserted </figure> this was the path i took yesterday left ordodraic to asaundling and passed on a few villages to finally meet bakhyen mountain folk the mountain people have such a cool town and there was a mine near bakhyen which had steepy caves so was very easy to escape and use arrows and mine well was a fruitful mining session over 21 iron ingots, 3 diamonds 5 amethyst 5 emeralds and 2 cobalt ores and cute fungomes </figure> this is the path i took today the first village was a normal savannah village nothing too extraordinary but after that i went to see town ereris which is uh no town actually got washed up by the lake/river sadly the circle with the number one is ereris the circle with number 2 is a mountain village called Ayialrad and surprisingly even if it has no means of transport has a lot of merchants and guards, was surprised that ordodraic, even if it had proper roads and proper houses had no people but this village had finally climbed up a mountain and glided down to Dunbapa, pretty cool day went on a deep mining session and got dripped </figure> climbed the tree of yest! </figure> omg i love this village's color scheme!! </figure> i was pleasantly surprised its so well organized as well me and my buddy driggle in cathos :) </figure> ft rai[¹] continuation of my journey so far! the tree of yest was pretty bigg </figure> here the town charlough was submerged and onipses was a pleasant surprise :o </figure> ended the day with ston and today i ended it at crathos another town just like onipses! </figure> met my new friend driggle at fobreric i skipped that village on the northeast of crathos cuz rai said it was submerged as well and ston had only one house lol very bizzarre yet cool the journey is almost coming to a close idk if indiana jones is here but im going to your fav town next ;) this is the ideal village </figure> just the center workstation nothing else </figure> reached my last village that i had to travel storic :) successfully completed the voyage came back to wreau in new drip :D </figure> So this is how my final day of journey went started from crathos </figure> went to adrespilling Indiana jones's fav town it was a nice beachside town pretty scenery Frilling is just another village you see and on the way i went to ostechrendam the most ideal village after which there was two towns that i havent went one was storic and the other was lamakan so i went thru abelen and the villages that i visited way earlier </figure> i really love how beautiful abelen is totally recommend doing a visit to the town could say its a better ornerd simply because you wouldnt find a frost giga suddenly spawning in there xD finally reached storic by gliding down the mountains with a melanchoclic music by the side the song name was "the heavens weep" thanks to nolan i completed the journey by airshipping to lamakan, why? well i wanted to try airship once in this journey </figure> and went to mine in a nearby cave that necti mentioned, and it had a lot of bloodsteel, mined with nolan got good amount of bloodsteel went to eleokvan, got my armour headed to wreau and ended my journey for the day :D that marks the end of the grand journey thanks for tagging along :) also forgot to mention while i was trying to go to adrespilling i was chased down by sea clerics -_- [¹]: feat Rai (The Wyvern Slayer), they accompanied me for that short journey in their airship Ongoing Haniwa tomb work</h2> @Floppy is working on a tomb inspired by structures close to the Great Wall, the screenshots are just too exciting to withhold. The original site design was done by @Hannibal in MagicaVoxel, @Gemu created new models. </figure> </figure> </figure> </figure> </figure> </figure> </figure> </iframe> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> Miscellaneous</h2> Perhaps when NPCs talk about the weather the code should check against the current weather </figcaption> </figure> </figure> </figure> Another Veloren news issue by Sam113 </figcaption> </figure> A table with a view </figcaption> </figure> Making good use of the stage </figcaption> </figure> Obviously this tavern isn't specialized on Denari customers </figcaption> </figure> Your browser does not support the video tag. </video> crabman found the bug which lead to deserted airships </figcaption> </figure> No game content but clearly in the holiday spirit </figcaption> </figure> Northern lights illuminate the way. See you next time! </figcaption> </figure> Two Weeks in Veloren 223 Tue, 19 Dec 2023 00:00:00 +0000 These weeks, we take the time before snow and illuminations transform the world of Veloren into a winter wonderland. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @Neras, @hrom, @Isse, @floppy, @uniior, @DoNoVan, @jcoxeye, @Froggy. The merged work includes cobalt and blood-stone armor buffs, sword skill icon fixes, Taverns💃🕺🍹, crab animation, crate and barrel sprites, Dagon and Wyvern poise resilience, and various Head Armor offset fixes. Ongoing (unmerged) work is happening on Dwarven Mines, Music updates, world boss location tools, new prices, crab taming, sword defense, spot to site conversion, Christmas content, personality traits, pumpkin recipes, mage tower, translations, anti-cheat, time length sliders, poise and combat and durability tweaks, a large event system overhaul, and potions. This developer blog is based on information collected in #blog-content</a>, where game contributors are always invited to communicate their updates or simply post a link to a different channel. Development updates</h2> New attacks of Frost Giants Your browser does not support the video tag. </video> </figure> World boss compass </iframe> </figure> Swiftness potion Your browser does not support the video tag. </video> </figure> modelled after a running champion's cup </figcaption> </figure> Crates and barrels </figure> Pumpkin cake </figure> How to create a party map by @Hannibal</h2> First I try to find a theme that I want to work on and that would fit Veloren. First release was Desert style city, Second was Pirate Tropical Island, Last One was a test for Elven architecture using Asian inspiration (Japan x China)</li> Then I look for artworks of those themes to get a first impression of what I am aiming to achieve, it often gives me direct or indirect inspiration</li> Then I watch minecraft timelapse, it's not always fully relatable but it gives me a first impression on how to turn those artworks into voxels (although minecraft cheats with different block types, but that is something you gotta adapt to)</li> Next I do the first draft, making a list of what I want on the map, to be sure to make a terrain that fits the idea</li> Next I create the terrain, using worldpainter. If you don't know how to use WorldPainter, I suggest watching Jeracraft tutorial and using his brushes. (Not that not everything from there is applicable, because it's a tool made for minecraft at first). The terrain MUST be below 2000x2000 blocks (it's MagicaVoxel limit).</li> I export the terrain as a heightmap</li> Either use photoshop or an alternative (I use PhotoScape X) to split the image. Splitting it allows you to create tiles. The size of each tile MUST be below 256x256. If I use a terrain of 1920x1920, I will split by 8x8 to get 64 tiles of 240x240. If I use 1792x1792, I divide by 7 to get 49 tiles of 256x256.</li> Then open MagicaVoxel, enter world mode, delete the box and select color palette 2</li> I then import all tiles into the world mode of MagicaVoxel (there are tutorials for world mode on YouTube)</li> Assemble all of them like puzzle pieces to make up the initial heightmap</li> Resize all the tiles to have a z height of 256</li> Then you need a special shader plugin for magicavoxel called xs heightmap (can be found online).</li> Use it on every tile to make up the terrain</li> Group them using the group tool, so it can be moved as a unit</li> Decide sea level (should be done on WorldPainter first, but you need to decide on MV too cuz sometimes it changes)</li> Then create your color palette by selecting Palette 3. (I use Adobe Color to create my palettes)</li> Recolor the terrain to fit your needs, for the soil i suggest using the xs soil shader or xs soil_replace shaders that can be found online, it saves dozens of hours of work</li> Then you can fill the water once terrain is done (use a blue block on MV, you will need to use that RGB in a future step at the end for it to be water in game)</li> Create all the assets you need, I suggest making them all in different boxes so it's faster AND easily copy-pasteable (I can't really detail this step it comes down to what you wanna do but it is the biggest step of the project, it can take more than 100 hours if you want it to be very detailed)</li> When your map is finished, you might want to add sprites. for that, select colors that you HAVE NOT used yet (that means the index AND the RGB).</li> Then, you will need @Isse's tool that will generate the chunks for you to load your asset on the map</li> for that you need to have the game compiled, download their tool (isse-vox-placer)</li> You need to make sure your terrain in your compiled game is persistent (there is an explanation on how to do that in the book)</li> Find a location in game where you can load the map. I suggest being near coasts in water, so it's not floating too much, which creates lag</li> Take the coordinates and input them in vox-placer</li> Place your .vox file of the map in vox-placer</li> For water and sprites, there is an explanation on the gitlab of vox-placer to transform the RGB you used.</li> Once all is set up, launch the vox-placer process using a terminal</li> wait for the process to end</li> copy the chunks generated in your chunk folder of your compiled veloren</li> launch the game and go to that location</li> if it's there, it worked xD</li> </ul> If you have never used MV, I suggest reading the tutorial pinned in ⁠new-contributors There is also this video that might be helpful: https://www.youtube.com/live/19D2kntYyKE?si=tJGEHhZX4rc4n01F</a> It goes more in depth for the asset modelling for party maps Veloren news</h2> </figure> </figure> </figure> </figure> Boss drop options</h2> This looks classy </figure> but shouldn't it become like this more realistic concept art: </figure> requires processing in-situ to get any use out of (can yield much-needed materials like tough hide, horn, teeth, tainted meat, etc. with proper tooling)</li> axes, while badass, are too heavy to haul without a team let alone wield</li> moderate health risk if left to fester, attracts scavengers, get fined if you fail to burn or bury the body</li> </ul> PvP tournament images</h2> </figure> </figure> This road crosses difficult terrain and weather. See you next time! </figcaption> </figure> Two Weeks in Veloren 222 Sat, 02 Dec 2023 00:00:00 +0000 These weeks, we look at cliff towns and crab animations. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @Isse, @crabman, @floppy, @Qsto, @zesterer. The merged work includes vehicle mounting fixes, precision balancing, troll cave and camp sites, clifftowns, new entity interaction commands, a fix for loot protection with curious potions, a modular component trading fix, the Phoenix rework🔥, and CI fixes. Ongoing (unmerged) work is happening on dwarven mines, modular character states, an event system rework, loot table fixes, charm animations, sword parrying, spot to site conversion, curious potion file rename, improved walking animations, more potions, world boss behavior fixes, terracotta ruins, mage tower, vampire castle and crab animation🦀. We met in #Working</a> last week, see the chat</a> for details. Development meetings are announced in #town-hall</a> and ping @DevPingSquad, self-subscribe here</a>. This developer blog is based on information collected by @Christof and on the links and text posted to #blog-content</a>, game contributors are always invited to post updates there. Cliff towns moved to mesa biomes</h2> </figure> </figure> </figure> </figure> Attack types are now separated from body</h2> </figure> </figure> Crab animation</h2> </iframe> </figure> </iframe> </figure> </figure> Different sizes </figcaption> </figure> And improved walking animation </iframe> </figure> Development news</h2> A single player was able to collect more loot than intended if they use the curious potion to shape-shift. This is now fixed, but if you want to read the details go to the discord thread</a>. Taverns are unintentionally dug into the ground </figcaption> </figure> @Horblegorble updated all entity pages and their drop tables in the Wiki. Thanks to them! @Uniior created a garlic model </figure> Your browser does not support the video tag. </video> More dangerous Frost Gigas </figcaption> </figure> The new entity interaction commands in action Your browser does not support the video tag. </video> </figure> Player vs player tournament</h2> A player vs player tournament took place in high ground </figure> The location </figcaption> </figure> </figure> </figure> </figure> Look for future event announcements in the #events</a> channel. Collected impressions from the game</h2> </figure> </figure> </figure> </figure> </figure> Bridge over peaceful water. See you next time! </figcaption> </figure> Two Weeks in Veloren 221 Sat, 18 Nov 2023 00:00:00 +0000 These weeks, we look at community events, plugin progress, Salamander animation and spot to site migration. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @floppy, @uniior, @crabman, @Christof, @Sorann753, @zesterer, @Isse, @Sam, @PopeRigby. The merged work includes fixes to Jungle ruins, a clover leaf glider recipe, buff balancing, kits in plugins, translation updates, ice reflections and mesas, rock circle sites, shader fixes, beam terrain collision fixes, separating combat and behaviour state, buff optimizations, a fire potion, precision 🞋, serde enum-maps, and removing the spin-melee state. Ongoing (unmerged) work is happening on zone balancing, mage tower, vampire castle, terracotta ruins, a burning pot model, learnable recipes, inventory overflow, rain extinguishing burning, Salamander AI, Torvus, Taverns, antigravity potions, and item merging. New web site layout</h2> @Walpo put significant effort into a modernization of the Veloren web site, now licensing became explicit, the blog posts got a new template and linking to streamable videos became more convenient. Thank you for pushing this through, @Walpo! Community events</h2> On November the 3rd @Hrom and @necti organized a Team vs Team death-match on the party island docks. </figure> </figure> </figure> Two weeks later there was an underground chicken fighting </figure> WECW plugin content</h2> You can find @EvanMeek's plugin here on Codeberg</a>. The original WECW, a Veloren fork, can be found here</a>. It adds new axes and hammers, </figure> … and panda armor </figure> </figure> and more </figure> We found that internationalization is needed for plugins as well: </figure> Adapting the model offset needs reloading for fast feedback - which isn't yet implemented, and the plugin manifest merging seems to have broken hot-reloading. New Salamander attacks</h2> @floppy and @MetalGunTalk are working on new Salamander fire attacks: </iframe> </figure> Your browser does not support the video tag. </video> </figure> Spot to site migration</h2> The stone circle became a site (like dungeons and towns), previously it was a spot (low overhead random structure, like pirate ship): </iframe> </figure> Camps in different environments </figure> </figure> </figure> And troll caves </figure> </figure> </figure> Tethering testing by @zesterer</h2> You can indeed build an airship convoy, I had to modify the /airship</code> command to give them a tether: </figure> But it doesn't always go to plan: </figure> A skillful love graffiti. See you next time! </figcaption> </figure> Two Weeks in Veloren 220 Sat, 04 Nov 2023 00:00:00 +0000 These weeks, we enjoy colorful trees and spooky monsters. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @crabman, @Christof, @xMAC94x, @floppy, @Isse, @Hannibal. The merged work includes less frequent Dullahan during Halloween, plugin fixes, CI fixes, items in plugins, NPC spawn fixes, snow glitter shaders, an extended roadmap section and a new section on plugins in the book. </figure> Ongoing (unmerged) work is happening on precision, preventing buff stacking, balancing, various worldgen improvements, starter glider, phoenix, WGPU 0.18 testing, torvus, single player worldgen parameters, and taverns. Meanwhile, @imbris is making progress on an automated scene recording and replay mechanism to investigate rendering performance and bugs. Your browser does not support the video tag. </video> Snow glitter </figcaption> </figure> Worldgen meeting by @Isse</h2> Last Saturday we had a worldgen meeting discussing how to move forward when it comes to plots. Right now plots decide their own shape and style, this is something we want to separate. This way we can more easily define similar buildings but have different styles. For example a blacksmith in a desert town and a mountain town might have similar shape and function, but very different styles in colors and details. We also want a concept of rooms in buildings, which would make buildings be able to have multiple purposes. Like a merchant having a shop on the lower floor, and a bedroom on the top floor. This would also make it easier to make buildings advertise what functions it has, by looking at what each room can do. Hierarchical plots were also discussed, and how it related to rooms. Hierarchical plots would allow plots to include other plots, like a castle being able to have houses within its walls. </figure> We reached a few conclusions: Rooms can be plots. With hierarchical plots, we can just say that rooms are sub-plots of the house.</li> We need a way to map connections between plots, and rooms because of the first conclusion. This would make it much easier for rtsim NPC to navigate sites. This can be done by keeping track of walls and what plots they connect to.</li> We need plots to be able to be 3d. For example a giant tree could have a house on one branch above another house, these shouldn't affect each other because of plots being allocated on a 2d grid.</li> We need to fully rework how plot allocation works, especially when it comes to hierarchical plots.</li> </ul> </figure> @zesterer wrote an example of what this could look like in code here</a>. We also talked about using more premade assets in site generation. One example of how to do this is using tiles, similar to how you'd use a tilegrid in 2d games, you can do the same in Veloren. But with voxel models. Veloren worldgen/worldsim terms: Site: A place with buildings, could be a town, a dungeon or even a giant tree.</li> Plots: An allocation of space in a site.</li> rtsim NPC: An NPC which is always simulated, even in chunks that aren't currently loaded by a player.</li> </ul> Halloween season impressions</h2> </figure> </figure> </figure> </figure> </figure> Your browser does not support the video tag. </video> </figure> </figure> Playing Veloren can obviously get addictive! </figcaption> </figure> Living in a pumpkin. See you next time! </figcaption> </figure> This Week in Veloren 219 Sun, 22 Oct 2023 00:00:00 +0000 This week, we enjoy terraced terrain. - Christof, TWiV editor Contributor Work</h2> Thanks to last week's contributors @RaulWCosta, @imbris, @Isse, @Sam, @floppy, @zesterer, @crabman, @Christof, @xMAC94x, @jshipsey and @DaforLynx. The merged work includes faster color mapping, hot re-loading fixes, puddle detail shader fixes, using Beziers for beams, dreadhorn hitbox fixes, fixing a panic on adding dead pets, fixing division by zero, avoiding the pilot duplication, new walking animations, adding items via plugins, moderation improvements, LoD improvements, spawning Dullahans in more remote places, lava sounds, carts and entity joints (tethering) and LoD reflection fixes. Ongoing (unmerged) work is happening on plugins, weapon precision, barns, worldgen experiments, balancing, dwarven mines, inventory overflow, item merging, phoenix, conversation UI, voxel file renaming, updating WGPU, taverns and blacksmith workshops. </figure> Precision explanation by @Sam</h2> Precision changes criticals to be non-random, and instead based on, well, precision. Only melee, projectile, and beam attacks can benefit from precision. All three can become precise when attacking from behind, or partially precise when attacking from the sides. Melee can also become precise when attacking a poised target, becoming more precise as a target is more poised. Projectile can also become precise when colliding with the head of a target (technically the upper 10% of a body's cylinder). Beam can also become precise when a target is continuously hit, becoming more precise over time. Server configuration changes by @xMAC94x</h2> There is an upcoming configuration change that requires your action: The setting server/server_config/settings.ron:metrics_address</code> will be moved to server-cli/settings.ron:web_address</code>. So, in case you used this setting, e.g. to collect metrics, you need to adjust the server-cli settings to make this work. This change went live on Oct 19th with the weekly release. Part of this change is also providing an API to monitor and moderate chat messages on the game server (Global, Group, Fraction, Direct Messages, everything). This feature isn't enabled on the official server, yet. But we plan to enable it soon, so be prepared. A dedicated announcement will follow before this gets enabled. Halloween is coming! </figcaption> </figure> Defining items in plugins by @Christof</h2> This week a long-running development branch was merged which enables definition of new items via plugins. Sadly sending plugins from the server to the client is still missing, so the effect is only local for now. You can take a look at an example plugin at https://github.com/cpetig/veloren-plugin-canoe . Vox files and similar assets can be directly included in the plugin. But adding new entries to existing RON based manifests is more tricky and requires merging the data, enabling this for all file variants is still worked on. Please note that for now we avoid making guarantees about plugin backwards compatibility. A 'weapon' and foot 'armor' defined in a plugin </figcaption> </figure> Other development reports</h2> WGPU recently gained support for WGL / OpenGL 3.3, so for older graphics cards there will soon be an alternative to directX 11 or Vulkan. We plan to release a test binary with a much newer WGPU soon. In this case we skipped eight full releases (0.9 to 0.18) and openGL support had been discontinued ever since Veloren 0.10 switched to WGPU in mid 2021! Dropping support for directX 11 isn't ideal, so we delayed this transition, but besides much improved support for directX 12 and Vulkan in WGPU 0.18, openGL should re-enable running on even much older cards and directX 11 might eventually get re-implemented again. An impressive video of a terracotta dungeon walkthrough by @floppy </iframe> </figure> Barns by @EvgenKot </figcaption> </figure> </figure> The new carts outside their comfort zone </figcaption> </figure> </figure> The new LoD transition by @zesterer </figcaption> </figure> Your browser does not support the video tag. </video> Taverns by @Isse </figcaption> </figure> Hall of mirrors by @zesterer </figcaption> </figure> Watch your steps! </figcaption> </figure> New geological structures by @zesterer (work in progress)</h2> </figure> </figure> </figure> </figure> </figure> </figure> </figure> Everybody waits for swamps to become real. See you next time! </figcaption> </figure> Two Weeks in Veloren 218 Sun, 15 Oct 2023 00:00:00 +0000 These weeks, we enjoy the new running animation updates. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @floppy, @crabman, @xMAC94x, @imbris, @uniior, @Isse, @zesterer, and @slipped. The merged work includes fix for stopping birds by talking to them, status messages during load, toolchain update, new treasure chests, frost giga tweaks, shader numerical fixes (for large clock values), new running animations, MacOS linking, airship docks, backpack fixes, and shaders in low reflection mode. Ongoing (unmerged) work is happening on items in plugins, barns, terracotta ruins, inventory overflow handling, vampire castle, mage tower, mines, bank storage, item merging, phoenix, loot export, and bird large routes. Developer meetings happen Saturdays or Sundays at 7pm UK time, they get announced a few hours ahead on #town-hall with a ping to @DevPingSquad, which is self-assignable in #rules-and-info. The recent weeks have been very informal in a small group, but this week had a larger audience, you can read the minutes here</a>. Toolchain update</h2> @imbris was able to fix the Vulkan crash in gfx-hal, so the toolchain was updated without requiring a newer WGPU version, which would break our directX11 support. Thank you to the moderators!</h2> This week, again, there were some hostile chat interactions and the moderators continued their unthankful work of warning, timing out or banning offenders. Many of them continuing the vandalism with alternate accounts. As usual seeing the deleted material isn't good for your mental health or belief in humanity's capacity for good. So many thanks to the moderators for their continued work to keep Veloren a friendly place! 🙏 Developer updates</h2> New walking animation by @zesterer on Imgur</a> RTSim bug causing pilot mass duplication </figure> Your browser does not support the video tag. </video> </figure> Some impressions from the game</h2> </figure> </figure> </figure> </figure> </figure> a sinkhole! </figcaption> </figure> </figure> a bug, but pretty </figcaption> </figure> </figure> Pilot error at night. See you next time! </figcaption> </figure> Three Weeks in Veloren 217 Sun, 01 Oct 2023 00:00:00 +0000 These weeks, we look at map experiments and the treasure hunt event. - Christof, TWiV editor Contributor Work</h2> Thanks to last three weeks' contributors @vasco, @imbris, @Haijo7, @xMAC94x, @christof, @james, @Isse, @crabman, @lle-bout, and @floppy. The merged work includes translation updates, cursor locking on wayland, item quality fixes, updating uuid, authentication fixes, location name fixes, updating to a new major version of specs🏆, the singleplayer map GUI🗺️, removing unwrap, non-hostile NPCs ignore loot, removing unused dependencies, localization of server command responses, the arena building in desert cities🏟️, fixing windowsills, and fixing airship de-synchronization (which caused duplication of captains)👩🏿‍✈️. </figure> Ongoing (unmerged) work is happening on Frost Giga buffing, numerical error reduction in shaders, toolchain update, vampire castle, barns, loading progress text, loot export, phoenix, bird travel, terracotta ruins, dwarven mines, heightmap loading, tethering, plugins, bank storage, localize commands, sword balancing, specs refactoring, windmills, and vox file names. </figure> Some small (up to five people) developer meetings took place, but I wrote down no minutes. Singleplayer map selection</h2> @Isse created a map selection UI for singleplayer mode: </figure> This has led to many experiments by players: </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> Treasure hunt event by @Vaga and @Hrom</h2> </figure> The puzzle starts with a riddle: </figure> With this you're led to the capture the flag tower by Werograd. Here you find a man playing the flute named Kokopelli, he gives you a string of letters and numbers, "BlzgI0yg87Y". This is the ending of a YouTube link</a>, that has a flute playing in Morse code, along with some other random gibberish to distract you. The Morse code gives you the word "Pralis", which happens to be a town. </figure> In this town you meet character called Portunus . He also gives you a string: "Fnzw Uzfx ov Xhtrsbacbh <r oelch tye kwif> occ lwlc pvdzx". This is a vigenere cipher and to solve this you need a key. In the town there are 4 more characters scattered around houses, each representing a relic weapon: Thor (Mjolnir), Loki (Laevateinn), Hermes (Caduceus), and Vidyudabhi (Parashu). Portunus also hints at needing keys, and that "United gods are unstoppable". </figure> In order to get the key, you needed to combine all the relic names into one and for the right order of the names, look at the armor the characters were wearing, which went from none all the way up to tier 4. </figure> Once you had the key, you could reveal the cipher's true text, and the answer that must be sent, "x marks the spot". </figure> </figure> Thanks for participating, there were some big brain ideas, congrats to: Luminas, Kotty, Dimlbur and do-no-van for reaching the end!!! </figure> Toolchain update and WGPU</h2> Updating the Rust compiler to a newer version crashes the Vulkan driver on @christof's computer. Updating WGPU fixes this problem. This led to a discussion of finally updating WGPU, with no solution for directX11 support. Perhaps a fork using the old WGPU for Windows builds is an option, or magically a DX11 backend for WGPU 0.10+ materializes with enough demand. Specs refactor</h2> @imbris fixed the ECS system specs (and its data manager shred) to be MIRI compliant. This is one of the most significant changes to specs since 2020. @imbris also changed Veloren to use this corrected ECS crate. Frost giga testing</h2> </figure> </figure> </figure> </iframe> </div> </figure>New moderator</h2> Please welcome @crabman as a newly nominated moderator. Upcoming Discord changes</h2> Discord adds new extensions to shared content which will likely restrict the time you can download a file from a link in the future. We are working on a new content system to deliver the images and videos included in this blog. Looking into the far distance of a hollow world. See you next time! </figcaption> </figure> Three Weeks in Veloren 216 Sun, 10 Sep 2023 00:00:00 +0000 These weeks, we look at arena, windmill and phoenix work. - Christof, TWiV editor Contributor Work</h2> Thanks to last three weeks' contributors @lle-bout, @Christof, @imbris, @crabman and @Nectical, @xMAC94x, @Gaxrodi, @tygyh, many contributors in Codeberg WebLate, @walpo, @vasco, @namolite, Thomas S, @Isse, @Qsto and @floppy, @xiretza, @Neras. The merged work includes a network library update, locations in character selection, a winit (OS window) update, a new portal graphic, dependency update, many translation updates, a README update, rtsim airship fixes, loot balancing, buff death message improvements, and group chat fixes. Ongoing (unmerged) work is happening on Phoenix abilities, NPC arena 🏟️, Frost Giga attacks, a compass, bank storage, windmills, CI scripts, saving window size, singleplayer world selection, lava material, and weather network optimization. Link to the last developer meeting's minutes</a>. Reviewing merge requests</h2> Although the amount of merge requests merged increased in August after a low in June, there are still plenty of them open. So we encourage everyone to participate in reviews, a gitlab account is all you need to start. Alternatively you can join the discussion in the Discord thread linked from the MR. If you want to learn more about how swarm reviews can work for open source projects, look at Alice's excellent blog post</a> or presentation video </iframe> </div> </figure> Misc development updates</h2> The new portal in action by @necti </figure> Ongoing work on Windmills by @EvgenKot </figure> </figure> NPC arena work</a> by @floppy, @Isse, @lle-bout and @zesterer </figure> </figure> </iframe> </figure> Some work in progress animations from the Phoenix rework</a> by @floppy and @Neras Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> </iframe> </figure> Game video footage</h2> Player vs player event footage by @necti </iframe> </div> </figure> Cave combat video by @Coba Your browser does not support the video tag. </video> </figure> Creative shader usage by @Uniior Your browser does not support the video tag. </video> </figure> Looking back to the last release party map. See you next time! </figcaption> </figure> Three Weeks in Veloren 215 Sun, 20 Aug 2023 00:00:00 +0000 These weeks, we again present many ongoing activities on the Veloren project. - Christof, TWiV editor Contributor Work</h2> Thanks to last three weeks' contributors @Igigog, @Isse, @NerasW, @aweinstock, @Maxicarlos, @Sam and @Pfau, @Daforlynx, @jimmy, @tibbon1, @Qsto, @floppy, @xMAC94x, @neutralmodder, @TelepathicWalrus, @imbris, and @EvgenKot. The merged work includes rtsim save refactor, a division by zero fix, balance tweaks, item quantity display, chieftain mask fixes, ⛏️ Axe skills, combat music toggle, controller layers, dependency updates, Brimstone armor fixes, 🐉 spawning Wyverns, chest loot balancing, CI fixes, repair sound, craftable shovels, desert biome fixes, a new leather backpack, zoom key bind, disable Sapling fleeing, stay and follow commands to pets, coastal town fence fixes, physics synchronization changes, pirate hideout, jungle ruins, cactus fixes, configurable SI prefixes, and dungeon cave intersection avoidance. Ongoing (unmerged) work is happening on food diversification, bank storage, NPC arena, new helper functions, inventory overflow, translations, mines, vampire castle, terracotta ruins, crab animation, phoenix, windmill, using the mold linker, multiple singleplayer worlds, farms, wind affecting gliding, airships, balancing, new textures, pan, agent debug menu, and documentation fixes. Link to the last developer meeting's minutes</a>. Misc. development updates</h2> Your browser does not support the video tag. </video> Timelapse by @Hrom </figcaption> </figure> @Qsto and @Isse are working on an iron pan item. Food changes by @Borbop are in review, @Qsto and @Gemu are working on existing bags and backpacks, @UncomfySilence is looking into balance tweaks (DPS squash and health up). @Isse: Shovels have now been made craftable, and are used to dig up mud and graves for loot. New content by @floppy</h2> Links to Streamable videos: </iframe> Shovel attack </figcaption> </figure> </iframe> Desert City Arena </figcaption> </figure> </iframe> Stay follow commands to pets (together with @Qsto) </figcaption> </figure> </iframe> Flame rain attack for phoenix </figcaption> </figure> </iframe> Fiery tornado </figcaption> </figure> Related work is the burn attack by @Neras. You can find many more videos in this Discord thread</a> Your browser does not support the video tag. </video> </figure> Farmers working in the fields by @zesterer</h2> </figure> </figure> Distant land experimental shader by @zesterer</h2> </figure> Maze creation by @aweinstock</h2> Your browser does not support the video tag. </video> </figure> </figure> Multiple singleplayer worlds in voxygen by @Isse</h2> I've been working on having multiple singleplayer worlds in voxygen, which you will see in the game soon. Which will allow players to more easily generate different maps to play on. And your current singleplayer world will be migrated to this new system, so progress won't be lost. </figure> As it is currently it's not really a user facing thing to generate maps. So I'm looking forward to more interesting maps being generated! Craftable shovels became popular. See you next time! </figcaption> </figure> Three Weeks in Veloren 214 Wed, 26 Jul 2023 00:00:00 +0000 These weeks, we take a look at the many things going on at veloren development at the moment. - Christof, TWiV editor Your browser does not support the video tag. </video> A very visual reminder </figcaption> </figure> Contributor Work</h2> Thanks to last three weeks' contributors @xMAC94x, @RunRobDog, @Qsto, @sglorch, Jaroslav Lichtblau, @Pfau, @floppy, @imbris, @aweinstock, . The merged work includes TCP receive buffer increase, spawn tab completion, loot changes, translation updates, dwarven quarry⛏️ (still inactive in game), coastal town, desert city fixes, CI optimization, shorter item count texts. Ongoing (unmerged) work is happening on vampire castle, terracotta ruins, more loot cleanup, medicine, defensive stance, moving crabs, avoiding dungeon cave intersections, iron pan, axe, controllers, readme clean-up, balancing, wgpu 0.17, wyverns, mines, winit update, jungle ruin, chieftain mask, agent debug menu, marketplace. Link to the developer meeting's minutes</a>. Ongoing work</h2> @crabman implemented adding discord links to the merge request in GitLab, so now we have bi-directional linking. @Hannibal initiated a veloren roadmap, the current draft version is available in GitLab</a>. @walpo set up web based veloren translation in Codeberg Weblate</a>, this is integrated with our GitLab instance</a>. This document</a> explains how to add translations. @Floppy, @Gemu, and @Hannibal have been working on creating small sites that would serve as a replacement to the 'spot' system. The goal is to have a variation of points of interest, smaller than dungeons, that will populate the wilderness of the world. Some of the planned ideas include moving the spots to site2, having more outposts, ruins, abandoned buildings, etc. To start off, we have been working on jungle ruins and temperate ruins, using handmade assets in site2. </figure> </figure> </figure> </figure> @Gemu, @Qsto and @Uncomfy are working on resource scarcity and more horizontal ways of obtaining them. They are cleaning the dungeons chests and moving woods to other droppers. They plan to decrease the occurrence of natural world materials in dungeons and incentivize foraging and wandering over the world to gather them. Prototype implementation of portals in dungeons by @crabman (teleportation is unlikely to be added to the main game): Your browser does not support the video tag. </video> </figure> @floppy and @Zion have been working on getting wyvern attack AI ready to match this fearful opponent. </iframe> </figure> </iframe> </figure> More food types with more diverse effects by @Borbop. Your browser does not support the video tag. </video> </figure> Another Frost Giga sighting</h2> Frost Giga was here </figcaption> </figure> Concert with a colorful light show. See you next time! </figcaption> </figure> Two Weeks in Veloren 213 Mon, 03 Jul 2023 00:00:00 +0000 These weeks, we look closer at what happened around the code freeze period. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @zesterer, @xMAC95x, @Pfau, @walpo, @Christof, @Isse, @floppy, @Sam, @bd, @aweinstock, @tygyh, @Fengo. The merged work includes anti-cheat mechanisms (speed limits), a new login background, bloom and cinematic shaders, version bumps, translation updates, wasmer update and cfg(wasm32)</code> removal, a plugin fix, wildlife spawn changes, durability changes, confirmation on one-way trades and item sorting by quantity. Ongoing (unmerged) work is happening on loot changes, coastal town, wyverns, avoiding cave dungeon intersections, map exploration, TCP buffering, iron pan, consumable cost reduction, lantern adjustments, axe skill tree, spawn entities from debug UI, voxel model spawning (a fortress), removing the coin counter, NPC searching players, wind affecting gliders and dwarven quarry. There was no weekly meeting in the past two weeks, but there was a release party. 0.15 Release</h2> Of course, you have to watch the cool trailer for this week's release with matching music: </iframe> </div> </figure> The release party recording is available at </iframe> </div> </figure> During the party someone used a loophole in veloren's crafting mechanism to overload the server, a fix has been developed since then. Ongoing work</h2> @Oguz did some experiments</a> with shiny indices, but the end result wasn't considered good enough - until shiny gets proper implementation</a>. Your browser does not support the video tag. </video> </figure> @floppy worked on rtsim large bird behavior, here is a test spawn of 600 crows: </iframe> </figure> Also @flopp4y improved wyvern attacks </iframe> </figure> </iframe> </figure> </iframe> </figure> </iframe> </figure> Assorted impressions</h2> Frost Giga was here </figcaption> </figure> Artistic view with nonoise and sobel shaders. See you then! </figcaption> </figure> Veloren 0.15 Release Sat, 01 Jul 2023 00:00:00 +0000 0.15 Release</h2> Veloren is releasing 0.15! This version is about 6 months in the making, and we have a lot to show off! If you're reading this before 18:00 GMT on July 1st</a>, make sure to join the release party. On the side, you can also watch the release party dev stream</a>, where we'll be chatting with devs about what went into this version. To join, you can download the game for free at veloren.net</a> and create an account</a>, then launch the game and hop on the default server. See you there! New in this release</h3> Here are some of the changes in this release: Our first world boss, the 'frost giga': seek him out if you dare!</li> A new dungeon: Adlet caves</li> Airships can now be used by players</li> Enemy loot is now shared between players</li> A reputation system: if you commit crimes, NPCs will remember it!</li> Improved AI: NPCs will talk to players and each other about events in the world</li> Much richer world simulation: NPCs will migrate and pass on rumours</li> You can now choose your character's starting town</li> A durability and repair system</li> Improved accessibility, performance, bug fixes, and much, much more!</li> </ul> Changelog</h3> As always, there are always more changes than we can add to a single post! You can check out the full changelog here</a>. Thanks to this versions contributors (in random order): João Capucho, Monty Marz, Francesco Vasco, Nico, Cat Stevens, tygyh, Marcel, Pexxxzz, Ellen Sun, Monty Marz, Vitalya, Sam, Youssef Fahmy, Antonios Barotsis, maxicarlos08, Hudson, Corvella, Thomas S, flo, Terraaaagd, Ellen Sun, mkatsenelson, Avi Weinstock, UncomfySilence, BigKhan, Rovetown, TaylorNAlbarnaz, Julian Tölle, NiniKo, Joshua Barretto, Thanos Psaridis, Tao In Way, Isse, Scott Bronson, walpo, Nicolas Wildner, MadirexRus, Marcel Märtens, Samuel Keiffer, cat stevens (catb0t), Christof Petig, walpo, Thegaming Life, Imbris, Pedro H, Sophia Waggoner, CxRedix, jshipsey, IsseW, Nils Ascheuer, Jonathan Berglin, Kittycat, Joseph Donofry, Ben Wallis, Tormod Gjeitnes Hellen, Justin Shipsey, Maxicarlos08, Joshua Yanovski, James Melkonian, Zaixun, Yusuf Bera Ertan, DaforLynx, and Archit Gupta Support the project</h3> As always, feel free to support the project on Open Collective. It allows us to keep our servers running, and launch great release parties like the one for this release! Two Weeks in Veloren 212 Mon, 19 Jun 2023 00:00:00 +0000 These weeks, we look closer at two of the ongoing development activities 🌬️ 🌵 and ask you for feedback on hammer 🔨. - Christof, TWiV editor Contributor Work</h2> Thanks to last two weeks' contributors @imbris, @walpo, @floppy, @aweinstock, @tormod, @archit, @mkatsenelson, @xMAC94x, @uniior, and Youssef Fahmy. The merged work includes mapping between RTSim, character and ECS ids, migration towards IETF language tags</a>, cliff town rework, a visual edge enhancement shader, town placement improvements, nix/flake updates, chat borders, CIDB server swap, more cacti models and small balance changes. Ongoing (unmerged) work is happening on dwarven quarry, physics synchronization between server and client, cart tethering, inventory rework, coastal towns, axe rework, winit and iced changes, learnable recipes, terracotta ruins, beginner difficulty balancing, gnarlings close to giant trees, secondary cities, CI optimization, woodcrafting tools, better game controller support, food rework, plugin code cleanup, avoiding dungeon-cave-intersections, recipe and stats tweaks, and glider-wind-interaction. Link to the weekly meeting minutes: Jun 17th</a>. Wind 🌬️ effects on gliding by @laund</h2> In reality, gliders don't just glide downwards - they can reach quite high altitudes by using atmospheric phenomena that produce lift. I have been working on adding a few of these to Veloren to make it possible for gliders to climb up in the air. The types of lift I have implemented are Thermals, which are columns of hot rising air created by the sun hitting surfaces and heating the air above. Thermals are more likely to occur in direct sunlight, so the time of day is a very important factor.</li> Ridge lift, which occurs when wind hits the side of a mountain and is guided upwards. This is not very reliable as it depends on the strength and direction of the wind.</li> </ul> </figure> Your browser does not support the video tag. </video> </figure> See also this discord thread</a> for more info. Cacti 🌵 rework by @Uniior</h2> With feedback received from Gemu, I have remade the cacti models that were in the game since 2019, plus added a few extra ones made by Ge. Here's a comparison for both the old cacti and the new ones remade by me, for reference. </figure> Hammer 🔨 skill questionnaire by @Sam</h2> As the axe skill tree rework nears its completion, it is time to start collecting ideas that will be used in the hammer rework. The hammer's intended play style is to provide crowd control and support. The abilities in the hammer skill tree are broadly intended to deal a large amount of poise damage to stagger targets, and have a hefty amount of knockback to remove enemies from your allies. Suggestions for the hammer abilities can be made in this form</a>. Assorted impressions</h2> </figure> Does curiosity kill cattle? </figcaption> </figure> A tower bathing in red sun-light. See you next week! </figcaption> </figure> Three Weeks in Veloren 211 Mon, 05 Jun 2023 00:00:00 +0000 These weeks, we look at some of the ongoing development activities. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last three weeks' contributors @zesterer, @taoist, @vasco, @thanosfisherman, @crabman, @lioncat2002, @tormod, @floppy, @tygyh, @xMAC94x, @walpo, @doiska, @Isse, and Thomas S. The merged work includes various fixes, charms, translation updates, one-way walls, loudness fixes, durability free areas, site placement improvements, IP address anonymization in logs, frost gigas in game, experimental shaders, fall damage fixes, savanna hut updates, plant creatures, cyclops and dullahan tweaks. Ongoing (unmerged) work is happening on ship movement, pet commands, Terracota ruins, dwarven quarry, coastal towns, cliff town rework, axe skills, physics sync, and many many more others. Link to the weekly meeting minutes: May 27th</a>. Vehicles by @zesterer</h2> I've mostly been screwing around with vehicles this week. In particular, I've been working on adding wheeled vehicles. </iframe> </div> </figure> </iframe> </div> </figure> RTSim NPC movement debugging by @Isse</h2> Recently a branch I was working on isse/rtsim-work was merged. With this came a fix for a bug that caused pilots to be dismounted from their airships if the ship was unloaded but the pilot wasn't. This also means that you won't find any empty airships anymore, yes it was a lot of fun, but airships also had their own issues and exploits. And hopefully players will be able to drive vehicles again, and it not being through a bug. It will also fix a bug causing rtsim monsters to swim into the depths of the ocean, never to be seen again. While fixing these issues I thought it would be nice to have a more proper way to view what was happening in rtsim, which became my weekend project. I first made a very simple version that drew everything on the CPU. The small yellow dots are npcs </figcaption> </figure> The next day I made a more involved version which uses bevy</a>, which draws things on the GPU making it a bit more efficient to run. And I added some features like inspecting and querying for NPCs. Source branch</a> </iframe> </div> </figure>Plant creatures by @taoist</h2> Recently, our branch, "plant creature" is merged. This branch consist a set of enchanting "plant" creatures that has been specifically designed to cater beginner players. The primary objective behind the inclusion of these new mobs is to enhance the starting experience for beginner players. </iframe> </figure> Charms by @taoist</h2> Charms, akin to ancient talismans or magic papers known as ofuda, offer players a unique way to harness supernatural powers and gain an edge in their adventures. Each charm corresponds to a specific unique attribute, allowing players to inflict unique effects on their foes or bolster their own abilities. These charms add an exciting layer of strategy and versatility to the gameplay experience. While these charms are not obtainable by normal means yet, their inclusion in our game opens up a world of possibilities for future updates and expansions. </figure> Site rework by @floppy</h2> Recently some work was done on existing and upcoming sites: Sea Chapel was overhauled and a couple of new assets and NPCs by Gemu were added, such as Coral Golem, Sea Bishop and Dagonite. Savannah Pits received two additional building types: Hut and Workshop. Cliff Towns were reworked for improved structures with better stairs and more accessible workshops. A new site, Coastal Town, was completed and work has progressed on a new dungeon, Terracotta Ruins. Also part of the site work was to include optimizations to prepare the sites better for the zoomy-worldgen optimization branch. </figure> A preview of an underground place by @Hannibal</h2> Your browser does not support the video tag. </video> </figure> Four years ago in comparison</h2> </figure> So many lights in the night! See you next week! </figcaption> </figure> Five years of Veloren Mon, 29 May 2023 00:00:00 +0000 This week we look back on the past five years of the project. - Christof, TWiV Contributor 2018 May 25th</h2> initial post on reddit </figure> </a></li> </ul> The name Veloren was chosen on May 28th</a>, it is a simplification of the German word for "lost": "verloren". Above's banner image was taken on 2018 July 2nd</a> and is the oldest screenshot in this collection. 2018 July 4th, Release 0.1</h2> </figure> </iframe> </div> Video of terrain generation </figcaption> </figure> On July 24th ambient occlusion was added</a> </figure> August 10th screenshot</a> </figure> On August 14th veloren.net</a> went live. On September 11th structures were added</a> </figure> September 21th A video with server commands</a> and another one with worldgen</a> and the new UI</a> </figure> October 21st worldgen work</a> and a new screenshot </figure> </a> On October 22nd terrain color blending was added </figure> </a> On October 24th terrain was generated by a single continuous function </figure> </a> November 6th saw a rework which temporarily broke character rendering </figure> </a> On November 18th the main menu was added</a>. </figure> On December 4th FXAA became an option</a> </figure> On January 15th the animation system was recreated</a>. On February 4th the first devblog</a> went live. On April 14th the book</a> went live</a>. April 16th Animation update with the new engine </iframe> </div> </figure> On April 17th this public thank you listed many early developers and their contributions</a>. 2019 May 28th, Release 0.2</h2> 0.2 was a full rewrite compared to 0.1 and came with enhanced stability. Highlights: Gliding, character customization and name tags, music, sword combat. Announcement</a> Devblog</a> </figure> 2019 August 4th, Release 0.3</h2> Highlights: NPC combat, caves, XP and leveling, character customization, day/night cycle. Devblog</a> </figure> 2019 October 10th, Release 0.4</h2> Highlights: Administrator level, asset reloading, adjustable FOV. Devblog</a> </figure> 2020 January 31st, Release 0.5</h2> Highlights: Moon, clouds, sounds, map, erosion simulation, new NPCs. Devblog</a> News </iframe> </div> </figure> Gource </iframe> </div> </figure> 2020 May 16th, Release 0.6</h2> Highlights: Music, hairstyles, authentication, advanced combat, armor, fields, dungeons, cultists. Devblog</a> Trailer </iframe> </div> </figure> 2020 August 15th, Release 0.7</h2> Highlights: Lottery, dancing, groups, crafting, furniture. Devblog</a> </figure> 2020 November 28th, Release 0.8</h2> Highlights: Far terrain, shadows, more attacks, sneaking, rolling, travellers, auroras. Devblog</a> Gameplay </iframe> </div> </figure> 2021 March 20th, Release 0.9</h2> Highlights: Reflections on water, skill trees, gems, trading, new dungeon NPCs, cliffs, giant trees, glow effect, airships. Devblog</a> Your browser does not support the video tag. </video> </figure> 2021 June 12th, Release 0.10</h2> Highlights: Mining, one handed weapons, crafting stations, new glider physics, minimap, new caves, craftable armor. Devblog</a> Party </iframe> </div> </figure> 2021 September 9th, Release 0.11</h2> Highlights: Persistent pets and terrain, spots. Devblog</a> Trailer </iframe> </div> </figure> 2021 December</h2> 150th devblog</a> And the first Christmas party</a>: </iframe> </div> </figure>2022 February 19th, Release 0.12</h2> Highlights: Hats, mounting pets, spiders. Devblog</a> Trailer </iframe> </div> </figure> 2022 July 23rd, Release 0.13</h2> Highlights: Modular weapons, weather system, cave biomes. Trailer </iframe> </div> </figure> Party </iframe> </div> </figure> Devblog</a> 2023 January 7th, Release 0.14</h2> Highlights: SeaChapel, water animation, sword skills, instruments. Party </iframe> </div> </figure> Devblog</a> A personal take on five years of Veloren by @zesterer</h2> Veloren is now more than 5 years old, and still kicking. I think this should come as a surprise to anybody that joined the project in the early days; it's most definitely a surprise to me. The project means many things to many people, but perhaps a little context about what it means to me might be interesting to some. In May 2018 I was coming to the end of my final exams at university. I also had a dissertation to finish and so, naturally, I did everything I could to distract myself from these inevitable realities and began aggressively pursuing anything that would take my mind off them. I remembered a game I'd found several years earlier, Cube World, that I'd briefly been obsessed with (despite not having a computer capable of running it). Disheartened by the lack of updates, I set about recreating</a> some of the bits I found most enjoyable about the game - the rolling hills and bright colours - as a weekend demo project using my newfound knowledge of C++ and OpenGL. After posting about the demo on the Cube World subreddit, I was shocked to find that the enthusiasm to turn it into a larger project was strong. People encouraged me to set up a Discord server for those interested, and suddenly the project was born. At the time, I considered it a bit of fun, something that would die down after a month. Back then I was never very good at committing to projects (as evidenced by 100+ dead repositories attached to my GitHub account), so I didn't have particularly high hopes for this one either. Needless to say, I severely underestimated the effect that an enthusiastic community has on the development process. Whenever I was lacking in motivation members of the community were there to cheer us on: and as one active developer turned into two, and two turned into five, and five turned into a dozen, the project began to take on a life of its own. The rest, as they say, is history. Five years on, I feel no sense of personal ownership over the project. Although I'm still an active developer, the project is so much bigger than any one individual. I'm frequently amazed by the skill and craftsmanship of others working on the project: artists, composers, programmers, designers, moderators, wiki editors, DevOps wizards, documenters, playtesters, and all those working in and around the project to make it what it is. If you'll excuse my grandstanding for a moment: What's most astounding, to me, is that nobody working on Veloren is paid for what they do. Every single person that contributes to the project does so without the expectation of reward or profit, creating a game that is free in the absolute strongest terms: not simply free to play, but also free from the constraints of monetisation, free from the whims of investors, free from the requirement to generate profit, free from the need to extort both players and developers as is so common in the increasingly exploitative games industry. Further, it's a positive affirmation that games and game development can not only survive outside the sphere of the profit motive, but that they can thrive for the very reason that they decide to reject it. It's also evidence to me that humans are at their most creative and motivated when they're not cajoled into the hierarchy of a corporation but are free to self-organise as equals. In this sense Veloren is as much a game as it is a political statement, and the project holds within it - as do countless other community-driven projects - the seeds of a possible future where the work we do, the games we play, and the communities we frequent do not need to exist at the behest of undemocratic corporations. We need only choose that future. For now, I'd just like to thank everybody that's been part of this project, no matter whether you've worked on the biggest features or whether you're a casual player that logs in to the server for an hour each month to check things out. I'm incredibly excited to see what the next 5 years has in store for the game and its community! 2023 July 1st, Release 0.15</h2> Highlights: Locks and keys, durability, rtsim2 (professions), sitting on chairs, Adlet caves. Do you want to explore this in game? Join us for the 0.15 release party! </figcaption> </figure> Three Weeks in Veloren 210 Mon, 15 May 2023 00:00:00 +0000 These weeks, Adlet dungeons and pets-on-shoulders were merged. The toolchain received an update and the server infrastructure was reworked. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last three weeks' contributors @Isse, @walpo, @Amaiolamo, @tygyh, @xMAC94x, @Terraaaagd, @DaforLynx, @zesterer, @hannibal, @imbris, @Vitalya, @Corvella, @Sam, @vasco, @maxicarlos08. The merged work includes translations, dependency updates, music updates, balancing, subtitles, server start optimization, dual sword skills, terrain persistance optimization, and sittable sprites. Ongoing (unmerged) work is happening on dwarven quarry, axe skills, plant creatures, seachapel rework, coastal towns, plugins, economy, pet commands, world generation, rtsim timescale, and many many more others. Link to the weekly meeting minutes: April 29th</del></a>, May 6th</a> and 13th</a>. Audio subtitles by @Isse</h2> Your browser does not support the video tag. </video> Audio subtitles (lower right) </figcaption> </figure> More complex patterns on blocks</h2> @zesterer has implemented material specific shaders, a very early prototype looks like this. This is promising interesting visual options for the future. </figure> New animations</h2> by @floppy </iframe> </figure> </iframe> </figure> and by @Lowis Your browser does not support the video tag. </video> </figure> Party map progress by @Hannibal</h2> </figure> </figure> More screen shots from the game</h2> </figure> </figure> </figure> Is it going to rain soon? See you next week! </figcaption> </figure> Three Weeks in Veloren 209 Mon, 24 Apr 2023 00:00:00 +0000 These weeks, durability and rtsim2 became part of the game. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last three weeks' contributors @aweinstock, @tony, @imbris, @UncomfySilence, @Christof, @hudson, @Sam, @floppy, @zesterer, @Isse, @taoist, @Corvella, @apricote, @ubruntu, @pegasus4903, @walpo, @amaiolamo, @tygyh, @xMAC94x. These changes include inventory list mode, an underwater fall damage fix, dependency updates, sword tweaks, multiple models in one VOX file, loot scrolling fixes, equipment wear on death ("durability"), drawing optimizations, salamander animation, resource exhaustion and NPC professions and detailed behavior ("rtsim2"), dullahan attacks, many further NPC behavior fixes, shader fixes, riding fixes, "multi-loot", translation updates and more sounds. </figure> Ongoing (unmerged) work is happening on adlets, combat balancing, Frost Gigas, accessibility, NPC behavior, sea chapel, economy, sit-enabled sprites, faster server startup, airship docks, charms, pyroscope, civilization simulation, and "zoomy worldgen". Link to the weekly meeting minutes: April 22nd</a> </iframe> </div> Code reading for rtsim2 </figcaption> </figure>Many new animations by @floppy</h2> Veloren seems to become a much scarier place if you watch these previews: Dullahan animations </iframe> </figure> </iframe> </figure> Cyclops animations </iframe> </figure> </iframe> </figure> Adlet elder animations </iframe> </figure> </iframe> </figure> Drum animations </iframe> </figure> Sea chapel animations </iframe> </figure> </iframe> </figure> </iframe> </figure> Your browser does not support the video tag. </video> an inn </figcaption> </figure> Airship furniture by @Isse</h2> In TWIV 206</a> you might have noticed an airship with a set of chairs on it. That's something I've been developing on and off the last couple of months. The goal is to be able to give more detail to airships and boats using sprites (which can be furniture, doors, ropes). This also makes voxygen handles voxel colliders a lot more like normal terrain, where you can interact with some blocks, other blocks give off particles or even sounds (sounds are yet to be implemented). 4 With this feature I've also implemented a way to mount a few sprites, like chairs or a helm which lets you control the vehicle. This makes riding an airship much more seamless as you don't have to worry about falling off. Your browser does not support the video tag. </video> airship equipment </figcaption> </figure> progress on the next release party map </figcaption> </figure> Game Gallery</h2> </figure> </figure> </figure> </figure> </figure> Getting ready for nightfall. See you next week! </figcaption> </figure> Three Weeks in Veloren 208 Mon, 03 Apr 2023 00:00:00 +0000 These weeks, we get to select a spawn location. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last three weeks' contributors, @imbris, @DuckLuck, @floppy, @christof, @zesterer, @Sam, @Pfau, @ProfessionalHobbyist, @yusdacra, @kinoshi, @tygyh, @Isse, and @Maxicarlos08. These changes include the new sword skill tree, an April's fool surprise, configurable day length, RON based spots, time synchronization, translations and the selection of the starting town. Ongoing (unmerged) work is happening on rtsim2, Adlet dungeons, Durability (aka death penalty), multi-loot and the optimization branch "zoomy worldgen". Links to the weekly meeting minutes: March 18th</a>, 25th</a> and April 1st</a> Work on learnable recipes by @James</h2> I've been working on crafting recipes. With my changes recipes can now be learned. Pfau and Gemu are working on the art side </figure> Your browser does not support the video tag. </video> </figure> Selectable Spawn location by @zesterer</h2> I'm working on allowing new players to choose their spawn location. The UI is still quite rough and @Pfau [GMT +2] will probably force me to clean it up before merge, but it does at least work. In the long term, I'd like this to grow into a system that allows you to choose your character's backstory and attributes more like a traditional RPG. (Yes, that is a temporary slider, I have no intention of forcing players to move a slider to choose their site) </figure> And here's the final result: </figure> Rtsim2 work</h2> @zesterer and @Isse are working on bringing the new simulation ready, this involves a lot of different professions in towns, more meaningful behavior of NPCs and persistent resource exhaustion. </figure> Two NPCs engaged in conversation </figcaption> </figure> Multi-model voxel files</h2> @Christof is working on loading multiple models from one voxel file, this should make coherent design of armor sets more easy. </figure> Adlet animations</h2> @floppy, @Gemu and @Sam are tirelessly working on making the Adlet dungeon a remarkable place </iframe> </figure> </iframe> </figure> Your browser does not support the video tag. </video> </figure> Assorted game impressions</h2> </figure> </figure> </figure> </figure> </figure> Isn't this magical? See you next week! </figcaption> </figure> Two Weeks in Veloren 207 Mon, 13 Mar 2023 00:00:00 +0000 These weeks, we see work on creating visual guides for people new to Veloren, progress on rtsim2, and a poll for a skill tree overhaul. - Sam, TWiV Contributor Contributor Work</h2> Thanks to last two weeks' contributors, @Pfau, @catb0t, @imbris, @floppy, @zesterer, and @Sam. These changes include culling of underground terrain for rendering, more spots such as campsites, the ability to lock camera zoom, and optimizations related to buffs and auras. </figure> Ongoing (unmerged) work is happening on sword rework, durability (death penalty), adlet caves, more food types, unlockable recipes, quests, arches, and many more. </figure> New Core Developers</h2> We recently added two new core developers. Welcome @Isse and @aweinstock to the core dev team. Visual Guides by @Atenea</h2> Atenea has created some visual guides to help new players to Veloren. </figure> </figure> </figure> </figure> </figure> </figure> </figure> Work on rtsim2 by @Isse</h2> This week I've been doing some work on rtsim2, in hopes of getting a version that's not a regression from master merged soon. More specifically I worked on rtsim birds, such as phoenixes and rocks, currently the implementation is very similar to master, except they have a home dungeon they will fly back to. In the future I hope the home can be a nest on top of a mountain or something similar. </figure> The second part I worked on was repopulation. One problem with the current rtsim is that players eradicate the population of both NPCs and phoenixes. Which is also the reason why merchants are currently immortal. That will be removed in rtsim2 as NPCs and birds will now be replenished. In the current implementation (might be changed before it gets merged) the population will always stay the same, as when one NPC dies, another one will spawn in another place. </figure> Buff and Aura Optimizations by @Sam</h2> Buffs have been using much more network bandwidth than they should need to. The reason for this is that they kept track of their remaining duration by a counter that decreased every tick by the delta time. Because this modifies the Buffs</code> component on an entity, it then is marked as needing to be resent over the network to each client, when obviously nothing has changed that the client should not be able to predict. </figure> Instead of tracking how much time each buff has remaining before it expires, I changed buffs to instead calculate what time they will end at. This has the added benefit that buffs do not need to be mutated every tick, which allowed for an additional optimization: the buff system would no longer require mutable access to buffs (which means it can parallelize with other systems that also need to access buffs). This change was also extended to auras as the implementation were similar enough to make doing so easy. Release Party Map by @Hannibal</h2> Hannibal has created the past few maps that we've had for release parties, and is working on the next one. </figure> Axe Skill Tree Overhaul by @Sam</h2> Now that the second sword skill tree overhaul is effectively done, we can begin the skill tree rework for axes. As with the sword rework, we plan to shift away from passive skills instead to unlocking active abilities. The axe is intended to be a weapon that is focused on maintaining a high amount of combo for more powerful attacks, with a berserker-theme. The ideas will primarily be used as a source of inspiration when designing the axe abilities. Some things to note, being specific in your ideas can be helpful, as it allows us to have a better idea of what your idea would actually entail, but if your idea contains numbers it will be ignored and discarded (by an auto-filter). Axe Skill Tree Suggestion Form</a> Unlockable Recipes by @James</h2> </figure> James has been working on unlockable crafting recipes. Pfau and Gemu have provided some models. Your browser does not support the video tag. </video> </figure> Recent Player Growth</h2> We recently saw a large influx of players that have pushed both the official server and community servers to the limits. Because of this, there has been some recent focus on optimizations as well as a decrease to the max player limit on the official server. Assorted game impressions</h2> </figure> </figure> Isn't this magical? See you next week! </figcaption> </figure> Two Weeks in Veloren 206 Sat, 25 Feb 2023 00:00:00 +0000 These weeks, we see work on extending voxel model usage in the game and hear about asset licencing. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last two weeks' contributors, @James, Scott Bronson, @walpo, @floppy, and @tormod. These changes include energy fixes, bird and Frost elemental and werewolf animations, and site placement changes. </figure> @James added swing sound effects to the new sword abilities. Ongoing (unmerged) work is happening on sword rework, camps (see below), sittable sprites, durability (death penalty), adlet caves, culling (display speedup), more food types, and many more. Deck-chairs </figcaption> </figure> Weekly meeting schedule change</h3> With less people attending the weekly meeting in this year we created a poll and found that Saturday evenings works best for the respondents. With the confusion about time zoned meetings in mind we decided for Saturday 8pm Bristol, UK time. So if you live in the northern hemisphere the time should remain mostly constant across the year, with a brief period of out-of-sync close to the switching. The later time should still make it convenient for west coast US and South American participants (sorry about the meeting time shifting two times a year). The 'weekly' developer meeting minutes are available at 2023-02-11</a>. </figure> More expressive site design</h3> @Pfau, @Sam, @zesterer and @Christof are working on getting more functionality into sites. Sites are small voxel models spread randomly across the world, you might have encountered them as witch houses, lion rocks, dwarven graves and many more. These voxel files typically come with a RON file describing some colors as special voxel, e.g. where to place doors, the cauldron, windows and chests. Now besides all sorts of materials (including Air and GlowingRock), trees, fruits and unoriented sprites, you can also define RotatedSprites (rotation is relative to the model and gets modified according to the random placement, the "unit" vectors), EntitySpawners (these place a NPC at this block with a specific chance) and a Keyhole. Keyholes react to items in your inventory and then destroy all (closed) doors around them. </figure> The creators of these features had mage towers and mines in mind, but we are quite sure that this convenient way to add content to the game with minimal coding (you have to add some lines to register the site with its environmental requirements, e.g. only spawn in cold climates in nearly flat areas) will enable lots of exciting contributions in the future. See the "camps" branch for this ongoing work. </figure> PS: @Christof thinks that this is a perfect candidate for cool extension mods using plugin files, especially if the remaining coding gets replaced by a RON file describing the environmental constraints via an enum. A most obscure physics bug by @Atenea</h3> If you use the glider at a proper angle just before diving into the water, you can propel yourself. You can do it repeatedly, even crossing lakes like this. https://imgur.com/a/I6bZN1X</a> Asset relicensing</h2> It became clear, that while the intention to share content for usage on open source games was well stated with the GNU general public licence, its requirement to share all source files to re-create the content was never fully intended for non text-based files like music and graphics. Thus we looked for a more suitable licence for game assets and contacted music and graphic contributors about their opinion. Two licenses made it to the final round, CC-BY</a> and CC-BY-SA</a>. While the SA variant is most similar to the previous GPLv3 licence it might create legal questions for using the music and graphics while streaming game content. Generally the consensus reached was to prefer the non-SA variant to enable free reuse in video streaming. So, if you have contributed content to veloren and want to re-license your files to a creative commons licence, reach out to the project via matrix or discord. Already contributed files keep their licence as GPLv3, but if you contributed music you might want to re-licence to escape GPLv3's source material guarantees. For future contributions to the game please either directly embed the licence of your choice into the file (e.g. in a file comment) or state it in a text file in the same directory. </figure> PS: Of course the licence decision remains the sole choice of the copyright owner! If you prefer the most liberal CC0 this is fine as well, as CC0 content can be included in any game without drawbacks. A ND clause will prevent modifications to your content, so you prevent us from re-coding into more efficient or suitable file formats in the future. And a NC clause might interfere with or even prevent potential future releases on proprietary gaming platforms. Assorted game impressions</h2> </figure> </figure> Isn't this magical? See you next week! </figcaption> </figure> Three Weeks in Veloren 205 Wed, 08 Feb 2023 00:00:00 +0000 These weeks, we see glowing sprite voxels and internship results. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last three weeks' contributors, @zesterer, @aweinstock, @isse, @joedonofry, @niniko, @tygyh, @walpo, @Corvella, @vasco, @Teffmasterjeff, @poggly, @floppy, @Christof, @capucho, Nicolas Wildner, @MadirexRus, @imbris, @james. These changes include potion sickness, many translations and fixes, more creatures, moderator badges and chat command suggestion fixes. The 'weekly' developer meeting minutes are available at 2023-01-22</a>, 2023-01-29</a> and 2023-02-04</a>. Potion shops were created during a two week internship by @nixda</h3> In my two-week internship about game-design, I learned a lot about the different aspects and tasks that come with it. I was always interested in programming and I always wanted to contribute to a game, which now I did. Around 1 month before the Internship started, I started learning the basics of Rust. In my first week, I learned a lot about what comes with game-design, for example economy or how the code of Veloren is structured and where to find things etc… In the second week I build my own random generated "house" using site2. </figure> </figure> Glowing sprite voxels finally made it into the game</h3> </figure> Assorted video and image impressions</h3> Your browser does not support the video tag. </video> </figure> </figure> </figure> </figure> </figure> Lightning at the tower. See you next week! </figcaption> </figure> Three Weeks in Veloren 204 Wed, 18 Jan 2023 00:00:00 +0000 These weeks, we make site code developers more productive and can't stop including images from the gallery. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last three weeks' contributors, @yusdacra, @DaforLynx, @ashirviskas, @thanosfisherman, @vasco, @blinc, @zesterer, @xMAC94x, @imbris, @tygyh, @Isse, @Sam, @nico, @Pfau, @floppy, @walpo, @Corvella, @James and @nixda. These changes include translation fixes, trading message fixes, graphics fixes, new instruments, soundtracks, sprite timeout, energy modifications, hitbox fixes, nix fixes, chat controlled experimental shader activation, MacOS fixes, wind sway fixes, better inventory sorting, and the changes for the 0.14 release! @James changed bat behavior: They now have larger hitboxes, move slower, and should bounce up and down less. The 'weekly' developer meeting minutes are available at 2023-01-01</a> 2023-01-15</a> Site2 hot reloading by @Sam</h3> I added the ability for site2 to be dynamically compiled, which allows changes to the code to be made and observed in game without needing to recompile (though you'll still need to use the /reload_chunks command). This uses the same mechanism that animations and agent code uses for hot reloading, and can be accessed by compiling with the hot-site feature. Your browser does not support the video tag. </video> </figure> Veloren Original Sound Track, 2023 edition</h3> @DaforLynx has created an updated OST with many updated screen shots, three hours filled with music and beautiful pictures. </iframe> </div> </figure>Plenty of beautiful screenshots from the #gallery channel</h3> Happy New Year in veloren </figcaption> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> Your browser does not support the video tag. </video> </figure> </figure> </figure> </figure> </figure> </figure> </figure> Looking out for more things to come. See you next week! </figcaption> </figure> Veloren 0.14 Release Fri, 06 Jan 2023 00:00:00 +0000 0.14 Release</h2> Veloren is releasing 0.14! This version is about 5 months in the making, and we have a lot to show off! If you're reading this before 18:00 GMT on January 7th</a>, make sure to join the release party. On the side, you can also watch the release party dev stream</a>, where we'll be chatting with devs about what went into this version. To join, you can download the game for free at veloren.net</a> and create an account</a>, then launch the game and hop on the default server. See you there! New in this release</h3> Here are some of the changes in this release: Added a Craft All button and new recipes</li> Musical instruments can now be crafted, looted and played</li> Pets can now be traded with</li> Added redwood and dead trees</li> SeaChapel, Greek/Latin inspired dungeon for ocean biome coasts</li> Doors now animate opening when entities are near them</li> Added screen-space reflection and refraction shaders</li> Added reflection quality setting</li> FxUpscale AA mode for higher quality graphics at reduced internal resolutions</li> NPCs now move to their target's last known position</li> </ul> Bridges</h4> </figure> Water flow</h4> Water will now move according to its apparent flow direction </figure> Changelog</h3> As always, there are always more changes than we can add to a single post! You can check out the full changelog here</a>. Thanks to this versions contributors (in random order): Tormod G. Hellen, Timothy Finnegan, Samuel Keiffer, Rares, UncomfySilence, 4ydx, Tianyang Zhang, Monty Marz, Bingen Galartza, Avi Weinstock, Welvex, Jonathan Berglin, holychowders, AldanTanneo, Ben Wallis, Dominik Broński, Saverio Miroddi, parzivale, Koboo, fanix472, Justin Shipsey, loki, MadirexRus, zDrag0nG, Benoît du Garreau, pepsalt, Henning Meyer, Halosesparta, Imbris, Thanos Psaridis, Kavin Teenakul, matheusclmb, Valter Sanches, Tine Jozelj, Vincent Foulon, Joshua Barretto, Juan Pablo Lagos, kitswas, WanCheng Ye, electro79, Marcel Märtens, Youssef Fahmy, IsseW, rmdlv, tygyh, flo, Socksonme, juliancoffee, James Gayfer, LunarEclipse, Sau, Yusuf Bera Ertan, Francesco Vasco, Kuba 1001, Julio Cezar Silva, Joshua Yanovski, Christof Petig, Tavo Annus, Eternalisime, Blinc, James Melkonian, Matheus, flo666, Gamma, Tim Finnegan, Madrots, Aidar Shaikhiev, Dong, Couls, DaforLynx, and Matas Minelga Support the project</h3> As always, feel free to support the project on Open Collective. It allows us to keep our servers running, and launch great release parties like the one for this release! This Week in Veloren 203 Thu, 29 Dec 2022 00:00:00 +0000 This week, we celebrate snow and glowing tree decorations. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last week's contributors, @DaforLynx, @Seventh Sam, @Pfau, @Rares, Francesco Vasco and @zesterer. Veloren on Steam Deck </figcaption> </figure> Skill bar rework by @Pfau</h3> </figure> Bag and Spell book buttons were moved and merged with elements on the left and right of the skill bar. Frost Gigas by @UncomfySilence</h3> A group of aspiring coders (@floppy, @Ythern, and myself) have been working over the past winter to present the first Veloren World-Boss! Frost Gigas (concept and models by @Gemu) was intended to be released during the first Winter event last year, 2021, but grew stale shortly before completion. However, thanks to @Floppy's remembrance of the first conceptualised Gigas we decided to try to get it up an running again with some refurbishing. Gigas will hopefully be the first of a numerous elemental giants to roam the open world of Veloren and will need a large group of players to be able to take it down and collect its new uncraftable and legendary loot! Special thanks to @Snowram and @Slipped for the initial ground work for Frost Gigas 😊 Sneak peak to some of the current animations made by floppy on Discord</a>. </iframe> </figure> Christmas event</h3> If you played veloren these days you might have noticed a special festive atmosphere with glowing ornaments in trees lighting the snowy nights. Most of the world is covered in snow and ice. Look out for wild snowball throwing creatures which can reward you with rare treasures like blue cheese or a wooly red cap. </figure> </figure> Winter has come. See you next week! </figcaption> </figure> This Week in Veloren 202 Mon, 19 Dec 2022 00:00:00 +0000 This week, we marvel at improved clouds and bird animations. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last week's contributors, @mentos1386, @jgayfer, Benoît du Garreau, @muphblu, @xMAC94x and @zesterer. Fixing the attack distance for Llamas, and other hoof animals like antelopes, alpacas or donkeys, is @mentos1386 first contribution, it got merged only 75 hours after they joined the Discord server. This feels like record time. For the owners of the currently 67 open merge requests, who contributed a fix and are still waiting for a review or merge decision this might sound outrageous, but please bear with the review team and keep reminding us of contributions to work on. You might simply have come at a less fortunate time or provided a much more complex patch. This week's minutes are here</a>. The meeting was mostly about the creation of this devblog and preparation for the Christmas event. New clouds by @zesterer</h3> Prettier and faster, as promised. Although not as much faster as I'd liked. Turns out that I'd actually already done the 'big' optimisation I thought about earlier but had forgotten about it. Still, substantially faster than before. It's actually faster to just make the noise texture larger and more detailed instead of trying to do lots of samples of the same low resolution texture and composite them. </figure> </figure> </figure> Veloren's got a lot more inputs to work with for clouds than OpenMW, so I can make it do nicer stuff. </figure> Morrowind was 2003, OpenMW is an open-source rewrite of the engine. And it recently got support for post-processing shaders. So, naturally, I added clouds</a>. </figure> Looking down at a town on a river from an airship. You forget how large Veloren's world is until you see each tree from above. </figure> </figure> </figure> </figure> Finance updates by @AngelOnFira</h3> I've updated the last several months of finances in the Google Sheets found here</a>. Of interest, here is the revenue of our Open Collective over time </figure> This also included me creating an expense for server costs of the last several months for Hetzner and Wasabi. The total of this invoice is $1,521.71, and can be viewed here</a>. Bird animations by @floppy</h3> In the past months, I have been adding a bunch of @Gemu's creature models to the game. He sent me a zip to work on something "on the side", and I soon realized that I had no idea what I got myself into. But @Slipped gave me the essential info how to best add creatures to the game. The wyverns' wings were most challenging to add because of their size and shape. Sometimes people say, you have to learn the tried and tested ways properly, to stray from them, and the wings did that for me, in a way. I had to really understand and practice first, what @Slipped taught me, to then adjust that process a little, to get the wyvern wings right. Another favorite creature of mine is the Dodarock, which annoyed many players when it was first added, much too strong. I like its grumpy but friendly face, and I'm always amazed how @Gemu's models seem to have actual personality. </iframe> </figure> Moonlit clouds. See you next week! </figcaption> </figure> Three Weeks in Veloren 201 Tue, 13 Dec 2022 00:00:00 +0000 This three weeks, we buy some extra time for our 200th issue. - Christof, TWiV Contributor Contributor Work</h2> Thanks to last three weeks' contributors, @Pfau, @DaforLynx, @JSweeney743, @FaceImplosion, @ElliotStone1998, @xMAC94x, @Isse, @electro79, @floppy, Francesco Vasco, @Madrots, @tygyh, @rmdlv, and @Gamma. What about issue 200?</h3> We would like to make the 200th issue of "This week in Veloren" special, very much in the tradition of the 100th</a>. But the option to not report ongoing activities by waiting for the 200th to become ready is not attractive as we just managed to get the issues more timely again. So here is the compromise: The issues will be named 199+x until the 200th is ready. Meanwhile we would like to collect personal stories of how people came to veloren and make it a quilted one. Roughly four sentences should already do, unless you have a very special story to tell us. I especially encourage the many non-English speaking server communities to contribute their individual view, preferably in their native language with an English translation to show the diversity of our user base. ¡Por favor escribe tu historia con veloren! Bitte schreib' deine Geschichte mit Veloren! S'il te plaît écrire ton histoire avec veloren! Napisz swoją historię z Veloren! … I just created a thread</a> below #general to collect these, if you prefer to remain anonymous (please say so) or if you use Matrix you can also DM or ping @Christof or @christof.petig:matrix.org - please don't count on me finding unmarked messages in some other channel. Weekly meetings</h3> You can find the weekly minutes at Nov 27th</a>, Dec 4th</a> and Dec 11th</a>. Wyvern</h3> @floppy created nice Wyvern animation videos: </iframe> </figure> </iframe> </figure> </iframe> </figure> </iframe> </figure> </iframe> </figure> And there is a video showing the medium bird animations, which I find very cute to watch </iframe> </figure> Here is another one with peacocks Your browser does not support the video tag. </video> </figure> Moderation web frontend by @Isse</h3> The past week or so I’ve been working on a website which would make things easier for moderators. This website would behave very much like Torvus, a bot that sits on the server and reads all messages on a server, but it would have more features like showing messages from a specific users. Or in general more advanced queries for messages. The main motivator for this change was that the discord search feature stopped working in #ingame-chat, which at least I heavily relied on when making moderation decisions. I also thought that I could use this as an opportunity to learn some rust web dev. I decided to use rocket</a> which is a framework which makes it easy to implement web applications. I used SQLite to store the logs of messages, users and user activity (which allows tracking playtime). And as you can see in the images, a pretty poorly made website with hacky JavaScript. While built to be used on the official servers it can be used for other servers too, I haven't written a guide to setting that up, but if someone would be interested in that you can @ me. The source is on GitHub</a> </figure> </figure> Watching a mesmerizing moon. See you next week! </figcaption> </figure> This Week In Veloren 200 Tue, 29 Nov 2022 00:00:00 +0000 This week, we take a step back and tell some personal stories behind the game development. - Christof, TWiV Contributor I apologize for dragging the final publication of this issue over several months. The excellent and plenty material in our 100th developer blog</a> certainly created high expectations for this issue. Since it coincided with a change of the editor position it was difficult to live up to these. Many people contributed their personal stories and I will just present them in arbitrary order, starting with the short ones. This issue also contains stories from moderators, an important assignment which was less prominent hundred issues ago. Though yet, I was not able to collect as many stories as I had liked to from the many non-English communities which grew during the past months. Please feel free to contribute your stories to a future issue. Stories with Veloren</h2> </figure> @darin755: "I found Veloren after searching for FOSS games other than Minetest. I started playing it and was blown away by how detailed and complex the game is." @RunRobDog: "After months upon months of playing Veloren I still play it now and then because it's just straight up a good game, especially to consider how early it is in development." @acrimon: "I've been here a darn long time too I feel not as early as lunar but still early Veloren had like 20 peeps or something caring about it? I think zest convinced me this was a good idea." @LunarEclipse: "For me it was the comment on the cube world subreddit, I was the 4th person to join the discord iirc and offered to help with setting up the server, then I learned Rust to work on Veloren." </figure> @Treeco: "I can't remember how I learned of it honestly, it wasn't a CubeWorld route, though I happened to join the day CW died so that was a bit of a mess. I mostly just sit in the Discord and argue with people so I never feel I have much to say for these things sadly. I remember the blog posts more than the game itself from early on, somehow? Following what was going on - rivers, at the time. I think I joined the server to follow that better, and then eventually got in to help test them, then got bullied into learning to compile so Sharp didn't have to manually start off a build with every push. Good times honestly. I guess the arguing began as it became more of a game, and my ideas for what kind of game I'd like to see solidified. The simulation aspects were what drew me to the project, and trying to get decent gameplay while not compromising that is an interesting problem. (And subjective as all hell of course. All in good fun, I'm phrasing it as arguing but I think it all stays fairly chill most of the time? I don't know if any of this is worth including in a writeup though. And the end I haven't done much, I guess. Might be impostor syndrome talking, but tbh I probably am the impostor.</del> Don't amogus me, I fucking swear...</del>)" </figure> @DaforLynx: "I formally joined Veloren development in August 2020, making music. At the time, 0.7 had just released. This little project seemed to me an incredible fortune to stumble upon - a true gem. An open-world game, open-source and open-development. The game itself captured my imagination, reminding me both of existing games I had put down and looked upon nostalgically and of games I had imagined making years ago. The years have flown by and I have contributed to development enough that I am now an audio team lead. When I joined, there were 15 music tracks in the game. Now, there are 64. As the gameplay and visuals evolved, so did the audio experience, thanks to the efforts of many, many composers, sound designers, and coders. However, I also see how far we have yet to go. The things I have in mind include a reorganized and revamped audio system, a potential library switch, adaptive music, and the long road to modernizing the audio experience. Which reminds me: among the first tasks to do this year is a switch of all "rendered" assets to a Creative Commons license. Currently, all assets and source code are licensed under GPLv3, which doesn't actually contain provisions for assets specifically. Switching these assets, mainly including all music and sounds, to a new license would clear the water regarding their use and publishing in other projects. This switch hasn't happened yet, but will in the near future. We will need the consent of the owners of the assets to include them in the game after the license switch." </figure> @KaliKatz: "Moderation is just a job like any other, no spot light is really required. recognition, sure..ok. As for the rules, that's going to be different for users and admins of there own servers. Should be up to the admin or admins to post the rules and regulations that there moderators use to police them. We have done that, the rules & info is posted already. We as moderators, should read and understand them, and then police on that basses. As for timeouts and bans, each would have a different case, going to be hard to make rules for each of them. Generally I go with no timeouts and just perm ban. Quite a lot of "people" listen and has worked for me. But I am usually quite forceful, in reminding players, fun is fun, but were all real people in the end and hurt is hurt. I don't reverse my decisions, and give pretty clear warnings before a perm ban. Kicking/killing merely wakes them up and reminds them that mods are real. On those that are clearly perm ban, easy. But easy moderating it isn't. Timeouts are good for those "jail" times, but they just instantly come back as alts, or don't bother coming back at all. Its simply easier to perm ban them away instead of micro-managing. Ban evasion is easy, the account page allows for this and should be made more challenging and slower to discourage griefers. But I have said that before. So, about the guidelines... each server will have its own, we already have ours, maybe add some "new" rules to it from the already heavily used and somewhat abused #moderation-discussion. As for a "spot light", in the end, its merely a self satisfying position...dirty...and no one really cares that you did a bad/good job. Its not for everyone. If its just for the free tp and tricks, then your just using them to play the game differently." </figure> @Christof: "Some weeks ago I realized that the majority of my work-related skills I learned on open source projects. PostgreSQL has taught me how to structure huge C projects, Gtkmm introduced me to the wonders of well designed C++-98, monotone taught me Lua and Boost. On Veloren I learned Rust and WebAssembly which right now is exactly what I use day in day out. I am immensely grateful to the numerous people on these projects which provided me guidance on how to properly write programs. This educational aspect of open source projects might be less obvious but it literally meant the world to me. I wouldn't be in the position I am now without the skills I learned, also on the Veloren project. Two years ago I was keen on making the economic simulation as good as possible - that dream has not come true yet. The economic simulation is still horribly inaccurate but sort of works, the rewrite while more correct had a tendency to spiral down to starvation. I learned a lot and got another brilliant idea on how to really fix it this time … Meanwhile I worked on the plugin infrastructure, both the WebAssembly and the asset only variant of plugins. I originally started this in preparation for a school internship in game development of a friend of the family. But it became clear that even with the work spent on improving wasm plugins, they wouldn't be ready in time. Luckily he proved skillful enough to create parametrized buildings with CSG in site2. At the beginning of this year I was contacted by @Pfau to fix a small glitch in spots - the work on that project has been immensely satisfying - because I had another person who was directly building on my work to create amazing in game structures. I really recommend anyone to team up in development, it is more fun, highly motivating and gives quick feed-back about the features you create. And the chance to get your work integrated into the game increases with every person also having a stake in the feature branch. So thanks to you all for a good two and a half years and let's make Veloren even better and better." </figure> @UncomfySilence: "Hello, most of you know me as Uncomfy. I first came across this game in the comment sections of one of many “CubeWorld’s Downfall” videos back in early April of 2021. I had a lot of free-time back then so I decided to download and boot this game up. The moment I stepped into the world of Veloren, only aware that it was a voxel game similar to CW, I was stunned by the visuals, animations, music, every little bit of the game I experienced. I sat glued to my little desk, walking around world for ~30 minutes, just exploring the various biomes and entities whilst muttering “wow” to myself. After familiarizing myself with the game some more I decided that I wanted to become more knowledgeable about it and help in any way I could considering that it was open source. I honestly didn’t really know how to approach this behemoth of an early development game and the thousands of people already seated within the discord server. I tried my hand at some art and some idea proposals but I mainly just ended up reading the new and unfolding discussions between some of the established members in the community. After some time just asking questions in-game and in discord about game mechanics I ended up with enough confidence to start answering questions from even newer members of the community. There was always the chance that I was wrong with a statement of mine, but I knew that there’d be a correction from someone more knowledgeable just around the corner. I simply wanted to be the one to help guide people that may have been as confused about certain mechanics as I was (considering that I didn’t know how to fix them code wise :P). Over time I eventually became a moderator for Veloren, likely due to my continuous participation amongst the community. To each moderator there is a different meaning to the term “moderation”, even though at the end of the day moderation is just keeping the peace within Veloren. To me, moderating is trying to guide, discuss, enjoy my time, and interact with the community! So far I’ve greatly appreciated my time here amongst the lot of you, no matter how many circular debates with treeco</del> I get into or repetitive questions I answer! Hopefully I’ll get to see some of you in-game or on the discord server soon. :)" </figure> @Hannibal: "Hello! I am Hannibal, also known as DA BIG KHAN in game. I arrived on the discord on January 19th, 2020, after reading about it on Cube World's Steam forum posts. At first, I was just curious about the project, and wanted to see how it’d progress before actually starting to play the game and to contribute on it. At that time, I decided to train on MagicaVoxel, the software we use for models, watching tutorials and practicing to get better at it. I originally come from Minecraft’s building scene, so voxel modeling was familiar, but I quickly realized how different the two were. I came back after a long break from discord activity in June 2021, where I became an active contributor. My contributions are mostly buildings and structures. I like to view myself as a 3D architect for Veloren, where my models serve as mockups for our procgen team. I have only a few actual contributions in the game because I mostly do 3D concept art, rather than direct contributions. Some of the in-game assets include spots (the pirate outpost, some jungle temples and totems, shipwrecks, and the Stonehenge-like structure), dungeon entrances (pyramids and desert structure). I believe I started making a “name” for myself when I designed a desert city in October 2021, which gave us the idea to have party maps, something our seasoned players are (I hope lol) enjoying a lot. In January 2022, we had our first big release party map, the desert city, where at the time, I thought I had pushed the limits of MagicaVoxel. It was a massive success, and I keep a lot of good memories from this time. After that, I began working on the second party map, the Jungle Pirate Islands, where I added an extra layer of work to the process: handmade terrain. It was quite a challenge, where I restarted the project from scratch 3 times and literally broke the vox-spawn tool we had in-game by crashing my PC with a VOX file that was too big. Thanks to Isse, we managed to make it work, and create Veloren’s first pirate hunt! However, with this amount of work for one single mockup, I had a bit of a burnout where I barely worked on Veloren for 3-4 months. At the time I am writing this, I am working on the 3rd party map, inspired by medieval fantasy China and Japan; it is meant to be a mockup for Elven architecture. It is colossal, but with the prior experiences, I learned how to rest, how to optimize my time, and also found new tools and techniques that allow me to add more impressive landscapes. I am most likely going to reach 1k hours on MV with this project, as I am currently around 600-700 hours. However, Veloren isn’t only contributing! It’s also a social gathering of passionate individuals with different backgrounds. I got to meet fascinating people through numerous discord conversations! On top of my head shoutout to: Gemu, the goat artist, my sensei, my boss, who taught me a lot, Isse and Zesty, my coding saviors, without whom none of the party maps would have been possible, Kali, the infamous pirate cook of the King of the Pirates DA BIG KHAN (YARRRRR)! Yuri, the weeb who can crash a server with his gaze, Treeco, how do I even describe him lol. It wouldn’t be the full Veloren experience without Treeco! Pfau, the dentist UI god who does way too many puns lmao. And finally, MY FAILED CLONE, the one and only UNCOMFYSILENCE, whose kindness only has for equal his love for feet! Of course, shoutout to all the team, all the contributors, who have made this one of the biggest open-source projects ever. At this point, this is the part I love the most about Veloren: seeing all those individuals, including myself, dream about the game’s future, while also watching it grow on to become one of the greats someday. I often joke around, saying that we will be GOTY 2025, or that someday, Veloren’s music will become as popular as Minecraft’s, but deep down, I truly believe that we can reach world renown, through hard work, passion, and dedication! THANK YOU VELOREN FOR EVERYTHING!!! Your favorite French, the King of the Pirates, DA BIG KHAN HANNIBAL." So many things to explore. See you soon! </figcaption> </figure> Closing thanks</h2> And of course I would like to thank numerous people who haven't contributed their story here, but instead have created amazing new features, some of them presented in parallel issues (201</a> to 209</a>). This Week In Veloren 199 Mon, 21 Nov 2022 00:00:00 +0000 This week, we see development on new more complex house layouts and many animation work. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's contributors, @ythern, @hjalle2000, xMAC95x, @Sam, @zesterer, @tormod, @tygyh, @kuba1001t, @halosesparta, @holychowders, @floppy, and Francesco Vasco. This week's meeting minutes</a> An improvement to quickly select internal resolution was merged, also @Pfau added the user interface for experience bars: </figure> Dagon attacks by @floppy</h3> </iframe> </figure> Bird animations by @floppy</h3> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Frost Giga animations</h3> The original work by @uncomfy was taken up by @floppy and can be seen in this video </iframe> </figure> Although it already looks impressive @Ythern and @floppy still work on the jumping animation: Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> New houses by @zesterer</h3> </figure> </figure> Not fully intentional variation </figcaption> </figure> Playing music with friends. See you next week! </figcaption> </figure> This Week In Veloren 198 Mon, 14 Nov 2022 00:00:00 +0000 This week, we gain insight into the many exciting developments happening at the moment. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's contributors, @DaforLynx, @Pfau, @floppy, @aweinstock, @floppy, and @holychowders. This week's meeting minutes</a> Train stations by @aweinstock</h3> </figure> </figure> If you want to get a glimpse into the difficulties and debugging aids to implement tracks you can take a look into these series of posts in #rendering</a>. instrument crafting</h3> @Pfau started a discord thread</a> about instrument crafting and received a lot of feedback. Savannah pits</h3> The merge of the savannah pits, a new town type, got lost during the pre-Halloween preparations, now with some minor fixes merged this week we feature a picture from within this town type: </figure> Flower variants by @Ge</h3> </figure> Minotaur buffs by @Froggy</h3> Minotaur attacks just became much more impressive with this work Your browser does not support the video tag. </video> </figure> Moss drake visuals and animations by @floppy</h3> </iframe> </figure> More adlet cave work by @floppy</h3> You can take a look at the current state of the adlet cave work (a new dungeon type) in this video </iframe> </figure> Roshwalr attacks by @Ythern</h3> @Ythern continued their work on giving the Roshwalr a specific attack capability Your browser does not support the video tag. </video> </figure> which then lead to an interesting discussion about the animation building up the attack and a reworked proposal by @floppy Your browser does not support the video tag. </video> </figure> and the subsequent reviews to get it merged. Bad weather ahead. See you next week! </figcaption> </figure> This Week In Veloren 197 Mon, 07 Nov 2022 00:00:00 +0000 This week, we learn about doors and train tracks. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's code contributors, @floppy, @aweinstock and @zesterer. This week's meeting minutes</a> Doors by @aweinstock</h3> Opening doors were merged this week. For now doors open consistently in one direction defined by the world orientation, because responding to a direction they get pushed in would require adding internal state to sprites. Your browser does not support the video tag. </video> </figure> Train tracks by @aweinstock</h3> Tracks are disabled by default and can be enabled in assets/world/features.ron. Train stations and (later) trains are still under progress. Getting the lighting correct on the tracks made this work more complicated. </figure> Your browser does not support the video tag. </video> </figure> Programming Veloren by @zesterer</h3> @zesterer gave a talk at the Rust and C++ Cardiff Meetup which gives a good overview of the early history of and the ideas behind Veloren: </iframe> </div> </figure> Exploring in the rain. See you next week! </figcaption> </figure> This Week In Veloren 196 Mon, 31 Oct 2022 00:00:00 +0000 This week, we admire the visuals introduced for the Halloween event. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @holychowders, @Sam, @jshipsey, @Isse, @floppy, @DaforLynx, @kevinsmia1939, @flaffwaffle, kitswas. Impressions from the Halloween event</h3> Colorful trees: </figure> </figure> </figure> </figure> </figure> </figure> </figure> Water reflections: </figure> </figure> Trick or treat: </figure> </figure> Your browser does not support the video tag. </video> Tricksters playing bass, … </figcaption> </figure> Your browser does not support the video tag. </video> … guitar, … </figcaption> </figure> Your browser does not support the video tag. </video> … and hurdy gurdy </figcaption> </figure> Bats: </figure> Harvester: </figure> A trailer showing off the Halloween themed content along spooky music. </iframe> </div> Halloween trailer </figcaption> </figure> A very special concert. See you next week! </figcaption> </figure> This Week In Veloren 195 Mon, 24 Oct 2022 00:00:00 +0000 This week, we see a preview of the upcoming sword skill tree and the moving and reflecting water changes. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @floppy, @Pfau, Sam, and @uncomfysilence. Water reflections by @zesterer</h3> I've been working on making water flow in the direction of rivers and adding screen-space reflections. </figure> </figure> </figure> A new gnarling chieftain mask by @Pfau</h3> The gnarling chieftain mask can now be looted from... the chieftain </figcaption> </figure> Sword skill redesign</h4> The animations created during the past weeks do now have a matching skill tree - with lots of different options to learn from: </figure> More moody screenshots before the trees get colorful next week</h4> Lightning hits a spot. </figcaption> </figure> Flying over misty hills </figcaption> </figure> Among the redwoods. See you next week for halloween! </figcaption> </figure> This Week In Veloren 194 Mon, 17 Oct 2022 00:00:00 +0000 This week, we plan more for the Halloween event. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's contributors, @Pfau, @4ydx, @zesterer, @Isse. Halloween planning</h3> During this week's meeting we did more planning for the Halloween event: Barren trees are being worked on as part of the citadel branch by @zesterer</li> Discussion of a Halloween boss (Vampire)</li> @Isse has been working on the Halloween branch</li> What can be worked on? Halloween songs in #audio?</li> @Hannibal might be working on a Halloween map location</li> Moving to a tracking issue</a> for all ideas</li> Working on Halloween town decorations</li> Carved pumpkin model</li> Villager costumes</li> Moon recolouring</li> NPC lantern changes, Green or orange</li> Create a broom model for a glider</li> Town NPCs get a spooky hat</li> NPCs are more inclined to using furry/scary clothing</li> Draugrs spawn in the wild and drop candy</li> Exclusive candy drops, would need the model created</li> </ul> See also this week's meeting minutes</a>. Server browser retrospective</h3> How has it been going?</h4> Overall, many communities have had more visibility on their servers, It’s quite easy to see nearby servers. Servers can specify which region they’re in, Number of players on the main game server is currently hovering around a reasonable number (~150). What are some things we’ve heard people want</h4> Communities want to feel more official, Only the main game server gets a star, and there is only one of them. Larger communities want methods to share characters between servers. Player count on servers. I’d like to be able to see which “federation” I can connect to with my current credentials, and how my characters can be shared across servers, This is quite dependent on the new auth system. What are the next steps?</h4> Work on the new auth system: Being worked on by @Nadja, @XVar, @Sharp, @imbris… Work on the player count: How are the config/status of the server being shared with Airshipper? Much is being discussed in this thread: V3650 DRAFT Added Query Server to Veloren Server There are issues of servers just sharing arbitrary information Plugins by @Christof</h4> I work on extending plugins. So far (MR V3658) I was able to add an item to the game without modifying or adding any file in assets and only providing voxel and RON files within assets/plugins/hello.plugin.tar. Sadly this alone is of less value as: sadly you can't build wasm modules in master (so the archive won't load), combined with socksonme/suggin_plugin_debuggin it loads</li> modules are not yet automatically downloaded to a client</li> no support for loot and crafting (so no way to get the items in the plugin as a normal user)</li> </ul> Example plugin: -rwxrwxr-x christof/christof 302432 2022-10-09 21:26 hello.wasm -rw-rw-r-- christof/christof 544 2022-10-16 19:14 plugin.toml -rw-rw-r-- christof/christof 157 2022-10-16 17:56 assets/voxygen/item_image_manifest.ron -rw-rw-r-- christof/christof 23027 2022-10-16 17:56 assets/voxygen/voxel/weapon/tool/paddle.vox -rw-rw-r-- christof/christof 142 2022-10-16 17:56 assets/voxygen/voxel/biped_weapon_manifest.ron -rw-rw-r-- christof/christof 467 2022-10-16 17:56 assets/common/items/weapons/tool/paddle.ron ```txt <figure class="inline-image"> <img src="https://s3.eu-central-2.wasabisys.com/veloren-blog/cdn/597826574095613962/1031262244715122738/unknown.png" loading="lazy" > <figcaption> Sneak preview, the dithering of the wood is still sketchy </figcaption> </figure> <figure class="inline-image"> <img src="https://s3.eu-central-2.wasabisys.com/veloren-blog/cdn/634860358623821835/1031012607253024788/screenshot_1665880531649.png" loading="lazy" > <figcaption> A witch living in the woods. See you next week! </figcaption> </figure> </code></pre> This Week In Veloren 193 Mon, 10 Oct 2022 00:00:00 +0000 This week, we learn about the planning for the Halloween event. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's contributors, Juan Pablo Lagos, @Nether190, @galaipa, WanCheng Ye, @kitswas, @tygyh, @kilpkonn, Julio Cezar Silva, and @james. Halloween planning</h3> The veloren team plans to have a Halloween themed week directly before November ends. Collected Ideas include werewolves, flying bats, spooky lanterns, pumpkins, villagers in costumes, candy drops, "trick or treat" interactions, flying with a broom, a more spooky moon color, acid rain. See also this week's meeting minutes</a> for more details. Ongoing work</h3> Bridges (Isse)</h4> </figure> @Isse has been doing some worldgen work on larger bridges, and can span larger gaps. They are inspired by larger-architected bridges. There is work that does checks at generation time to make sure that the bridges flow nicely into the terrain. There are several different types of bridges, some with the ability to bridge high and low terrain with a tower and stairs to help players get to different heights. Another bridge variant is small, and allows for roads to cross small rivers. Once the bridges are ready, you’ll be able to see them on the minimap as well! These different variants are inspired from medieval bridges in different cultures, as well as different architectural patterns. Prototype models were created by @Hannibal, and then remade with CSG objects by @Isse. </figure> Plugin work (Socksonme and Christof)</h4> @Christof and @Socksonme have been working on updating @zesterer’s plugins branch to the current head of master. @Christof has been planning some dug-out canoes to see how it can be made with the plugin system. Water work (Zesterer)</h4> Zesterer has worked on water shaders. Implemented moving water, screen space reflection, and in general improving water shaders. Although much of this is experimental, the techniques add a lot to how water looks in lakes and rivers. Halloween is coming. See you next week! </figcaption> </figure> This Week In Veloren 192 Mon, 03 Oct 2022 00:00:00 +0000 This week, we watch a certain jumping plumber. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @fanix472, @aweinstock, @juliancoffee, @meyerhenning, @ztianyang. Tracking issues in the book by @zesterer</h3> I added a page to the book that lists all of the currently open tracking issues. I hope this will act as a useful resource for contributors looking to work on things, and hopefully it'll encourage us to improve the quality of our tracking issues</a>! See also this week's developer meeting minutes</a> for more details. Super Veloren 64</h3> Also @zesterer created a cool tech demo because he "was bored today": </iframe> </div> </figure> Translation changes by @Juliancoffee</h3> Me and @xMAC94x made some changes to how chat is translated and introduced the new i18n-helpers crate. For the time being it lies in voxygen workspace. It enables third-party clients to use localisation (and translations, if desired) via the client/i18n subcrate. And with that we now have the possibility to work on more complex translations, like character names and items. Until that point, we could translate mostly GUI only (+ some NPC messages). If you want to work on it, ping me @juliancoffee in #new-contributors A diverse group. See you next week! </figcaption> </figure> This Week In Veloren 191 Mon, 26 Sep 2022 00:00:00 +0000 This week, we hear about recent pet feeding improvements. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's code contributors, @xMAC94x, @Welvex, @zesterer, @floppy, @Sharp, @LunarEclipse, @Sam, @Couls, @MadirexRus. Pet feeding by @aweinstock</h3> To solve the problem of pets choosing not to pick up food (and having other NPCs take the food), I added trade AI for pets. Pets only accept trade requests with their owner, only accept food, and do not return food that they're given. In the process of working with pet inventories to ensure that they had the right amount of slots, I also fixed an issue where pets were not supplied their intrinsic weapons and armour when reloaded on login (e.g. tortoises had significantly lower defence after taming them and logging out and in). Trading with your pet </figcaption> </figure> 20,000 Members in Discord</h3> On September, 22nd we reached the 20,000 member mark in Discord: </figure> Here are some graphs over time: </figure> </figure> Enjoying the view. See you next week! </figcaption> </figure> This Week In Veloren 190 Mon, 19 Sep 2022 00:00:00 +0000 This week, we hear about the airshipper release which deploys the server browser feature. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's code contributors, @koboo, @floppy, @yusdacra, @james, @Sharp, @tygyh, @XVar, @xMAC94x and @juliancoffee. Details</h3> @James fixed a bug where pets would attack their owner when healed with the sceptre. @Sharp is working on several changes to improve parallelism and resource utilization within the server process. One server reported a 10× reduction in tick times at 90 players. (These are separate from his other worldgen improvements which optimize site voxel drawing). Airshipper 0.9 is available and includes a server browser, by @XVar</h3> This release includes an exciting new feature, the Server Browser. As many of you will have noticed, our player count has rapidly increased over the past few weeks, to the point at which the main Veloren server is often no longer the most populated server. To aid discovery of non-official servers, we have added a Server Browser to Airshipper. This feature allows you to select a server before running the game, which will cause that server to be pre-populated in the Server. Initially, all servers featured in the Server Browser will be using the official auth.veloren.net auth server meaning you can use the same username/password for all servers - your characters are still unique to each server though. All servers will also be using the Weekly update channel, so the game client distributed via Airshipper will be compatible as long as the server owner has their server configured to correctly update with the weekly releases. Following this release, the #servers channel is now deprecated and no longer a supported way to share servers. However, we have added the #communities channel in its place, which is focused on sharing your own communities including their Discord, website, etc. If you have a server that you wish to be listed in the server browser that isn't already listed, please follow the instructions here</a>. We hope this feature brings greater accessibility to the many servers run by the community 🙂 If you have any questions or issues regarding this update, please feel free to ask in support or questions. Getting the update</h4> Windows - Airshipper should auto-update itself the next time it is launched. Linux / MacOS - The latest version of Airshipper can be downloaded from the links on our Download page</a>. Flatpak / AUR distributions will be updated shortly. </figure> Testing aids and more by @juliancoffee</h3> I added a new Golden Cheese item. It is meant for testers with admin rights and provides an almost infinite source of health and energy. It helps when you want to test interaction with the world without full invincibility from the admin Tabard. Also the /kit command when containing a modular weapon will give you all variants. The loot export to CSV binary now exports all modular weapons included in a loot table, this helps wiki preparation. And of course, there were minor improvements and bug fixes to internationalisation. Ping @juliancoffee on Discord if you want to get involved. Right now we are designing a system that allows our third-party front-ends to localise content, that should unblock many nice things like translation of NPCs, items, better chat and much more. Exploring the world below! See you next week! </figcaption> </figure> This Week In Veloren 189 Mon, 12 Sep 2022 00:00:00 +0000 This week, we hear about the progress of high quality upscaling. - Christof, TWiV Contributor Contributor Work</h2> Thanks to this week's contributors, @yusdacra, @matheusclmb, @juliancoffee, @Sharp, @xMAC94x, @XVar, @zesterer and @floppy. High quality upscaling by @zesterer</h2> For those that run Veloren with a low internal resolution, I made some changes that might improve the game for you: Firstly, I realised that the way we applied FXAA at internal resolutions other than 1.0x was incorrect. After fixing this, FXAA does its job more effectively at lower internal resolutions. Secondly, I added a HQX anti-aliasing option (although technically, it's less anti-aliasing and more upscaling). It attempts to take the low resolution framebuffer generated by the game and perform edge detection to reconstruct the original geometry. It's by no means perfect, but I personally much prefer it over both no anti-aliasing and FXAA at very low internal resolutions. Here's a comparison at 0.25x internal resolution between no-AA, FXAA, and HQX: No anti-aliasing </figcaption> </figure> FXAA </figcaption> </figure> HQX </figcaption> </figure> This Week In Veloren 188 Mon, 05 Sep 2022 00:00:00 +0000 - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @YusufBeraErtan, @juliancoffee, @Isse, @imbris, @zesterer, @Sam, @flo, @XVar, @DominikBroński, @Dong, @tygyh, @xMAC94x, @Sau, and @zDrag0nG! This week saw an unprecedented increase in player count. When the number of players came closer to the server limit of 400 the overall gaming experience became bad due the long reaction time. Thus this week was dominated by developers working to optimize the server code. </figure> </figure> </figure> @tormeh</h3> A while back I added a modification to NPC behavior where NPCs with a certain personality and above a certain health threshold would attack others if there were no one else nearby (i.e. no witnesses) @floppy</h3> We have been working on playable music instruments that allow players to combine their collected instruments into (hopefully) enjoyable sounds. The guitar in the video uses samples, recorded by @Oolnokk, the model was created by MerlinMan. </iframe> </figure> @YuriMomo, @Isse, @Sharp</h3> There was a spooky interaction between environment variables, a vulkan SDK installation, shaderc, changing Rust compiler versions and voxygen compilation which created a reproducibility nightmare for the developers this week. The problem manifested as broken DX11 and DX12 support with @Sharps latest thread pool changes. See also this Discord thread</a> for more details. PS: Other problems around these changes were far from solved at the date of this blog post. Taking a refreshing bath. See you next time! </figcaption> </figure> This Week In Veloren 187 Mon, 29 Aug 2022 00:00:00 +0000 This week, we see some updates to the parrying stances. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @xMAC94x, @flo666, @juliancoffee, @parzivale, @Christof, @Isse, @flo, @tygyh, @XVar, @Isse, @Sharp, @MadirexRus, @Sam, and @Sau Parrying stance related animations: Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Ukraine update by @juliancoffee</h3> Despite everything, I am now writing this post from my home in Kyiv, the capital of Ukraine. And if at first people were betting how long Ukraine could stand, three days or three months, it's sixth month and it seems that Ukraine still alive 🙂 In 1994, Russian president Borist Yeltsin started First Chechen War and destroyed Grozny, in 1999 Russian prime minister and future president Vladimir Putin led Second Chechen War and occupied Ichkeria Republic, in 2008 Russian president Dmitry Medvedev invaded Georgia, in 2014 Russian president Vladimir Putin invaded Ukraine and in 2022 committed full-scale invasion of Ukraine. And now we have the chance to stop it, once and for all. Huge thanks to all people of the free world for support and huge thanks to Veloren community for sharing my story ❤️. As always, here are some links to volunteer and charity organizations. https://www.comebackalive.in.ua/</a> https://nestprytulafoundation.org/</a> https://www.savedschools.in.ua/</a> Слава Україні! Жыве Беларусь! Glory to Ukraine! Long Live Belarus! Riding from a sea chapel into the desert. See you next time! </figcaption> </figure> This Week In Veloren 186 Mon, 22 Aug 2022 00:00:00 +0000 This week, we hear about work done with the translation system by @juliancoffee. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @juliancoffee, @matheusclmb, @xMAC94x, @parzivale, @xMAC94x, @zesterer, @XVar, @Matheus, @DaforLynx, @SaverioMiroddi, @Socksonme, @Tormod, and @tygyh Translation updates by @juliancoffee</h3> Henlo frens, if you remember last blog</a>, I mentioned that we're moving to a new translation system. And now, I want to say that we officially did it! As you will see in this RFC</a>, our old system was plain hash map in .ron</code> format. .ron</code> is Rust's analogue for .json</code> format from the web world, and it's good for generic structured data but quite verbose for specific cases like translation. Let's look at a "hello world" example. /// Localization for "global" English (.ron) ( string_map: { /// Start Main screen section "main.intro": "Hello, World!", }, vector_map: { }, ) </code></pre> And with our new format, #### Localization for "global" English (.ftl) main-intro = Hello, World! </code></pre> </figure> Of course, we didn't move to a new translation system just because it was verbose, but during my research I was like, wow, it's so pleasant to write in. So, to give more background, we knew that .ron</code> system is temporary. Localisation isn't something you want to build yourself because you need to support large variety of languages, standards, and tooling, if you want to create a good thing. And for more than a year (29 November 2020), we had an issue that pointed to limitations of the system, like web UI and plural forms. Assuming you know English, we all know that in plural form, words get a -s ending, for example, coin => coins. And, of course, it's not that easy. Even in English, there are deviations from this rule, words that end with s/sh already, like ash => ashes. And there is more, think about counting: first, second, third, fourth, twenty-first. Four forms overall. Thankfully, there is a standard for that</a>, and of course, our .ron</code> format didn't cover that. This and web UI sounded so incredibly complex that I was afraid to even think about that, but when I tried to fix one of the issues with translations, @Sharp pointed to me that it makes more sense to create a more flexible localisation system than trying to extend our .ron</code> system. That's when the journey began. I looked at our issue https://gitlab.com/veloren/veloren/-/issues/858</a> and proposed solutions there, found Fluent's main page, found Weblate docs and started research. And to be honest, I was sold on Fluent right there because of an example of Polish as Polish being one of the Slavic languages has quite complex grammar and Fluent can handle it, yay. Fluent has basic things you expect from a localisation format: Plain messages.</li> Variables. We supported them in .ron</code> format, but it worked as a convention, variables weren't part of the syntax and weren't checked.</li> Attributes, as a way to group messages.</li> Selectors on numbers.</li> Selectors on arbitrary strings (gender, grammar case, letter case).</li> </ol> </figure> There are many formats other than Fluent - one of them is gettext</code> with .po</code> files. Legends say Ancient Maya used it to communicate with Spanish conquistadors. It's very primitive by itself but has a lot of extensions and tools to work with it. Despite that, in our opinion, Fluent has a brighter future so we decided to use it. At last, here are some examples. ## trivial message common-singleplayer = Singleplayer ## variables hud-sct-experience = { $amount } Exp ## attributes common-abilities-debug-possess = Possessing Arrow .desc = Shoots a poisonous arrow. Lets you control your target. common-abilities-sword-spin = Whirlwind .desc = Move forward while spinning with your sword. common-abilities-axe-leap = Axe Jump .desc = A jump with the slashing leap to position of cursor. ## number selectors hud-trade-buy = Buy Price: { $coin_num -> [one] one coin [other] { $coin_formatted } coins } hud-trade-sell = Sell Price: { $coin_num -> [one] one coin. [other] { $coin_formatted } coins } </code></pre> Also thanks to @Sharp for pushing for new translation system and @EvanMeek for pushing translation work. Of course, we still have a lot of things to do for internalisation of Veloren, so if you want to get involved, check this tracking issue</a>. And if you want to get involved in translating the game to your favourite language, check out this guide</a>. Translation is cool, but it's some nerdy thing for devs. Veloren now has another killer feature, /body</code> command, which is obviously admin-only, and it allows you to change your body to arbitrary species. It allows you to fly like an eagle, swim like a fish and beave like a beaver. Here are some pictures of me having fun: </figure> </figure> </figure> </figure> </figure> </figure> </figure> And to add on beavers and eagles, there is war. I wrote my first impression on 24 February here https://veloren.net/ukraine</a>. Read it if you haven't. In two days from the time I'm writing this post, it will be Ukraine Independence Day, and ironically, it will be six months since Russia's full-scale invasion, so I wanted to express my feelings again. The first thing I wanted to mention is that I call 24 February a full-scale invasion because the war started eight years ago, with the occupation of Crimea and the War in Donbas started by Russian agents like Girkin. The second thing that I think is important to understand is that every war has the front line and rear. And for eight years, the front line was mostly stable, and while more two million people left their homes, it was so easy to forget about the war. What I can say about today, Russian reminds about war every day. I can only imagine what happens on occupied territories, knowing what happened in Bucha. And I can only imagine what happens at towns near frontline. But what I don't need to imagine is air alarm each day and night, two three times per day or sometimes even frequent. And usually these air alarm end with strikes of Russian rockets somewhere in Ukraine. And if at first, core emotion was chaos, now the core emotion is non-stop stress. Stress and hope. Gliding towards the moon's reflection. See you next time! </figcaption> </figure> This Week In Veloren 185 Mon, 15 Aug 2022 00:00:00 +0000 - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Isse, @zesterer, @xMAC94x, @DaforLynx, @JulioCezarSilva, @Pfau, @Sam, @flo, @AldanTanneo, @imbris, @Slipped, @Vincent, and @juliancoffee. More mediocre animations Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> @Isse</h3> This week I got my MR merged that implemented spectator mode, but hidden in that MR was also a bug fix. Which is in my opinion more interesting than the feature itself. So for some time now we've had a bug were if you die while in lava, you would still be on fire when you respawn. So a fix for this bug had already been outlined by @imbris [GMT-4], and a very good description by @zesterer [GMT+0], in this</a> issue. The first part of the issue was caused by having client authoritative physics, and the client "teleporting" back into the lava after respawning. Zesterer wrote this great diagram describing the issue: Server thinks the player is... | Client thinks the player is... ---------------------------------|------------------------------- 1) Player walks into lava In lava, alive | In lava, alive 2) Player burns to death, entering the dead state In lava, dead | In lava, dead 3) Player requests a respawn. Request received by server and a teleport occurs, but client does not yet know At waypoint, alive | In lava, dead 4) Client and server now send contradictory position requests to one-another: the client still thinks the player is in the lava, but the server thinks they are respawned. Both server and client accept the reality of the other, so the server and client's view of the world 'swap'. In lava, alive (on fire) | At waypoint, alive 5) The short window above is enough time for the character to pick up the burning debuff because the server sees them as being in the lava. Now, the client's new "correct" position request gets sent back to the server, unifying both views of reality and finally placing the player back at the waypoint for both server and client At waypoint, alive (on fire) | At waypoint, alive (on fire) 6) The burning debuff sticks around because it is on a time delay. The player perceives this as a continuation of the debuff they had when they died, but in fact it is a new debuff that got picked up as a result of the respawn position hot-swapping discussed above. </code></pre> This issue was fixed by holding a counter of each force update that is done for that client, i.e each respawn, mounting position updates and teleports through commands. If we then we also keep this counter in sync on the client, and send that synced counter back with position updates from the client to the server, we can check if that position update is valid for the current counter on the server. If it's not equal to the one on the server, we can throw that update out. So, I had implemented all that... But it still wasn't working. So I tested a bit and found out that the bug still happened with client authoritative physics turned off! Which was surprising. After some debugging I found that after respawning, the server still thought that the player was in lava. Which definitely wasn't correct. I'll also make a little diagram of what was happening. 1) Player walks into lava 2) The phys system runs, setting in_liquid to Some(Lava). 3) Player dies from burning debuff, in_liquid remains unchanged 4) Player respawns, in_liquid still remains unchanged. // This next part depends on ecs system order being this way 5) The buff system runs, checking that in_liquid is Some(Lava) and if so applying the burning debuff. 6) The phys system runs, setting in_liquid to None. // In most cases. There could be a campfire underwater :P </code></pre> This was a much simpler fix than the former one. We just needed to reset the component holding in_liquid once the player respawned. This being a double issue might've contributed to why it took so long for it to be fixed, and also the former fix is not really a straight forward fix. But in most cases it was the second fix that actually caused the bug, because client authoritative couldn't have caused it if the player's spawn point is far enough away, or they're playing on server authoritative physics. A large tree in the distance! See you next time! </figcaption> </figure> This Week In Veloren 184 Mon, 08 Aug 2022 00:00:00 +0000 This week, we see many new animation videos. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @juliancoffee, @Vincent, @xMAC94x, @loki, @Sam, @XVar, @DaforLynx, @imbris, @Isse, @Tavo, and @flo! @Sam has been attempting to make things that resemble animations to expedite sword skill tree rework. Here are some of the results: Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> A chill campfire in the evening. See you next time! </figcaption> </figure> This Week In Veloren 183 Mon, 01 Aug 2022 00:00:00 +0000 This week, we hear about new worldgen settings, and how the translation system update is going. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Isse, @xMAC94x, and @LunarEclipse Worldgen settings by @juliancoffee</h2> I implemented a new setting for worldgen, LoadOrGenerate</code>. Previously you needed to use Save</code> options to generate a new map and save it on disk with some cryptic name (it's actually the date of map generation). Then, when you would want to use it next time, you would need to use Load</code> option to load your map and pass it that cryptic name, unless you renamed it yourself. Now with LoadOrGenerate</code> you don't need to care about it all, you can just say LoadOrGenerate("my-cool-map")</code> and things will work automatically. You can pass optional parameters, like map size and scale hack, the same way you would do that with Save or Generate option, read about it in The Book. If you specify new parameters and a name for the map with old parameters, worldgen will panic, if you will want to overwrite the map, you can use overwrite parameter. Ask us on Discord if you will have some troubles with it. Also, to give an update on my previous post about translation, I am actively researching Fluent project</a> and it will be just a warp-jump for our translation capabilities. Probably no web-service UI yet though. Here is RFC about the translation move</a>. Read this, if you're translating Veloren to your language because quite soon that will be the way to translate the game. How are we gonna get up this? See you next week! </figcaption> </figure> This Week In Veloren 182 Mon, 25 Jul 2022 00:00:00 +0000 This week, we hear about how the 0.13 release party went. We also get a video of a lightning storm. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @DaforLynx, @JonHeath, and @Pfau! </iframe> </div> </figure>0.13 Release Party by @YuriMomo</h3> This week, Veloren 0.13 was released</a>! We smashed our previous release party record with 277 players online at peak! </figure> Here's the old record, on the 0.12 release we peaked at 195 players! </figure> Check out the trailer to see some of the changes. The release party took the place at 18:00 GMT on July 24th, if you missed the release party you can watch it on our YouTube channel! </iframe> </div> </figure> Here is the list of the features which were added to Veloren! Better Weather system by @DaforLynx (sound) @zesterer @Isse (programming)</li> LoD Objects by @zesterer</li> Balance changes to items and monsters</li> Performance improvements</li> Water caves by @Isse</li> CliffTowns by @floppy</li> Modular weapon @Sam sword overhaul by @Slipped [GMT -5]</li> Added loot ownership for drops from mining</li> Updated the Polish translation @LunarEclipse (LunarEclipse)</li> More varied ambient birdcalls @DaforLynx</li> Overhauled caves: they're now a multi-layer network spanning the entire world @zesterer [GMT+0]</li> Modular weapons now have a selling price @Christof</li> Metadata added to music files. Listen to the soundtrack more easily @DaforLynx</li> Optimized sprite processing decreasing the startup time of voxygen (and long freezes when trying to enter the world when this hasn't finished). @Imbris</li> </ul> Taking a rest while exploring the caverns. See you next week! </figcaption> </figure> Veloren 0.13 Release Sat, 23 Jul 2022 00:00:00 +0000 0.13 Release</h2> Veloren is releasing 0.13! This version is 5 months in the making, and we have a lot to show off! If you're reading this before 18:00 GMT on July 23rd</a>, make sure to join the release party. There will be a custom pirate-themed map with plenty of secrets to find ( thanks to @Hannibal ), minigames, and other events so don't miss it and make sure to bring your friends along! 🏴‍☠️ Explore the handcrafted jungle isles to seek the treasures of the Sunken Duchess! To join, you can download the game for free at veloren.net</a> and create an account</a>, then launch the game and hop on the default server. See you there! We've also put together trailer for 0.13 release party, made by @Hannibal, and with music by Benjam Soule H. Walker, aka @Oolnokk. </iframe> </div> </figure>New in this release</h3> ⚔️ Modular weapons</h4> You can now craft weapons in new ways! </figure> ⛈️ Real-time weather: rain, wind, thunder, lightning</h4> </figure> 🏔️ Cliff towns</h4> </figure> 🔦 Interconnected cave networks with cave biomes</h4> So much more cave to explore! Your browser does not support the video tag. </video> </figure> 🌲 LoD trees</h4> You can see trees past the boundaries of loaded chunks now. This is going to add a lot to far-off mountains! </figure> 💇‍♂️ More character customisation options</h4> </figure> 🤸 NPC personalities</h4> </figure> 🙌 And much more!</h4> Changelog</h3> You can check out the full changelog here</a>. Thanks to this versions contributors (in random order): John Heath, Karl Werf, Samuel Keiffer, Olexorus, Vlad, markobekko, Snowram, Mehmet-dev, InfRandomness, Dr. Dystopia, Brandon Dyer, Benoît du Garreau, tygyh, Imbris, Clary Chevry, Jack hollis-london, Bryant Deters, runrobdog, Enrique AM, Corvella, Hugo Peixoto, Cheuk Yin Ng, Tormod G. Hellen, Monty Marz, Leonid Toshchev, Andrzej Drabarek, jh0l, DaforLynx, Stanisław Grupiński, floppy, Влад Куцепалов, Makselord, Samuel Lopes Mastrofrancisco, JakobDev, Vincent Foulon, Joshua Barretto, brunt, Chase Rozon, UncomfySilence, StereoJunkie, Isidor Nielsen, juliancoffee, terrarier2111, Euryn, Justin Shipsey, Plright, ninefox, IsseW, Forest Anderson, Dominik Broński, Maxwell, Manuel Schmidbauer, Treeco, Christof Petig, Ben Wallis, Socksonme, James Melkonian, Awkor, Anton Katsuba, Avi Weinstock, aflying pumpkin, holychowders, Mckol, ubruntu, Jonathan Berglin, Samantha W, Joshua Yanovski, Marcel, Julio Cezar Silva, Youssef Fahmy, Mel, flo, jshipsey, Benjam Soule H. Walker, and Inojelis Support the project</h3> As always, feel free to support the project on Open Collective. It allows us to keep our servers running, and launch great release parties like the one today! This Week In Veloren 181 Mon, 18 Jul 2022 00:00:00 +0000 This week, we hear about the new server-side physics system's development. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Christof, @juliancoffee, @tygyh, @xMAC94x, @Isse, @aweinstock, @Treeco, @AngelOnFira, @Sharp, @Treeco, @DaforLynx, @LunarEclipse, @Socksonme, @VincentFoulon80, and @UncomfySilence! @LunarEclipse has updated the Polish translations. The roadway to better server-side physics by @xMAC94x</h3> There are currently 2 physics modes: client-side physics which is prone to hacks and has low latency, and server-side physics which is not hackable (or so we think) but has high latency. Here's how we want to get the best out of both. First, let's have a look how current server-side physics works. Assume we have a Server</code>, ClientA</code>. and ClientB</code>. The latency (ping) of ClientA</code> is 300ms and the latency of ClientB</code> 200ms. This means that sending a message to the server for ClientA</code> takes ~150ms, and getting a message back takes ~150ms. So when ClientA</code> jumps it takes 150ms for the server to find out, and then 100ms for ClientB</code> to get that update. ClientB</code> sees this after 150 + 100 = 250ms. Even worse: The same goes for ClientA</code>, it sends the message to the server, waits for the servers answer and therefore starts the jump animation after its ping time, or 300ms+. 300ms till the press of a button and seeing something happen is unplayable. </figure> Our new server-side physics will work with 2 clever tricks: A client no longer waits for a message to go to the server and back, but will start the animation immediately</li> Voxygen does not show you what the server sends you, but always "project" a latency + a bit in the future.</li> </ol> Lets deep dive into the latter one. The server counts the time since its start, the so called tick time. starting with 0s, and increasing every tick by ~33.3ms. Lets look at what happens a bit after the game starts, at time t=10s. The server makes it calculations and sends an event to the client: Arrow is flying to your feet and will reach you in 1s! ClientA</code> does not yet know about this arrow, as the message hasn't been sent over the internet. It takes 300ms, so at t=10.3s, the client receives the message of the arrow. Now comes the fancy part. ClientA</code> knows the message was sent at the server at t=10s, so the client will revert it's time back to t=10s and now simulates 300ms. If we would keep it like that the client would see the arrow 700ms away. </figure> This is good, Voxygen already substracted the 300ms for the latency from server->client. But we don't stop here. We are simulating another 300ms + a bit (lets say 50ms) = 350ms. This way, we are taking into account the time it will take from the client to the server. The 50ms are a small buffer that will be explained later. The actually image ClientA</code> will see shows the arrow only 350ms away from their feet, as we show 10.75s even though the time is t=10.3s The client now sees exactly what the server will see once their message arrives, so they quickly press the jump button. ClientA</code> sends a message to the server: Hey, I want to jump at exactly t=100.65s. When the server receives that message another 300ms are gone, it's not t=100.6s. The server processes the jump-request and sees: it's still valid, it was send 50ms ahead of time and starts the jump of ClientA</code>. All this what we spoke about will repeat endlessly. with each message from the server additional info is send, e.g.: your message was 50ms early. This will then be used at the client to tighten the timings and calculate the ping. For this algorithm to work flawlessly we need to improve the accuracy of our tick calculations and physics calculations. We need to predict a lot of variables and constantly need to adjust the 50 ms buffer we talked earlier about so that the image doesn't appear laggy. All this is another story for anther blog but needs to be done first. Expect it NOT before the next release party. With the right knowlege, you too can levitate! See you next week! </figcaption> </figure> This Week In Veloren 180 Mon, 11 Jul 2022 00:00:00 +0000 This week, we hear about changes that are being made to the Scrolling Combat Text system. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @xMAC94x, @DaforLynx, @Isse, @XVar, @Awkor, @Christof, @Julio, @Slipped, and @Socksonme! Weather by @Isse has been merged!</a> Scrolling combat text by @Socksonme</h3> For the past couple of months, I've been working on a rewrite of the SCT system that we have. (These are the damage numbers that show up on the screen - both for the player and the enemies). The old method that was used for creating the "floaters" had many issues. First, it checked if the health had changed in the last frame, and second, it only used the last change applied to the health. The way that the check was made was by storing the HP on the current tick, and then on the next tick - comparing them to see if they're different. The issue that this caused was that an equal amount of healing and damage done in the same tick would lead to no damage numbers being shown. The second issue, which is displaying only the last change, led to some attacks/weapons showing incorrect damage. For example - the bow's "Shotgun" attack, the slashing damage from the sword, whenever the enemy doesn't have enough energy left, or the poise damage, whenever the enemy is stunned. All of these attacks apply multiple changes to the health, in the same tick, which would obviously cause an issue. </figure> The new system put in place now uses "outcomes", which are the result of an event. Whenever an attack is applied, a HealthChange</code> server event is emitted. This is then handled and then a HealthChange</code> outcome is emitted. Then, for every HealthChange</code> outcome, we go through some new conditions in order to see how some health changes should be displayed. Before the HealthChange</code> server event is emitted, a random number is generated and then stored, since we will want to group up damage from the same attack (I will explain why later). Another value that is now stored is the crit. Boolean, which, as the name suggests, stores whether a health change was a crit or not. Crits dealt to an enemy are separated from regular attacks, and they themselves aren't accumulated with other crits. They are also displayed in a random position left or right from where the regular attacks show up. They are a bit larger than the damage numbers for regular attacks and have a yellow color. In comparison to the floaters for the enemies, crits and regular attacks are shown in the same position for the player, and are accumulated normally, however, they still possess a yellow color. I decided to also let the player decide the duration for which floaters should be accumulated. This is done by having two separate sliders going from 0.0 seconds to 2.0 seconds (one for damage dealt by the player and one for damage dealt to the player). </figure> However, this poses another small issue, which is that, if you have damage from the same attack happening in the same tick, while you have the damage accumulation duration set to 0 seconds, this would lead to the text being unreadable. As a method to solve this, as I mentioned before, we check if this random number (which is the same for damage from the same attack) is the same, and also if it's from the same tick, and if so - accumulate the damage. Some minor changes also include: having a toggleable option for rounding damage which is greater than or equal to 1.0, having an option for experience number accumulation (I decided that having a slider for the duration would be excessive) and some sources of damage/healing - for example, fall damage, campfires, food, the regeneration buff, and others, now show up in the SCT. Also, since we now have a slider for the accumulation duration, I felt that I should remove both the single and cumulated damage options. (might post some images later) Ready to fight! See you next week! </figcaption> </figure> This Week In Veloren 179 Mon, 04 Jul 2022 00:00:00 +0000 This week, we hear about some work being done on the translation system. We also have a small video of some cave spelunking! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Isse, @Socksonme, @imbris, @DaforLynx, @zesterer, @xMAC94x, @Sharp, @BenjamWalker, @Sam, @James, @Treeco, and @AngelOnFira! @YuriMome and @xMAC94x got the ultimate plan set up for our GitLab organization, which will give us more information about our development cycle. Your browser does not support the video tag. </video> Cave spelunking by @Dumpling </figcaption> </figure> Translations by @juliancoffee</h3> I started doing translation work and started with introducing translation of abilities (you can already see it in the ability selection menu of the diary). Take a look at en/hud/ability.ron</code> file for an example of how it is being done: /// Localization for "global" English ( string_map: { // Debug stick "common.abilities.debug.possess.name": "Possessing Arrow", "common.abilities.debug.possess.desc": "Shoots a poisonous arrow. Lets you control your target.", // Sword "common.abilities.sword.spin.name": "Whirlwind", "common.abilities.sword.spin.desc": "Move forward while spinning with your sword.", ... }, ) </code></pre> Not only you can translate existing abilities, you can also translate "modded ones" by just adding .name</code> and .desc</code> to ability id. And on the topic of translation, I can also give a sneak peek of a few things. First, we want to add translation of names for entities soon (like, you know, rabbit or Cultist). And second, more importantly, is that we want to move from our self-made internationalization (i18n) system to something already used in open source world, for example PO files. I can't give any time estimate on when they'll be ready, but if you're interested in it, please jump to our Discord to discuss! A dreary night, best to stay inside! See you next week! </figcaption> </figure> This Week In Veloren 178 Mon, 27 Jun 2022 00:00:00 +0000 This week, we have a great writeup from @Sharp about optimizations being made to the site2 system. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @juliancoffee, @xMAC94x, @runrobdog, @BrandonDyer, @imbris, and @Sam! Site2 optimizations by @Sharp</h3> I've been working on speeding up site2 rendering time by roughly an order of magnitude across the board. Site2 greatly simplifies things for developers by giving them normal geometric primitives to work with (rather than forcing them to write everything in a sampling-based way), and allowing direct draws of primitives to occur in a specific order with different fills. (Un)fortunately, site2's power and ease of use has led to a lot of rather expensive patterns and primitives being used to emulate things like archways, hollowed-out rooms, or sprites on the ground. This, combined with the actual rendering still being done in a mostly sampling-based way (albeit with a bit of cleverness around bounding boxes), has resulted in large regressions in overall render time for chunks, putting us far out of reach of our end goal if we want to support higher view distances or larger numbers of players. </figure> Chunk generation times are highly variable and depend on many factors (player count, player distribution, and view distance) that we don't have much control over, and as maps get bigger and servers get fuller, these factors are likely to grow. While it's true that chunks can mostly render in parallel, many players play single player or use servers with only a handful of cores; on such systems, driving generation into the background isn't as helpful as it seems. Even on beefy servers, any CPU cycles spent on chunk generation are not being spent on more useful work (plus, it's lame to restrict players to such a small view distance!). Even if most cores are ideal, many systems (and players themselves!) can't run or perceive anything until a chunk is loaded, so slow chunk generation time has a disproportionate impact on perceived latency. This is especially true in the context of very fast transport systems, such as high speed trains, which require loading new chunks very rapidly in order to keep up with the player. We've recognized that this is a problem for a while, so @aweinstock had been working on a pretty interesting idea--JIT compiling expensive nodes in the site2 render tree, then evaluating it! While he got impressive results from doing this, even taking the JIT compilation overhead into account, the total time still seemed much too high to me. Since even if you have a JIT compiler, having a faster interpreter is still always beneficial (since you can compile in the background, or use the interpreter for all but the most expensive nodes), I decided to see what improvements we could get by improving the interpreter instead. </figure> Fortunately, because site2 is so high-level, there is a lot of room to optimize the interpreter! I quickly realized that there was a lot of low-hanging fruit in that department, and the improvements quickly grew to the point where the interpreter was finishing well before JIT compilation had a chance to finish. Some techniques applied so far include: Added UnionAll and IntersectAll primitives, which reduce the amount of time spent recursing through the tree and result in easier and more frequent chances for optimization.</li> Added a proper cost model to decide join ordering on unions, intersections, and differences.</li> Reducing the number and capabilities of primitives, allowing us to focus more on optimizing the remaining ones (for example, we have removed arbitrary fills, and now insist that all lazy primitives be convex).</li> Changing from a sampling-based approach that walks the tree per-voxel, to one that walks the tree to find bounding volumes; we now maintain a context with a mask, transformation matrix, and stack of partially applied intersections, which allows us to delay evaluation efficiently.</li> Pushing down unions and intersections as far as possible, only dropping to point-based approaches when we hit a primitive (so we iterate over small, mostly-disjoint AABBs).</li> Some tentative initial applications of explicit SIMD (to parts of the segment prism algorithm). Over time, we will probably convert the entire render loop to SIMD, treating the mechanics of rendering more like we would a GPU.</li> A lot of heroic optimizations for difficult primitives and special cases (for example, superquadrics are about 4x as fast as they were with a more naive approach, due to exploiting symmetry, inline caching, and the fact that they have explicit solutions in restricted cases).</li> Avoiding per-voxel dynamic dispatch on fills (which turns out to have a huge impact in some cases, e.g. cliff towns).</li> Restricting differences statically to ensure that the domain is strict (inspired by polarized type theory).</li> </ul> </figure> These, plus a number of other miscellaneous optimizations, have resulted in very significant wins! Caveat: some features still need to be enabled, and segments are broken in ways that may affect benchmarks, so some of these may regress a bit--but they are very impressive... Gnarling fortresses are about 15x faster than they were on master, and render in about 2.1 ms / chunk. While they are segment-heavy and therefore might regress, they also have the most complex geometry by far of any site2 to date, and don't use any custom fills, so they have much more room for improvement by optimizing geometry than any of the other sites do. Therefore, I'm fairly confident that we will end up at least 15x faster after my changes are complete.</li> Dungeons are about 7x faster than they were on master, and render in about 3.3 ms / chunk (they lag other results because they are almost entirely bottlenecked on their complex custom fill, which I have not spent much time optimizing because dungeons are due for a rewrite anyway). This improvement also seems to have some impact on server startup time!</li> Cliff towns are 7x faster than they were after some other fairly significant performance improvements, so they are likely at least 10x faster than master (I'd guess a lot more, since they heavily use large intersected superquadrics).</li> Cities use a lot of primitives that haven't been optimized, so it's hard to say how they would compare to master (we didn't have an old benchmark for them), but they render in under 2ms / chunk.</li> Giant trees were not benchmarked on master, but they now actually render at less than 125 μs per chunk (which was my original super stretch goal time for chunk rendering--I believe this is the first time we have hit that with a realistic structure!). Avoiding dynamic dispatch on fills, alone, made giant trees over 4x faster than they were after other fairly significant performance improvements compared to master, so it is likely that they also saw an order of magnitude speedup overall. However, they are very segment-heavy, so it's difficult to say where they'll end up after segments are fixed.</li> </ul> Finally, to validate that the existing optimizations are indeed useful, I ported citadel code from @zesterer's branch (which I'd never looked at before), fixed it to be compatible with my current code (which required only a handful of changes, since it was already correctly polarized), and then benchmarked it. As it turns out, it was very superquadric, union, and intersection-with-AABB heavy, so it benefited from many of the optimizations mentioned above! Citadels now render in only about 650 μs/chunk--making them more efficient than any site except giant trees. I am extremely confident that this represents more than a 10x improvement over the old branch (I included some pictures of it to break up the text!). </figure> Going forward, there are still several more optimizations to implement before I submit my changes (this is by no means the end of possible optimizations--I have many more ideas!--but it's a good stopping point assuming that we can maintain our order of magnitude improvement after segments are fixed and differences are added back): Draw immediately when fill is called, rather than allocating into a primitive array first and then dispatching later.</li> Add efficient internal algorithms for rendering the remaining primitives, in both the intersection and masked cases (and consolidate any we no longer need).</li> Make sharing of primitives explicit and visible to the user, so we avoid recomputing the same primitive too many times (at least in some cases) and instead cache enough information to efficiently re-render the volume. This should be especially useful for hard "problem" cases, such as the various hacks we use to ensure sprites in caves lie on the floor.</li> Reimplement differences, using the fact that we have an explicit primitive to efficiently mask it out by inverting it.</li> Also use the above technique when distributing intersections over unions (or at least cache some information, such as data allocated in the arena, to avoid exponential explosions in memory use).</li> </ul> As well as extra cleanup work: Finish up filling in cost model details that have been omitted so far (since it turned out that improving render performance was far more important than getting the cost model correct given where we currently are).</li> Finish up work needed to make sure all values are validated on construction and that we don't have more than a handful of ways of directly constructing the primitive.</li> Finish up making sure that correctly polarized combinations of unions and intersections all actually work (this part is quite unfinished, since validating the performance improvements only required dealing with the patterns that we actually use so far).</li> Do a better job of avoiding recursion in common cases (this one may be hard).</li> Figure out a proper structure for the various kinds of heroic optimizations we have, categorize them, and put them in their own files, so we can focus on them individually rather than having gigantic, messy functions. Keep the core loop of the interpreter small.</li> </ul> Overall, I am really excited about these (and future!) improvements, especially in tandem with improvements elsewhere (such as the preliminary design of a site2 visual editor, hierarchical plots, and discussions about how better to handle common cases like putting sprites on the floor and walls). Hopefully, these improvements are able to make it into the game in some capacity within the next month or two! </figure> Update #1</h4> I seem to have gotten another order of magnitude performance win with the first future work suggestion in the post ("draw immediately"). New numbers (faster across the board, generally much faster, with roughly equivalent geometry). The "render" is the relevant one here, the generate_</code> are testing something that only happens at server startup (AFAIK). Every site type tested now renders in under 1ms / chunk, and many of them run at around double that speed (500 microseconds / chunk). Giant trees, the surprise champions from earlier, render in a ridiculous 40 microseconds / chunk! These numbers will regress with proper segments, but not by nearly enough to lose our order of magnitude improvements. Below are some of the results of the benchmarks, but you can see the rest of them here</a> generate_city time: [19.520 ms 19.538 ms 19.559 ms] change: [-0.3957% -0.1977% +0.0013%] (p = 0.05 > 0.05) No change in performance detected. Found 9 outliers among 100 measurements (9.00%) 1 (1.00%) low severe 2 (2.00%) low mild 2 (2.00%) high mild 4 (4.00%) high severe render_city/identity_allocator time: [3.4023 ms 3.4114 ms 3.4207 ms] thrpt: [1.7540 Kelem/s 1.7588 Kelem/s 1.7635 Kelem/s] change: time: [-2.3020% -1.9525% -1.6172%] (p = 0.00 < 0.05) thrpt: [+1.6438% +1.9913% +2.3562%] Performance has improved. generate_cliff_town time: [6.9444 ms 6.9518 ms 6.9609 ms] change: [-0.2329% -0.0320% +0.1523%] (p = 0.75 > 0.05) No change in performance detected. Found 13 outliers among 100 measurements (13.00%) 6 (6.00%) high mild 7 (7.00%) high severe render_cliff_town/identity_allocator time: [2.0587 ms 2.0692 ms 2.0800 ms] thrpt: [1.9230 Kelem/s 1.9331 Kelem/s 1.9430 Kelem/s] change: time: [-4.5641% -3.8519% -3.1480%] (p = 0.00 < 0.05) thrpt: [+3.2503% +4.0062% +4.7823%] Performance has improved. generate_dungeon time: [4.2436 ms 4.2503 ms 4.2572 ms] change: [+0.3002% +0.5213% +0.7344%] (p = 0.00 < 0.05) Change within noise threshold. Found 2 outliers among 100 measurements (2.00%) 1 (1.00%) high mild 1 (1.00%) high severe </code></pre> Update #2</h4> I just got a 5x improvement to forested chunks by (basically) rendering them with site2 after my changes, even with the old segments algorithm! Since tree chunks are very common they tend to in practice be a huge bottleneck, so this is a very welcome development. I still need to add back a bit of the old functionality and figure out the differences between old and new tree rendering to make this fully apples to apples, but I think that improvement will remain 🙂 That's all of the updates on site2 performance, but @Sharp will be back in later posts with more updates. Stay tuned! </blockquote> A bright night. See you next week! </figcaption> </figure> This Week In Veloren 177 Mon, 20 Jun 2022 00:00:00 +0000 This week, we hear about how what @YuriMomo has been doing in the world of testing. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Imbris, @xMAC94x, @Sam, @XVar, @Ixxe, @Maveth, @BrandonDyer, and @YuriMomo! This week in testing by @YuriMomo</h3> In his regular rounds as lead of Veloren's testing working group, @YuriMomo got the game server banned from using the Veloren's login API. </figure> </figure> In an interview with @YuriMomo, he promised to not take down auth for at least one week. (@AngelOnFira) Hello, do you promise to not take down server auth for at least a week? </blockquote> (@YuriMomo) Yes, I promise 😄 </blockquote> </figure> This Week In Veloren 176 Mon, 13 Jun 2022 00:00:00 +0000 This week, we hear about more progress that has gone into the new weather system. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Christof, @xMAC94x, @Isse, @zesterer, and @Sam! Weather by @Isse</h3> Weather is getting closer! 🌧️ 🌦️ There will be different weather in different parts of the world at the same time. And it will be consistent among all clients playing on a server. Right now, the only variables for weather are clouds, rain, and wind. So the existing clouds will now be controlled by the server. And you will also see rain, which is affected by wind. And also some other cool effects that come with this. More technical: The weather is built up of a grid of weather cells. Where each cell has each of the variables cloud, rain, and wind. Each one of these weather cells covers 16x16 chunks. Meaning that on a default world there are 64x64 weather cells. Your browser does not support the video tag. </video> </figure> On the server, we have two new ECS systems for weather. One for simulating and one for syncing, which are both run at regular time intervals of 5 seconds. The simulation in this first implementation is simplified to using noise to fill the weather cells with sensible values.</li> The syncing sends the weather grid to every connected client.</li> </ul> On the client-side, we store three weather grids, with the latter two being the last weather grids the server sent us. The third is created by linearly interpolating between the two grids sent from the server. This smooths out the weather between updates from the server. So now we have a grid of the current weather on the server, but we still have the problem of getting the weather at a specific location. This is done by bilinearly interpolating between the closest four weather cells for that position. This weather value can give us the values we need for playing sound, choosing music, etc. The weather grid is also used to update a texture on the GPU. This texture is then used for when the clouds are raytraced, and displaying the new rain. One important thing when having a weather grid on both the GPU and CPU is making sure that weather at certain positions lines up correctly. Which, in this case, was solved by letting the world position (0, 0) be the center of the (0, 0) cell. Rain is drawn in the second pass in the same shader as clouds, meaning that we have access to a depth buffer to make sure we don't draw rain in front of something when it should be behind. But there is another case where we shouldn't draw rain, that's when it should be blocked by something. We solve this by shadow mapping, yes the same shadow mapping we use for the sun. Shadows are similar to rain occlusion </figcaption> </figure> Much like sun light, rain can be simplified to a number of beams on a plane. So we render depth of terrain and entities to a texture with an orthographic projection rotated by the rain's falling direction (Not actually using an orthographic projection, but the same principle applies). Although in contrast to shadows from the sun that take all loaded chunks into consideration, rain occlusion only takes 9 chunks, and the entities in those chunks into consideration. This Week In Veloren 175 Mon, 06 Jun 2022 00:00:00 +0000 This week, we hear about an issue with memory leaking somewhere in the memory pipeline. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Christof, @imbris, @XVar, @Slipped, and @terrarier2111! </figure> Veloren memory leak by @YuriMomo</h3> This week, @YuriMomo found a memory leak in the Veloren. </figure> As we can see, Veloren is taking up significantly more RAM than it should. @YuriMomo dove deeper into the problem to diagnose it. They found that something was constantly allocating 32 bytes each frame, which added up over time. </figure> Although this memory would be freed just fine after the game closes, it's clearly living for longer than it should. Ideally, it should be cleaned up after each frame. A little more analysis lead to discovering this code: ##[no_mangle] pub unsafe extern "C" fn wgpu_render_pass_push_debug_group( pass: &mut RenderPass, label: RawString, color: u32, ) { let bytes = ffi::CStr::from_ptr(label).to_bytes(); pass.base.string_data.extend_from_slice(bytes); pass.base.commands.push(RenderCommand::PushDebugGroup { color, len: bytes.len(), }); } </code></pre> Which was passing information from Veloren to wgpu, the rendering API that Veloren uses. Some more diagnostics were run, and @imbris mentioned that the problem seemed to be deeper than what we have access to through just the wgpu API. </figure> This issue still has not been fully resolved, but more people on the team are looking into parts of it. More to come in the future! Flying through the valley. See you next week! </figcaption> </figure> This Week In Veloren 174 Mon, 30 May 2022 00:00:00 +0000 This week, we hear about additions to the taming system. We also get to see some of the progress of SFX with weather, and we see a prototype for a proposed UI overhaul to Airshipper - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Makselord, @xMAC94x, @XVar, @BenoîtduGarreau, @Christof, @Sam, @imbris, @zesterer, @Isse, @inojelis, and @StereoJunkie! </figure> Taken by @KaliKatz, the Elbst is a fun mount, has a nice green glow with lantern, and is a fav amongst pirates YARRRR </blockquote> Taming special animals by @Inojelis</h3> I've been working on special animals that can be tamed and mounted. The MR was merged! Taming</h4> Now Hirdrasil, Catoblepas, and Mammoths (they're going to become peaceful soon) are not tameable, as they're too overpowered for being used as pets. Medium birds were also added as pets, but they're not mountable at all. Mounting</h4> A mass limit was added for mouflon, holladon, and boar. Currently, the limit is above the heaviest humanoids, as it is expected to be balanced in the future. Most medium quadrupeds are still mountable. Small quadrupeds are now not mountable except truffler (for all riders), holladons, and boar (with a mass limit that I previously mentioned). Low quadrupeds are now not all rideable except salamanders and tortoises. Weather SFX by @DaforLynx</h3> Over the past couple of months, a few of us have been working on weather sim. That includes adding rain ambience SFX. The previous ambience system was exclusive to wind and worked well enough. But I decided it needed a slight rewrite to support multiple layers of sound at once. The new system now supports rustling leaves, rain, rumbling thunder, and wind (which now takes into account weather sim wind) all at the same time with volume depending on certain factors. In the future, I envision the system also supporting things like crowds and cave ambience, and possibly pseudo-directional sounds like rivers. The music system can also detect weather, and some new tracks by @Oolnokk have been added which are exclusive to rainy weather (one of which can be heard in the clip). In addition to the ambience changes, I added functionality for true UI SFX. Before, these sounds played from the camera's position instead of "omnisciently", which is most noticeable with the level-up sound. Now, the sound properly plays in stereo. The same goes for inventory-related sounds, as well as a new "crafting" SFX that happens when you craft an item - the first step to button clicks and other UI SFX. Your browser does not support the video tag. </video> </figure> Airshipper UI prototype by @mark</h3> I've been working on a UI Concept prototype for an overhaul of Airshipper. I focused on maintaining the main features of the launcher we have right now, but during the wireframing process I realized there was space for much more. Adding the links present in the website (game's manual (book), contact info, account details, and donations) to Airshipper makes for a handy user experience. This turns it into a hub for everything someone might need, without having to go back to the main page after downloading the game. And because Veloren's community is so heartwarming and interactive, I have also added a "Community Showcase" section, so everyone can look at beautiful gallery submissions while preparing to launch the game, as well as a new way to differentiate patch notes from website content. The colors were supposed to reflect the current daytime, but that's still a WIP. I am heavily inexperienced when it comes to coding in general, so this is just a prototype for now, if you want to contribute anyhow, feel free to ping me on Discord at @marcelompf c: There is a working Figma prototype</a> if you want to try clicking the buttons. </figure> </figure> </figure> An airship battle! See you next week! </figcaption> </figure> This Week In Veloren 173 Mon, 23 May 2022 00:00:00 +0000 This week, modular weapons were merged, and we learn about some changes that will come from them. We also hear about how NPCs can now pick up items. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @zesterer, @Corvella, @imbris, @xMAC94x, @Inojelis, @XVar, @chaserozon, @Euryn, @HugoPeixoto, @Slipped, @samuellm, @s.grupinski, and @UncomfySilince! Modular weapons by @Sam</h3> The modular weapons branch started a little over 10 months ago. What started as a plan to simply implement the initial prototype created by @aweinstock quickly expanded to require a rewrite the majority of the item code, and almost the entirety of the crafting code. Further, I had substantially underestimated the amount of models that would need to be created (a total of 330 weapon models, and a few dozen more for the new items were needed, a big thanks to @Gemu for creating all of them). All in all, something that I had initially expected to take 3-4 months quickly came to require much larger changes than I had been expecting. </figure> Changes</h4> 3 new stats have been added to weapons: energy efficiency, buff strength, and range. Energy efficiency reduces the energy cost and energy drain on abilities. Buff strength increases the strength of debuffs applied through attacks, and of buffs applied through auras. Range increases the range of melee attacks, the speed of projectiles, shockwaves, and beam segments; and the radius of explosions. Most weapons have been migrated to new modular weapons. Modular weapons have two parts: a primary and a secondary component (for swords, the blade, and hilt respectively). The stats of the weapon depend on what components are used, for example using a sabre blade when making a sword will increase the power of that sword. The primary component is also made of some material, a kind of metal for swords, axes, and hammers; and a kind of wood for bows, staves, and sceptres. You can now craft most weapons that are in the game. This is done by combining two components of the same toolkind at a crafting bench. Secondary components can be directly crafted while primary components are created by combining a material with a modifier (animal-related crafting ingredients, e.g. predator claw, strong pincer, and a few others). Different components will affect stats differently in the weapon. </figure> NPC pickups by @Inojelis</h3> My first big MR (for me at least, I'm not experienced in Open Source lol) was finally merged 🥳 NPCs will now pick up items lying on the floor if there isn't a threat. Thanks to this, players can now heal their pets with potions or food. Also, this removes the problem of using villages or travellers to get loot from hostile entities. Enjoying a campfire at night. See you next week! </figcaption> </figure> This Week In Veloren 172 Mon, 16 May 2022 00:00:00 +0000 This week, we hear about performance improvements being made to the game server. We also learn about balance changes to items and monsters. Finally, there is some work being done on water caves. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @GLawrence, @Sam, @zesterer, @BryantDeters, @xMAC94x, @holychowders, @Snowram, @Pfau, @HugoPeixoto, @Isse, @UncomfySilence, @markobekko, and @CheukYinNg. Performance improvements by @xMAC94x</h3> by moving chunk serialisation out of the hot loop </blockquote> With the recent growth of our community, and hence our main game server, we were in need of some performance improvements. One of those planned improvements was moving the serialisation and compression of chunks out of the ECS. Serialisation is the task of moving the chunk data into a format that can be sent over the network from the server to the client. For measuring the results we calculate a metric that basically says "how many cores would need to run at 100% when the game server would be under full load". Let's assume we would have a 32 core server, that manages 37 ticks per second (TPS) with an 28% CPU usage. 37 TPS means the game server is at 30TPS/37TPS = 80%</code> of its maximum capacity. We can then look at the full system usage 28% / 80% = 0.355</code>. That multiplied by our number of cores gives us 0.355 * 32 = 11.36</code>. Graph of this tracked metric on our game server dashboard </figcaption> </figure> This means that under a full load of our server we would parallelize everything to 35.5% and would reach a theoretical usage of 11 cores of our 32. For us as a server owner, it's important to optimize the software to parallelize more, as we still have to pay for 32 cores, even though we only "use" 11 of them. The numbers above were the status quo before moving chunk out of the hot game loop. After the optimisation we reach a metric of 41.3%, or 13 cores. 2 cores don't sound much, but it's a 15% improvement which will help us to keep the tick times low and stabilize the server even with many people on it. The cost for this optimisation is that chunk requests are now delayed up to half a second due to clustering multiple requests and only serialising them once. This optimisation is only part of a series of optimisations that were done and will be written in smaller blog posts over the next weeks. Balancing by @Chaseowski</h3> I've made a bunch of balancing adjustments and tweaks, as well as redid or edited a lot of descriptions for most items, I am now much happier with them and item drop-rates etc now, but there's always room for improvements! This involves more headgear, necklace stat balances, and drop-rate changes to items within enemy loot-pools, I also went ahead and moved some items around (such as straw hat and wanderers). Adjusted loot tables and drop rates involve creatures like rats, wolves, pirates, yaks, cattle, highland, salamander, and elbst. You'll see a drastic change in Crown and Pirate Hat drop rates as well for those grinding those too 👀 You'll also notice changes to items tiers/color that should match how hard they are to get, or how good they are! There's also a ton of other stuff, and there are over 123 changes to everything I did in total. I think I've covered the gist of them all here, but I am very excited to see how they work out! Enjoy! </figure> Water caves by @Isse</h3> I've been working on water caves. So now instead of a cave entrance in oceans being blocked off, you'll be able to enter. (Entrances in lakes will still be blocked off because of issues relating to water going through a cave to a lower altitude) Right now they aren't filled with anything that makes them any more interesting than normal caves, but that will hopefully change soon. </figure> The darkest of caves. See you next week! </figcaption> </figure> This Week In Veloren 171 Mon, 09 May 2022 00:00:00 +0000 This week, we hear about the new LoD Object system. There are also more cool images this week! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @xMAC94x, @holychowders, @Isse, @Treeco, @Anton, @markobekko, @AngelOnFira, @imbris, and @Sam! LoD Objects by @zesterer</h3> I've been working on an LoD object system. The obvious first candidate for this system are trees. </figure> The LoD system pre-generates the position and kind of trees (and other objects) on the server, but not the models themselves (doing so would be very costly). This allows Voxygen to add a cheap placeholder model. At a distance, these look sufficiently like the real thing to be passable. The net effect is that the scale of distant terrain is more obvious. I've also been very surprised by just how many trees Veloren's world has! </figure> </figure> Headwear pieces by @AlbinoAxolotl</h3> </figure> </figure> </figure> </figure> A sneak peak of modular weapons. See you next week! </figcaption> </figure> War in Ukraine Wed, 04 May 2022 00:00:00 +0000 The following was written by @JulianCoffee, an active contributor to Veloren. On 24th February, in Kyiv I woke up earlier than usual because my parents were chaotically searching something in closets. My uncle in town near Kyiv, who left Russia years ago, woke up earlier than usual because of sounds of explosions and was trying to leave his home. My grandfather in town near Kherson woke up earlier than usual because of sound of Russian tanks moving. Millions of people in Ukraine woke up earlier than usual that day, because Russia went for full-scale war against Ukraine. Do you know what war looks like? Imagine that 9/11 happens multiple times per day in hundred of towns. Imagine that people leaving its home to save their families. Imagine that in blocked cities people don't have water, roof, medicine and food. Imagine that children became orphans because their father was killed by enemy soldier and his mother was raped and then killed. There is no war without war crimes, like in Bucha</a>. If you can't imagine that, that probably good at least for you. At first day I explored shelters near my home. While I was coming from one of them, I heard sound of flying missile. People run in panic back to shelter. And I should say that sound of flying missile is just sound of something moving fast, so I was in fear for my life each time I heard regular car moving. At second day when I heard sound of air alarm, I run to shelter and I saw helicopter moving above us. And the most scary thing is that I had no idea which side this helicopter belongs to and whether I will be able to run to shelter or will die right there. When I got to shelter I was told that helicopter was Ukrainian helicopter specialised on emergency situations. For me the war is just pure chaos and understanding that most elementary things might vanish. At second day I didn't have electricity and most markets were closed, partly because workers were scared of leaving their houses, partly because people bought everything at first day and logistic to deliver food just died as everything else. By some luck, I managed to leave Kyiv at second day and move to West of Ukraine. I can't return to my home, but I want it so much. If you want to help Ukraine and stop this war, you can in multiple ways! Please, call this war, not "conflict" or "military operation". Yes, word "war" is scary as it is.</li> You can donate, for example here</a> or here</a>. Don't donate to International Committee of the Red Cross, because it's unclear were money will go. Maybe to Russia?</a> ("International" part is important, there are different ones, like Ukrainian Red Cross Society)* Boycott companies that sponsor Russia by continuing working there, like Leroy Merlin.</li> Go for protests, asking your government for stronger actions.</li> </ul> Слава Україні! Жыве Беларусь! This Week In Veloren 170 Mon, 02 May 2022 00:00:00 +0000 This week, we have a lot of exciting images to check out! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @holychowders, @xMAC94x, @Isse, @ClaryChevry, @EnriqueAM, and @DrDystopia! @Gemu has been working on some Wyvern models. </figure> @Christof worked on smoke strength and color variations. </figure> @James has been working on a rib cage generator that can generate some fun variations. These will be used in adlet fortresses. Rib cages to discover. See you next week! </figcaption> </figure> This Week In Veloren 169 Mon, 25 Apr 2022 00:00:00 +0000 This week, we hear about some balances to arthropods. We also hear a bit about bank storage. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Anton, @Christof, @Sam, and @UncomfySilence! The map for the future 0.13 release party </figcaption> </figure> @ubruntu has been working on bank storage, which is a separate inventory that players will be able to access in towns to store excess items. Credit goes to @Toaster for the sprite model. </figure> There was also another Veloren Code Review stream. In this episode, @Sam brought us through a merge request about how damage numbers show on screen. </iframe> </div> </figure>Arthropods and the Harvester @UncomfySilence</h3> I've made a small balance tweaks branch which touches upon a couple of things that weren't quite right nor was I happy with. As part of this, I've finally rebalanced arthropods, so the long pain in finally over. It took considerably longer than expected due to multiple things so I'm incredibly sorry for the wait. I also ended up changing the stats for most hats so that they're better befitting of their rank alongside more specialized stats, so I'd suggest checking them out and comparing! I've also adjusted the stats of the Harvester so that it has roughly the same difficulty as a T4 boss. To hinder even more feature creep I am planning on making another MR which will give the Harvester a new set of skills to make sure that it's as threatening as possible. Dinner time! See you next week! </figcaption> </figure> This Week In Veloren 168 Mon, 18 Apr 2022 00:00:00 +0000 This week, we hear about loadouts and livestreams that @JulianCoffee has been doing. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @xMAC94x, @Anton, @Leonic, @Plright, @Vlad, @aflyingpumpkin, and @flo! A new Veloren Reading Club is out, this time with @imbris! This week, we explored Veloren's graphics pipeline. We worked on refactoring particles, and how they re-create their buffer every frame. </iframe> </div> </figure>Livestreams and loadouts by @JulianCoffee</h3> So, this MR happens to be my 100th. And to make it more special, I wanted to make a live coding playlist</a> of me making it and trying to explain what I am doing. It mostly covers handling errors in Rust, a bit about traits, and type conversions via From/Into traits. For Veloren it is mostly concentrated on our assets system and Serde (library for serialisation and de-serialisation). I wanted to record full work and mention review process, but then war happened, so sorry for the incomplete playlist. As for what has changed, we can now create the following loadout config. ##![enable(implicit_some)] ( inherit: Combine([ Asset("test.loadout.ok.just_crafted_rings"), Choice([ (1, Asset("test.loadout.ok.just_ori_armor")), (1, Asset("test.loadout.ok.just_dragonscale")), ]), Asset("test.loadout.ok.just_butterfly_gliders"), Asset("test.loadout.ok.just_lanterns"), ]), active_hands: [ (1, ( "common.items.weapons.sword.caladbolg", None, )), (1, ( "common.items.weapons.bow.sagitta", None, )), (1, ( "common.items.weapons.hammer_1h.orichalcum-0", "common.items.weapons.hammer_1h.orichalcum-0", )), (1, ( "common.items.weapons.axe_1h.orichalcum-0", "common.items.weapons.shield.shield_1", )), ], ) </code></pre> The most notable thing is inheriting, yes, you can now reuse available loadouts in other loadouts. Also, the way of handling weapons is improved, as you can see we can have paired weapons or just one two-handed weapon. (Pirates that can switch between paired swords and bows when?) And there is more! If you have any questions, feel free to ping me on the Veloren Discord! Out for a midnight ride. See you next week! </figcaption> </figure> This Week In Veloren 167 Mon, 11 Apr 2022 00:00:00 +0000 This week, we see a breakdown of the finances over the last several months. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @juliancoffee, @imbris, @xMAC94x, @Sam, @holychowders, and @oversram! Finances by @AngelOnFira</h3> I recently went and took care of several months of finances. You can see the results here</a> (please feel free to reach out if you come across any discrepancies). Since there were several months of invoices to process, it resulted in over $1,200 USD being expensed from the Veloren Open Collective</a>. Currently, Veloren is paying for services from Hetzner (compute), Wasabi (storage), and OVH (temporary download server). Below, you can see the revenue from Open Collective over each month. We can see that most months are around $200 USD, but we had some large donations in November and December of 2021. We also can see that in 2022, we're trending towards $250 each month. </figure> Over time, our monthly Hetzner bill has increased. This is because we've had to provision progressively more powerful game servers. Currently, we're at the highest tier that Hetzner provides for normal cloud servers, and this lets us handle around 100 players at once. Ideally, the next level after this is distributing to multiple servers. Altogether, we seem to be trending upwards in the number of people who donate. In the near future, I hope that this will help us host more servers around the world with confidence that we'll be financially stable enough to keep them going. And of course, as always, donations are always appreciated! This Week In Veloren 166 Mon, 04 Apr 2022 00:00:00 +0000 This week, we see Veloren's participation in /r/place. We also have a new Veloren Reading Club episode out! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @JakobDev, @James, @Sam, and @Tormod! Last weekend, Veloren participated in Reddit's /r/place project. Veloren was able to get a spot on the map by allying with /r/Rust and building beside them. A template was created so that everyone in the area could know what colours to place, which made it easy to protect the area. It was a lot of fun, and we got a pretty great result eternalized in the final image (before the destruction of the whole map 😛). Day one on the left, day two on the right. </figcaption> </figure> If you missed it, be sure to check out Veloren's April Fools post</a>! Veloren Reading Club #7 by @aweinstock</h3> This week, another Veloren Reading Club was held! The topic was profiling Veloren with the Tracy profiler</a>. </iframe> </div> </figure> As a supplement to the talk, here are some commands to follow along and try Tracy yourself: Compiling and running Tracy: git clone https://github.com/wolfpld/tracy cd tracy git checkout tags/v0.7.8 -b tags_v0.7.8 cd profiler/build/unix make ./Tracy-release </code></pre> Compiling and running Veloren with Tracy support: cargo run --features=tracy --bin veloren-server-cli cargo run --features=tracy --bin veloren-voxygen </code></pre> Running Veloren's "swarm" client (requires running the server with --no-auth and making swarm0 an admin): cargo run --features='bin_bot tick_network' --bin swarm </code></pre> [April Fools] Need for Voxels: Veloren Cart Fri, 01 Apr 2022 00:00:00 +0000 Veloren's New Direction</h2> Since Veloren's inception, people have seen Veloren as heavily inspired by Cube World. Today, we're excited to fully break away from this lineage as we announce the new direction of the project: Need for Voxels: Veloren Cart. Market research shows that the most potential for a voxel game is in the casual gaming market. That means games that can be played for a quick 15-30 minute session and put down afterward. However, role-playing games, which are grinding-focused, do not fit so well into this category. Therefore, we decided to pivot the core mechanics to focus on racing. This change will give you the opportunity to join the new world of Need for Voxels: Veloren Cart in a race with up to 2,000 players through the places you love: gigantic cities, scary dungeons, and on a moving airship! Not only this, but we'll be able to re-use many of our models from Veloren, so you'll be able to race while riding horses, fish, and spiders. The planned release date will be in exactly one year, on 2023-04-01. </figure> This Week In Veloren 165 Mon, 28 Mar 2022 00:00:00 +0000 This week, we hear about the new GitHub Releases system for game updates through Airshipper. We also hear about how the 0.13 release map will look, and about CliffTowns. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @jh0l, @Sam, @xMAC94x, @JackHollisLondon, @ubruntu, @InfRandomness, @James, @Slipped, and @holychowders! @Inojelis was continuing my work on making agents pick up items (ItemDrops). This week they worked on making agents walk right to the ItemDrops. @Christof just parallelized economic simulation - shortening server startup time (by a small fraction) - but this prepares for adding more Goods (econsim groups of items). GitHub Releases by @Shouvik</h3> I worked on setting up GitHub releases for Veloren. We can use GitHub as a faster and more stable backend for downloading files. Earlier, many users had sporadic issues with bad connections and aborting updates in Airshipper. Those should be gone now. Users outside of Europe can especially profit from this fix. Setting this up involved using the Octocrab crate for uploads, and making changes to Airshipper's database and URL structure. Incremental Airshipper updates by @aweinstock</h3> @XVar and I have been experimenting with packing extra metadata to facilitate incremental Airshipper updates into standard zip files. Currently, Airshipper downloads an entire ~224MB zip containing all the binaries and assets for each update. Since GitHub Releases supports HTTP range requests, and since zip supports random access to contained files, if the offsets of files within the zip that have changed are known--, it's possible to save bandwidth by only downloading those files from the zip. Since zip's central directory supports adding a "comment" field containing arbitrary metadata, we can store hashes there to detect which files need to be redownloaded before downloading them. Since it's possible to pack a file at the beginning of a zip that's not indexed in the central directory, it's possible to prefix enough metadata to the zip to locate the central directory in one additional range request. 0.13 Release Map by @Hannibal</h3> I've been working on the next release party map that will also serve as a mockup. This map's theme is JUNGLE!!! 🥳 🥳 This time, the party map will be an entire island. That way, its placement in the water will look less odd than the desert city did. Things to expect: Lots of trees!</li> Jungle temples!</li> Tribal villages</li> Treehouses</li> Secret areas 👀</li> </ul> A first tiny look at the map (although there is much to do!): </figure> </figure> CliffTowns by @floppy</h3> Under @Gemu's artistic supervision and with patient guidance from @zesterer, @Isse, and others, I have been working on CliffTowns, Hoodoo/Arabic inspired towns for mountain regions. CliffTowns' houses are natural structures of sedimentary stone layers, inhabited by Mountaineer NPCs. @MerlinMan created the great furniture assets. </figure> </figure> Living in a cliff town. See you next week! </figcaption> </figure> This Week In Veloren 164 Mon, 21 Mar 2022 00:00:00 +0000 This week, we see some work being done on modular weapons and hear about Veloren's talk at Rust in Arts. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @XVar, @xMAC94x, @holychowders, @AndrzejDrabarek, @Christof, @imbris, @James, @Mehmet-dev, @Mel! @batvin123 got crafty, and put the Linux, Windows, and MacOS versions of the launcher for Veloren on a cd-r. Now they can play the game like they were back in the early 2000s or 90s! </figure> Modular weapon tooltips by @ubruntu</h3> I worked on tooltips for modular weapon components. Not all the models are in yet and the numbers need balancing, but now they display new stats. Also, the item-kind text (e.g. 'Fire staff Component' in this example) is dynamically generated and i18n friendly. </figure> RustFest 2021</h3> </figure> Back in November of 2021, Veloren spoke at Rust in Arts with a "Director's Commentary" of the game. The talk was just released on YouTube, and you can watch it here</a> A golden sunrise. See you next week! </figcaption> </figure> This Week In Veloren 163 Mon, 14 Mar 2022 00:00:00 +0000 This week, we hear about some work on the audio system. We also look at some of the stats from last week's post on Hacker News. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @Tormod, @DaforLynx, @Sam, @Isse, @zesterer, @Slipped, @xMAC94x, and @Treeco! @ubruntu worked on adding decorations and sprites to houses and learning site2 as they go. </figure> Audio work by @DaforLynx</h3> I've merged a bunch of audio work. I fixed the swimming sounds from playing too unevenly and fixed the glider closing and opening sounds not playing at the right times. I also made it so faster segments of rivers (i.e. most of them) make a "rushing river" sound, while slow-flowing river segments make the old "bubbling" sound. Keep in mind that river speed currently has no effect on gameplay outside of worldgen and these sounds. Lastly, I added sounds to the gliding that makes it sound like the cloth of the glider is flapping in the wind. It's very subtle, but it should add a bit more auditory interest to long glides. Also, town music is back after being broken by site2 towns :) Hacker News stats by @AngelOnFira</h3> This week, a post about Veloren reached the top of Hacker News for half a day. You can read the post</a> if you like. The comment section had quite a few good discussions, and I took the time to answer several questions myself. Out of interest, I wanted to see how the post affected our YouTube views. Below is an image of the stats: </figure> This Week In Veloren 162 Mon, 07 Mar 2022 00:00:00 +0000 This week, we hear about a bug in Airshipper. We also explore some of the difficulties of running Veloren on the Steam Deck. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Dr.Dystopia, @Christof, @xMAC94x, @Isee, @Pfau, @DaforLynx, @imbris, @zesterer, @Slipped, and @ninefox! @Isse has been working on creating new rocks that will be scattered across the world. </figure> Airshipper 0.7.0 release</h3> We've released a new Airshipper version that makes launching Veloren even better: Changelog is rendered</li> Ability to specify ENV variables in airshipper.</li> Heavy under the hood maintenance to improve in the future.</li> </ul> ACTION REQUIRED: Please upgrade ASAP as the old Airshipper 0.6 will no longer work in a few days. You can read the release notes here</a> Airshipper fixes by @xMAC94x</h3> This week we had a silent bug at Airshipper which was seen during some testing. Our GitLab jobs reached the 2,147,483,647 barrier. That is a common number for computer engineers, for example, until 2014 it wasn't possible for a YouTube video to get more than this number of views. Back then google faced a similar issue than we faced, if a video would get more than this number of views, it would overflow the possible 32-bit number range and would be -2,147,483,648. Luckily neither YouTube nor Veloren faced an outage. We were able to patch a version overnight before the weekly Thursday release by increasing the number to 64-bit. Our new limit is 9,223,372,036,854,775,807, roughly the number of sand grains on earth. We're also preparing for better multi-architecture and multi-channel support. In the future, it will be possible to use Airshipper to download different versions of Veloren and also historic versions. The groundwork for this feature has been made and the feature will probably come within the next weeks. Veloren on Steam Deck by @AngelOnFira</h3> </figure> Last week, I got my Steam Deck in! One of the first things I wanted to try was running Veloren on it, and seeing what the process of getting into the game was. Veloren isn't on Steam (yet), but the Steam Deck does have a cool feature where you can add applications from the desktop mode. And since Steam OS runs on Arch Linux, the process of installing Veloren isn't so difficult. In the desktop mode of the deck, I was able to go to the software store and find it without too much difficulty. However, after I got the game installed, there were many issues that arose that would prevent people from playing the game with ease. First off, it seems that the flatpak version of the game doesn't allow permissions for controller input to work. We had to download Airshipper manually and launch the game through it outside of the flatpak version. Then, it tends to run alright. The controller maps pretty nicely to the inputs of the game, however, there are interactions that it's much more difficult to achieve on the Deck. Either the UX can't be navigated easily enough, or it's not clear how to achieve something. We mostly saw around 60fps while playing, although in multiplayer on the main server, we experienced closer to 40fps, and some issues with networking. Although this could also be because I'm located in North America, and the server in Germany. </figure> If you want to see more about the problems, you can check out the tracking issue</a> and the notes doc</a>. Moving forward, we want to explore how to create a more clear UI/UX for controller-first experiences. We also want to explore what graphics settings might be best for this hardware, since it could be standardized quite easily. This Week In Veloren 161 Mon, 28 Feb 2022 00:00:00 +0000 This week, we have another code reading club to watch. Work is being done on pet healing, and how sites are placed. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @ninefox, @Slipped, @ubruntu, @InfRandomness, @zesterer, @bwerf, @xMAC94x, @inojelis, @Sam, @floppy! @ubruntu got players to now heal their pets as well as themselves when sitting at a campfire. @tormeh has been working on sites. Giant trees, castles, towns, and other sites should now be placed more appropriately, both in regards to terrain and each other. Veloren Reading Club #6</h3> This week, another reading club was recorded! In this one, we learned about some internals of Git, and how to move around different workflows. We also learned about how the economy sim for Veloren is designed. </iframe> </div> </figure> A shady deal is happening out back of the inn </figcaption> </figure> This Week In Veloren 160 Mon, 21 Feb 2022 00:00:00 +0000 The Veloren core developers condemn the aggressive and unprecedented invasion of Ukraine and the violence committed toward its people on the orders of Vladimir Putin. We also wish to make clear that Russian people continue to be welcome in the Veloren community, as ever, and that we do not consider them in any way accountable for the unaccountable and unforgivable actions of Vladimir Putin. - Veloren team Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @imbris, @inojelis, @IseeW, @zesterer, @Slipped, @James, @Pfau, @shouvik, @Treeco, @floppy! This week, Veloren 0.12 was released! You can check out the release blog post here</a>. We broke our previous release party record with 195 players online at peak. </figure> Veloren 0.12 Dev Chats</h3> For the 0.12 release, some of the core developers streamed another "dev chats". We looked at the map used for the release party, and gnarling forts. </iframe> </div> </figure>Veloren Mastodon</h3> I created a Mastodon account for Veloren (@veloren@mastodon.technology</a>) to better communicate with our FOSS friends. For those unfamiliar, Mastodon is an open source decentralized microblogging platform. We will be posting updates there in addition to our current use of Reddit and Twitter. Veloren GSoC</h3> Veloren is applying for Google Summer of Code! Although we haven't been accepted yet, we still have planned many areas where potential work on Veloren could happen. To learn more, you can read the blog post</a>. A Gnarling stalker out and about. See you next week! </figcaption> </figure> GSoC 2022 Contribution Guide Mon, 21 Feb 2022 00:00:00 +0000 Applying for GSoC</h2> Welcome! The application process consists of the following steps First of all, Read up on the Veloren book</a> to understand the basics of what the project is about, how to compile and much more.</li> Play! You can download the game here</a>, and then either create an account</a> or try out single player.</li> Join us on social media platforms</a> to get in contact with developers and better understand the different areas of the codebase, known as Working Groups.</li> Begin thinking about improvements you'd like to see, or areas you'd like to focus on. Reach out with questions!</li> Submit the application/proposal including all requirements at the Google Summer of Code Site.</li> </ul> Ideas for GSoC Contributions</h3> We're welcome to any ideas you can come up with for contributing to Veloren, and we've compiled a few examples. Refactoring the AI system for robustness and ease of use</h4> (175 hours) (medium)</h5> Re-organization of the agent system will allow for continued expansion to include new desired features (group-based combat mechanics, more environmental awareness, daily simulated activity). Desired skills: Some basic behavior tree knowledge Mentors: James, Sam Integrating the wiring system in procedurally generated structures allowing for increased player interaction</h4> (350 hours) (hard)</h5> The wiring system is Turing-complete and allows electricity-like mechanics to be added into the game. One desired feature is to introduce this system into procedural structures such as dungeons to allow for opening of doors with switches and similar features. Desired skills: Strong mathematical logic capability Mentors: James Implement a site governance AI that can grow a site over time based on economic factors</h4> (350 hours) (medium)</h5> Sites such as towns currently contain knowledge of the land around them to determine available resources, economic prosperity, potential to trade, etc. It is desired for these sites to be able to develop over time based on incoming and outgoing resources, using the flow of material to determine population change and overall development of the site. Desired skills: Modelling or economic background Mentors: zesterer, Christof Combat expansion, developing new ability sets and attacks</h4> (175 hours) (easy)</h5> Many existing entities in the game have very basic or placeholder combat ability sets. Expansion of these ability sets will be critical to create a varied, diverse experience in different sections of the game. Desired skills: General programming, game design Mentors: Sam, James Interactive vehicles, expanding on ships and airships to allow player use</h4> (175 hours) (medium)</h5> Currently ships and airships exist in a fairly simple state, and expansion of the feature is necessary to properly engage players with the feature. The ability to mount and control these ships will require improvements in pathfinding, physics, and simulated interaction with towns. Desired skills: Physics knowledge, general programming Mentors: zesterer, James Transitioning network to QUIC</h4> (350 hours) (hard)</h5> QUIC is a general-purpose network protocol which is partially implemented in Veloren, however, not fully active. Further implementation of the protocol is desired and will be used to improve player latency, creating a better experience. Desired skills: Network experience Mentors: xMax94x Create diagnostics for tracking bandwidth contribution of each type of message with counts, uncompressed size, and estimated compressed size</h4> (175 hours) (easy)</h5> Improving these metrics will give us more insight into network performance and where bottlenecks are located, helping us better allocate time when determining future improvements. Desired skills: General programming, network experience Mentors: imbris, xMac94x Expand authorization system with password reset, email tracking, a friends list, etc</h4> (350 hours) (medium)</h5> Improving this system will require programming experience to work on the veloren authorization code and also some background into the security requirements related to storage of data, such as e-mail addresses, across the US, EU and other places. Desired skills: Knowledge of standard practices for authorization Mentors: zesterer, AngelOnFira Develop the plugin system to a maturity that allows for writing useful plugins</h4> (350 hours) (hard)</h5> The plugin system will allow the download and use of mods for players and servers, a strongly desired Veloren feature. Currently this system exists but is not robust enough to introduce to the playerbase. Continued expansion of the plugin system will greatly improve player experience. Desired skills: ECS experience, WASM knowledge Mentors: zesterer Implement server federation, allowing characters to transfer between servers in the same federation</h4> (350 hours) (medium)</h5> A server federation is a union of trusted servers, and allows the servers in the federation to operate knowing that the others can be trusted to hold characters which haven't been manipulated in any undesirable way (such as using commands to introduce items). Desired skills: Database experience, general programming Mentors: xMac94x, zesterer, XVar UI refactor to continue the transition to new GUI backend</h4> (175 hours) (medium)</h5> Currently, the ICED and Conrod UI backends both exist in Veloren, it is desired to make a full transition of the UI to the newer, improved UI backend, ICED. As part of a visual UI overhaul as well, the transition will require both the ability to create new widgets and artistic insight. Desired skills: UI development experience Mentors: imbris Implement UDP hole-punching on the auth server so that players can host games locally without needing to port-forward</h4> (175 hours) (hard)</h5> UDP hole-punching establishes bidirectional connection between hosts, allowing transfer of data between the hosts. The feature is desired in order to simplify the creation of private servers for players to make it easier to play the game with a group of friends. Mentors: zesterer Improve controller support, adding a GUI for editing controller bindings</h4> (175 hours) (easy)</h5> Controller support exists in a simple form, but additional features are desired such as improving the editing of controller bindings, the ability to use the UI with a controller, etc. Desired skills: General programming Mentors: imbris Veloren 0.12 Release Sat, 19 Feb 2022 00:00:00 +0000 0.12 Release</h2> Today, Veloren is releasing 0.12. This version is 5 months in the making, and we have a lot to show off! If you're reading this before 18:00 GMT today (February 19th)</a>, make sure to join the release party. To join, you can download the game for free at veloren.net</a> and create an account</a>, then launch the game and hop on the default server. See you there! We have also made a trailer for 0.12, so be sure to check it out! </iframe> </div> </figure>Changelog</h3> Below are some of the key items from the release. You can check out the full changelog here</a>. Added</h4> Added a crafting station icon to the crafting menu sidebar for items that could be crafted at a crafting station</li> Added a credits screen in the main menu which shows attributions for assets</li> Shrubs, a system for spawning smaller tree-like plants into the world.</li> Waterfalls</li> Sailing boat (currently requires spawning in)</li> Sneaking with weapons drawn</li> Stealth stat values on (some) armors</li> All new dismantling interface found at your nearest dismantling station</li> Wearable headgear, including hood, crown, bandanas</li> Bomb sprites (can be exploded with arrows or other explosions)</li> Campfire waypoints in towns</li> New outfit for merchants</li> Rivers now make ambient sounds (again)</li> Players can now mount and ride pets</li> Experimental shaders, that can be enabled in Voxygen's settings (see the book for more information)</li> Keybinding customization to set waypoint on Map</li> Added arthropods</li> A 'point light glow' effect, making lanterns and other point lights more visually pronounced</li> Convert giant trees to site2</li> Add new upgraded travelers</li> Wallrunning</li> </ul> Changed</h4> Made dungeon tiers 3, 4, and 5 more common</li> The Interact button can be used on campfires to sit</li> Made map icons fade out when near the edge of the map display</li> Agents using fireball projectiles aim at the feet instead of the eyes</li> Explosions can now have a nonzero minimum falloff</li> EXP on kill is now shared based on damage contribution</li> Dungeons have somewhat proper scaling. The higher the dungeon the harder it gets, Cultist staying unchanged while Mino is now at its level.</li> Yeti loot table modified</li> Green/Red lantern now shine their respective color instead of the default lantern color</li> Poise damage dealt to a target that is in a stunned state is now converted to health damage at an efficiency dependent on the severity of the stunned state</li> Made the hotbar link to items by item definition id and component composition instead of specific inventory slots.</li> Made loot boxes drop items instead of doing nothing in order to loot forcing</li> Changed the way light strength is rendered by moving processing from shader code (GPU) to CPU code</li> Made /home command a mod+ exclusive</li> Friendly creatures will now defend each other</li> Creatures will now defend their pets</li> </ul> Fixed</h4> The menu map now properly handles dragging the map, zooming, and setting the waypoint when hovering icons</li> Falling through an airship in flight should no longer be possible (although many issues with airship physics remain)</li> Avoided black hexagons when bloom is enabled by suppressing NaN/Inf pixels during the first bloom blur pass</li> Many known water generation problems</li> Trading over long distances using ghost characters or client-side exploits is no longer possible</li> Merchant cost percentages displayed as floored, whole numbers</li> Bodies of water no longer contain black chunks on the voxel minimap.</li> Agents can flee once again, and more appropriately</li> Items in hotbar no longer change when sorting inventory</li> Lantern color changes when swapping lanterns</li> NPCs no longer wander off cliffs</li> Guards will defend villagers instead of simply threatening the attacker</li> Seafaring ships no longer spawn on dry land</li> </ul> </figure> Support the project</h3> As always, feel free to support the project on Open Collective. It allows us to keep our servers running, and launch great release parties like the one today! This Week In Veloren 159 Mon, 14 Feb 2022 00:00:00 +0000 This week, we see the 0.12 trailer. We hear about the new travelers that are being implemented, and how species can now defend each other. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Slipped, @zesterer, @imbris, @James, @xMAC94x, @floppy, @aweinstock, @Tormod, @XVar, @Crow, @IbrahimBeladi, @InfRandomness, @DrDystopia, @Pfau, @UnfomfySilince, @ninefox, @phoenix13032005, and @unvariant! new map icons for gnarlings, minotaur and mindflayer. Old icons for comparison. </figcaption> </figure> Another Veloren Reading Club episode is out! In this one, @JulianCoffee talks to us about getting started with some initial contributions. We see how to create a new entity, and how to then go through the Merge Request process. </iframe> </div> </figure>New travelers by @Juliancoffee</h3> I finished the New Travelers MR based on ideas and work from @UncomfySilence. That's the same MR we started in the last Veloren Code Reading Club</a>, and here is the link to the MR</a> if you're interested. 0.12 Release</h3> This weekend, Veloren is releasing 0.12! Check out the trailer to see some of the changes. The release party will be taking place at 18:00 GMT on February 19th, this is one you won't want to miss! </iframe> </div> </figure>Defending species by @tormeh</h3> I made creatures of the same species defend each other, so individual horses (for example) in bigger herds should now be a bit harder to pick off one by one. I was just always annoyed by the fact that I could kill a horse and his buddy two metres over would be like "Meh, Dave kinda sucked anyway" while continuing to graze. The biggest problem was probably to figure out if two entities had the same species or not, as the code isn't particularly well-suited for that exact problem. Turns out the solution wasn't that complicated in the end, although a bit verbose. A new traveler ready for adventure. See you next week! </figcaption> </figure> This Week In Veloren 158 Mon, 07 Feb 2022 00:00:00 +0000 This week, we hear about the work going on with giant trees and their new CSG implementation. Waypoints now work better while you're playing with group members. Fine-grain support was added for server socket configs. Mockups were made for potential future dungeons, and some changes were made to the econsim. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Christof, @James, @zesterer, @xMAC94x, @floppy, @IsseW, @protheory8, @Crow, @Yurimomo, @imbris, @InfRandomness, @Slipped, @Sam, @UncomfySilence, @Zughy, and @juliancoffee! @InfRandomess worked on migrating giant trees from site to site2 (hopefully releasing soon!). This uses an algorithm that generates a tree based on a given scale that we paint by walking from the trunk to the very leaves. </figure> CSG Shapes by @Isse</h3> In addition to James' additions to CSG, I've added a way to repeat other CSG shapes. </figure> I've also made waypoints shared with group members, and saved between sessions, which will hopefully get merged before release. Your browser does not support the video tag. </video> </figure> More fine granular support for socket listening and IPv4 and IPv6 by @xMAC94x</h3> With an update on Tuesday the 8th of February at 10:00 GMT, we will switch the server config format in a way that allows you to specify the sockets for the server to listen on in a more fine-grain way. The old scheme: gameserver_address: "0.0.0.0:14004" </code></pre> This only allowed setting a single socket with a single port. E.g. IPv4 0.0.0.0:14004</code> or IPv6 [::]:14004</code>. This had a different behavior under Linux/Windows, for example, it was possible to enable the server for both IPv4 and IPv6 traffic under Linux by setting it to [::]:14004</code>. But that configuration didn't work on a Windows server. To solve this problem we now extended the configuration scheme to list multiple addresses like: gameserver_protocols: [ Tcp( address: "[::]:14004", ), Tcp( address: "0.0.0.0:14004", ), ], </code></pre> This will be the new default for new installations which will listen on all IPv4 and all IPv6 addresses by default. You now have to possibility to either disable one of them, change the port or also add other protocols, like the experimental QUIC support: gameserver_protocols: [ Quic( address: "[::]:14004", cert_file_path: "cert.der", key_file_path: "key.der", ), Tcp( address: "0.0.0.0:1234", ), Tcp( address: "[::]:1234", ), ], </code></pre> Hannibal</h3> This week, I worked on dungeon mockups to give ideas and concepts for the dungeon overhaul coming up. The small designs help to create the general atmosphere and layout of the dungeon to inspire the proc-geniuses. First, we have a sewer dungeon with poisonous liquid. The deeper you go, the fouler and more dangerous it is. Then, we have the Sahagin dungeon, which has areas accessible only after going underwater or in the water. Finally, the adlet troglodytes in snowy mountains, who live in caves and carved their houses on the walls of the grotto. Hopefully, the mockups will help the proc-geniuses have an easier time with the generation of dungeons! Sewer Dungeon </figcaption> </figure> Sahagin Dungeon </figcaption> </figure> </figure> Adlet Troglodytes </figcaption> </figure> @Christof</h3> I just provided a small fix to trading price calculation from loot tables. Previously the loot tables were used as-is and then individually scaled against each other - now each loot table is normalized to 100% and then multiplied and combined. This might be less surprising to people changing weights and feels more logical. I just adjusted the new weights to result in unchanged prices. Something off in the dark, but what is it? See you next week! </figcaption> </figure> This Week In Veloren 157 Mon, 31 Jan 2022 00:00:00 +0000 This week, we see the progress of gnarling fortifications and weapon trails. We hear about the worldgen tracking issue from @zesterer, and entity refactors by @juliancoffee. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @juliancoffee, @zesterer, @Dr.Dystopia, @imbris, @xMAC94x, @Sam, @floppy, @Slipped, @Aweinstock, @Martin, @YuriMomo, @AngelOnFira, @InfRandomness, @IsseW, @James, @Scott, @Treeco, @threadexception! @Sam has been working a bit on weapon trails. Your browser does not support the video tag. </video> </figure> @juliancoffee migrated the project to Rust 2021. Back to the future! You can read more about what the 2021 edition includes here</a>. More work is needed, but gnarling fortifications are slowly getting completed by @Slipped and others. </figure> Worldgen tracking issue by @zesterer</h3> I created a tracking issue for worldgen things (in particular, the move to site2 and the upcoming rtsim refactor). You can see it here</a>. The plan is to use it as a central place to coordinate development and break larger tasks down into smaller ones that can be taken on by individual contributors. I recommend you take a look at it! Entity config refactor by @juliancoffee</h3> I've refactored our entity configs to fix some potential logic holes and extend features. This can affect any NPC, such as travellers, cultist, or foxes. Now it's possible to randomly choose which loadout an entity will get and to give initial inventory items to NPCs in the entity config without the need for coding. If everything works as planned, you shouldn't notice any behaviour change yet, but expect greater things soon™️. Note for server owners with custom assets, you will need to update them to the new format. To help with this, we created a special tool for migration. To use it, you'll need to follow a couple of steps. Note: If there were comments in it, they will be erased, so make sure to create backups 1. Execute these commands $ git checkout 7585c8 # to go back in history, where this tool is active $ cargo run --bin entity_migrate --features bin_entity_migrate 2. Follow instructions of binary 3. Grab migrated assets folder and replace old assets folder with it 4. Check if everything is ok </code></pre> Have fun! A midnight meeting among unusual suspects. See you next week! </figcaption> </figure> This Week In Veloren 156 Mon, 24 Jan 2022 00:00:00 +0000 This week, we hear about some new shaders being developed. We also have a new Veloren Reading Club to check out! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @DaforLynx, @InfRandomness, @flo, @Slipped, @XVar, @imbris, @tygyh, @ubruntu, @unvariant, @AngelOnFira, @Sam, @terrarier2111, @Snowram, @JulianCoffee, @IsseW, @roidujeu, and @James! The December Rust Gamedev Newsletter is out! You can read it here</a>. @AngelOnFira has been starting work on improving parts of how Veloren's GitLab bot works. Now, using /review</code> on Discord will pin the link to the thread it makes. Very helpful for developers! Another Veloren Reading Club episode is out! In this one, @Sam talks to us about attacks and character states. </iframe> </div> </figure>Shader Changes by @zesterer</h3> I've been working on some changes to shaders this week. First up, I added an 'experimental shader' feature that allows us to add shader effects to the game without committing to adding them by default. The system is very simple, but allows enabling shader effects via Voxygen's settings.ron</code>. That also makes space for us to add some 'fun' shaders that we don't feel are a fit for the main game, but that we want to give users the opportunity to play with. Information about these shaders and how to enable them can be found here</a>. CurveWorld shader </figcaption> </figure> Brickloren shader </figcaption> </figure> Before `ProceduralLodDetail` shader ^ and after v </figcaption> </figure> </figure> Secondly, I've added a 'point glow' effect to the game. For a while now I've struggled to make lanterns/lights look visually impactful, but a few days ago I found a neat technique that (ab)uses the depth buffer and some fast shader maths to add a halo around point lights to simulate light diffusion in the air. Even better, this effect works when the point light itself isn't visible: you can see the light of a campfire before you see it as you approach from over a hill, for example. I know that it's not for everybody so I added an in-game slider to allow players to adjust the intensity of the effect (this will be in next week's build). Here's a before and after that show the effect in action (I've cranked it up to the highest setting to make it more obvious, but players can tone it down if they so choose). </figure> </figure> Lastly, I'm currently working on sprucing up the water shaders. There are a fair few things going on here: I added a caustic effect that shows refracted light projected onto the ocean floor</li> I added distance fog that uses an approximation of water depth to calculate light attenuation. It takes into account sun and moon light so the water appears as a sensible colour</li> I altered the water surface rendering, re-enabling depth writing and fixing the way reflection vs refraction was calculated when the water was viewed from below</li> </ul> Exploring the underwater world is now beautiful and creepy, as it should be! </figure> </figure> </figure> </figure> An endless ocean to explore. See you next week! </figcaption> </figure> This Week In Veloren 155 Mon, 17 Jan 2022 00:00:00 +0000 This week, we hear about many small changes to the renderer, the agent system, skiing, inventories, and arthropods. We also hear about how the development of the new mount system is progressing. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @flo, @zesterer, @unvariant, @imbris, @Maveth1, @JakobDev, @Slipped, @Kember, @Sam, @terrarier2111, @Isse, @Pfau, @Yurimomo, and @Tormod! @Capucho has gotten Veloren working with WGPU and OpenGL! Right now, we're able to use WGPU with Vulkan, however, this meant that older GPUs that couldn't run Vulkan couldn't run Veloren. This is a step towards some more backward compatibility. Your browser does not support the video tag. </video> </figure> @James broke up the monolithic agent system into several modules that will hopefully make it easier to work with. @Christof got skiing and ice skating into a playable state and made a video: Your browser does not support the video tag. </video> </figure> @tormeh made item shortcuts in the hotbar independent of inventory sort, so you can sort your possessions without losing the hotkey for your potions. @Snowram added a new skeleton to the game; the arthropod. Here is the new batch of creatures you will encounter soon... </figure> </figure> Mounts by @zesterer</h3> I've been working with @Slipped on getting mounts ready for players. We did already have a mounting system, but it was weird, arcane, and fundamentally broken in a variety of ways. It integrated very poorly with the rest of the game and was full of bugs. For this reason, it wasn't player-facing: only admin-spawned entities could be mounted. This week, that all changed! I finally had the time to sit down and rewrite the entire mounting system from the ground up. It's now very reliable, has fewer bugs (although there may still be some: please report them!), and has more features. New features include: New jumping/mounting animations (thanks @Slipped)</li> Interaction hints when close to entities (talk, trade, mount, pick up, etc.)</li> Mounted combat: you can use weapons while mounted, to a limited degree (certain moves are disabled for now)</li> Teleporting while mounted now works. You can use /home while riding a mount!</li> </ul> @Slipped gives a shoutout to @Snowram and @imbris too for setting up the mounted animation some months back, which now gets to be used. </iframe> </div> </figure>Devblog Recap by @Dalyc</h3> Be sure to check out last week's devblog recap by @Dalyc if you missed it! There are also videos for #153</a> and #152</a>. </iframe> </div> </figure> As the lookout calls 'land ho!', the ship runs aground. See you next week! </figcaption> </figure> This Week In Veloren 154 Mon, 10 Jan 2022 00:00:00 +0000 This week, we see lots of small improvements that are being made around the codebase. @Sam has a poll to ask about what some new abilities for the sword could look like. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @XVar, @tygyh, @Sam, @imbris, @Yurimomo, @FreeFull, @Pfau, @zesterer, @unvariant, @fetsorn, and @voxal! @Sam Skill persistence changes have finally merged. That means all your skill points have been reset to ensure proper migration to the new persistence format. @Pfau implemented UI visuals for crafting modular weapons: </figure> @Voxal implemented a setting that allows players to see their own speech bubbles. Most of the code was already there, and @Voxal just needed to check if the setting is on. The main issue was wrestling with Git, somehow 135 commits were added and it took them a few days to find a way to fix. </figure> @Yurimomo and @imbris managed to fix black reeds which were a byproduct of getting the square root of a negative number in shader code, which produced a NaN value. </figure> @FreeFull found a solution for certain players where the world wouldn't load for them 💜 </figure> </figure> @Christof worked on implementing physics for skiing ⛷️ and ice skating ⛸️. They have a working prototype but will need more days to create a cool video of it. Sword survey by @Sam</h3> Now that the skill persistence overhaul and ability selection UI has merged, we can now begin the skill tree rework. In the rework, we plan to shift away from passive skills instead to unlocking active abilities. We are beginning the skill tree rework with the sword, and since we want to have many abilities, we have created a poll</a> for all of you to suggest ideas. The sword is intended to be a weapon that is comb-focused and involves swapping between different stances. The ideas will primarily be used as a source of inspiration when designing the sword abilities. Some things to note, being specific in your ideas can be helpful, as it allows us to have a better idea of what your idea would entail. However if your idea contains exact numbers we will be less likely to accept it. Time to bargain. See you next week! </figcaption> </figure> This Week In Veloren 153 Mon, 03 Jan 2022 00:00:00 +0000 New week, new year! We hear about upcoming fixes to daggers, and hear the audio changes that are being made to rivers. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @DaforLynx, @imbris, @XVar, @tygyh, @UncomfySilence, @xMAC94x, @Ubruntu, @AngelOnFira, and @flo! This week, @AngelOnFira worked on fixing the GitHub mirror of the project. It turns out that there was a bug in the most recent version of git-lfs</code>. On the game server-side, the entity_sync</code> system was reworked to become parallel! This was a large issue that came up during the last release party. Once 150+ players were on the server, it started taking more time each tick than any other system. Hopefully, we get to test the improvements at the next release! </figure> Lunar New Year by @AngelOnFira</h3> With the Christmas holiday event just ending, we're looking forward to the next event, Lunar New Year 2022. However, our dev team doesn't have many people who celebrate this holiday. Because of this, we'd like to get more help on this! If you'd like to help us get this event ready, feel free to join the effort in the #aesthetics channel on our Discord server. This can include music, decorations, information, and any other ideas. Give me a ping if you want to get involved! Dagger animations by @Ubruntu</h3> This week, I worked on dagger animations. I started with some experimentation using the live reloading feature cargo run --features "hot-anim"</code>. I did some investigation into why daggers had such a different orientation on character models compared to all other weapons. I couldn't find a reason in the animation code itself, so I opened the dagger .vox</code> models in MagicaVoxel and found that they were horizontal whereas all other weapon models were positioned vertically. </figure> This was my first time using MagicaVoxel but I managed to rotate the models to the same orientation as other weapons, and after that, it was a matter of playing with orientations in the animation files to make them look naturally positioned on the character model. I took some artistic liberty and positioned the daggers at the hip instead of across the back like other weapons and that received some positive feedback. I also tied the "tempbasic" dagger attack skill to a basic swing animation that one-handed swords use, just for the time being. Daggers still aren't acquirable normally in the game and still aren't as polished as other weapons but now they definitely don't feel as "under construction" as they were before. At this point, however, players can spawn them with commands in singleplayer and try them out. We can now start to think of making new dagger VOX models and NPCs that use daggers as weapons, as well as work on animations for attacks that will use these cool weapons. </figure> @DaforLynx</h3> This week, I worked on re-implementing sounds of flowing water for rivers. Before this feature was removed a while ago, it sounded very sparse and rather un-riverlike. I took a different approach this time, making small bubbling sounds emit from a single random water block every tick. The result is that rivers sound a bit like a babbling brook now, and it gets appropriately louder as you get closer. Also, new town music by @phoenix13032005 and @Thy-SFX-[Velorian]- was added. Your browser does not support the video tag. </video> </figure> What's this ship doing here?! See you next week! </figcaption> </figure> This Week In Veloren 152 Mon, 27 Dec 2021 00:00:00 +0000 This week, we hear about some updates to the item displays. The Christmas holiday event is coming to a close. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @DoctorKompot, @zesterer, @DaforLynx, and @UncomfySilence! @Christof added some Christmas decorations with the help of @Sarra_Kitty. </figure> @Christof is also working on skiing, which is not yet ready as physics and animations aren't finished. Hopefully, we can hit the slopes in 2022! </figure> @DaForLynx, @Oolnokk, and @Rarnage have been working on adding new music to the game. Expect some more variety. Item Displays by @DoctorKompot</h2> This week, I updated the item displays! All the items that were still using old PNG files to display in the inventory have been updated to .vox</code> models, which look a lot better. Credits to @Gemu for the awesome art. I also updated the item quality backgrounds, making them lighter, as it was pretty hard to tell what item you were looking at sometimes. Other changes: Phoenix Feather is now Legendary quality</li> Yeti loot table has been tweaked by @UncomfySilence (The Polaris lantern and Boreal Warhelm are no longer dropped by the wild Christmas Yeti)</li> @Pfau's Turban hat has been worked on to better fit the head of characters</li> </ul> </figure> Devblog Recap by @Dalyc</h3> Be sure to check out last week's devblog recap by @Dalyc if you missed it! </iframe> </div> </figure> A Christmas tree in town. See you in 2022! </figcaption> </figure> Veloren Christmas Week Sat, 25 Dec 2021 00:00:00 +0000 Christmas Week 2021</h2> It's the Christmas season, and we've made some special changes exclusive to this week! We'll be having a Christmas Party at 18:00 GMT on December 25th on the official server. We know that many folks are separated from friends and family this year due to Coronavirus, so feel free to log on if you're looking for some company. </figure> We have a ton of changes just for this week that are winter themed. Here's some of what we have: ❄️ Snow everywhere and new ice lakes!</li> 🎄 Ornaments on trees!</li> 🎅 Christmas hats!</li> 🎁 Unique seasonal items to find!</li> </ul> From all of us in the Veloren community, we wish you all a happy holidays, no matter what you're celebrating! </figure> Support the project</h3> As always, feel free to support the project on Open Collective. It allows us to keep our servers running, and launch great holiday parties like the one today! This Week In Veloren 151 Mon, 20 Dec 2021 00:00:00 +0000 This week we hear about how the appearance of characters can now be edited. We also hear about changes to how armor tooltips are displayed. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @UncomfySilence, @Christof, @flo, @XVar, @ubruntu, @tygyh, @Slipped, @Snowram, @IsseW, @Sam, @xMAC94x, and @EvenMeek! Editing Characters by @DrDystopia</h3> I've made it possible to edit the appearance of characters after they've been created. The reason for this was many players have asked for the ability to change their characters without having to make a new character from scratch. During the process, I was helped a lot by @zesterer and @Isse. Their greater understanding was essential to finish this feature. To add this feature I had to apply a persistency state so that players wouldn't lose their ability, weapon, and item info when changing the appearance of their characters. For the screen used to edit the character, we used a stripped-down version of the original character creator as a base. In doing so we had to disable the starting weapon, gender, and race choices. The character's inventory and equipment are not affected by this change and during the editing, the current equipment is shown. Other than some delays because people were busy with other features and life in general, everything worked smoothly and efficiently. Devblog Recap by @Dalyc</h3> Be sure to check out last week's devblog recap by @Dalyc if you missed it! </iframe> </div> </figure>Armor tooltips by @Ubruntu and @James</h3> @Ubruntu worked on item tooltips so that armors don't show stats that have a value of 0. This makes armor tooltips more compact and their stat benefits more immediately apparent. New armor stats can now be added in the future without worrying about excessive clutter to tooltips on unrelated armors. @James made armor stats optional as far as the code is concerned which will allow us to add more armor stats without having to add zero values to a bunch of armor pieces that wouldn't have a given stat. Hanging out with a mammoth. See you next week! </figcaption> </figure> This Week In Veloren 150 Mon, 13 Dec 2021 00:00:00 +0000 This week, it's the 150th Veloren blog! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @a1phyr, @zesterer, @tygyh, @Sam, @James, @holychowders, @xMAC94x, and @EvenMeek! 150 Devblogs by @AngelOnFira</h3> It's that time again; a large milestone in the number of blog posts we've released! Every 50 editions tend to be close enough to a year that it can act as a recap for everything that happened in the previous year. This milestone doesn't feel nearly as momentous as the 50th edition, however, there are new achievements that are being reached. For example, we finally had a release party that broke out of the loop of "server crashing during release party under the player load". We've also reached amazingly high numbers of players on the server not during a release party, which was around 90 people. We've also completed phenomenal systems that players can interact with what we've aspired to have since starting development of the game. 10,000 commits, 10,000 members on our Discord server, 9,000 members on the subreddit, and the 7th most starred project on GitLab. There's a lot we have going on! Normally, I use every 50th blog post to write something much larger, but I didn't have a lot of time to prepare something this week. Hopefully, we can see something large for the end of the year post. See you at episode 200 for the next TWiV milestone! Devblog Recap by @Dalyc</h3> Be sure to check out last week's devblog recap by @Dalyc if you missed it! </iframe> </div> </figure> A peaceful city on the water. See you next week! </figcaption> </figure> This Week In Veloren 149 Mon, 06 Dec 2021 00:00:00 +0000 This week, we hear about the plans for the upcoming Christmas holiday week. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @tygyh, @Sam, @zesterer, and @imbris! This week has been slower for developers as we approach the Christmas season. However, we have something special planned for that this year! Be sure to check out last week's devblog recap by @Dalyc if you missed it! </iframe> </div> </figure>Christmas week by @AngelOnFira</h3> From the 20th to the 30th of December, we are going to be running our first holiday event! Not only that, but on the 25th, on Christmas Day, we'll be hosting a Christmas party for anyone who wants to join! We've been working on a system to add a feature flag that we can toggle when the event starts, and this will allow us to completely change out how parts of worldgen and assets are loaded. We have some pretty exciting stuff planned! </figure> The main features we're going for are all about winter. We've got way more snow, decorations on trees, and even ice on lakes! Lots of Christmas elves (developers and artists) are working hard on this right now to get more assets and themed features into the game. Here are some other ideas that have been thrown around: Blue cheese</li> Guards with Christmas colored lanterns</li> Snowmen that spawn</li> Snowshoes to help players move better in the snow</li> Sleighs and reindeer</li> </ul> Note; these ideas aren't final, and we don't know if we can get all of them in before the holiday week starts. If you've wanted to contribute something small, maybe now is the time! We've created a branch and dev channel for the work on this event. Message me on Discord if you want to be added to that. Also! This holiday event is the first one we have planned, but we want to work on adding more holidays from more cultures! If you have something you celebrate, reach out so we can figure out how we can make it happen! Out on a cold winters night. See you next week! </figcaption> </figure> This Week In Veloren 148 Mon, 29 Nov 2021 00:00:00 +0000 This week, we have a new episode of the Veloren Reading Club out. We also see some experiments with the new site system, and current work on ability selection. @Dalyc is also back with another devblog recap! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @XVar, @aweinstock, @xMAC94x, @tygyh, @imbris, @Treeco, @Capucho, @Sam, and @James! Veloren is running an Advent of Code</a> leaderboard! Advent of Code is a programming challenge that takes place in the first 25 days of December every year. Every day at 00:00 EST, a new challenge is released. If you want to join the Veloren leaderboard, stop by the ##advent-of-code</code> channel on Discord to get the code! This week, @Pfau and @Sam have been working on adding ability selection. </figure> There have also been ongoing experiments with the new site system, which has been attracting a lot of attention since the first Veloren Reading Club. Below, we can see some trials done by @James. </figure> Dev(v)log Recap with @Dalyc</h3> @Dalyc is back with another TWiV recap! </iframe> </div> </figure>Veloren Reading Club #2: Spots and Worldgen Layers</h3> If you missed it, we ran another Veloren Reading Club last week! In this one, we explore how the spots system works to place things around the world, and how the layers of worldgen are set up. </iframe> </div> </figure> A sea chapel in a peculiar spot. See you next week! </figcaption> </figure> This Week In Veloren 147 Mon, 22 Nov 2021 00:00:00 +0000 This week, we hear about changes being made to dungeon difficulty. We also dive into how skill persistence is being changed. Finally, we learn about some proposed changes to the Site2 system, and the addition of giant mushrooms! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @xMAC94x, @Sam, @IsseW, @UncomfySilence, @Treeco, @zesterer, @Kemper, @Pfau, and @Limofeus! Did you miss last week's blog? No worries, @Dalyc recorded an overview of everything you need to know! </iframe> </div> </figure>Dungeon difficulty by @UncomfySilence</h3> I made some alterations to the dungeon mobs and loot tables to allow the dungeon difficulty to scale a bit better until T6 (cultist dungeon). Previously, players would be able to rush through dungeons T1-T5 even without much experience. Once they reached T6 the insanely powerful cultists would make anything and everything painful, primarily due to their humanoid AI. To accommodate for this I varied and increased mobs skills based on tier, and gave them other stats to their armor (although slightly sacrificing their overall defense). Gnarling armor count - 7 previous being 7</li> Adlet-bow armor count - 39 previous being 62</li> Sahagin armor count - 71 previous being 88</li> Haniwa armor count - 96 previous being 91</li> Myrmidon armor count - 152 previous being 161</li> </ul> Furthermore, all bosses ranging from T0 to T3 drop equipment one tier higher than their code gear, i.e. T0 drops T1 gear. (In-game T3s now drop T3 loot and so on). All these factors should force players, particularly inexperienced players, into joining groups. It should also add more grind time to "complete" the game as newer players would be inclined to "over level" their characters to effectively complete the next tier. </figure> Skill persistence overhaul by @Sam</h3> I've recently worked on an overhaul of the way that we persist skills, to allow it to be more flexible to both future balance changes and future changes to skills. The first change I made is that we no longer store how many skill points you have, instead, we store the total amount of experience that you have earned. In the future, this will allow us to adjust the amount of experience required to earn skill points, and have your number of skill points automatically adjust to account for it. The migration to convert does require (ab)using bit shifting to emulate an exponential function (which SQLite does not have as a supported function). However, so far some skill points there may be a slight error in conversion, but it should always be less than 100 exp. The second change is that rather than storing skills in a separate table from skill groups, skills are now stored as an array in the table with skill groups. In making this change, we will now also no longer need a conversion function from each skill to a string and back again, instead, we are just serializing the vec</code> of skills directly, and handling the case of failing to serialize or deserialize safely by invalidating your skills in that skill group (more on this in a lower section). </figure> Because of how we handle the failure case, this also allows us to no longer need a migration when we change skills. This change was made so that we can verify that the skills you have can still be acquired. For example, if we made changes to which skills are a prerequisite for other skills, this will correctly not let you have skills if you don't have the new prerequisite. It also can handle the case of changing the skill point cost required to unlock a particular skill, where it will not give you the skill if we increased the cost of skill points and you didn't have excess. The third change is that we now store a hash with each skill group. This hash is currently defined from the skills available to unlock in a particular skill group, as well as their max level. We persist the hash from when your skills were last persisted, and then next time you log in compare that persisted hash to a newly calculated hash, and if the two differ we invalidate your skills in that particular skill group. </figure> Now for the largest benefit of this skill persistence overhaul; the ability to automatically invalidate your skills. What this means is that when you load into the game, any skills you had in the skill group are cleared, and you have the ability to respec your skill points in that skill group as you wish. Further, this respec only occurs within the skill tree that was invalidated (unless it has skills that other skill trees depend on, e.g. how all of the weapon skill trees depend on the general skill tree). For the most part, this respec will be triggered when we make any balance changes to skill trees both as a precaution to ensure that it is still possible to reach your current skillset with the experience you have and the order you acquired skills in, and as a way to allow you to potentially respec with the changing opportunity cost of any balance changes we make. If we change the amount of experience required per skill point, the skill points required to unlock a skill, what skills are in a skill group, the max level of the skills in the skill group, or the prerequisites required to unlock a particular skill, it should trigger a respec. When this change hits master, don't be surprised to see all your skill points refunded, as it was a necessary measure to take to ensure that stuff is properly migrated to the new format. </figure> Site2 work and giant mushrooms by @floppy</h3> Recently, @floppy has been making some test modifications to the site2 system. These aren't the final form and are being reviewed by the worldgen team. @floppy has modified the spot structure to scale with plot size and prepared offsets and options that allow generating variations of the structure. The variations from plot size alone are quite plentiful with only the larger shrooms generating the carved-out home. Variations could be extended and tweaked after testing in the actual spot environment and connecting RNG. @floppy has also been working on creating giant mushrooms. Here are the current variations/options: 2 Color Schemes</li> offsets to "grow" structure differently</li> dents for more organic appearance</li> carved home</li> water puddle at the bottom</li> smaller side-mushroom</li> broken window</li> outside pool from decomposing shroom-top</li> </ul> In the video</a>, all options are enabled giving all larger shrooms interior, water-puddle, side-shroom etc. A postcard to send home! See you next week! </figcaption> </figure> This Week In Veloren 146 Mon, 15 Nov 2021 00:00:00 +0000 This week, we see some videos of the new dynamic weather. We also hear about how the new EXP sharing system works. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Sam, @Oolnokk, @zesterer, @XVar, @Slipped, @imbris, @UncomfySilence, and @Socksonme! @Pfau is working on a new outfit for our merchants </figure> </iframe> </div> Veloren ran its first Code Reading Club! </figcaption> </figure>Dynamic weather by @zesterer and @Isse</h3> This week, @zesterer and @Isse worked on dynamic weather. Time for some rainy weather! </iframe> </div> </figure> </iframe> </div> </figure>EXP sharing by @XVar</h3> This week I implemented EXP sharing</a>, which replaces the previous behaviour of the entity (NPC or player) that deals the final blow getting 100% of the EXP for a kill. This mechanic encouraged EXP stealing and didn't fairly reward players when multiple players or groups contributed to a kill. EXP on kill is now shared between damage contributors. A "damage contributor" is either an individual entity, or a group - depending if the attacker is in a group. This means that not only does the "killing blow" no longer get 100% of EXP, but multiple groups and individuals all receive their fair share of EXP on death (assuming they are still within range of the entity when it dies). The diagram below shows a scenario where two groups of players and a solo player contributed damage to an NPC that was killed. As you can see, the EXP is split based on damage contribution but once it reaches a group the EXP is split evenly to members within the group regardless of their individual damage contribution. This ensures that all players within a group, even those playing a support/healer role get their fair share of their group's EXP even though they contributed less damage. </figure> Damage from a given individual or group only counts towards a kill for 10 minutes since that individual or group's last damage to the entity - after this period their damage contribution is removed. This avoids the list of damage contributors growing excessively large for an entity that does a lot of combat but never dies. The Damage Contribution calculations implemented for this feature are also planned to serve as the basis for further enhancements to team play and anti-griefing measures - for example loot distribution may use the same calculation to decide which player or group gets a drop. This Week In Veloren 145 Mon, 08 Nov 2021 00:00:00 +0000 This week, we hear about some changes to the textures of dropped items. We also see into how some concept art for larger cities in Veloren is being created. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Demonic, @Sam, @UncomfySilence, @jon18, and @XVar! New textures of item drops by @Socksonme</h3> I've recently touched up some of the textures for item drops. Instead of having the default be BeastMeat</code>, which isn't really that general, it's now Pouch</code>. I've also changed BipedLarge</code> to use Pouch</code>, much like how BipedSmall</code> does, and Object</code> (for example, the turrets in tier 6 dungeons) now drops Chest</code> instead of BeastMeat</code>. We'd eventually want to change how the item drop textures are chosen, but as of now, they are based on the Body</code> type of the entity, rather than the actual items themselves. </figure> </figure> </figure> City concepts by @Hannibal</h3> Editor's note; for clarity, this section is done entirely in MagicaVoxel, and doesn't represent changes to the proc gen of current villages. </blockquote> I am currently developing the concept art architecture of different biomes and races for future villages, cities, and towns. I do mockups on MagicaVoxel to show how potential biome sites could look. So far I have done one variant of desert biome rework and I am planning for the next few months to design the architecture of: Humans in plains</li> Elves</li> Danari</li> Orcs</li> </ul> This should take me quite some time but will be a massive advancement in terms of concept art for how Veloren architecture could look. Model imported into Veloren </figcaption> </figure> The desert city mockup I made was imported on a Veloren test server in October to see how it would look and to see if the scale was right and it helped me see what could be improved in terms of design and layering. The biggest changes in the next mockups will include: More variants of houses and assets in general</li> More structures and pathed areas</li> Better polishing of the smaller assets</li> </ul> Of course, we are a long way from having actual cities in the game but I do think it's important to start designing concepts now so we know what to aim for in the long term. A small teaser of the Human Plain Architecture: </figure> </figure> This Week In Veloren 144 Mon, 01 Nov 2021 00:00:00 +0000 Hats were merged this week, and the server hosting section of The Book was updated. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Slipped, @Oolnokk, @Sam, @Evelyn, @xMAC94x, @juliancoffee, @tijnvdheuvel, @Pfau, @IsseW, @Kemper, and @Demonic! This week, @LunarEclipse finished a major rewrite of the server hosting section of The Book. Hats were also merged! Check out the images below: </figure> </figure> That's all we have for this week! See you next week! </figcaption> </figure> This Week In Veloren 143 Mon, 25 Oct 2021 00:00:00 +0000 This week, we hear about improvements that are being made to the stealth system. Worldgen is also getting some work done. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @IsseW, @Demonic, @zesterer, @Slipped, @Kemper, @AngelOnFira, @Snowram, @Qiu, @antoniomuso, @Sam, @ubruntu, @UncomfySilence, and @DoctorKompot! This week, we hit 10,000 members on our Discord server! Stealth by @ubruntu</h3> Since the last blog post, I added the stealth attribute to armors. It was sort of already there, but set to 0 on all armors. I basically added values for the craftable armors and added the logic to make the numbers correspond to stealth effectiveness. It can be understandably opaque what the associated number means exactly so I want to explain it a bit here. I'm hoping to convert it to a more understandable number like a percentage, and show more details with tooltip information about it in the future! Currently, the way stealth works is that your character is considered sneaking when they are crouched down, or rolling when previously crouched. Right now sneaking only affects the perception distances (both sight and hearing) in the agent system, meaning that sneaking characters must be closer to NPCs before they are detected. The stealth stat specifically affects the perception distances of NPCs, and here's how: With no increases to the stealth stat, sneaking cuts the perception distance in half.</li> Additional stealth from armor is added to the denominator of this fraction, so 1 / (2 + n)</code>, and this number is multiplied with the agent's perception distances. Reaching a percentage around 20-25% is probably enough to avoid most confrontations.</li> The stealth stat is currently intended to be the highest value on hide armors, half as much on cloth armors, and mail armors aren't intended to have stealth bonuses. I didn't add the stat to rings and necklaces because those were recently overhauled, but I'm not opposed to those having stealth bonuses as well.</li> </ul> A few other things to mention about stealth: All agents have the same perception distances and that might change.</li> Using a lantern does not affect stealth yet. Caves and dungeons may require more light sources before this changes.</li> I am by no means 'the stealth dev', so I won't prevent anyone from improving this fun game mechanic.</li> </ul> </figure> Worldgen by @Demonic</h3> This is my first blog post since I've returned to the project. I've been working on adding Spots, Sprites, Ships, and Shrubs, "Holy that's a lot of S's" to our current world generation system. I've been working with @zesterer to improve upon the current river world generation. He's teaching me about how a bit of the backend works. Newly added: Shrubs - Added to Jungles/Forests, Savannahs, Grasslands, and Taiga biomes.</li> </ul> Spots: Added Gnarling Tree - that can be found in jungles and forests.</li> Added Troll Cave - Spawns in Jungles, Forests, Grasslands, and Taiga biomes</li> Added Shipwreck - Spawns within lakes and coasts</li> </ul> Ships: Added Galleon class ship - spawns naturally or can be spawned by a Game Moderator (Drivable)</li> </ul> (WIP Un-merged) Sprites: Added Lilly pads and new Reeds to rivers and lakes.</li> Added new Ferns, Red Grass, and Flowers to Jungle, Forest, Grassland biomes</li> </ul> Massive thanks for most of the Assets contributed by @Gemu. Roaming in the wild. See you next week! </figcaption> </figure> This Week In Veloren 142 Mon, 18 Oct 2021 00:00:00 +0000 This week, we learn about some proposed changes to how Airshipper downloads updated assets. We also learn about some changes coming to jewelry. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @ubruntu, @xMAC94x, @nwildner, @Slipped, @UncomfySilence, @zesterer, @MHK.2012, @kaedr, @Socksonme, @KaliKatz, @Sharp, and @imbris! @zesterer reworked the aurora shaders (along with how lighting at night is handled). You can see the results below. You can read this week's meeting notes here</a>. </iframe> </div> </figure>Asset downloads by @Christof</h3> Motivated by the network speed issues with Airshipper, I recently made a proposal for incremental downloads of the game. See the discussion in this thread</a> for more details. Basically, this proposal will send the checksum of all the files to Airshipper which will download only missing and updated parts of the archive - using either individual file sub-archives or full directories as needed. These sub-archives can be generated from a complete archive, on the fly by a cheap server-side logic, and are fully cacheable. The assets are even identical across architectures. Also, I found that of the 200MB distribution file only 66MB are taken by the daily changing binaries, the rest is typically unchanged. Further investigation showed that the 66MB for veloren-server-cli.exe</code> and veloren-voxygen.exe</code> can shrink to 40MB by using a more efficient compression</a> (aka .lzma or .xz) instead of deflate</a> (aka .gz or zlib). Typically we might avoid this less portable compression method in zip files, if the archive was meant to be extracted by a different program than Airshipper. In Airshipper, we can bundle lzma-rs</a> to decompress this format (which is also supported by 7-Zip and newer WinZip versions). </figure> Sneaking by @ubruntu</h3> This week, I refactored character states a bit so that sneaking isn't its own distinct state in the CharacterState</code> enum, but rather it's an attribute of the "idle" state. The wielding and equipping states also got a stealth variety, and the end result is that players can pull out their weapons while sneaking. Shout out to @Slipped for doing all the animation work. Jewelry changes by @DoctorKompot</h3> Recently, I've been working on an update for jewelry. Existing rings are being reworked and some new necklaces are getting added. </figure> Legendary necklaces (yellow borders): Ankh of Life - Drops from mind flayer, an energy-based necklace</li> Carcanet of Wrath - Drops from minotaur, gives critical power</li> </ul> Epic necklaces (purple borders): Cultist Amulet - Drops from mind flayer, similar stats to the Cultist set, well balanced</li> Diamond Necklace - Craftable, similar stats to the ring, but stronger</li> Ruby Necklace - Craftable, similar stats to the ring, but stronger</li> Emerald Necklace - Craftable, similar stats to the ring, but stronger</li> </ul> Rare necklaces (blue borders): Fang Necklace - Craftable</li> Haniwa Talisman - Drops from T3 dungeon boss (Golems)</li> Honeycomb Pendant - Craftable</li> </ul> Uncommon necklaces (green borders): Sapphire, Amethyst, and Topaz Necklaces - Craftable, similar stats to the rings</li> Gold Necklace - drops, from sauroks, humanoids, and large cave monsters</li> Seashell - craftable</li> Gem of Resilience - (renamed from Gem of Lesser Protection) drops from T2 dungeon boss</li> </ul> Common necklaces (grey borders): Pendant of Protection (used to be named Plain Necklace) Drops from T1 dungeon</li> Low-Quality Necklace (basically starter item) Scratched necklace Drops from T0 dungeon</li> </ul> A serene morning. See you next week! </figcaption> </figure> This Week In Veloren 141 Mon, 11 Oct 2021 00:00:00 +0000 This week, we hear about a crafting overhaul and the new salvage functionality that will come with it. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @imbris, @juliancoffee, @Sam, @xMAC94x, @IsseW, @JTriantafylos, @Pfau, @antoniomuso, @ubruntu, @devrique, @GLawrence29, @Treeco, and @CapsizeGlimmer! This week, Veloren hit 10,000 commits! You can read this week's meeting notes here</a>. Several developers are participating in Hacktoberfest contributions to Veloren; make sure to read our blog post about it</a> if you want to also participate! Number of lines of code at this point </figcaption> </figure> @ubruntu added loot notifications for groups. When people are in a group, they receive notifications of what other members of the group pick up. People no longer have to ask "What did the boss drop?" or "What was in that chest?". @juliancoffee Fixed strange names for travelers, no more Orcs named Danari. Crafting updates by @Sam</h3> I've begun (and almost finished) making some tweaks to how crafting works in the backend. Crafting now works through an enum. For now, there will be two kinds of crafting: SimpleRecipe</code> (which works much the same as current crafting), and Salvage</code> (which is the dismantle recipe, but better). For SimpleRecipe</code>, rather than only sending over the recipe that the client is trying to craft, it now also sends over a vector of slots that the client wants to use to craft the recipe. In the future, this will aid in allowing a player to specify which item they want to use in a recipe where there are multiple valid inputs. This will be the case for modular weapons, which is one of the main motivations for me to do all this work. A potion is being brewed! </figcaption> </figure> Also, all dismantling recipes have been removed. Instead, they now go through the aforementioned Salvage</code>. This works by specifying a slot that the client wishes to salvage, and the server then checks if the item can be salvaged, returning the salvaged items if it could be. Salvaging will now also be done using a new crafting station, the Salvaging Station. @Pfau has made a model for this. @Snowram has also been working on getting the salvage output to be displayed in the tooltip of an item when you are at the salvaging station. Flight coming in at night. See you next week! </figcaption> </figure> This Week In Veloren 140 Mon, 04 Oct 2021 00:00:00 +0000 This week, we hear about some bugs that are in the game right now. We also explore some upcoming changes to the economic system. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @imbris, @Sam, @ubruntu, @a1phyr, @Yurimomo, @flo, @sylvain_m, and @Bafon! @zesterer got shrubs merged, so at last most existing water issues have been fixed and rivers should generally look better. Also, waterfalls! @ubruntu made a small change so that the interact key can be used on campfires. Right now it makes you sit at a campfire which activates the campfire healing aura. This opens up the possibility that campfires open a crafting menu in the future. @imbris created a credits screen so attribution for various art assets (especially the ones that require it) can be added. They also refactored resizing a bit making it no longer produce weird behavior or Vulkan validation errors when rapidly resizing. </iframe> </div> A timelapse by @fisik_yum </figcaption> </figure> Network speed issues by @AngelOnFira</h3> Of recent, we've been seeing a lot more people mention they have issues with downloading, connecting, or playing the game due to network issues. This week, I've been working on examining the cause of these issues more. A bandwidth test on the server </figcaption> </figure> First off, even for fast internet connections, people haven't been able to download updates on Airshipper at more than around 100Mbps. This issue could come from many places, including the server network, the server filesystem, the datacenter networking, the Airshipper client, or something more obscure. Server bandwidth recoded when a single client is updating. Peaks around 100Mbps. </figcaption> </figure> I examined some code on both the Airshipper client and server to track down where the key points of the download are happening. I didn't find anything that stood out right away, such as an artificial bandwidth limit hardcoded or anything. I then came up with some tests to rule out areas where the issue might be caused. I first launched a dozen or so Airshipper instances, and got each of them to update at once. You can see the network usage in the image below. Note; something is wrong with the metrics, since our server is capped at 1Gbps. </figure> However, with this graph, we can see that we are able to transmit far over the 100Mbps rate that clients are receiving. This was backed up by the fact that all of my Airshipper clients were able to download the updates in about the same amount of time as if it was just a single client downloading. This increased the probability of the problem being on Airshipper's client, however, I quickly ruled this out by trying to manually download the updates through my web browser. I was limited to the same speed, and Firefox can certainly download higher speeds. I then simulated the Airshipper server on my local machine. It uses Rocket under the hood, so @imbris gave me a hand looking around to see if it could cause any issues. Once I ran the tests, I did see that it allowed me to download files locally at greater-than-gigabit speeds. At this point, it seems that the client code is fine, the server code is fine, and the problem has to be in the network or the server's filesystem. I spend some time playing with how Docker access files from its filesystem. I'm not sure about this, but I think that if a volume is mounted into Docker, it is accessed differently than if it was built into the image. I tried running some tests on the server to see how it was able to access data from within the container vs on the filesystem. </figure> These tests aren't very accurate, but it does show us that it can write files inside and outside the Docker container at about the same speed. Next, generated a garbage file that was a gigabyte in size inside the server, and tried downloading it through HTTP, as the client would. The download was on the same host, and it was able to download at local speeds. After all of this, it seems the problem is around how fast a single stream can download data from Hetzner. I ended my investigations for the night at this point, and sent off an email to Hetzner to see if they could help. They didn't know of any immediate issues, and suggested running some diagnostics from their end. Going forward, there are still a few more tests I want to run. One is getting a generic file server to try and download a file from. I want to prove that we can't download any file from the server at more than 100Mbps. From there, I'll probably dive further into networking on the VM itself. Hopefully, we can see improvements to download speeds in the future. The lone airship. See you next week! </figcaption> </figure> Hacktoberfest 2021 Sun, 03 Oct 2021 00:00:00 +0000 Hacktoberfest 2021</h2> Veloren will be participating in Hacktoberfest 2021</a>! This will be an opportunity to get more developers started on the project, and help them along the way. Also, you get a cool t-shirt if you make 4 separate pull requests! What is Hacktoberfest?</h3> From the website: Hacktoberfest, in its 8th year, is a month-long celebration of open source software run by DigitalOcean. During the month of October, we invite you to join open-source software enthusiasts, beginners, and the developer community by contributing to open-source projects. You can do this in a variety of ways: Prepare and share your project for collaboration</li> Contribute to the betterment of a project via pull requests</li> Organize an event</li> Mentor others</li> Donate directly to open source projects</li> </ul> How do I get started?</h3> First of all, register on the Hacktoberfest website</a>. You'll need to sign up with GitLab (and GitHub as well if you like), since all pull requests are done through GitLab. Next, hop into our Discord Server</a>, and go to the #hacktoberfest channel. Here, you can ask for help to get started. We'll get you set up with contributing, and help you find an issue with the Hacktoberfest tag</a>. As you're working on it, core developers will be on hand to help you understand what you need. Feel free to ask for help! We hope that this will help new contributors get started on the project, and help improve their Rust skills. This Week In Veloren 139 Mon, 27 Sep 2021 00:00:00 +0000 This week, we hear about some bugs that are in the game right now. We also explore some upcoming changes to the economic system. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @juliancoffee, @Sam, @xMAC94x, @j4n3z, @imbris, @XVar, @Seth, @Bafon, @Capucho, @heydabop, @zesterer, @ubruntu, and @Slipped! @Saluki did a little bit of refactoring on some asset names so references should be a bit more logical. Bug searching by @Yuri and @zesterer</h3> Yuri has been working on searching for bugs. Here is a description of one bug, written by @zesterer: One of the mind flayers (let's call him Dave) reduced the maximum health of another (let's call her Susan). When Susan's AI code ran, she checked her health proportion to decide what strategy to use next. But the problem is that when the maximum health of an entity gets changed, it doesn't change the current health. So you had a situation where Susan's current health > her maximum health. If you calculate health as a proportion of the maximum, in that case, you end up with a number > 1. So the only thing that needs to happen is that her maximum health gets updated by Dave, and then on the next (or even the same) tick Susan runs her AI code. And Susan was using this >1 proportion as a probability, which is not valid (you can't have a probability > 1, or more than certain). </figure> New economic system by @Christof</h3> I have a working prototype of the new economic system in my side branch. This system is much more complex (e.g. compare the image below to older tech trees in devblog 114</a>), has reusable tools, building ground limiting city population, and works even in remote biomes. It prefers different house styles (tent, hut, wood, and stone house) and food types in different biomes. The next steps are: better balance between tiers (e.g. different gem/ore types) and making the economic situation more player visible in cities (clothing, housing, activities). </figure> This Week In Veloren 138 Mon, 20 Sep 2021 00:00:00 +0000 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</h2> 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</li> 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)</li> </ul> </figure> Hitboxes by @juliancoffee</h3> 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 </figcaption> </figure> 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 </figcaption> </figure> 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 </figcaption> </figure> 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. </figure> Tail hitbox </figcaption> </figure> 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 </figcaption> </figure> 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: </figure> Sausage boxes </figcaption> </figure> 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! </figcaption> </figure> Cursor Curmudgeons by @anomaluridae</h3> 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</h3> 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. Your browser does not support the video tag. </video> A sneak peak from @Snowram, @Slipped, and @Gemu. See you next week! </figcaption> </figure> This Week In Veloren 137 Mon, 13 Sep 2021 00:00:00 +0000 This week, we break down how the 0.11 release party went and examine server metrics. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Sam, @Capucho, @xMAC94x, @imbris, and @Pfau! This week, 0.11 was released! The release party was the largest yet, with 181 players on the server at once. You can read the blog post with the changelog here</a>. If you haven't already, check out the trailer: </iframe> </div> </figure> During the release party, some devs chatted about what new changes there were, as well as some more technical details about the launch. You can check that out here: </iframe> </div> </figure>Analyzing the release party by @AngelOnFira</h3> Images by @YuriMomo </blockquote> This release party was by far the best yet from the perspective of the infrastructure team. In previous releases, our server started having major issues as we reached our record player counts. There were also several issues we didn't see before having that many players online, such as deadlocks in players connecting, or having certain systems taking longer each tick, causing a snowball effect. With this release however, we did not experience any of these issues. The largest problem we found was that our entity sync system was taking too much time, since it hasn't been parallelized properly. But it didn't cause larger issues in the release party. Even with the 181 players, the server was still operating nominally! Server statistics over the release party </figcaption> </figure> We ran the release party on a 48 core compute server in a Hetzner datacenter. For the last release party</a>, we used a 32 core server. Throughout that party, we were still struggling under the load of several systems. It's hard to say how much this server helped improve the performance overall, but it clearly helped with several of the larger systems. </figure> In the image above, we can see that the heaviest systems are terrain and physics. Each tick is supposed to be around 33 milliseconds, which will create 30 ticks per second. Terrain is taking 523 ms, while physics is taking 252 ms. This is because they are combining work over all 48 cores to add to this time. </figure> Above, we get a larger breakdown of the "slow systems" that are taking up time on the main thread. We can see that times for the terrain and physics systems are quite small since they're parallelizing nicely. However, entity sync is much higher. We can also see that it becomes a larger problem later during the release party. This should be fixed before the next large server party. </figure> Above, we can see our bandwidth usage. At peak, we were transmitting around 40 megabytes per second. This is about a third of what the cloud server can offer with its gigabit internet, but we should expect it not to meet those limits, as cloud instances share the uplink with other VMs on the same host machine. Going forward, bandwidth is something we'll work on improving. This is both to take the load off the server, but make it easier for clients as well. Community videos</h3> </iframe> </div> </figure> </iframe> </div> </figure> Adventurers at the release party. See you next week! </figcaption> </figure> Veloren 0.11 Release Sat, 11 Sep 2021 00:00:00 +0000 0.11 Release</h2> Today, Veloren is releasing 0.11. This version is 3 months in the making, and we have a lot to show off! If you're reading this before 18:00 GMT today (September 11th)</a>, make sure to join the release party. To join, you can download the game for free at veloren.net</a> and create an account</a>, then launch the game and hop on the default server. See you there! </iframe> </div> </figure>Changelog</h3> Below are some of the key items from the release. You can check out the full changelog here</a>. A large emphasis in this version was making combat more dynamic all around the world. This comes in the form of the new spot system, as well as how NPCs and mobs can interact with the world. Read on to see what else is new! Added</h4> Added a skill tree for mining, which gains xp from mining ores and gems.</li> HUD debug info now displays current biome and site</li> Pets are now saved on logout 🐕 🦎 🐼</li> NPCs can now warn players before engaging in combat</li> Add server setting with PvE/PvP switch</li> Experimental terrain persistence</li> The 'spot' system, which generates smaller site-like structures and scenarios</li> Chestnut and cedar tree varieties</li> Shooting sprites, such as apples and hives, can knock them out of trees</li> Cultist raiders</li> Bloom Slider</li> </ul> Changed</h4> Harvester boss now has new abilities and AI</li> Death particles and SFX</li> Trades now consider if items can stack in full inventories.</li> The radius of the safe zone around the starting town has been doubled</li> </ul> Fixed</h4> Crafting Stations aren't exploadable anymore</li> Significantly improved the performance of playing sound effects</li> Campfires now despawn when underwater</li> Map will now zoom around the cursor's position and drag correctly</li> No more jittering while running down slopes with the glider out</li> Camera is now clipping a lot less</li> </ul> </figure> Updates from developers</h3> Now, let's hear from some of the developers about this version. @zesterer, Worldgen Lead and Core Developer</h4> I'm most excited about 0.11 because it finally starts to tie together some of the grander themes and plans that we've always had for the game: a sense of freedom, adventure, and place within a dynamic, open world without scripted events or hard-coded locations. You can see this vision beginning to materialise all across the game: the increasingly mature crafting system, world generation, real-time simulation such as cultist raids, etc. I'm sure that 0.12 will bring more of this vision in abundance. </figure> @Slipped, Animation Lead and Core Developer</h4> I think what I'm looking forward to most this version is for the world to feel more alive. We've added a ton of small-scale sites to the overworld where NPCs live and interact with the simulation. You can find occupied igloos, hideouts, and burrows. With new pickup animations and collectibles, the player is encouraged to take their time in the world and interact with it, or try to pass through stealthily. On a grand scale, the world has looked great for a while but we're starting to bring real excitement to it at small scales too, by allowing the player to make new discoveries all the time while exploring </figure> @Sam, Combat Lead and Core Developer</h4> What I like most about this version is that players must think more about what they need to do. Previously, players really only would rush the bosses in dungeons with maybe the occasional foray into a cave, and would "loot vacuum" everything that could be picked up that they encountered. Now players often delay going to the boss to first loot chests in the dungeons, or they may dedicate an expedition to harvesting flax for a set of linen armor instead of spamming the collect key as they passed by a field of flax. There are also now cultist raiders to provide a challenge on the surface, which will hopefully pave the way for more real-time simulation surface encounters where players can watch their actions have a meaningful effect on the world. </figure> @Snowram, Assets & Aesthetics Lead</h4> This release is a big step toward a dynamic world. With the inclusion of several new locations and some promising real-time simulation usage, this is the start of something big. I'm also very excited about the recent development of site which will eventually allow us to simply add more complex procedurally generated structure in the game. About myself, I have been away for quite a bit of time which made me miss the deadline for a new arthropod skeleton and its big batch of new species, so keep an eye for them in the next version! </figure> @Aweinstock, General Developer</h4> I ported dungeons from sampling to CSG (site2) between 0.10 and 0.11. This allowed adding details (like the septagonal stars and the pillar bases) more easily, and also sped up dungeon generation since the system no longer has to sample every block in the chunk, only blocks inside dungeon rooms. Keep an eye out for these new detail in the release! Your browser does not support the video tag. </video> Taken by @KaliKatz. Say cheese! </figcaption> </figure> Support the project</h3> As always, feel free to support the project on Open Collective. It allows us to keep our servers running, and launch great release parties like the one today! This Week In Veloren 136 Mon, 06 Sep 2021 00:00:00 +0000 - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Naryadchikov, @XVar, @xeriab, @Sam, @Slipped, @khalludi, @xMAC94x, @slashplusplus, @Sharp, @juliancoffee, @ubruntu, @Snowram, @knightresspaladin, @imbris, and @Capucho! @nomango hosted a gliding race from the town of Sist, in the highest mountain peak of the map, to the town of Irronk at the foot of the mountain. Organizing it was a fun experience, and in the end 5 people participated and a bunch more watched. The winner was @Boudin, congratulations! The race contestents </figcaption> </figure> Improvements by @juliancoffee</h3> I've recently been working on new server setting and command! battle_mode</code> setting Global(PvP/PvE) or PerPlayer(default: PvP/PvE)</li> /battlemode</code> command which allows you to switch between your battle mode (pvp and pve). Can be used once in 5 minutes, only in towns and only if server enabled PerPlayer() battle_mode</code> setting. Enabled on official server which means no more ganking of new players!</li> </ul> Balance changes</h4> Chests no longer spawn on the starting floor of dungeons (and more of them spawn in final floors). Chests now have equal chance of spawning between different dungeon levels. Developer experience changes</h4> VELOREN_ASSETS_OVERRIDE</code> environmental variable should help to run servers with modified assets (should be declared as on server machine and on client machines) and allows you to add folders with assets you want to have at a higher priority (while keeping every other assets the same).</li> Refactor of server and voxygen code that interacted with skills to make it easier to add new skills and modify existing ones. Main changes are the SKILL_MODIFIERS</code> constant which stores every constant used for skills in a more declarative way to specify skill icons in voxygen code.</li> </ul> </figure> Cultist Raiders by @Sam</h3> Cultist raiders have been added. Now, cultist raiding parties will periodically set out from cultist dungeons to raid nearby settlements for sacrifices. In adding them, the real-time simulation system needed to be slightly expanded to allow for rtsim entities being attached to a particular site as well as have the species, loadout, and alignment of the rtsim entity being specified instead of just entirely random. Naga by @Capucho</h3> Last week we merged the MR replacing shaderc</code> with naga</code>, but despite the MR only having one commit and a three week merge window, the work to make naga</code> capable of parsing all of Veloren's GLSL</code> shaders and emitting spir-v</code> took more than a year! The initial reasoning behind this switch was to make the lives of developers easier. shaderc</code> adds more requirements to the tools needed to compile Veloren and was a bit of nightmare when trying to cross-compile to macOS in CI. But after working with naga</code> and integrating into Veloren, there are some other benefits: Validation</h4> naga</code>, being part of the WebGPU pipeline means that it's exposed to potentially bad shaders that can cause issues with GPU drivers and potentially bring them down. A validation layer is added that rejects shaders that can cause this bad behavior. In Veloren, this is very helpful since bad shaders can go unnoticed on developers' machine and produce bad results for end users or affect performance. In particular, uniformity analysis has caught a handful of errors with texture sampling that can cause undefined behavior. Error messages</h4> The error infrastructure of naga</code> allows easy coupling with error reporting crates like codespan</code>. This allows for Rust-like error reporting, but this is an area that needs more work for example hints. </figure> So far everything has behaved extremely well, though there are some people reporting black worlds when using high lightning settings. The cause hasn't yet been identified and for most users has been working correctly. If you do see a black world go to the graphics settings and change lightning to type L - Cheap</code>. The glsl</code> frontend despite being in a pretty good state is still far from being completed. I intend to support some of the more popular extensions to the language, for example include directives that are for now being handled by glsl_include</code>. There's also the question of optimizations that are for now delegated to the driver, but in the future may also happen in naga</code>. I really enjoyed working in naga</code> and with the people building it (special thanks to @kvark for reviewing and helping out in my contributions). I've worked on some other things besides glsl</code>, most recently the spir-v</code> frontend so that in the future we can migrate to wgpu</code> 0.10 </figure> Assignment problem by @Christof</h3> This week, I've been working on solving the Assignment Problem</a> for Veloren. Simulating economies is not that hard to understand; you start with a bunch of resources, define a goal (e.g. population growth) and then steer the population to create secondary/tertiary/... goods to fulfill this goal. The above-mentioned "assignment" is the answer to the question "how many farmers/hunters/guards/... do I need to achieve that goal?" (or more generic: "How to assign NPCs to professions?") The previous solution in Veloren was to assign according to the relative surplus per produced good (called value). This worked just fine for non-merchants, as merchants trade but don’t produce goods, thus there is an upper limit in available goods. At some point employing more and more merchants won’t give you more of that rare good you desperately look for. Also this was just a relative assignment, you could not plan how long each person would need to work to produce the needed amount of goods. On top of this, I recently added more complications to the system: People use some tools for their work, thus these tools are needed but not consumed. Also I wanted coal and animal dung to potentially replace wood as fuel, introducing another tricky logic puzzle. </figure> So I came up with the plan to define an error function and simply minimize the quadratic sum. This sent me on a path where I learned a lot of numerical algorithms I never took a closer look at before. A mathematician friend was my guide on this journey. Once the pieces come together the solution is easy and robust; just use a matrix to calculate the necessary change in assignment from the difference to your target in produced goods. If you also want to take stock fill into account, just apply a nonlinear mapping of the difference to the target before applying this matrix. This is similar to the Gauss Newton algorithm and its generalization for not directly invertible matrices, the Levenberg-Marquardt algorithm. These use a matrix derivative of the error function and invert it to compute the next step. Luckily you can phrase the equation differently; you need the difference in input which causes a change in output. Basically, the derivative of the input to the output (the inverse of the normal derivative). And this matrix is easy to write down by hand; how many people do you need to add of each profession (recursively) for an increase of one - per good. This easy to understand concept is the true meaning of the three multiplied matrices (JTJ)^-1JT</code> in the Gauss Newton algorithm. On this journey I also tried pseudo-inversion of matrices - a mathematical concept which defines sort of invertability for non-quadratic matrices. This pseudo inverse is typically computed by using an SVD algorithm and gives the result of the three matrix multiplication with less numerical error. Unfortunately this matrix also resulted in negative numbers - stealing raw materials from other professions instead of pushing them through the whole supply chain. And in simulation this quickly caused a general shortage of people producing important stuff. To get the new system ready I still have to complete the planning of merchants and the correct mapping of in game items to economic goods. Also I would like to modify the type of buildings, the loadout and the behaviour of the town dwellers according to the economic situation of the town. A cave to explore </figcaption> </figure> This Week In Veloren 135 Mon, 30 Aug 2021 00:00:00 +0000 This week, we see some changes to how sprite collections work. We also hear about some improvements to how admins can control loot tables on their servers. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Sam, @Pfau, and @Gemu! @XVar I added a new settings pane to Airshipper to allow easy changing of the WGPU rendering mode, the game client log level, and also a button to open the logs directory. Airshipper 0.6 has now been released</a>! @Capucho finished up work to get naga merged. Expect a write-up on this next week. You can read this week's meeting notes here</a>. </figure> Sprite Collection by @Sam</h3> Last week, I did some work on how sprite collections work: Added a character state for sprite collection to go through</li> Made attacks interrupt the character state</li> Required that there is a valid path between the sprite and the entity collecting the sprite</li> </ul> For the character state, this now means that there is an animation that occurs when you go to pick up a sprite. @Slipped created the animations for this. There is a short animation for things that can be quickly picked up such as twigs and stones, and a longer animation for things that take longer to collect the item from such as chests. This will eventually allow us to start adding better loot to dungeon chests as you will actually have to defeat the enemies (or sneak past I suppose) before looting the chest, as otherwise, they will interrupt you in the process of looting a chest. For requiring that a valid path exists, this means that you will no longer be able to pick up bowls, potions, vials, and other such items through house walls. You'll now actually have to enter a villager's residence to thieve their items. It will also allow the spot system @zesterer is working on to position loot in interesting places that can't be grabbed without first accessing the sprite. </figure> Loot tables by @Ubruntu</h3> I added a new variant to the LootSpec</code> enum: None</code>. For context, server admins can already control what loot is dropped by using .ron</code> files in the assets/common/loot_tables</code> folder. At the simplest level, these files can contain an array of tuples specifying an item that can drop and its associated chance. It's a bit more powerful than that though, because the "item" part of the tuple can refer to an individual item, a stackable item with a range of possible quantities, or even another loot table. These are the different variants specified in the LootSpec</code> enum. The new variant I added allows for more fine-grained control of loot drops by allowing the .ron</code> files to specify with the existing lottery mechanic whether or not any loot is dropped at all. This will give server owners and game designers more control over item progression and player economy on their servers. The file assets/common/loot_tables/nothing.ron</code> provides an example of specifying a loot table where no items are dropped. A long flight. See you next week! </figcaption> </figure> This Week In Veloren 134 Mon, 23 Aug 2021 00:00:00 +0000 This week, we see the plans for the 0.11 release. RTSim sees some optimizations, and we examine the situation with CI runners. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @XVar, @Sam, @imbris, @ubruntu, and @flo. @XVar added a small utility cargo cmd-doc-gen</code> that auto-generates documentation of the in-game commands for the book: https://book.veloren.net/players/commands.html</a>. You can read this week's meeting notes here</a>. 0.11 Release Prep by @xMAC94x</h3> The 0.11 release will be on Saturday, 2021-09-11, at 18:00 GMT. As usual, there will be a feature freeze starting from 2021-09-04 18:00 GMT. We recommend submitting critical and large MRs for review now, before the feature freeze. This release will also have a stress test event between the feature freeze and the release. We will be sharing further details of this later. Getting your large MR merged before feature freeze Please mention @xMAC94x in the #ReleaseMRs_0.11</code> thread (in programmers) with a short summary with the following details (the more, the better): - What is complete - What needs to be done - Can your feature be partially introduced to master in its current state (as multiple MRs)? - Do you foresee any issues with your MR and if so, which ones? - Why should this feature be in 0.11? </code></pre> This is required to align our testing and review strategies to ensure a smooth release. 2021-09-04 18:00:00 GMT Feature freeze — No new feature MRs will be merged. 2021-09-06 18:00:00 GMT Stress test event. 2021-09-10 10:00:00 GMT Total freeze — no new merges will be introduced unless they're critical. 2021-09-10 16:00:00 GMT Release build will be compiled. 2021-09-11 12:00:00 GMT Main server hardware upgrade. 2021-09-11 18:00:00 GMT Release party! </code></pre> </figure> RTSim optimizations by @ubruntu</h3> I started working on making RTSim entities update in smaller groups because I saw a TODO comment in the code and got nerd sniped into trying to find a solution. The idea is that there are NPC entities that only exist when they are in a chunk that is loaded and in view of a player, and there are also RTSim entities that continue to simulate behavior when they are far away from players in unloaded chunks. Originally, every RTSim entity was being simulated during every tick, and that didn't have to be the case. It's easier to tell something to move 10 feet once than to tell it 5 times to move 2 feet, which means during each tick we don't have to tell as many entities to update their position. The trade-off is that the precision of movement for simulated entities can suffer when too much time elapses between their updates, so they could for example run past the town they were trying to reach. RTSim entities that are unloaded will update once every 30 server ticks, which I believe is slightly more than once per second. RTSim entities that are loaded in view of players are still updated every server tick so their pathfinding and general behavior shouldn't look noticeably different to players. In order to keep loaded and unloaded entities in sync we need to store the time (as an f64) that the entity was last updated, and use that to calculate the delta time which is then needed to calculate simulated travel speed. I'm satisfied with the solution because it takes advantage of the monotonically increasing tick number that was already there and some iterator methods found in the standard library. No new dependencies were needed and relatively few lines of code were added to achieve some performance gains. Thanks to @zesterer and @xMAC94x for helping me understand RTSim and timing-related things that the solution needed to take into account. RTSim tick performance before the change on the left, and after the change on the right (the server was also busier). </figcaption> </figure> Fixing Veloren's CI Runner Shortage by @XVar</h3> This writeup was originally created as a document for the Meta team to look into. </blockquote> Introduction</h4> Recently, Veloren has been suffering from both a lack of available GitLab CI runners, and quite often even when a runner is available, it has insufficient resources and may fail jobs due to the child processes of the build being OOM-killed by the host OS kernel. As of the time of writing, we have only 3 CI runners (+1 dedicated MacOS runner). This document aims to determine what the baseline resource requirements for a Veloren CI runner should be, and to propose a route forwards. Performance Benchmarking</h4> In order to determine the effect that different numbers of CPU cores and available RAM have on build times, a VMWare virtual machine was used to run three different build jobs from the master branch. The host machine used has an AMD Ryzen 3900X and 32GB RAM. The numbers presented below will be affected by the single-threaded performance of the host machine of a given runner so not much meaning should be taken from the absolute values, but rather the relative difference between different resource configurations. </figure> The first line in the table represents the base-line performance for a high-spec machine with a large amount of memory. With 16GB available, swap was not used at all during any of the builds in this configuration. </blockquote> CPU Cores</h5> Adding additional CPU cores appears to have diminishing returns for numbers greater than 8, however when less than 4 cores are available, performance takes a significant hit with the unittests job taking almost twice as long when the number of cores were reduced from 4 to 2. As is to be expected, further reducing the number of cores from 2 to 1 results in a 50% increase in duration for the code-quality job and a 100% increase in duration for the unittests job. Memory</h5> The RAM requirements for a runner vary based on the particular job, with those that don’t involve linking executables requiring much less RAM. The code-quality and unittests jobs use around 2GB of RAM and only really suffered when physical memory was reduced to 1GB which meant the half of the memory for the job was provided by swap. The opt-linux job however requires a significant amount of memory - around 11GB at peak. Attempting to run the job with less than 12GB available memory (physical+swap) results in the runner jobs being OOM-killed by the kernel, and the build failing. As is to be expected, additional available memory above the amount required for a given job does nothing to improve performance since the excess memory remains unused. Security and role separation of runners</h5> MR 2537 was merged on 20/08/2021 that introduces more granular runner tags to the Veloren CI configuration. One of the primary motivations for this work was to allow us to use runners provided by 3rd parties and contributors without this being a security risk. For example, a rogue runner that is tasked with executing the job that publishes artifacts for distribution via AirShipper could in theory modify the binary before it’s uploaded back to GitLab to include malicious code (a supply-chain attack). With this change in, we can freely accept runners from anyone who wishes to provide them even if they aren’t personally known by anyone on the project. </figure> Recommendation</h4> Minimum runner specification</h5> Given the above results, it is clear that the resource requirements for a runner differ based on the job being run. Therefore there are two different minimum requirements proposed, depending on whether the runner is configured with just the check tag or also with the build tag. </figure> While a minimum physical amount of RAM is listed, it is ideal for the total amount of required memory to be available to avoid using swap at all. Despite the fact that less than 4 cores would work for a runner, having runners with any fewer causes unnecessary delays for CI jobs and inconvenience for developers. If any of our current CI runners have less than 4 cores available, they should be considered for retirement should we meet our target number of runners in each category. Target runner quantity</h5> We should aim to have at least 8 CI runners of the above specification available to ensure prompt processing of CI jobs, with at least 4 with the build tag and at least 2 of those being trusted to process publish jobs. There is no need for an upper limit on runners, the more we have the more contingency we have against runners being retired. Next Actions</h5> If there is agreement on the above, we should advertise that we need runners, perhaps with a ping to @DevPingSquad or @Contributor and a section in the blog until we have enough. If we have any unused resource available on our server infrastructure, we might consider hosting runners on it since the CPU/memory is otherwise sitting idle. Since this writeup was created, @AngelOnFira has added 10 runners worth of compute, and @Sam has added 2. This resolves the situation for the time being. </blockquote> An early morning glide. See you next week! </figcaption> </figure> This Week In Veloren 133 Mon, 16 Aug 2021 00:00:00 +0000 This week, we hear about updates to the state of terrain persistence. There are also optimizations being worked on with our real-time simulation system. A brief overview of our server history is also included. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @alykhouzov, @ygor.souza, @Sam, @juliancoffee, @imbris, @zesterer, @DanTheOne, @DaniilNemtsev, @xMAC94x, @nwildner, @xeriab, @tygyh, and @klipkonn. You can read this week's meeting notes here</a>. </figure> RTSim optimizations by @ubruntu</h3> This is still a work in progress, but last week I worked on splitting up the iteration of RTSim entities so that each entity is updated every n ticks (whatever that number ends up being). Hopefully, this improves performance a little as RTSim entities don't need their simulated behavior to happen every server tick when they are off-screen and away from players. This shouldn't cause any noticeable changes for players. Terrain persistence by @zesterer</h3> Last week, the min_persistent_world</code> branch was merged. It adds an experimental terrain persistence system. When enabled, changes made to the world with build mode will be written to disk and will not disappear on server restart or chunk unload. It comes with some very big caveats: the system is not intended to be a player-facing or a general-purpose build system. It is not stable, well-integrated into the rest of the game, nor do we guarantee support for it moving forwards. Additionally, it is intended to be replaced entirely in the future (with no migration) with a proper player-oriented zone-based building system. Things can and will break! It exists primarily as a way for server admins to add small customisation to their worlds to improve the experience for players. </figure> See this page</a> in The Book for more detailed information about terrain persistence. Here are a few ideas for things that server admins could use the feature for: Gliding courses demarcated with pillars and hoops for glider racing.</li> A custom spawn zone complete with crafting stations and meeting areas for players.</li> Mining challenges (using mineable blocks like WeakRock and ores) that players can partake in. Because mining is not persisted, any mined blocks will naturally regenerate when the chunk reloads!</li> Custom mazes and climbing/jumping challenges for players with rewards in the form of chests/ores/etc.</li> Pixel artwork and sculptures dotted around the world for players to find.</li> Visual customisations to existing world structures like towns and dungeons that make them more interesting to explore.</li> </ul> If you end up making something interesting with the feature, please tell us! We'd like to see what you come up with. Feedback is also appreciated, although bear in mind that the feature is not supposed to be extensive or player-facing. A brief history of our servers by @AngelOnFira</h3> The following was taken from a thread on the Bevy Discord about server costs. Just happened across this thread, and although I don't know the entire context, I can give some interesting stats from Veloren. We used to host our main game server out of the basement of one of our devs. But when we had release parties, we would expect around 50 players to join. At the time, we were used to around 1 MB/s of bandwidth per player, and so over a release party, we normally saw around 100 GB of bandwidth used. We were hosting on Digital Ocean and AWS. Over the last few months, we've been transferring all of our servers over to Hetzner in Germany. Their bandwidth costs are pretty great for cloud servers, 20 TB/month for any instance, and about 1.20 Euros for every Terabyte after. It is still difficult to do NA game servers though. But for distributing our game binary and assets, it works quite well. A rough estimate from our dashboard</a> shows that we get about 700 downloads per day, and our download size is around 160 MB. So that's about 110 GB of download bandwidth per day. We are running this on a dedicated server Hetzner server though, which has no bandwidth cap. Your browser does not support the video tag. </video> Groovin with the gang. See you next week! </figcaption> </figure> This Week In Veloren 132 Mon, 09 Aug 2021 00:00:00 +0000 This week, we have several writeups from devs. We hear about the status of modular weapons, some physics improvements, and camera clipping. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @juliancoffee, @Sam, @Snowram, @pacmanmati, @Treeco, @lboklin, @Xeriab, @XVar, @ubruntu, @imbris, @Capucho, @zesterer, @UMR1352, @yusdacra, @KnightressPaladin, and @ygor.souoza! The Rust Gamedev Newsletter</a> is out! You can read this week's meeting minutes here</a>. @Christof is thinking about introducing Levenberg-Marquardt to the profession re-assignment in econsim and seeing the difference in correctness. This clearly calls out for a writeup, but he is still working on it. There will be a long form post once it's further along. Work by @ubruntu</h3> I tweaked the formula that sets how much experience is required to level up in a skill tree. The result is that lower-level characters will gain levels a little faster, while some higher levels take a bit more, but the maximum amount of experience required to level up is still capped at the same value (1000). I felt this was necessary because some recent gameplay videos showed new characters grinding for quite a while before earning their first skill point. </figure> Modular weapon status by @Sam</h3> Modular weapons are in progress. Not all of this has been done in the past week, I've just been lazy about throwing any updates about modular weapons into the blog at all until now. All crafting mechanics work as desired</li> Modular weapons will now automatically resolve their quality and handedness from their components (they previously only resolved their stats)</li> All modular components have been added as items (they still need models)</li> Names are programmatically generated from the shape of components used and the material used to make the components</li> Wood models and sprites were added for 6 new types of wood that will be used in making bows, staffs, and sceptres</li> Fixed loading of persisted items to properly handle items that had more than one layer of components (and now it supports an arbitrary layer of component nesting)</li> Changed specification of models for weapons both in the inventory and equipped in the hand to work for modular weapons</li> Added ability for modular weapons to be randomly generated given a toolkind, material, and handedness to allow them to be dropped as loot, given to enemies, and offered as stock in a merchant</li> </ul> </figure> Things that still need to be done before merging: Migration to remove many of the old weapons and migrate them to modular variants</li> Insert all the models for modular weapons after the rest have been made</li> Figure out where wood will go to prevent easy progression skips</li> Make recipes more interesting</li> Various UI/UX improvements to the process of crafting modular weapons</li> Balance and stress testing to ensure nothing unexpected is broken</li> </ul> Dev tweaking by @juliancoffee</h3> This week, I've been working on debugging UX. E-gui hotkey toggle, press F7 to enable/disable e-gui debug window (you'll still need press F3 to enable debug mode)</li> Three new debug lines: Gliding ratio, Gliding Angle of Attack, and Look Direction</li> Update of asset_tweak module</li> </ul> Now if you compile the game with --features asset_tweak</code> you can use tweak!</code> macro from the common::assets</code> module. Here is quite a trivial example, I hope you'll find how to use it in your code. use common::assets::tweak; let x: i32 = tweak!("x", 5); </code></pre> This will create an assets/tweak/x.ron</code> file with (5) as its content, but whenever you'll call it again, it will hot-reload so you can tweak values during play testing. This works with structs too! They need to implement Serialize</code> and Deserialize</code> if you want to use default value. use serde::{Deserialize, Serialize}; use common::assets::tweak; #[derive(Clone, Deserialize, Serialize)] struct Data { x: i32, y: i32, } let default = Data { x: 5, y: 7 }; let data: Data = tweak!("dimensions", default); </code></pre> Note that struct should have double parentheses (like (5) in previous example and one pair of parentheses for the struct itself). Check examples and tests in this module to learn more. And for small combat fixes; beams now follow the orientation of caster (not look direction like it was before) and agents now can correctly use it too. </figure> Physics improvements by @sudoreboot</h3> This week, I identified and resolved a mistake in the aerodynamics simulation that improves glide ratios significantly. More specifically, the mistake was that the lift coefficient included the glider's reference area as a factor. This messed with the resulting induced drag, which is a function of the (square of the) lift coefficient and the glider's aspect ratio. In other words, the amount of drag from angling against the wind was much too high, and now it should be much lower and more accurate. I also made the orientation of the glider tend towards the camera direction while wielding it on the ground. Mostly because it makes the state feel more visually dynamic and interesting, but also because it makes the transition a little more seamless. Between @juliancoffee, @treeco and myself, we managed to come up with a way to make the different playable species glide equally well while letting them keep their distinguishing physical attributes, such as size and mass (both of which were also adjusted to be more sensible). As a side-effect, hitboxes now also very closely match the characters' models. Camera clipping by @klipkonn</h3> Your browser does not support the video tag. </video> LEFT - old, RIGHT - new </figcaption> </figure> I've been working on improving camera clipping. I started by reduced camera clipping by ray casting just outside each camera corner instead of ray casting only to/from the center. Now the camera will automatically zoom in if the player model becomes hidden and the target zoom is under 20. Zooming in makes much more sense in tight environments such as in town as otherwise it's hard for the player to navigate. The change itself was rather easy it was by flipping ray casting direction. With further distances, we ray cast from camera towards player until we get out of solid blocks and place camera there. Now in near distances, we ray cast from player to camera until we hit solid object and then place camera in front of it. For zoom distances greater than 20, previous behavior was kept to allow trees eg to pass in front of camera and cause less jumps if zoomed further out. Next, I'll work on "mode" switching between near and far "mode" as well as on far mode in the future as I got some great ideas from discussions. Out for a dip. See you next week! </figcaption> </figure> This Week In Veloren 131 Mon, 02 Aug 2021 00:00:00 +0000 This week, we see some work on translation, as well as where towers are headed. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @KnightressPaladin, @Pfau, @xMAC94x, @zesterer, @tygyh, @imbris, @lboklin, @Capucho, @Snowram, @mohs8421, @juliancoffee, @XVar, @kilpkonn, @AngelOnFira, @aweinstock, @Fxsch, and @Fungoid! @juliancoffee has been working on a PvP and PvE server switch. @Dr.Dystopia spent the week extracting methods across the codebase. @xMAC94x has been working on translation cleanups, with a unique translation scheme. These improvements have also increased the translation test times by 4x. Work was also done to get this information into Grafana, which can be seen below. </figure> You can check out this week's meeting minutes here</a>. @aweinstock</h3> I've been working on towers (aboveground dungeons, intended to be populated with things like mages and golems and animated books). </figure> </figure> In the process, I found that site2 structure blitting accidentally had quadratic runtime complexity. Generation of each chunk was trying to iterate over each primitive in the structure, instead of only the intersection of those primitives with the chunk. This fix was merged ahead of the rest of towers, and makes dungeons load faster. Videos showing the performance difference: Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> Crossing the vast desert. See you next week! </figcaption> </figure> This Week In Veloren 130 Mon, 26 Jul 2021 00:00:00 +0000 This week we see some new visual changes to caves and caverns. We hear from many contributors about what they've been preparing for the 0.11 release. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @imbris, @DanTheOne, @Sam, @zesterer, @XVar, @aweinstock, @tygyh, @KK, @James, @juliancoffee, @KnightressPaladin, and @schnippl0r! You can check out this week's meeting minutes here</a>. Licenses for assets was discussed, as well as prep for the 0.11 release in early September. </figure> Concept art by @Pfau for the mushrooms in @zesterer's caves </figcaption> </figure> @zesterer has been working on some items: Added better command parsing: arguments now support quotation and escape characters</li> Fixed a variety of smaller bugs</li> Began work on a new cavern system</li> Switch the default singleplayer map to make it less punishing for new players</li> </ul> </figure> </figure> </figure> Some of the images above have the new bloom feature that is being worked on by @imbris. It's not merged just yet, as it is not yet togglable. @LunarEclipse worked with @poVoq to bridge the #general channel on Discord to IRC. @Dr.Dystopia finished resolving clippy error suppressions and began working on creating a settings menu for the main menu. @Gemu made a whole lot of new creatures, along with the long hinted after spiders. This includes some inhabitants of these glowing caves: </figure> Upcoming for 0.11</h3> With discussion starting around what the 0.11 release would look like, contributors took the time to start rounding up their plans for what they wanted to get in before feature freeze. @Sam is working on getting modular weapons wrapped up. @aweinstock hopes to get at least plant growth, and possibly planting plants from seeds (i.e. farming) in before 0.11. @Snowram is aiming to implement an arthropod skeleton for species such as spiders and beetles. </figure> 0.11: Spot system by @zesterer</h4> For 0.11, I'm aiming to get the "spot" system ready. Spots are a halfway house between fully-blown sites (like towns, dungeons, giant trees, and castles) and much simpler localised structures like trees. They support some advantages of the former (custom generation rules, entity spawning, etc.) along with some of the advantages of the latter (better performance, a simpler implementation, ease of development). However, they come with some downsides too: lack of global visibility (i.e: you don't know where they are until you happen upon one) and size limitations. Here are some things that could be added to the game via the spot system in the future: Troll huts</li> Bandit camps/hideouts</li> Animal dens</li> Ruins</li> Settlement outposts</li> Wells</li> Merchant camps</li> Shrines/standing stones/statues</li> </ul> 0.11: UI items by @Pfau</h4> I will do my best to get in some UI features from my list: Improve trading UI/UX</li> Clock-like time indicator near the minimap</li> Different default zoom levels for the minimap modes</li> </ul> Other things that might be in are: Cultist slayer set, craftable with cultist gear acting as "tokens" at one of the spots zesterer is working on</li> More lanterns</li> Visual rework of undead and female orc characters</li> </ul> </figure> 0.11: SFX by @Princess-Lana</h4> I am busy fixing the wind sound, the wendigo SFX, and also aiming to contribute more SFX. The wolf and hyena sounds are ready, they just need to be added to repo and tested locally before I'll commit them. I might also possibly get the dog (canine family of animals) as well. I'm also going to add a license document for the samples that I used for some of the SFX, however the wind SFX I designed from scratch. A beautiful fog. See you next week! </figcaption> </figure> This Week In Veloren 129 Mon, 19 Jul 2021 00:00:00 +0000 This week, we see improvements to AI, new SFX, and some new icons. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @xMAC94x, @KnightressPaladin, @juliancoffee, @Snowram, @tygyh, @zesterer, @AngelOnFira, @aweinstock, @Sam, @Pfau, @Yurimomo, @Aylana, @Savalige, @XVar, and @holychowders! Veloren recently hit 300k lines of code in the project! @Dr.Dystopia has been trying to resolve all clippy error suppressions. You can read this week's meeting notes here</a>. New SFX by @Princess-Lana</h3> I added SFX to the Asp Animal (Creature) in game. It's the first animal to have SFX for all three states (to my knowledge), angry, calm, and hurt. The clips are Royalty-Free, and have been edited to fit in as needed. Some are recordings from other open source projects. I measured them against a few other in-game creature/animal sounds, and found that they sound about right at -5db. It is my first contribution towards the development of Veloren and being part of a team on GitLab. A lot of gratitude goes out to the people who have guided and helped me, thank you. I am looking forward to adding my next SFX contribution soon. </figure> Wgpu work by @Sharp</h3> I've been working for a while now on this, but just to let you know I haven't disappeared! I'm doing a bunch of work directly in wgpu to improve its performance and API for native applications (including Veloren, of course!). I'm also removing pretty much all of the locking (except for locks that are held very briefly for things like allocation, and locks that appear to be hard to eliminate due to the native drivers demanding synchronization). I will probably have a bigger post to talk about this when I'm done as it's a fairly substantial change. Fixes by @aweinstock</h3> I rebased some MRs by @holychowders and @Savalige that were finished, and got them merged. The former makes guards respond when villagers shout for help, and the latter causes melee enemies (most noticeably husks) to spread out, resulting in swarming behavior that reduces the number that can get hit by a single fireball, and causes them to surround you. I adjusted spawning behavior to place players aboveground when logging in, which should eliminate the need to manually use /home to get unstuck. I also improved the PID controllers used for airships and re-tuned them (previously, the integral term was incorrectly discarding old samples instead of accumulating total error). Additionally, I've added support for hats. No hats are currently accessible without /give_item, but the support for them being added is there. </figure> </figure> Icons by @Pfau</h3> I worked on two icons this week: New healing aura </figcaption> </figure> Airshipper icon </figcaption> </figure> I also continued the concept for the crafting window overhaul. The new crafting window will hopefully show things like: Crafting trees (with ingredients for ingredients)</li> More info about ingredients ("what can I craft with this?" or "where do I get it?")</li> More user-friendly representation of armour tiers and sets</li> More filters</li> </ul> AI fixes by @juliancoffee</h3> This week I worked on small AI fixes. AI now knows how to interact in this evil world and doesn't get stuck within three seconds waiting to be killed. Travelers don't hunt their target forever, and get calm after one kill. Merchants don't get stuck in battle trying to eat curry. Cultists target their leaps better and not just by flying to the other end of the room. AI also now uses gliders better which reduces their chance to die from falling. Charge animals (wolves, mammoths, etc) and spear warriors don't double-hit while dashing. Wildlife spawn rules were moved to .ron</code> configs, which opens possibilities for easier balancing and testing. A successful expedition, time to celebrate! </figcaption> </figure> This Week In Veloren 128 Mon, 12 Jul 2021 00:00:00 +0000 This week, we get to see some progress on some new character variations. We also learn about what changes are being made to modular weapons. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Sam, @ubruntu, @tygyh, @szabo_lambert, @a1phyr, @swrup, @knightresspaladin, @caldog20, @YuriMomo, @Pfau, @zesterer, @juliancoffee@DixieDev, @Swagazaki, @Snowram, @aweinstock, @XVar. @Pfau is making his way back to working on the project. His first bigger contribution was adding baldness as an option for the body type 1 of Danari and humans. Also, there are now more horn variations for Danari And 10+ beard styles for Danari. @Pfau also added a button to the map menu to toggle @aweinstock's more detailed minimap mode. </figure> </figure> </figure> You can read more about the minimap in a previous TWiV</a>. Modular weapons by @Sam</h3> In preparation for modular weapons, I've added a few stats to weapons. Range: For melee attacks, this will obviously increase the range. For projectile-based attacks, this increases the projectile speed. For both shockwaves and beams, this increases the duration of the shockwave or beam segment.</li> Energy efficiency: This reduces both the energy cost of activating an ability, and the rate at which energy drains for any abilities that have an energy drain.</li> Buff strength: This will affect the power of buffs and debuffs inflicted in attacks. We are also considering having buff strength affect the strength of buffs applied by auras instead of power.</li> </ul> A few weeks ago, we also had a meeting on working out some of the specifics for modular weapons. The details from that meeting were made into an RFC and can be found here</a>. A valley of grass. See you next week! </figcaption> </figure> This Week In Veloren 127 Mon, 05 Jul 2021 00:00:00 +0000 This week, we see some changes coming to the economic system, as well as food. We hear about some network fixes, and what issues caused them. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @a1phyr, @xMAC94x, @aweinstock, @juliancoffee, @Sam, @UMR1352, @zoli111, @AldanTanneo, @XVar, @Yusdacra, @swrup, @steanne, @eckso, @imbris, @tygyh, @zesterer, @DaforLynx, @Slipped. This month's Rust Gamedev newsletter is out</a>! You can also read this week's meeting minutes here</a>. @Snowram added death SFX and VFX, and made dungeon entrances spawn depend on biomes (MR yet to be reviewed). @LunarEclipse I've been working on a few small improvements to Torvus such as adding /version and /help commands. @juliancoffee adjusted the yeti difficulty for beginner dungeon. @Christof just started a redesign of the economic simulation to support new items and game mechanics introduced in the past six months. With housing, gliders, lanterns, ores, coal, and gems added, the new schema feels more adequate but is still a work in progress. Making the conversion between items and economic wares more reasonable is the major goal here. </figure> Food rework by @juliancoffee</h3> I've been working on a food rework after consuming animations got merged, now most of the food heals you in 5-10 seconds and starts when you sit down. We also got a new food item which gives you two effects at the same time - Mushroom Curry 🍛. It requires you to patiently eat it, but then gives you quick saturation buff which restores 50 HP as well as a long-lasting regeneration buff, which slowly heals you for more than a minute! As for small fixes, merchants now can sell and buy most of the items at reasonable prices (when Mushroom Curry costs more than its ingredients). They can even buy mind flayer spell bags though quite frequently they don't have coins that you would want for it. </figure> Network improvements by @aweinstock</h3> Disabling Nagle's algorithm</h4> In order to debug some networking performance issues, I added some instrumentation of network requests to the client using the tracy tracing profiler. This revealed that messages on the in-game stream (which is meant to handle low-latency data like entity position updates and client inputs) were being delivered in batches. Graph showing nearly a full second of latency, after which 6 messages were delivered at once: </figure> This turned out to be a result of not disabling Nagle's algorithm/enabling TCP_NODELAY</code>. Nagle's algorithm maintains a buffer of small messages, only sending a TCP packet when it's full. This trades away latency to improve throughput, which is the opposite of what's desired for the in-game stream. As a result of disabling Nagle's algorithm, input handling and entity movement should be smoother. Attempts to improve lossy terrain compression</h4> I also tried to improve terrain compression by using 256-color palettes per block kind. This should allow for sending terrain that's a third of the size (since it's 1 byte per voxel for color data instead of 3 bytes for RGB triples), while still being fairly high quality (since Grass has 256 shades of green, Wood has 256 shades of brown, and so on). The slow part of using a palette on terrain is finding the closest color to the original color, which can be sped up relative to linear search by treating the colors as vectors and using spatial data structures like kd-trees and R-trees to find nearest neighbors of a color by Euclidean distance. While this was a success compression ratio wise (a full resolution chunk can be stored at 6% of an in-memory chonk with quantized colors, compared to the 17% or so of deflate or full resolution unquantized PNG), it was an order of magnitude slower than either deflate or quarter resolution PNG (the previous best lossy compression format, at 3% ratio, with noticeable artifacts), rendering it unsuitable for real-time compression of terrain chunks. Graph showing average compression time vs chunk height for a set of chunks near a dungeon: </figure> Bugfixes</h4> I gave a few more materials non-zero prices, which resulted in most metal and hide armor being valued by NPC merchants. Cloth isn't being given a price yet since cloth is considered too easy to acquire via chunk reloading, this is intended to be addressed by modeling plant growth. I also fixed a longstanding bug with underwater campfires, they now no longer emit smoke or light when they get put out by being submerged underwater: </figure> This Week In Veloren 126 Mon, 28 Jun 2021 00:00:00 +0000 This week, we get an overview of changes to how development will be done on GitLab. Lots of new models were added, and we say farewell to a longtime core developer. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Snowram, @XVar, @xMAC94x, @imbris, @tygyh, @aweinstock, @juliancoffee, @Yusdacra, @drunkonhotcoco, @Slipped, @nwildner, @teenjuna, @Danacus, @a1phyr, @SWilliamsGames, @zesterer, @Sam, and @AldanTanneo! @Songtronix did a lot in preparations for Airshipper 0.4.3: The server now validates a lot of things before publishing, and the server and client should now stay in sync</li> Windows 7/8 support is back (unexpected or badly formatted error) courtesy of @Capucho's PR</li> Many other fixes</li> </ul> @Songtonix is taking leave from the development of the project this week as well. @Airshipper has been moved to the Veloren org on GitHub. He'll still be around as a player, but must focus his energy on other work and education. The core team is very thankful for his work, and wishes him the best with his future endeavors! @Snowram added 2 new species to compensate for the lack of wool, an alpaca (model by @Gemu) and a llama (model by @Snowram), also added mammoth and ngoubou species (models by @Gemu) </figure> @Snowram also substituted the cultist's loadout with warlock/warlord armour that was unavailable for players. The cultists now look more fierce and meaner. A buffed up version of the husk was also added for mini-boss rooms: the Husk Brute (models by @Gemu) </figure> @Sam worked on adding durations to potions and food (and this will also be easily extendable to other item uses). What this will mean is that consumables are no longer instantaneously used, limited only by how fast you can spam a button. Now you will need to drink the potion or eat the food. @Slipped has made animations for both drinking and eating. Your browser does not support the video tag. </video> </figure> @aweinstock ported the dungeon generator from the sampling-based approach to site2's CSG generator, making it easier to modify. </figure> @juliancoffee made a MR which sorts crafting tabs in logical order and splits recipes from Dismantle and Material tabs. </figure> The cultist predicament by @juliancoffee</h3> Mind flayers were a little worried about their cultists being too weak. Someone even said that cultists are weaker than ants from Myrmidon dungeon! What nonsense! Reforms were needed, everyone knew that. So best darksmiths worked on new armour. Orichalcum? Good choice, if you want to get hit, but cultists should be smarter than that. Dragonscale? Better, but still has less protection. While you can hit harder with it, you lack stamina. Sunsilk solves this issue, but only if you consider a bunch of silk the armour. Cultists are best, they deserve to have this all! And the darksmiths come up with the answer. Smith's chef-d'oeuvre gives its owner strength of any possible armour. Mind flayer also get a better weapon with the flamethrower of such power so they hardly can handle it themselves. But a single piece of metal and heat of fire doesn't win fights alone. so mind flayers gathered the best warriors and gave them power consumed from weaker ones (so that mind flayer don't need to waste their corrupted spores...). </figure> GitLab repository changes by @xMAC94x</h3> Veloren's community is open and volunteer-driven. We welcome new contributors from all walks of life in our mission to build the best game we possibly can. Currently, we hand out 'developer'-level permissions to contributors on the main Veloren GitLab repository. Long-term, this situation is untenable and will need reevaluating: GitLab's permission system is crude and doesn't allow us to control access permissions across branches, meaning that contributors have more permissions than are necessary to do their work. The obvious alternative to this workflow is to have contributors fork the repository and contribute by upstreaming to the main repository through merge requests. However, this comes with some disadvantages: Collaboration between multiple contributors is harder: contributors must decide to work on a specific lead contributors fork, and will require permissions to do so, as well as adding the fork as a remote locally</li> Continuous Integration (CI), the system for testing changes to the codebase before merge, will need to be manually set up for each fork.</li> </ul> For these reasons, we're going to be trialing a third solution: a dedicated 'contributor' repository where contributors can work on features as they do on the main repository today, but will open MRs against the main repository when features are complete. The main repository will be used only for branches authored by core developers, and the main branch/release tags. What this means for you</h4> For contributors, the change in workflow should be minimal: the only change you'll need to make is to switch the URL of your 'origin' remote locally, and remembering to open an MR with the main repository when you feature is ready for review. All permissions, CI-related things, etc. will be handled by us. Shortly after a transition period, we will deactivate the developer rights on the main repo and ask you to switch to the veloren/dev/veloren</code> repository permanently. For developer this means you need to change the remote URL. git remote set-url origin git@gitlab.com:veloren/dev/veloren.git </code></pre> We are happy to hear your feedback and questions in the respective channels 🙂 FAQ</h3> What exactly are the security concerns? We will publish them in a blog post once we this change is complete, to avoid tempting potential exploits. Will I still be able to use my Fork? Yes: the dev repo is optional. Feel free to continue forks, though we do recommend you join the dev repository in order to make your life easier. I have an ongoing MR on the veloren/veloren repository. What do I need to do? Nothing will happen to core developers and team leads, they will keep access to the main repo until their MR is merged or closed. If you made the change in on your fork, this will also be the case. If you made the change on the main repo but are neither a core developer nor a team lead, please contact me (@xMAC94x). If you are currently working on a branch, please push that branch to the dev repository, using the same name. How do I join the dev repository? We have already invited all members of veloren/veloren</code> to the dev group. If you are not yet a member, apply here: https://gitlab.com/groups/veloren/dev/-/group_members</a> and ping one of the core developers. Should I now star</code>, fork</code>, open issues on the veloren/dev/veloren</code> repo instead? No, please use our main repo veloren/veloren</code> as the project's 'ground truth'. Only use the dev repo for development purposes. How do I open Merge Requests (MRs) now? When you open a new MR in the dev repo, it should automatically have the target veloren/veloren/master</code>. This means that the process should not differ in practice. Lots to explore in the caves. See you next week! </figcaption> </figure> This Week In Veloren 125 Mon, 21 Jun 2021 00:00:00 +0000 This week, we get an in-depth view into what was required for the wgpu integration. We see some changes to econsim, performance, and caves. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @YuriMomo, @zesterer, @Slipped, @xMAC94x, @SWilliamsGames, @Christof, @aweinstock, @Sam, @juliancoffee, @Yusdacra, @imbris, @DaforLynx, @donovanlank, @AngelOnFira, @Capucho, @Snowram, @Zakru, and @Kisa! @Sam worked on a harvester rework. It'll have 4 unique attacks and all-new AI. To see it, go visit your local T0 dungeon (after it merges). This week's meeting minutes.</a> Lava and performance by @aweinstock</h3> This week, I added Lava to caves, which glows, and which sets you on fire when you enter it. Your browser does not support the video tag. </video> </figure> I also improved the performance of entity-terrain collisions (one of the main parts of physics) by an average of 20 microseconds per frame by adding a check for a more precise bounding box before looking up voxels in the terrain. </figure> Econsim improvements @Christof</h3> I finally found the mistake in the faster economy simulation code and the code got merged - server startup should be faster by several seconds. After that, I started an RFC</a> about short and long-term goals. Econsim will soon get more wares and professions to match the increased number of items, and the much more powerful crafting recipes. Also, prices will probably get independent of loot probabilities and become more raw material derived. All about wgpu</h3> A section by @imbris and @Sharp, edited by @Capucho and @AngelOnFira. We now use the wgpu</code></a> crate for our graphics! After a long journey of refactoring our rendering code for wgpu</code>, rebasing, refactoring new graphics features to use wgpu</code>, updating the code across wgpu</code> versions, testing on a plethora of platforms, fixing miscellaneous bugs, and rewriting parts of our CI cache generation with efforts from @Imbris, @Capucho, @Sharp, and others we have finally merged</a> the long awaited 129 commit branch that switches our rendering code to this new graphics crate! wgpu</code> is the spiritual successor to the gfx</code> (pre low level) crate we were using for graphics so it sits at a similar level of abstraction. However, wgpu</code> provides a cleaner modern API that gives use more control and the ability to leverage the power of modern backends including vulkan, metal, and dx12. With gfx</code> we only used the OpenGL backend and now with wgpu</code> we have automatic support for multiple backends including automatic runtime backend selection. The currently functioning backends are vulkan, dx12, metal, and dx11 (support for OpenGL is lost for the moment). We saw improvements in performance especially for Windows users with decent graphics cards that previously experienced a significant discrepancy in performance from Linux users with similar cards. Now that this period of refactoring has been finished, we're excited to see the optimizations and features we can develop on this fresh graphics API. Much thanks to @kvark and @cwfitzgerald ❤️ for answering the questions we had about wgpu</code>, resolving bugs we encountered, and being extremely receptive to issue reports and pull requests! Thanks to all the testers who helped us track down platform-specific bugs and make sure everything was mostly working everywhere! Notable previous mentions of the wgpu</code> refactor are in devblog-64</a> and devblog-100</a> Presentation modes option</h4> We added a new option in the graphics menu with the three presentation modes exposed by wgpu</code>: Immediate, Mailbox, and Fifo. Selecting Fifo or Mailbox can be used to avoid screen tearing. Fifo corresponds to VSync and as such caps the frame rate at the display refresh rate. Immediate and Mailbox both fallback to Fifo within wgpu</code> if that option isn't available on the current platform. </figure> GPU timing with wgpu-profiler</code></a></h4> While working on this refactor I discovered, via lurking on the Rust gamedev Discord and the wgpu matrix channels, that wpgu provided an API for collecting timestamps</a> between sections of work on the GPU. This piqued my interest as I've previously had much success identifying and optimizing our CPU bottlenecks with the use of flame graph</a> and Tracy</a> while our GPU side performance was mostly opaque to me. Thus, I started working on writing an abstraction to make it easier to instrument our rendering code with timestamps. While I was in the process of this, Wumpf released wgpu-profiler</code>. I discovered it had everything I needed and nicely solved the complications of identifying timestamps which I was too focused on over-optimizing. It even included the ability to write out to a chrome trace which was pretty neat! So I switched to wgpu-profiler</code>, made a PR</a> adding drop based scope wrappers around wgpu types, and deleted all the extra code I had for this in the Veloren codebase which was pretty satisfying. I then added scopes around all the major portions of our rendering (essentially one for each render pass and one for each pipeline). To make it easy to access this new information I added a new option in the graphics menu to enable GPU timing. The timing values can be viewed in the HUD debug info (F3) and will be saved as chrome trace files in the working directory when taking a screenshot. It's mostly just supported on the Vulkan backend at the moment so if you don't see anything new in the debug info then the feature isn't available on your current backend/platform combination. I intend to eventually make the checkbox gray out in this case instead of having no indication. It would be neat to plot these values over time in the future. Chrome trace </figcaption> </figure> GPU timing in HUD debug info </figcaption> </figure> We can also now use tooling for profiling vulkan and dx12 such as this profiler from AMD: https://gpuopen.com/rgp/</a> Example RGP profile on Ryzen 3 3200U integrated graphics </figcaption> </figure> Sprite optimization</h4> High sprite view distances previously had a really large impact on the CPU. We used instancing for sprites to draw multiple ones with the same model within a single draw call. However, within a chunk there several different sprite kinds (some with multiple variations in their models) leading to a large number of draw calls and significant CPU overhead when trying to draw more sprites farther away. To reduce the number of draw calls we need to make I combined all the sprite models into a single buffer of vertices and then used a technique called vertex pulling to fetch the vertex data from this buffer within the vertex shader by determining the location in the buffer from the index of the current vertex combined with the mesh offset for the current instance. This moved the bottleneck for sprites into the vertex shader both because this introduced a bit more work in the shader and because sprites simply have a lot of vertices and were no longer limited by the CPU. To help alleviate this I converted all our quad drawing (i.e. what all our terrain, figures, and sprites are made of) to use an index buffer to reduce the number of vertices that need to be processed per quad from 6 to 4 (as the GPU should cache vertices with the same index). This helped and also led to small gains for shadow rendering times, presumably terrain and figures also benefited but the cost of the fragment shader for those is far greater in typical scenes. I think we can squeeze more performance out of sprites by optimizing the vertex shader further and reducing the amount of per-instance data. Another area where we can tackle this is reducing the vertices used for sprites that are far off and take up only a few pixels. We already have different LOD levels that reduce the number of vertices but we may be able to go further and simply render 2D billboard-style sprites for these. Reversing the depth buffer</h4> One of the bigger wins from switching to wgpu</code> is that it lets us abandon the OpenGL depth buffer. To make a long story short, the standard method for calculating depth buffers is the worst possible way to do it</a>. They should be computed "backwards" from how people normally set them up due to this taking far better advantage of the way floating point precision works (in fact, it is nearly optimal for floating point)! Unfortunately, since it takes some fairly involved math to realize this, the OpenGL spec was published in a way that makes it impossible to realize the benefits of reversed depth buffers, due to setting depth planes to go from -1 to 1 instead of 0 to 1; the conversion to 0 to 1 must then be done in the drivers by computing depth 0.5 + 0.5</code>, which is pretty much the worst possible thing you can do for floating point accuracy and negates the reversal effect. wgpu</code> follows the far more sensible Vulkan, Metal, and DirectX option, and sets depth buffers from 0 to 1, enabling us to realize the effect. The practical upshot of this is that we can set the near plane much, much closer than before, while extending the far plane to (effectively) infinity, while retaining better precision than before at literally every point in the whole range (except maybe within a very tiny fraction of a block in front of the near plane). This should help us improve clipping since it solves the most annoying aspect of it (near plane) and also lets us render much bigger maps without noticeable artifacts (unless you zoom all the way out). Organizing bind group and pipeline switching</h4> To avoid redundant state changes (setting pipelines, bind groups, vertex buffers) as much as possible. We created a series of "Drawer" types that wrap a reference to the render pass and guarantee for instance that a certain pipeline is in use. We have a top level Drawer</code> that exists transiently during the recording of the frame: pub struct Drawer<'frame> { encoder: Option<ManualOwningScope<'frame, wgpu::CommandEncoder>>, borrow: RendererBorrow<'frame>, swap_tex: wgpu::SwapChainTexture, globals: &'frame GlobalsBindGroup, // Texture and other info for taking a screenshot // Writes to this instead in the third pass if it is present taking_screenshot: Option<super::screenshot::TakeScreenshot>, } </code></pre> This hold references to bits of the render state that we need and owns the command encoder. Then for example, there is a method to start the first render pass that returns a FirstPassDrawer</code>: /// Returns None if all the pipelines are not available pub fn first_pass(&mut self) -> Option<FirstPassDrawer> { let pipelines = self.borrow.pipelines.all()?; // Note: this becomes Some once pipeline creation is complete even if shadows // are not enabled let shadow = self.borrow.shadow?; let encoder = self.encoder.as_mut().unwrap(); let device = self.borrow.device; let mut render_pass = encoder.scoped_render_pass("first_pass", /* snip / }); render_pass.set_bind_group(0, &self.globals.bind_group, &[]); render_pass.set_bind_group(1, &shadow.bind.bind_group, &[]); Some(FirstPassDrawer { render_pass, borrow: &self.borrow, pipelines, globals: self.globals, shadows: &shadow.bind, }) } </code></pre> But before returning it two bind groups are set: render_pass.set_bind_group(0, &self.globals.bind_group, &[]); render_pass.set_bind_group(1, &shadow.bind.bind_group, &[]); </code></pre> In subsequent drawing, we can then rely on these bind groups being set (as long as we maintain that they aren't overridden which we accomplish by keeping all the logic which sets bind groups (and other things) in this one module). Then e.g. to start drawing terrain we create a TerrainDrawer</code> setting the pipeline and the index buffer in the process: pub fn draw_terrain(&mut self) -> TerrainDrawer<'_, 'pass> { let mut render_pass = self.render_pass.scope("terrain", self.borrow.device); render_pass.set_pipeline(&self.pipelines.terrain.pipeline); set_quad_index_buffer::<terrain::Vertex>(&mut render_pass, &self.borrow); TerrainDrawer { render_pass, col_lights: None, } } </code></pre> Such that when we draw all the chunks we only need to set the additional bind groups and vertex buffer specific to each chunk: impl<'pass_ref, 'pass: 'pass_ref> TerrainDrawer<'pass_ref, 'pass> { pub fn draw<'data: 'pass>( &mut self, model: &'data Model<terrain::Vertex>, col_lights: &'data Arc<ColLights<terrain::Locals>>, locals: &'data terrain::BoundLocals, ) { if self.col_lights // Check if we are still using the same atlas texture as the previous drawn chunk .filter(|current_col_lights| Arc::ptr_eq(current_col_lights, col_lights)) .is_none() { self.render_pass .set_bind_group(2, &col_lights.bind_group, &[]); self.col_lights = Some(col_lights); }; self.render_pass.set_bind_group(3, &locals.bind_group, &[]); self.render_pass.set_vertex_buffer(0, model.buf().slice(..)); self.render_pass .draw_indexed(0..model.len() as u32 / 4 6, 0, 0..1); } } </code></pre> Future of OpenGL support</h4> With this transition, we gain access to a lot of new graphics backends, but we now no longer have OpenGL support. This mainly affects Linux users as support for older Windows machines is provided through dx11. Nevertheless, we may regain some form of OpenGL support on Linux in the future. The backend abstraction layer for wgpu</code> was recently rewritten and moved into the main wgpu</code> repo</a> removing a lot of the barriers to getting an OpenGL backend working. Shaderc adventures</h4> To use our GLSL shaders with wgpu</code> we have to compile them to SPIRV. Currently, the only viable option for this is using shaderc. However, shaderc is a C++ dependency and thus has the potential to bring complications to the build process which it does. Building shaderc requires git</code>, cmake</code>, and python</code> to be installed and also ninja</code> on Windows. This adds extra steps for new contributors looking to compile Veloren. Additionally, shaderc introduced complications into our cross compiled CI builds (for non Linux platforms). Cross compiling to Windows, I ran into this issue</a> which I was only able to solve by using the POSIX threads version of MinGW which necessitated distributing some DLL files. Cross compiling to macOS also had various issues with compiling and/or linking shaderc. After several attempts including trying to use prebuilt versions of shaderc, we eventually switched to natively building on a macOS runner which was admittedly a somewhat useful change outside of getting shaderc working as we have had other</a> issues</a> with cross compiling to macOS. Shaderc is also pretty massive and appears to add at least ~10 MB to our binary size. Hence, we are really looking forward to when naga</code></a>, a shader translator library written in pure Rust, will be able to replace shaderc for our purposes. CPU profiling</h4> Since we had a major refactor I thought it would be neat to examine the CPU profiles of the work being done during rendering. Most of the CPU side time for rendering appears to be spent in run_render_pass</code>: Tracy profile showing ~2 ms to queue rendering of everything for a frame </figcaption> </figure> Flamegraph snippet showing where `run_render_pass` spends time </figcaption> </figure> Settings used for CPU profiling </figcaption> </figure> Future directions</h4> Our future with wgpu is bright. Because its API is much closer to that of modern graphics drivers, it should be much easier to incorporate newer hardware features (at least if they have a little bit of cross-platform support). We also have a great opportunity to help influence the shape of not only wgpu, but the WebGPU specification itself, to make it better for games in general. Finally, having made this switch lets us focus on other rendering improvements we'd been putting off in order not to block wgpu work (or which were blocked by lack of wgpu), such as: Separate the voxygen renderer module into its own crate (e.g. we can use it in a voxel editor)</li> Create a small renderer engine test/demo for rapid iteration and testing.</li> Rendering on multiple threads (impossible before wgpu, currently waiting on removal of locks in wgpu).</li> Deferred rendering (making large numbers of unshaded point lights cheap).</li> Move completely to naga</code> once it has GLSL support and can handle our shaders.</li> SMAA</a></li> Improved LOD rendering (including things like trees, sites, and maybe even some form of sprites).</li> Smarter and more accurate shadows with occlusion queries (useful for many other purposes as well) and Z-partitioning.</li> Faster and smarter chunk updates, both for initial rendering and updates to things like sprites, to reduce apparent load times.</li> More physically correct HDR, allowing us to remove various lighting hacks (should especially help at night).</li> Take advantage of compute shaders and GPU-side buffer updates to speed up CPU-limited operations.</li> (Maybe) explicit tiled rendering, tessellation shaders, and multiple queues, if/when supported!</li> And much, much more!</li> </ul> Out for an early morning dip. See you next week! </figcaption> </figure> This Week In Veloren 124 Mon, 14 Jun 2021 00:00:00 +0000 This week, 0.10 released! We hear from @Slipped about caves, plugins from @zesterer, and other improvements by @aweinstock and @juliancoffe. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @AsumFace, @xMAC94x, @aweinstock, @SpecificProtagonist, @juliancoffee, @Pfau, @Yusdacra, @Kisa, @XVar, @AngelOnFira, @Cr0ss0vr, @Slipped, @zesterer, @Capucho, @jvck10, @Scott, @tygyh, @Sam, and @Christof! This past week, 0.10 released! At peak, there were 118 unique players online. Read more about the release in the writeup below. </figure> @Nomagno has been pondering the feasibility of a partial WASM port of veloren-server</code>, veloren-common</code>, and veloren-client</code>, and hopes to put some work into it in the future. @Scott adjusted most of the NPC's hitboxes to better fit their models and lowered a lot of the smaller creatures' health values to make early game easier. Crafting exp with a different colour and an extra symbol </figcaption> </figure> During the debugging of the meat MR, @aweinstock made a Graphviz generator that processes the recipe book: </figure> @Snowram added some new NPCs, including a roc NPC with a new tornado summoning attack. Look out for it in the sky! @Slipped merged some rebalancing to correct things after the armor MR made everyone stronger. Hopefully, now we have better progression barricades for the tiers of monsters that drop the materials you need to advance through the crafting system, by making lots of stuff stronger. And we have a basilisk petrify attack so that's pretty rad. @juliancoffee worked on loading EntityInfo</code> from assets. EntityInfo</code> is builder-like structure that is used to populate chunks and then server spawns creatures from that. Now you can describe body (only random for now), loadout, skillset, name, loot, and weapons in asset and then just load them where you need them. Currently, it works only for single entities (so if you need to spawn multiple entities, you are using vector for this) but this is base for things like loading whole dungeon crowd from asset where you can specify enemies for each room or describe what pack of animals will be spawned somewhere in overworld. </figure> Caves by @Slipped</h3> One thing that became super clear once we decided to start adding more ores to caves was that they were due for a tune-up. They took very little advantage of static lighting, weren't very deeply tied to progression and their difficulty was a bit all over the place. However, their actual structure set up by @zesterer was amazing and we were completely underselling that. Caves break down to 4 points of hierarchy: Layout</h4> This is the existing canvas. Caves can be super vertical, super wide or frighteningly narrow. They can have platforms, glider obstacle courses, and a ton of other things. No changes were needed for the lowest level hierarchy, it's already great. </figure> Structures</h4> So far, caves have had some really cool stalactites for structure. We needed more of that. First was color, there are now noisy colored floors and ceilings in the caves, which helps break up the old gray. New caves also have different structures depending on depth. Once you enter, there are ridges, which are huge white scaffolds that hold up the ceiling of the cave. They cover some percent of the ceiling at specific intervals of the cave depth, which creates clean structures in narrow hallways and very chaotic bands of scaffold in bigger rooms. As you go deeper, we trigger the stalactites. Finally, at the lowest levels we trigger pits, which can go 30 blocks deep, along with veins. Veins store the best ores in the game, so look for orange sand and you can pickaxe through for the ore deposits at the bottom. Sprites</h4> Sprites are the next level up the hierarchy. A few big changes here were making sprite spawns width dependent so that they mostly spawn closer to the walls, adding ceiling sprites, and adjusting the sprite glow color to be less fire-like and more neutral. Thanks to the artists, we have different layers which use mushroom, crystal, or orb sprites as you go deeper, and caves are very lit up now. We also added dripping particles from the ceiling. </figure> Enemies</h4> Enemies are on the top level of the hierarchy, and got rebalanced to tune difficulty. On entry, things are still passive so new players can gather basic ore. Next, you hit moderate enemies like asps and salamanders, to give scales and protect the iron. After that you reach the cobalt/coal layer, protected by basilisks and firedrakes, upping the difficulty. Finally, the bottom layer has ogres, cyclops, trolls, and others protecting gold, silver, and bloodstone, the most useful ores in the game. The next plans are to start getting into biome-specific cave themes, so look out for that! Plugin Tutorial by @zesterer</h3> I finally got around to writing a tutorial for the new plugin API. It's worth noting that the plugin API is still under heavy development, but I'll try to update the tutorial regularly to reflect changes. The tutorial takes budding modders all the way from setting up the project to packing, playing in the game, and demonstrates a series of API features. Hopefully, this is going to accelerate activity around plugins and help us push the API to the point that it becomes viable for community modding. https://book.veloren.net/contributors/modders/writing-a-plugin.html</a> </figure> Mining and movement fixes by @aweinstock</h3> I added a mining skill tree, which gives XP when mining ore (and not from combat). Skill points in the mining skill tree can be spent on mining faster, and on a chance to gain extra ore and gems when mining. @Scott made the icons for the skill tree, and @Pfau helped to fine-tune the UI. @DrDystopia also helped by refactoring voxygen::hud::diary</code>, which made it easier for me to add the new skill tree to the UI. Your browser does not support the video tag. </video> </figure> I also made it so that character abilities that apply forced movement (primarily leaps and rolls) temporarily disable entity-entity pushback. This fixes a bug with axe/hammer leap where you couldn't deliver the hit because you'd be pushed away on landing from the leap before swinging the axe or hammer. This also makes it possible to roll through creatures, which means that it's now possible to escape being stuck in a corner by a minotaur. Your browser does not support the video tag. </video> </figure> 0.10 Release Party by @AngelOnFira</h3> With the release party last Saturday, lots of telemetry was recorded. In comparison to the previous release, 0.10 went a lot smoother. Some of the devs got into a voice chat to talk about the game's development, and this was streamed to Twitch. Check out the recording below! </iframe> </div> </figure> One of the primary metrics that we can best use to determine server health during releases is the tick time. In the case of this release, we saw healthy tick times of between ~40-50ms. Ideally, it would be best if they were less than 33ms, as this gives the target tick rate of 30 ticks per second. During previous releases, we saw it go as high as 100ms, which would tend to snowball while trying to catch up on work from previous ticks. For the release, we used a 32 core dedicated server from Hetzner. This time, we made use of the new AMD CPU option, which turned out to help a lot. </figure> As you can see, during the release party each core never really went above 30% usage. This shows that although we can make use of parallel processing, we're still limited by how fast the main thread is working. A key point of future optimizations will be to distribute work across the cores more efficiently. Tests were done on both the 32 core AMD and Intel chips that could have been provisioned for the dedicated server. Hetzner won't tell us the exact chip models that are used "for security reasons", so instead we ran some of our own tests. The tests were run with sysbench</code>, and although they don't exactly represent more complex problems than just what can calculate primes better, it still showed us some useful information: </figure> Overall, the release party went quite well. We definitely want to do a bigger push for the next release, so we can hopefully blow past our record of 133 players on the server at once! </figure> </figure> </figure> Balance and UX improvements by @juliancoffee</h3> I was recently working on some balance and UX improvements. This includes slightly buffing the bow, staff (especially at lower stages of the game), sword, and nerfing the hammer. Dungeon enemies were also nerfed; primarily Tidal Warrior and NPC dashes. Also, the bow zoom is less annoying now. /kit and /skill_preset were also updated. Here is the changelog of weapons: !!! DISCLAIMER: these values are just coefficients, which is then multiplied by weapon power, weapon kind, skills, and other coefficients !!! - Bow M1: * charge_time reduced from 1.2 to 1.0 * damage range was changed from [20; 100] to [5; 125] * regen range was changed from [20; 140] to [5; 125] -> bow now shoots faster - Staff M1: * regen was changed from 50 to 60 * explosion effect was reworked to more smooth damage distribution over the area -> you now can get stamina to roll if you hit two enemies. You also do more AoE damage on lower stages of the game when your explosion radius isn't that great Tidal Warrior Bubbles: * damage reduced twice -> you have more chances to not die when doing melee Totem: * much longer reload time of wave * wave now pushes you away of totem, not upward -> orcs aren't dying from fall damage while fighting Tidal Warrior now Dashes - Spear dash (T0-T4 enemies) * damage range was reduced from [60;160] to [10;90] * poise range was reduced from [45;45] to [0;25] * recover duration was increased from 0.5 to 0.8 - Animal Dashes (Lions, Bonerattlers, etc) * recover duration was increased from 0.5 to 1.0 -> you now can move after getting dashed so it's less likely you will get damage twice UX - Bow Zoom: * starts with 50% of charge * more lite zoom at the end of charge -> aiming with bow M1 is now easier - `/kit` command * new `tier-5` kit with yellow armour and tier-5 weapons. * kits from `tier-0` to `tier-4` were updated to match new armour update. * new `endgame` kit with cultist and legendary weapons, cultist rings, and gem of lesser protection - `/skill_preset` command * temporary `middle` preset with random copypasta from `max` :P. I plan to add skill presets for each tier in future. Bug fixes Damage from melee weapons is now produced in the middle of swing animation, not at the start. This solves a bug when you can hit your enemy without swing and roll away. Now you still can cancel swing animation, but you won't hit your enemy. Melee Balance changes - Sword: * first stage buildup is boosted from 0.15 to 0.1 -> you start your attack faster - Hammer: * base poise damage is reduced from 25 to 20 -> it's less likely hammer can stunlock enemies </code></pre> Will you please listen? I'm not the Messiah! ( See you next week! ) </figcaption> </figure> This Week In Veloren 123 Mon, 07 Jun 2021 00:00:00 +0000 This week, everything is wrapping up before the code freeze for 0.10. We hear about some physics changes, and other technical stuff. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @aweinstock, @Christof, @imbris, @Slipped, @Pfau, @Snowram, @Sam, @hqurve, @backyard_tourist, @XVar, @tygyh, @Capucho, @juliancoffee, @Yusdacra, @Sharp, @Synis, @zesterer! This week, lots of work was done in preparation for the 0.10 code freeze. This is the last stretch before the full release on the 12th at 18:00 GMT. Make sure to join the release party, as we're super excited to celebrate what we've been working on! We recently hit 2000 merged MRs on GitLab, which is made up of 8500+ commits and 280k+ lines of code. </figure> @Sam reworked the tidal warrior and yeti, the bosses in tier 1 and 2 dungeons. @Capucho fixed a VRAM leak and some other graphics-related panics from after wgpu was merged. @Vechro worked on a slight website redesign, which is going to be pretty hard to miss if the MR gets merged before the next blog post. @Slipped has continued to work on the armor/meat branch merged and after working out initial bugs people seem to mostly like it. Hot-reloading by @juliancoffee</h3> I created asset_tweak</code> module in common/assets to allow developers to tweak values while running the game which don't yet have RON files. To use it you need to compile game with asset_tweak</code> feature (it's not a default feature because we don't want it used it production code) by adding --features asset_tweak</code> to any command you use to compile game. For example (cargo run --features asset_tweak</code>). </figure> Example of usage: Consider this code in Body::dimensions()</code>: Body::BipedSmall(_) => Vec3::new(1.0, 0.75, 1.4)</code> To start hot-reload it, you need to rewrite code above like following: Body::BipedSmall(_) => { let (x, y, z) = assets::asset_tweak::tweak_expect_or_create("biped_small_dim", (1.0, 0.75, 1.4)); Vec3::new(x, y, z) } </code></pre> This will create a file "assets/tweak/biped_small_dim.ron" with following content: ((1.0, 0.75, 1.4))</code> Note the parentheses around, it's important because it's a tuple. From now you can edit this file and each time game will call Body::dimensions() method, it will use your values. Voxel minimaps and tornados by @aweinstock</h3> I did more work on the voxel minimaps (which I've blogged about previously) and they're now merged. They can be enabled by setting map_show_voxel_map: true</code> in voxygen's settings.ron</code>. I also got tornados working again on Snowram's branch once wgpu was merged (which were an edge case since tornados use entities with no meshes, only particles). </figure> Physics changes by @sudoreboot</h3> I've made good progress on the glider controls rework. The character now rotates based on the change in the relative velocity of the glider, which in conjunction with the reworked control logic enables you to perform manoeuvres such as loops and gliding upside-down. The strafe keys are repurposed to affect only roll rather than direction. </figure> The glider now also generates forces even in glider wield state, and you can pitch it up and down before even taking off. This allows you to take the glider out while riding an airship and -- provided it's going fast enough -- start hovering (or get blown off of it if you angle it the right/wrong way). To implement this I had to do a fair amount of refactoring, which requires more careful code review. For this reason (and the fact that we're past feature freeze) it won't be merged before 0.10. If it ends up getting approved, we may expect this to appear on the live server sometime after this coming release. A ride through the clouds. See you next week! </figcaption> </figure> This Week In Veloren 122 Mon, 31 May 2021 00:00:00 +0000 This week was Veloren's 3rd birthday! We are getting ready for the 0.10 release coming in two weeks. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Adam, @ygor.souza, @xMAC94x, @aweinstock, @Pfau, @Slipped, @juliancoffee, and @tygyh! Veloren turned 3 last week! The day varies, whether you base it on the day that the idea was suggested</a> (the 25th), or the day the name "Veloren" was chosen (the 28th). Either way, happy birthday to the project! You can read this week's meeting notes here</a>. @Songtronix open sourced the Veloren testing bot</a>. He's also working on a crate to facilitate airshipper 0.5 featuring automatic retries, exponential backoff, and an easy way to introduce file-based updates for anyone writing a launcher in Rust. It will be fully async and based on Streams. @Snowram added material tags to armor to help with the big progression MR, also added 3 new troll variants with models by @Gemu. </figure> 0.10 release schedule</h3> Veloren will release 0.10 on June 12th at 18:00 GMT+0. This means that over the next couple of weeks, we'll be tying down loose ends of features, and going into code freeze. Here is the planned schedule: 2021-06-06 18:00:00 GMT+0 Feature freeze - At this point no features will be merged. 2021-06-08 18:00:00 GMT+0 Public Stability Testing with many people 2021-06-11 16:00:00 GMT+0 Fixes freeze - Nothing will be merged except game-breaking fixes 2021-06-12 09:00:00 GMT+0 Final Build 2021-06-12 12:00:00 GMT+0 Prepare a Release Server 2021-06-12 18:00:00 GMT+0 Release Party </code></pre> </figure> Bugfixes by @aweinstock</h3> I fixed a bug with the economy where data from the economic simulation wasn't properly being converted to in-game prices, resulting in most towns having the same prices for many kinds of goods. I also implemented PID controllers to allow the AI to control airship buoyancy properly (resulting in less intense acceleration), as well as fixed an issue in collision resolution where players would collide with where an airship was in the previous frame. Both of these fixes should make airships more robust to stand on without falling through them. Two airships, off to far lands. See you next week! </figcaption> </figure> This Week In Veloren 121 Mon, 24 May 2021 00:00:00 +0000 This week, we see lots of design changes to many systems. We hear about how this what is going on with the crafting and loot systems, as well as planned improvements in the combat fields. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Slipped, @juliancoffee, @xMAC94x, @Sam, @James, @sudoreboot, @aweinstock, @Pfau, @XVar, @hqurve, @imbris, and @Sharp! You can take a look at this week's meeting notes here</a>. @Sam removed the 2 old weapon loadout slots and added 4 new ones in their place. With the new weapon slots, you can have up to 4 hands worth of weapons, so you can run either 2 2h weapons, 1 2h and 2 1h weapons, or 4 1h weapons. UI work by @Pfau and @R.A.B </figcaption> </figure> A loot log </figcaption> </figure> The loot log removes the loot messages from the chat and puts them above it. It's scrollable and will only show recently looted items when not being interacted with (with the older ones fading out). @aweinstock has been working on addressing reviews on the farming and voxel minimap MRs. He's also made a camera zoom effect for ChargedRanged: Your browser does not support the video tag. </video> </figure> @Snowram has been learning the basics of the new site procgen by trying to make a cemetery. The tombstone models are by @sStellar, and there is still work to go before the final version. </figure> Your browser does not support the video tag. </video> A full fight against the Mindflayer by @WECW-KKY on a custom modded server. </figcaption> </figure> Bow changes by @Sam</h3> This week, I started on a bow rework, with all abilities have being replaced. The new M1 is very similar to the old M2, in that you charge it for greater effect, and it fires when you release. The main changes here in functionality are that it no longer drains energy, and it now will reward energy on shots that hit. The new M2 is called repeater like the old S1, however, it now has new functionality. Instead of the leap and the simultaneous fire of a few arrows, it instead will continually fire arrows with an increasing rate of fire over time (each arrow costs energy to fire). The new S1 is a shotgun-like ability, which fires multiple arrows with some degree of spread. With this rework come very slightly different skills, and a reset to the bow skill tree. Improvements by @James</h3> For the past few days I've been working on moving all body attributes to RON files. These are body and species-specific stats like mass, height, base health, etc. I have each attribute loading from a RON file into one compound asset (eg. the mass.ron and base_health.ron get loaded together as one BodyAttributes asset). The server loads the RON files and sends the body data to the client on initial sync. This means that server owners could adjust values and not require a modified client. To help with debugging and development, I'm planning to add an admin command to resync body data (since the assets already hot-reload) after the initial sync. I also fixed a bug where NPCs would ignore you if you hit them with a projectile from too far away. While I initially thought this was simply because they were being attacked from outside of a set range, I discovered I had accidentally reduced the response time for NPCs for damage from 3.1 seconds to 0.1 seconds about a month ago. This meant that when an NPC received damage, it had 0.1 seconds to respond. If it didn't see the target in those 0.1 seconds it would return to idling. I returned the damage memory duration to 3.1 seconds as well as provided a way for NPCs to path toward positions outside of the maximum allowed pathing radius by choosing an intermediate point a set distance away. A* pathfinding gets more and more expensive the longer your path is so hopefully we will see some performance improvement in the agent system. </figure> Dungeon balancing by @juliancoffee</h3> I've been working on a lite dungeon rebalance by updating minibosses at lower tiers and adjusting loot tables at higher tiers. Now there is Deadwood in T0 dungeons instead of Bonerattler, and Rats in T1 dungeons instead of Bonerattler pack. For making dungeon looting a bit more enjoyable I removed low tier gear from cultist loot table and added average enemy loot to beast masters so they don't drop cultist gear only to have small wow effect when they do. Also each dungeon now has unique loot from chests. Also for purpose of modification and future reworks I added placeholder armor and loot table for each boss. For dungeon enemies and village inhabitants I've added RON files to specify their loadout. Glider and physics changes @sudoreboot</h3> I implemented auto-glide by making auto-walk work properly while gliding. While enabled, it will assume pitch control to take you as far as possible in the direction you're looking. With free-look enabled you can now spend your time looking around at the scenery while gliding. This is a step in the direction of making the glider more accessible to use. There will likely be a setting added in the future to automatically toggle it while gliding. This feature is not meant to make manual piloting obsolete, so if you find yourself using the functionality even when you would have preferred not to, please provide feedback to help us make it more balanced. I've specified some more appropriate masses for some species and increased the (logical, not visual) size of some objects (which makes them a little less... aerodynamic). I also scaled down the resulting knockback on entities of a mass under 40 kg, which hopefully removes the involuntary bird-golf minigame from hammer combat. It, together with increasing the max possible drag applied to an entity per tick (which is a necessary safeguard against very bad bugs), should prevent loot drops from sometimes flying off into the distance when a mob dies immediately from an attack with knockback. </figure> Meat and crafting by @Slipped</h3> I'm finishing up a rather big MR that adds a lot of the core of Veloren's armor progression system. It's sort of grown into a bit of a behemoth but I'm ok with it in this case because I think doing this all at once is very helpful towards building a single, cohesive system. The goal of the MR is to get three things to work synchronously: loot, crafting, and gear. The MR started with loot, as a simple meat MR designed to give different animals different meat drops that you can cook in towns to help with combat. This gave a cheaper, non-potion option to healing, and made sure there's always something to be gained from simple combat in the wild. Once animals dropped appropriate meats we wanted to flesh out their loot tables to a more finalized state, and we knew we wanted them to drop hides. So animals now drop specific hides (animal hide/tough hide/scale/carapace/plate/dragon scale) depending on their type and overall difficulty. </figure> From here we get into crafting, since we obviously needed something to do with these materials. So we started re-imagining the crafting system. From the hides you can now craft leathers, and use them in different recipes, so the system goes much deeper than simple leather scraps like before. Making hides into leather doesn't get you much without a final, usable product though, so after that we started bringing in Gemu's armor sets to finalize progression of the 'hide' armor track. Next, covering only hide seemed a little lame so we expanded to the mail and cloth armor tracks. These armors are craftable mainly from ingots (which can be smelted in the new forges) and cloths (which can be spun in the new spinning wheel, and crafted into armor in new loom stations). Next, these ores weren't actually accessible yet so we've started on a minor cave overhaul to add distinct difficulty levels to caves, so you can fight your way through tougher enemies to reach deeper levels with better ores for the best armor. </figure> Adding new plants for cloth armors is also on the progress list. The different armor tracks need to actually do something unique, since in Veloren right now, armors just give you armor. After a lot of back and forth, we sorted an initial implementation: - Mail: highest armor - Stun resistance hide: high critical hit damage - Stealth cloth: higher energy total, higher energy rewards </code></pre> Stats have been graciously added by @Sam. Each of the tracks has six "core" armors associated with it, along with possible spinoff armors later. The tracks are considered equal (for armors of the same vertical level) but benefit different playstyles. The game is transitioning to more of a crafting-based gear system instead of findable gear, with the player needing to find the materials for each set, which might require you to explore multiple areas. Far-off ridges to explore. See you next week! </figcaption> </figure> This Week In Veloren 120 Mon, 17 May 2021 00:00:00 +0000 This week, we have some nice visuals to check out. We also see some updates to the minimap. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Snowram, @James, @xMAC94x, @nwildner, @Sharp, @Slipped, @juliancoffee, @Same, @holychowders, @Pfau, @hqurve, and @imbris! You can see this week's meeting notes here</a>. Your browser does not support the video tag. </video> Out of the house and through the valley, by u/Russhang </figcaption> </figure> @Yusdacra packaged Airshipper for NixOS and implemented NixOS-specific executable patching, so now it can be used on NixOS without Flatpak. Currently, these changes are on the staging branch of Airshipper repository. @R.A.B added a chat tab system. It allows players to select filters for different tabs of the chat. @holychowders got NPCs to hear and respond to sounds. </figure> </figure> Minimap by @aweinstock</h3> This week, I added a minimap mode where voxel terrain data is visible on the minimap. For each loaded chunk with some radius of the player, it builds a map of what's visible looking downwards from each z-level. It uses the maps to efficiently build a composite image of the currently loaded chunks from the ceiling above the player, in a manner that works nicely with dungeons, caves, and houses. </figure> I also fixed the mind flayer AI so it can summon minions at HP thresholds again, and added a purple fireball attack that it uses when the player is out of range. </figure> Blossoming trees. See you next week! </figcaption> </figure> This Week In Veloren 119 Mon, 10 May 2021 00:00:00 +0000 This week, we take a deep dive into the recent physics overhaul with @lboklin. We also see improvements in the moderations, translation, and skill systems. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Slipped, @xMAC94x, @juliancoffee, @Snowram, @Pfau, @Sharp, @zesterer, @aweinstock, @aws107, @nwildner, @James, @Danielduel, @imbris, and @Yusdacra! At this week's meeting, we set a release date for 0.10 to be June 5th. We have had a ton of changes over the last few months, and we're excited to get a formal release together! We've also recently passed 1000 stars on both GitLab and GitHub! This week, @Sam has been reworking clay golems. @Sharp fixed shadows in wgpu, which means that the last blocker to get it merged is OSX builds. Changes have also been made to improve how moderators have control over a server. Moderation tools by @Sharp</h3> I just finished up a decent-sized change that allows timed bans and non-administrator moderators (which involved a few updates to the security model). It also switches us to a versioned settings file for editable settings and migrates from the old format, so going forward we can add metadata and stuff to settings files without breaking backwards compatibility. This should be the precursor to nicer mod tool functionality. </figure> Skills and translation diagnostics by @juliancoffee</h3> I've added /skill_preset command which allows you to unlock pack of skills or reset your skillset to fresh character. Currently, there is only one 'max' preset which just instantly unlocks all skills and upgrades it to max level, but new presets can be added in 'assets/server/manifests/presets.ron'. Also I created binary to run diagnostic of specific language for translators by extracting i18n code to its own crate. With no serious dependencies, it compiles very fast even from scratch and allows to get quick feedback on changes to localization. For anyone who uses the /spawn command I also have good news. I added auto-complete of species (before it was just body kind, like biped_large</code>). Updates by @aweinstock</h3> I did the following this week: Added damage types (Piercing, Slashing, Crushing, Energy) to combat skills; Piercing attacks (such as arrows) now partially ignore armor damage resistance.</li> Fixed an issue where projectiles would miss entities that had terrain too close behind them (primarily small things like squirrels from a downward angle, or cultists next to walls).</li> Made merchants nametags visible at a higher distance, since players had difficulty finding merchants in towns.</li> Added a pulsing red warning on the 2nd phase of a trade when one party is trading no items, since players were mistakenly giving merchants items for free.</li> </ul> </figure> New playable species by @Pfau</h3> We discussed new playable species and came up with these things: The undead will get a visual overhaul to look more like Draugr from northern mythology (Don't worry, they will still look like undead!)</li> The actual new species we will introduce over the course of the next months are: The Aunqa: Elemental/Geode style species with oriental features</li> The Morx: Bird/Crow species with a Gothic/Steampunk/Pest-Doctor theme</li> </ul> </li> </ul> (Screenshots coming whenever we got something to show off...) Implementing physics and then glider physics by @lboklin</h3> </iframe> </div> </figure> Physics in Veloren has been a long road for me. It began some time after discovering the game late last year, when I decided the gliders could be more than they were. How hard could some basic aerodynamics simulation possibly be? There were a couple of false starts, a lot of refactors and changes in approach. I submitted my first draft MR a few days before the end of last year. It began a bit rough, with a lot of little quirks since I didn't really understand what I was implementing and what I wasn't. I spent a good few weeks on controls alone. Finding an intuitive way to control 3D movement that gives justice to the complexity of the gliding mechanics was one of the hardest things, and making it look and feel right was even harder. As time went on I kept coming up with complex solutions to complex issues. At some point I asked myself whether this one mechanic in the game justified implementing rigid body dynamics. I decided that even if it did, I didn't want to bother with it then, or I would never get anything done. I wanted to reduce the size and complexity of the MR, so I began splitting things out that wasn't directly related to the hardest part of glider physics, such as some much needed refactors, basic Newtonian physics, and equations for things like drag to replace the hacks that powered the old physics system. So then I took some time off from working on gliding to get these prerequisite features and changes into the game. I managed one small MR before creating another monster that was the addition of masses, densities, basic implementation of buoyancy, and aerodynamic drag (with all the fluid types and relevant fluid dynamic equations). Admittedly, buoyancy didn't really have to be part of it, but it made contextual sense and so I added it anyway because I have no sense of priority. </figure> These massive changes more or less fundamentally broke or changed the way every physical entity interacted with each other. Knockbacks now depended on mass and applied impulse strength; pushback from collisions made moving some things much less feasible while other things like campfires and turrets now slid around when pushed; projectiles used to have their own gravity to give them a custom arc which obviously wasn't very compatible, so that changed as well (which required implementing proper projectile motion prediction by enemies, which @James helped me with). And we haven't even gotten to the water and air interactions! If it weren't for @Ygor's endless testing and feedback I would still be fixing numerical mistakes and tweaking values to this day. In addition to entities being assigned mass, I also gave them density. By giving entities a density I could then use that to derive buoyancy under the simplifying assumption that their mass is equally distributed over their height, so as they become submersed in water their effective weight is reduced based on the ratio of (toe) depth to their height. The gravity experienced by an entity is gravity * (density - fluid_density) / density</code>, where fluid_density</code> can be a mix of density of air and density of water if partially submersed. In the end, this allows things to float or sink based on this modifiable density component. As a proof of concept, I made airships control their elevation via modifying their density (which is the equivalent to pressure regulation in real life) and the capability for airships to become water ships by rapidly "deflating" their magical lighter-than-nothing balloon, leaving the ship with a density more or less equal to that of a normal 18th century sailing ship. </figure> Now that entities had masses I also had to define some more accurate dimensions for entities (which had previously only been defined using height and radius) before I could begin to derive aerodynamic drag for them. Once everything had dimensions along each axis, it was time to implement the drag equation. Aerodynamics, which is a subfield of gas dynamics and more generally fluid dynamics, are hard. It's one of the big unsolved problems in physics, and best we can do to make accurate predictions is through numerical methods, but we can't afford that in a game that isn't (just?) a flight simulator. We have other things to simulate and compute, so running a full-blown fluid simulation for each and every entity in the game just to get precisely accurate aerodynamic behaviour is not anywhere on the table, unfortunately. Thus, my approach has been to find simplified models and analytical formulas with empirically derived coefficients as a substitute for fluid interactions we can't mathematically describe. For each body type I had to define a drag coefficient, which is an arbitrary dimensionless constant which represents how approximately aerodynamic something is, and a reference area to complement it. The reference area is a number derived from the dimensions of an object in somewhat arbitrary ways, so that you can have two of the same type of shapes but of different sizes and have it affect the amount of drag affecting each. </figure> Both the drag coefficient and reference area have to be looked up in scientific literature for each type of shape, and in many cases there is more than one convention used. For wings it is usually the planform (surface area of the wing as seen from above), for (ellipsoidal) airships it is the square of the cube root of its volume, and for spheres it is the projected circle area. Using the drag coefficient and reference area together with Bernoulli's equation gives us the total amount of drag produced by an entity in the direction opposite to their velocity (relative to wind, specifically, but wind velocity is currently invariably zero). The above was the foundation I wanted in place before getting to the juicy part: aerodynamic lift. In comparison to lift, drag is quite easy: it's just drag_coefficient * reference_area * 0.5 * fluid_density * relative_flow_velocity²</code> applied as a force in the direction of relative_flow_velocity</code>. The formula for lift looks the same at this level of abstraction: lift_coefficient * reference_area * 0.5 * fluid_density * relative_flow_velocity²</code>, but it's applied in a direction that isn't necessarily perpendicular to either the wing's chord line (the line that goes from the leading edge to the trailing edge) nor perpendicular to the direction of flow. This is because of an effect called downwash, which is due to vortices forming at the wingtips that pulls the wind along in a backwards and slightly downwards direction, producing a force called induced drag (aka drag due to lift), which shifts the lifting force vector rearwards. The angle between the lift</code> and lift - induced_drag</code> vectors is called the induced angle of attack and it can be derived from the lift coefficient and aspect ratio of the wing. It's the lift coefficient that is the hard part. In my original attempt at implementing aerodynamic lift, I found this simple formula derived from something called the Thin Aerofoil Theory: it states that for an infinitely thin 2D aerofoil, the difference in lift over difference in angle of attack for small angles (up to ~15±3° depending on model) is simply 2π, and the section lift coefficient for the aerofoil is then 2πα, where α is angle of attack. </figure> The section part of section lift coefficient is important, and something I struggled to reconcile with my goal at that point, because this 2D aerofoil is not only infinitely thin, but also has an infinite span. The significance of the infinite span is that it entirely removes spanwise flow (and thus wingtip vortices) from the equation, which means no induced drag. So what do we do when gliders most definitely have a finite span and glide around in 3D space? I did not like the idea of deriving lift using this equation by simply multiplying the section lift coefficient by the number of aerofoil sections that would fit along the span the wing, partly because it just felt wrong and inappropriate, and partly because I had no solid understanding of what the actual consequences and trade-offs would be. Maybe it would be fun anyway.. maybe even more so than a correct model. Maybe it would feel a bit awkward but we never realise why or what we're missing out on. I didn't want that. To have players get used to erroneous behaviour and then maybe I (or someone else) comes back to fix these flaws and upsets everyone again in the name of some pesky realism and supposed correctness. So I went and borrowed a (really thick) book called Fundamentals of Aerodynamics (by John D. Anderson) and spent some time trying to learn and understand what was missing and to find out what I needed in order to simulate lift for a finite, 3-dimensional wing. The book was very helpful, and also conveniently spoon-fed me with some useful analytical formulas I could apply with the caveats of them only applying to specific types of wings at limited ranges of angles of attack etc etc. In the end I went with the most straight forward approach with the simplest solution for finite, 3-dimensional wings that also accounts for induced drag: by simplifying every wing shape to be perfectly elliptical, parameterised only by span length and chord length. With this simplification, we have a few equations that each handle slightly different cases for increased accuracy. For higher aspect ratio we have an equation derived from Prandtl's Lifting-line Theory. For lower aspect ratios we have a modification to that equation by H. B. Helmbold. For swept wings (which we aren't currently using) we use Küchemann's modification to the latter. The end result is what you can see right now on the live server (to the dismay of some players who really liked the old hover-gliders). </figure> The biggest caveat right now that I'm not entirely happy with but see no good solution to (which is not to say there isn't one!) is that I don't know what to do with lateral wind. The equations simply don't account for side-slip (or yawed orientations), because the shape of the wing is then effectively skewed from the perspective of the oncoming wind, which changes the effective aspect ratio, spanwise flow and vortices at each wingtip, which consequently affects the induced drag and angular momentum in general. Speaking of angular momentum: it's the trickiest part of rigid body dynamics by far, and is the reason I decided to forego that route in favour of simpler solutions to glider handling. That is to say we don't calculate the angular forces at all for either glider or pilot, so the lift and drag forces do not change the orientation of either. The character pendulum effects are a complete hack. This is why it's even more unfortunate that lateral wind is ignored since it ought to have a noticeable effect on the glider's rotation. Aside from the issue of lateral wind, I would say the controls are the weakest point of the glider right now. It's something I'm currently trying to improve by removing the assumptions about what's up and what's down to allow freer maneuvers like loops and fully controlled rolls. I'm also not happy about the magical yawing, so I'm trying to work with roll and pitch exclusively. The heuristics for when and how to pitch and roll is turning out to be quite tricky, so we'll how that goes. In the future I would like to implement different wing shapes. Tapered wings should be quite feasible as the equations wouldn't need much modification to account for it. Delta wings I'm not so sure about, but it's not out of the realm of possibility. On the less physics-heavy side of things I would also like to see gliders having individual dimensions (and shapes in the future; hopefully we'll see more aerodynamically shaped glider models too). I also hope to have something to share on the topic of wind in the near future, but this is all for now. Two explorers, ready to set out on a quest. See you next week! </figcaption> </figure> This Week In Veloren 118 Mon, 03 May 2021 00:00:00 +0000 This week, we see an amazing video of the new glider changes. Work is being done with audio, UX/UI, economics, maps, and lots more. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @xMAC94x, @juliancoffee, @Sam, @aweinstock, @LunarEclipse, @Slipped, @James, @Danielduel, @Nereux, @XVar, @Pfau, @zesterer, @lboklin, @Jandre, @DaforLynx, @Snowram, @Synis, @Yusdacra, @bronson! </iframe> </div> </figure> @DaforLynx added the ability for music to play exclusively in towns. This included sifting through some of the site code, but it now works quite reliably. As a side effect, dungeon music should no longer play where there isn't a dungeon! The new tracks are by @badbbad and @sharpie. And with that, pretty much all the music that has been made for the game that can be implemented - has been implemented! @zesterer added custom location marking this week </figcaption> </figure> @christof created a simple spreadsheet to simulate econsim internals. GHI are goods, LMN are professions, R is a natural resource, G as food controls the population. Econsim is now much faster during server startup, but still debug has some unintended differences. @Sam got the minotaur merged. </figure> @holychowders fixed villagers spamming messages when they see an enemy in a safe zone, and now they're trying to get NPC's to be aware of sound. @DaforLynx created and implemented SFX for the poise system. There are distinct SFX for each level of stun, which should hopefully help the feel of combat. @James worked on adding mountain names, lake names, and markers for both on the map. They also worked on various AI fixes and refactoring. </figure> </figure> @aweinstock worked on optimizing the encoding speed of terrain compression a bit more. It turns out that since PNGs use a separate zlib stream for each row, wide images encode faster than tall images: </figure> @Snowram has been working to make mounting visually pleasing, with the hope of making it player-facing soon. @Danielduel implemented part of @aweinstock's proposal for a Turing-complete wiring system</a>. Currently, the /wiring admin command will summon a pressure plate and an arrow emitter, such that when the pressure plate is stepped on, the arrow emitter emits an arrow. While it doesn't have logic gates yet, it's likely already advanced enough to start adding traps to dungeons. Your browser does not support the video tag. </video> </figure> Work by @juliancoffee</h3> I have been working mostly on the UX of debugging tools and some other fixes. I added the ability for translators to translate buff outcomes in death messages. I've updated kits and split debug kit to real parts and cosmetic, added bijou to cultist kit, and mushroom curry to potion kit (which I've renamed to consumables). </figure> </figure> I added checks to /dropall</code> command so it won't drop Debug items on ground (and prevent admins from giving OP things to players while clearing inventory). I implemented /buff command which allows cast buffs or debuffs on player (on yourself or someone else with sudo). Dungeoneering begins. See you next week! </figcaption> </figure> This Week In Veloren 117 Mon, 26 Apr 2021 00:00:00 +0000 This week, we get a deep dive into how world chunks are compressed and sent over the network. We see updates on the packaging front, and some amazing new creatures. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Slipped, @Sam @xMAC94x, @juliancoffee, @zesterer, @holychowders, @aweinstock, @Pfau, @alfy, @XVar, @Snowram, @James, @Adalovegirls, @ygor.souza, @nwildner, @lboklin, @YuriMomo, and @imbris! @zesterer added the ability for characters to hold their lantern when their right hand is free (i.e: when not wielding, or when using a single-handed weapon). @Pfau is in the process of remodelling the lanterns so they have a handle. The swinging animation looks surprisingly realistic given that it's entirely 'fake' (no physics is being simulated). Your browser does not support the video tag. </video> </figure> @alfy made some brand-spanking-new block and parry sound, as well as tweaked the wind sound to be a bit more organic. @LunarEclipse made a few improvements to Torvus, most notable is messages from Matrix are now bridged to Veloren in #ingame-chat. A full list of changes is included in the MR description</a>. @juliancoffee fixed off-by-one error in localization tests, so outdated fields are now a more reliable way to check if a translation is up-to-date than before. @XVar added more player-friendly error handling for network errors caused by client/server version mismatches. You will now get a dialog informing of a version mismatch if a version mismatch is detected and a networking error occurs during login after the server version is fetched. If login does succeed but there is still a client/server mismatch a warning banner is shown on the character select screen. @Snowram created a new skeleton that will fit big winged creatures. They also made several animations for it and collaborated with @Gemu to make a phoenix model as well as transition the existing cockatrice NPC to the new skeleton. @Snowram also coded a combat AI for those new NPCs with the help of @James. Daytime-specific NPCs spawns were also added. Your browser does not support the video tag. </video> </figure> Your browser does not support the video tag. </video> </figure> @juliancoffee fixed the burning debuff icon, which was previously displayed as a question mark on the hotbar. @Christof brought English as a fallback language to the finish line and resumed work on accelerating econsim using arrays. Packaging Airshipper by @Frinsky</h3> I have kept going with packaging Airshipper. There is now a PPA available for Ubuntu-based distributions: https://launchpad.net/~frinksy/+archive/ubuntu/airshipper</a>. Packages are available for Ubuntu 18.04, 20.04, 20.10, 21.04 and their derived distros. Additionally, I have made more packages available in my Copr repository (https://copr.fedorainfracloud.org/coprs/frinksy/airshipper/</a>) to support more distributions. There are now builds for Fedora 32/33/34/Rawhide, Mageia 7/8/cauldron and openSUSE Leap 15.2. I am also planning on creating a comprehensive page with installation instructions for each distribution, to help new players get into the game more easily. Finally, I've submitted an Airshipper flatpak for inclusion into the Flathub repository, and it recently got merged and is now available here</a>. Compression by @aweinstock</h3> I've been working on better compression formats for terrain chunks for sending them over the network. This is intended to help players with poor connections be able to play on servers in the first place, and to allow players with good connections to comfortably set a higher view distance to load more chunks at once. I've already merged a format that reduces the per-chunk space cost by 1.5x lossless, and have a few formats on a branch that can give another 5-9x reduction with some reduction in visual quality (but no cost to gameplay accuracy). Terrain and lossless compression</h4> Veloren only stores a very coarse heightmap of the world on disk. For a 1024x1024 chunk world, the mapfile is around 16MB, which is only 16 bytes per chunk. Pre-generating this is an expensive step, "worldgen", which simulates geological processes including erosion. Chunks are generated with 32x32xZ voxels of data when their location comes within a player's view distance (Z varies per chunk). The in-memory structure (a "Chonk") consists of a z-offset for the bottom of the chunk, a vector of subchunks, and two default blocks for above and below the chunk. The subchunks are 32x32x16 slices, and internally deduplicate adjacent blocks of the same kind. These chunks tend to be a few hundred kilobytes each. Previously, chunks were compressed the same way that most network traffic in Veloren is, with LZ4, achieving around 25% of uncompressed size. LZ-family algorithms accomplish compression by referencing previous occurrences of the data within the same file. This works great for text: the string " the "</code>with spaces included occurs often in English, and a reference to a previous occurrence of the string " the "</code> can save up to 5 bytes if the instruction to do a backreference takes less than 5 bytes. By backreferencing from the current position, you can also compress 200 copies of the same letter/voxel by emitting an instruction like "from 1 position backwards, copy 199 characters". </figure> When I printed out some statistics on frequently occurring byte patterns in Chonk</code>s, I noticed that they had long runs of 0 bytes (which is good for LZ4), but sparse positions of other bytes, positioned seemingly randomly in the window size I was using. Since most of those bytes had a few common values, I tried using deflate, achieving around 17% of uncompressed size (with a quality setting that had a similar encoding time to LZ4). Deflate is the algorithm used by zip and gzip, and is a mix of LZ77 and Huffman coding. Huffman coding computes statistics on the input, and uses fewer bits to encode more common symbols. For example, in English text, "e" occurs more frequently than "z", but ASCII encodes both of them as 8 bits. With Huffman coding, it's possible to use fewer than 8 bits for "e" (like 3-4), and more than 8 bits (like 10-11) for "z". Huffman also synergizes nicely with LZ because the backreference instruction doesn't to be given a byte representation manually, it's just another abstract symbol that occurs with some frequency, which can get allocated a bit-sequence by Huffman coding. Spatial locality and greyscale PNGs</h4> LZ4 and Deflate operate on one-dimensional sequences of bytes. When applied to voxel data, this makes a x-aligned wall compress really well (since it's a run of adjacent bricks of the same kind and color), but a y-aligned wall or z-aligned pillar doesn't correspond to a contiguous run of bytes. LZ4 and Deflate also don't assume much about the statistical model of the data, so they don't compress increasing or decreasing runs of adjacent bytes (e.g. color gradients). PNGs handles both of these concerns for 2d pixel data losslessly by using delta-encoding with a packing order, such that horizontal gradients get encoded with instructions like "copy left color and add 1" and vertical gradients get encoded with instructions like "copy above color and add 1". This makes the byte stream have contiguous runs of relative positions and offsets, which then compress well with deflate. Greyscale channel of 3x3 chunks centered on a dungeon </figcaption> </figure> Color channel of 3x3 chunks centered on a dungeon </figcaption> </figure> Each 32x32x1 slice of a chunk can be treated as an image. Encoding them as separate images per z-level would cost lots of space to image headers, so I pack all the z-levels for a chunk into a single image. Encoding each z-level into a square image, packed next to each other left to right, then packed as rows top to bottom, works well for visualizing what's going on, but wastes space if chunk height isn't a perfect square. Encoding a tall image, with each z-level stacked vertically in the image, doesn't waste any space. Additionally, flipping every odd z-level across the y-axis improves spatial locality, which translates to improved compression ratio and encoding speed in practice. The gameplay-critical part of terrain (BlockKind data used for collisions, and sprite attributes used for interactable objects like treasure and plants) are stored in greyscale PNGs with 1 byte per voxel. This is around 1-2% of the uncompressed Chonks, and is the best format for it I've made so far, though it might be possible to do slightly better on this part with custom space-filling-curve orderings to improve locality. Lossy compression for colors</h4> The color data for blocks is much more expensive than the gameplay-critical data. Encoding it in an RGB PNG losslessly gives 16% compression ratio (barely better than deflated chonks). Currently, the leading techniques for lossy compression of colors are: 256-color palette (throws away all the color info except for what's already knowable from the BlockKind, basically free)</li> low-quality JPEG (2-3% of uncompressed size, but has horrible artifacting)</li> Quarter-resolution PNG (3-5% of uncompressed size, but looks reasonably good, and allows control over artifacting).</li> </ul> Town with 256-color PNG colors </figcaption> </figure> Town with JPEG colors </figcaption> </figure> Town with Quarter-resolution PNG and no upscaling </figcaption> </figure> Town with Quarter-resolution PNG and Lanczos upscaling </figcaption> </figure> For improving the aesthetics of the quarter-resolution PNGs, @LunarEclipse is tuning an implementation of Lanczos interpolation, which sweeps a convolutional filter across the image to upscale it in a way that tends to keep good edges (like road paths) and blur bad edges (like block artifacts). An endless landscape in the morning. See you next week! </figcaption> </figure> This Week In Veloren 116 Mon, 19 Apr 2021 00:00:00 +0000 This week, we see lots of changes in the realm of network physics. New crafting stations are being implemented, and music is getting optimized. Inventory improvements are also being made. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @zesterer, @imbris, @Capucho, @juliancoffee, @James, @Sam, @UMR1352, @aweinstock, @nwilder, @XVar, @Sharp, @Yusdacra, @DaforLynx, @gGmMsS123, @Slipped, @hqurve, @Pfau, @holychowders, @kinggred, @socherbyc, and @Frinsky! @DaforLynx recompressed all the music and converted all sounds to the OGG format, as well as changed the stone footstep sounds again - new ones are made by @alfy. @Sam made safe zones remain permanently in the spawn chunk. @Sam also did some backend work on blocking and parrying, it now just needs animations. Both will use the same button, however, if you release the block button quickly, it will become a parry, if you hold the block button it will remain a block. @Pfau and @zesterer have been working on crafting stations: sprites like anvils, cauldrons, workbenches, and cooking pots that are required to craft certain recipes. Hopefully, it'll add an extra layer of depth to the crafting system. Crafting stations are shown in the crafting menu now. Interacting with a station opens the corresponding crafting tab. </figure> </figure> @XVar added a button to sort your inventory, which toggles between 3 different sort orders. They also fixed a bug that caused UI components to move around when they shouldn't, and the Diesel to Rusqlite MR was merged. @Christof worked on an older merge request by @Ada about displaying English as a fallback translation. After a deep dive into asset manager and its data structures @Christof came up with a novel design that the borrow checker could agree to. It still needs some work to get mergeable though. Server physics by @aweinstock</h3> I added a per-player setting to switch between server-authoritative and client-authoritative physics. With client-authoritative physics, which was previously the default, anyone could set their position and velocity arbitrarily, allowing them to teleport and fly. This isn't possible with server-authoritative physics, which makes it nice to have as an option (which admins can force with the /server_physics command). </figure> Server-authoritative physics is currently less smooth, and causes you to feel more of the latency of the connection to the server. Despite feeling less smooth, it gives you a more accurate understanding of your position, which prevents issues like wandering into a dungeon, thinking you've avoided some attacks successfully, and then dying minutes later because your inputs arrived too slowly. Once we get better interpolation (and possibly rollback netcode) and server-authoritative physics is sufficiently smooth, I hope that server-authoritative physics can be made the default mode. Your browser does not support the video tag. </video> </figure> Dodge roll and fireball staff previously required skill points to be spent on unlocking melee invulnerability-frames and fireball explosions, respectively. To make these skills more useful to new characters, I made these upgrades available by default, and refunded the points that existing characters had spent on them. The fireball staff now starts out with smaller explosions, but has an extra rank of radius-upgrade and gives a bigger increase per level (15% vs 10%). A snowy glide through the mountains. See you next week! </figcaption> </figure> This Week In Veloren 115 Mon, 12 Apr 2021 00:00:00 +0000 This week, lots of work has been done on combat audio. We also take a deep dive into Veloren's financials, as well as a newly-provisioned dedicated server. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Ceikry, @XVar, @juliancoffee, @Sam, @VincentFoulon80, @Sharp, @Pfau, @aweinstock, @DaforLynx, @law4x, @hqurve, @imbris, @BuildTools, @Snowram, @mdx97, @davidruizagustin2002, @ccm7676, @UMR1352, @zesterer, @Desttinghim, @romulans, @James, and @kimamb! This month's Rust Gamedev blog is out, be sure to check it out</a>! @Sam overhauled loot tables to allow them to recursively reference other loot tables in addition to items. @Destinghim added travelers back into the game and made them follow paths. @Ceikry added a setting for resetting inputs when chat is opened. They also added ctrl-click and shift-click info to item tooltips when trading, and updated the book slightly. @Ceikry also improved trading sanity by making sure the server denies active trades in the case that a player logs out during a trade. </figure> @Ultimafounding has some plans for some new music in the next few weeks. There is also a lot of other audio content coming in from @Flashbang, @DaforLynx, @Aeronic, @badbbad, and @alfy. Songs have also been revamped for distribution over biomes. @Pfau has been working on some new map mode button visuals. @aweinstock made villagers, guards, and merchants able to drink potions and eat food. @juliancoffee fixed a bug in localization tests which caused them to incorrectly find lines of keys in .ron</code> files. Now if tests are showing that there are some untranslated fields, they are really untranslated and not just a false positive. </figure> Combat Audio by @aweinstock</h3> I extended the music system to support combat music. Previously, there was an activity field for the soundtracks that could be either Explore</code> or Combat</code>, but nothing was making use of the Combat</code> state. With my changes, the field is now music_state</code>, and can be either Activity(x)</code> or Transition(x, y)</code>, where x and y are in {Explore, Combat(Low), Combat(High)}</code>. </figure> The system tracks how many nearby hostile enemies there are, and heuristically determines whether the player is in combat, and if so, how intense the combat is, to select a track to play (and the corresponding transition snippet for that track). Currently, the only combat music is @DaforLynx's "Barred Paths", which plays in dungeons, but the system is general enough to support another biome, site, and time-of-day dependent combat music. Veloren financials by @AngelOnFira</h3> Recently, another big push was made towards provisioning our own dedicated server for Veloren's general use. Currently, we have a cloud server at Hetzner that we use to host the game server, as well as a server in Digital Ocean to host our auth, Airshipper CDN, and some other items. The idea of this dedicated server is that it will allow us to lay the foundations for future federated server clusters all around the world. As the project grows, more players will want to play on the servers, and geo-located hardware will be necessary. Further, the number of services that Veloren makes use of will also go up. Here is a list of some items: - Website - Wiki - Book - Auth - Airshipper CDN - Veloren test server - CI - Grafana - Prometheus - Main game server - Discourse </code></pre> </figure> Now not all of these items need to be hosted by us, and many are distributed, like CI. But historically these have all been hosted on donated compute from the contributors. Lots of this can be re-deployed onto a dedicated server. After doing an audit of how our financials are looking month to month, I created a spreadsheet that should encompass everything. This process helped clear up a few discrepancies: The amount we're paying for bandwidth from Digital Ocean will increase further if we keep using their CDN.</li> A mistake was made in several previous Digital Ocean invoices, which has been since resolved.</li> Many of our services are distributed over many different servers that aren't necessarily controlled by the Veloren core team.</li> We had no tracking of our monthly revenue, compared to how much we spend in operation costs.</li> </ul> You can check out the spreadsheet here</a>. I also created a more formal proposal and reasoning document for the dedicated server. You can see that document here</a>. Hopefully, this financial progress can help lead us to have a better handle while we move forward on further server provisioning. A small fire at night </figcaption> </figure> This Week In Veloren 114 Mon, 05 Apr 2021 00:00:00 +0000 This week, we see lots of changes to trading systems. New sound effects are being worked on, and new visualizations for maps are being made as well. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Sam, @xMAC94x, @theCow61, @Pfau, @aweinstock, @HunterTParks, @1b15, @Slipped, @DaforLynx, @tonyvu0605, @Sharp, @Christof, @Snowram, @nogajun, @VincentFoulon80, @Songtronix, @aljazerzen, and @James! @Songtronix Squashed/fixed Airshipper bugs in preparation for its 0.5 release. There is still a lot to do, but the backend is mostly figured out. @Pfau worked on crafting window tabs with icons by @VincentFoulon80, with bug tracking and programming support by @aweinstock and @imbris. Window tabs </figcaption> </figure> @Gemu has been working on more gear set models, which will lead to animals being able to drop different crafting materials which can be used to craft the new gear. @DaforLynx has been working on more sound effects for combat. @LunarEclipse worked on improving the readability of Torvus. @Christof created an updated 0.9 economy tree. The leather line-up of new gear </figcaption> </figure> @James has been going through new variants of what the map could look like. @aweinstock worked on some changes to trading. @LunarEclipse made some big improvements to the readability of Torvus by making different message kinds from Veloren look different on Discord as well. You can check out the MR here</a>. Torvus readability changes. Left is old, right is new. </figcaption> </figure> Sound effects by @DaforLynx</h3> I implemented more sound effects for combat using the outcome system. A sound will emit from a struck entity when attacks connect, similar to what @zesterer did with arrows earlier this week. The new sounds were made by @Flashbang. Planned for the future are further diversifying the sounds based on things like weapon used, armor worn, etc. How is the trading price calculated @Christof</h3> It all starts with an economic simulation of the resources available to a town. Each chunk counts as terrain</code> towards the closest town (site), with the different biomes</code> providing different potential goods</code>. Guards turn this into controlled territory</code>. The most important good</code> is food as it determines the maximum number of inhabitants of a town. As long as there is enough food, the population will grow (exponentially). Of course, the recursive raw materials needed to cook food and to produce equipment for guards create an interesting cycle. Merchants will travel to neighboring towns and trade extra goods for missing ones, a maximum transportation capacity per merchant considered. The ratio between annual need and stockpile determines the local value for each Good. This number is typically between 0.1 and 4.0 and varies between towns (due to access to different resources). To generate a price for a specific item</code>, the rarity of the item (as derived from loot tables) is translated into an equivalent amount of good</code> (a rare weapon translates into a large amount of tools</code>). Here the individual weight of a loot table is tuneable (more dangerous encounters associated with a loot table should result in lower probability). The most common item per good</code> is normalized to a given amount of this ware. Only towns with a high enough extra stock of that ware can offer rarer goods (as the equivalent can never exceed to local unclaimed stock, currently these limits are hardly perceived though). And last but not least the merchant will sell items at a higher cost than they bought them for. As in real life, consumable goods (food, potions, ingredients) achieve a better buy-to-sell price ratio than investments (armor, weapons). PS: For coin, there is no definitive need, so it uses the starting amount per town for an annual consumption to calculate local value. Some fortunate towns accumulate coin from their neighbors, some towns have nothing to offer and spend all their money on buying missing goods. I finally created an updated 0.9 economy tree, see devblog 99</a> for the much simpler old one. </figure> Maps by @James</h3> Recently, I've worked on making the map more "map-like". I'm still going through lots of options and variants: </figure> </figure> I've separated this map into three layers that are all stacked on top of each other. The first layer has hill shading, lake shores, rivers, and coastlines on a yellowish background. The second layer is terrain color with a reduced alpha channel. The final layer applies the contour lines and redraws the roads on top. I've also given the minimap layer support. </figure> Trading fixes by @aweinstock</h3> I made more changes to trading: When trading with a merchant, ctrl-clicking an item will automatically insert/remove enough of that item to balance the trade with the current prices. Shift-clicking will add/remove items from a trade one at a time.</li> Merchants now spawn with stacks of stackable items.</li> The buy/sell prices when trading with an NPC are heuristically colored: if buy is green and sell is red, it's probably a better idea to buy that item then sell that item at that site.</li> </ul> A fight with the Mindflayer! See you next week! </figcaption> </figure> This Week In Veloren 113 Mon, 29 Mar 2021 00:00:00 +0000 This week, we have lots of work being done on optimization fronts, as well as world improvements. We hear from several developers about what they've been working on this week. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Snowram, @Sam, @zesterer, @xMAC94x, @Capucho, @imbris, @Treeco, @XVar, @Sharp, @aweinstock, @SWilliamsGames, @Christof, @Pfau, @Slipped, @Desttinghim, @aljazerzen, @yusdacra, @Quibble, @Synis, @steanne, and @heydabop! </figure> This week, @Sam got the Mind flayer merged. @Songtronix was working on some bot upgrades. @YuriMomo has been keeping up with testing new features. @zesterer overhauled clouds to make them faster and prettier. @Treeco added a command to teleport to sites by name, and a server setting to specify the player spawn site. @Treeco also generated a new default map, and another larger one for the server to switch to. @XVar completed the switch from Diesel to Rusqlite, which should make working with the database code simpler as well as provide full SQL trace logging. @Desttinghim added commands to define build areas. This allows admins to set up specific areas where building can be done. Individual players can be given permission to build in these. </figure> Mind flayer by @Sam</h3> The Mind flayer has 4 new abilities. It can attack you with cursed flames, which not only burn you, but also drain away your max health. It can create a necrotic vortex to drain the life from surrounding creatures and replenish its own. It can step through dimensions, to instantly teleport to you across short distances. And it can summon husks of previous victims it has devoured to fight for it. Terrain messages by @xMAC94x</h3> </figure> Terrain messages are now handled in multiple threads. You can see a visual improvement from the left side to the right. Especially on HIGH load, such as release parties, this helps us stay stable. It also increases our Multi-core usage from 69% to 71%, therefore increasing the efficiency of high CPU core servers that we provision for large events. Various goodies by @aweinstock</h3> I fixed a server-side .expect</code> failure on entity/UID lookups when a player disconnected during a trade.</li> I added coin-denominated prices to the item tooltips during a trade.</li> A few price-related fixes: Glowing Remains were previously Ingredients</code> instead of Armor</code>, resulting in it being 15x cheaper than the finished Mind flayer Spell bag.</li> Diamonds (and gems in general) were too cheap because the weights of the loot tables containing them didn't match rates at which the loot tables would be rolled in-game.</li> </ul> </li> I added some steeper spiral stairs to dungeons, with a hole in the center that can be glided down.</li> Airships/birds now cast multiple rays below/in front of them, so it's more likely that they'll detect trees/cliffs and rise in time not to get stuck.</li> </ul> Wating for the ride to the next village. See you next week! </figcaption> </figure> This Week In Veloren 112 Mon, 22 Mar 2021 00:00:00 +0000 This week, 0.9 released. We hear about some changes that were made during code freeze, as well as some stats from the release party. A survey was sent out to Veloren players and we see some responses from that. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @xMAC94x, @Slipped, @zesterer, @VincentFoulon80, @RedlineTriad, @aweinstock, @Sharp, @imbris, @Christof, @Snowram, @Sarra_Kitty, @DaforLynx, @TormodHellen, @Pfau, and @James! This week Veloren 0.9 was released! @Sam started reworking the mind flayer boss. It will have new attacks and a new AI. Any other information about it will need to be discovered through gameplay when it merges!@VincentFoulon80 worked on implementing three new skills: climbing speed, climbing cost, and swimming speed. @zesterer added a pickaxe, which can be used to collect gems and break weak rocks. @baddbad created a video to show off some Veloren gameplay, and it is being added to the website. Your browser does not support the video tag. </video> </figure> @yusdacra got Nix builds working again. They switched the build to use naersk</code> instead of crate2nix</code>, so there shouldn't have be a generated file each time Cargo.lock / Cargo.toml changes (which also means the build files should always work!). @AlbineAxolotl is working on some weapons based on ones from the Philippines. Here is a kampilan: </figure> Feature freeze work by @aweinstock</h3> For feature freeze week, I mainly worked on bug fixes: Interpolation was mistakenly being applied to the client's entity under certain circumstances, causing the player to fly away at high speed or get locked into place if they entered character select before the bug was fixed.</li> Mounting was temporarily broken by a physics optimization (the player character's orientation and the mount's position would be updated, but the player's position wouldn't be locked to the mount's).</li> The Agent system (NPC AI) wasn't correctly enabling fly mode, causing airships and birds to just slowly hop forward along the ground instead of flying.</li> During the release party, under high server load, the physics system would get a higher-than-normal delta time value for the tick, causing gravity to be applied unevenly, manifesting in ticks where waves of people took lethal fall damage while standing still on the ground.</li> </ul> I also have a few fixes and features in the merge queue for once the feature freeze ends: Merchants previously tried to accept trades multiple times, instead of only accepting when they haven't accepted yet, resulting in lag and sometimes making it to the review phase of a trade they end up rejecting.</li> Airships now fly properly without a health component, allowing them to be made invulnerable. This allows enabling RtSim airships flying between towns without players being able to hammer them out of the sky.</li> I'm adding a camera clamp angle and toggle to voxygen, to make it easier to see horizontally when rapidly rolling and changing angle (e.g. not ending up pointed at the floor or ceiling in the middle of combat).</li> </ul> 0.9 survey</h3> We put out a survey right before the 0.9 release. It was meant to gather some insights about the player's experience in Veloren. If you're interested in filling out this survey, you can do it here</a> </figure> </figure> </figure> </figure> There were also some open-ended questions. Here are some key insights from them: How well does Veloren run on your computer? It runs good enough for my laptop without a graphics card! </blockquote> Good on the NVIDIA [computer] terrible on AMD one </blockquote> I think it uses 30-45% of my CPU which isn't bad. </blockquote> It runs OK-ish I guess, but I struggle A LOT with high latency. FPS varies from 30 to 40-something (with medium settings, more or less). Ping 250ish to 500-something, peaking at 700, 800, even 900 sometimes. </blockquote> What are you most excited for in Veloren? Many things but you'd press me on a specific point... I would say the possibilities. I love Dwarf Fortress for a reason. I love Cube World (alpha) for a reason. And I am loving Veloren even more for the same reasons, but Veloren begs to keep offering more and more. Politics, faction wars, world generation and exploration, combat, building, the fact that all of this is possible, the fact that it will keep improving and be refined. </blockquote> That it's not stable and runs on main/master. Contributors just keep adding new cool stuff and it's playable immediately. Very easy to get hyped about this. </blockquote> Everything, maybe most urgently noob slaughter prevention. </blockquote> Adventuring and Exploring mostly! I really like the economy aspect I've read about in the devlogs and would love to see some sort of Town Creation? Like you can start your own little town and maybe send NPCs you meet during travel there. The town expands with income </blockquote> Story quests! I really like the gameplay so far but there is nothing to do other than grinding to your heart's content </blockquote> During my first experience while entering the game and making a character, I thought this game was similar to WoW, especially since it allows the user to choose a weapon while making the character. And since I was playing this game with my friends, I decided to choose a role like wow, one as a tank, another as a damage, and another as a healer. My friends and I really enjoyed this style of play, especially When I used a hammer to throw the enemies into a corner and we would trap it and damage it. But since the developers weakened Sceptre in the game, my friend reacted strongly to the game developers. </blockquote> An open and communicating community that listens and adjusts to feedback, without leaving everyone in the dark for years, only to change everything about the gameplay, that everyone loved. </blockquote> In your opinion, what is the biggest feature missing from Veloren? More contributors! Relating to the game... I would say world interactions. Going both way, how the world is influenced by your actions and how your actions will be influenced by the world. </blockquote> Pets persisting between logins </blockquote> In my opinion, the lack of a quest system is likely the biggest feature that is currently absent. </blockquote> I haven't played very much yet, but I sort of wish that the tutorial mission was more fleshed out in terms of explaining crafting and combat. I crafted a couple pieces of armor with leather that I got around town and still got destroyed immediately as soon as I went to a dungeon. Maybe that was just an issue with my level, but I was getting 2-shotted and had trouble inflicting any damage at all. </blockquote> NPC interaction mostly, right now the world feels a bit empty when not doing dungeons. </blockquote> More item variety! Seeing just mushrooms and same loot models is really disappointing for me. I love stuff, and when there is little of variety it makes it pretty bland. </blockquote> Some kind of completion mechanic, like a book for tracking all the monsters I defeated, all the fish I fish, all the insects I catch, and more of this kind of grind. </blockquote> Combat. I don't find it is bad right now but I think combat needs to be improved above all of the other features. It is the top priority for me. When I use close-range weapons, monsters always beat me cause I can see neither their attack states nor if they hit me, so I can't dodge. </blockquote> Procedurally generated maps. Content to do between dungeons such as camps, quests, or even a main story. </blockquote> The world itself needs a little more love, it feels a little empty, I understand there are many dungeons, its the place between the big places that needs a little bit of love and detail. </blockquote> Deferred rendering, GI, and LOD trees ;P kidding. Combat overhaul: Better anticipatory animations, w/ SFX. Better hitboxes. Smarter AI. Sharper movement. Combat feels clunky, and the positions/movements of entities feel totally disconnected from their combat actions -- lacking the tactile quality of (say) Dark Souls. I don't feel encouraged to "get good" when the game provides no feedback (or provides false feedback). Can't trust my eyes, and there's no sound. So it's memorizing, which by itself is really boring. </blockquote> Definitely quests. But also, more bosses, especially overworld bosses, and more gear. Now that I got the complete cultist set, I kind of hit a (temporary) dead end. I heard there are legendary items but the drop rate seems to be kind of unfair (I know... it's called legendary for a reason). </blockquote> 0.9 release stats</h3> We hit a new record for most players on the server at once! At peak, 133 players joined the server. However, the release party saw several problems. Disconnects were happening frequently, and the latency for players was quite high. There were also some massive spikes with incoming bandwidth. Lots of this is still being diagnosed, and tooling is being improved to simulate environments similar to release parties. </figure> </figure> </figure> </figure> </figure> </figure> </figure> This Week In Veloren 111 Mon, 15 Mar 2021 00:00:00 +0000 This week, we hear about many improvements to systems across the codebase. Network and metric improvements, airships, physics, pathfinding, AI, and much more. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Sam, @zesterer, @aweinstock, @AngelOnfira, @James, @imbris, @Synis, @DaforLynx, @Snowram, @PersianKnight, @Christof, @Slipped, @tukilo, @ccgauche, @BryanQuigley, and @Pfau! This week, Veloren is preparing for code freeze as 0.9 approaches. @Snowram added the latest batch of NPCs made by Gemu into the game. @DaforLynx updated and moved the "Getting Started" new player's guide to the Veloren Wiki (along with other topics in the Wiki) in preparation for an influx of new (and returning) players when 0.9 releases. @Frinksy packaged Airshipper for Fedora and set up a Copr</code> repository</a> to help with installing/integrating the game. @Christof get trading merged and created several bug fixes afterwards. @lboklin has been working on density and buoyancy, and there are two videos you can go check out to see the progress (1)</a> (2)</a>. </figure> Improvements by @xMAC94x</h3> Network Improvements</h4> Veloren's backend recently had a huge network improvement. It was a complete rewrite which allows it to easily switch the underlying protocol on an abstracted layer. We use a technique called I/O-Free Protocol, in which we implement the protocol-code without the need for an actual TCP or UDP connection, which makes testing much easier. As a result of this, we were able to implement a MPSC backend in addition to our current TCP backend. Which will be used in singleplayer. The MPSC backend will reduce the load on networking while in singleplayer and thus give you more CPU performance for higher FPS. </figure> Metrics Improvements</h4> We redid the way we are tracking all different systems in Veloren. Veloren has all kinds of systems for internal tasks, such as NPC controlling, physics, and persistence. Before we just measured the runtime each system took, now we additionally also track WHEN a system starts, and on how many cores it runs. This helps us devs to get a better overview of what's going on on the server and where we need to improve things. For example, you may think that a system that is only single-threaded is bad and slow? But if it's designed in a way to run in parallel with 7 other systems it still behaves quite well in terms of multitasking. If a system is single-threaded AND many other systems are waiting on it to complete, it's a different story though. We need to improve this by either changing the algorithm, introducing multithreading, or change the dependency of those systems. It also gives us a better overview of how expensive our systems are in total. </figure> In the image above you can see a list of all our systems, suffixed with an s</code> for start or e</code> for end. You can either read the exact times when a system is started or a have a look at the graph. For reference, the big red system is our physics. Pathfinding improvements by @Yakei</h3> With school work done, I was finally able to start working on the pathfinding rework. The current pathfinding algorithm used is the A</code> (A Star). While it has plenty of benefits in a controlled environment, it is definitely lacking in result in Veloren for multiple reasons. Primarily, AI currently can't climb nor fly outside of RtSim. After talking a lot with @aweinstock and @zesterer, the goal for now is to implement a rapidly exploring random tree. This is an algorithm tailored for exploration of the environment until a working path has been found. </figure> In theory, I finished a very crude and naive working proof-of-concept. In practice, there are plenty of limitations that I need to remove as soon as possible. The biggest one for now is how explored paths are stored. I am using a K-dimension tree as the primary data structure. Nonetheless, the crate I found does not really suit our need in many ways: You can query data related to spatial points but you can't query the actual point. In our case, we want the coordinates, while we don't store data.</li> You can't build a path in the coordinates graph. This means I need to store each point in the KdTree in order to query the nearest neighbor, but I need to store it in a vector along a parent-id so that I can return a complete route for the agent system to follow.</li> </ul> I ended up forking the crate and rewriting a part of the code in order to remove some of these limitations (and I gained a 40/45% perf increase in some of my benchmarks). However, the graph part is not properly doable without tricks that I wouldn't consider long term. My plan is now to rewrite from scratch the KdTree implementation in order to achieve better performances, more convenience for our needs and a more Rust idiomatic code. Input improvements by @Sam</h3> I have completely rewritten how inputs are handled by the game. Previously, there was a struct containing a field for each input, and each field contained data on whether the input was pressed and how recently it was pressed. Now, inputs are represented by an enum, and an input being pressed and unpressed are sent as separate control actions. When an action to start input is received, it is added to a BTreeSet, and when an action to cancel an input is received, it is removed from the BTreeSet. </figure> Changing inputs this way has a few advantages: If an input happened within the space of a tick, before it could go unnoticed if it was pressed and unpressed within the same tick, now that input should be recognized by the server when doing an action.</li> Now that inputs are collected in a BTreeSet, we can also prioritize inputs such that certain inputs are handled before others as the BTreeSet orders the inputs.</li> The amount of data synced from the client to the server is now also moderately smaller, as less information needs to be sent</li> </ul> Agent Code Update by @James</h3> My agent code refactor got merged almost two weeks ago, but I haven't yet written anything about it. I refactored the agent system into a behavior tree. Previously it was a finite state machine (FSM) with massive states and confusing transitions hidden all over the place. It looked a little bit like a plate of spaghetti with transitions and states all tangled up. Luckily for me, I had written a good chunk of that spaghetti and found it relatively palatable. The fact that the file was ~1500 lines of code and in such a messy state didn't exactly make it easy for other developers to work on the agent code. For those of you who aren't familiar with the Veloren code base, the agent system is what governs NPC AI. Before this refactor, an agent could be in one of a number of states, such as Idling</code>, Fleeing</code>, etc. Transitions between these states were scattered throughout the states and as overrides before and after the bulk of the code in the agent system making the decision-making logic difficult to follow. </figure> Finite state machines and behavior trees are the two most popular game AI code structures. At its simplest, a behavior tree is a decision tree that determines behavior based on a series of conditions. The end (or action) nodes represent an agent behavior. For Veloren's implementation, all the random information about a specific agent pulled from the ECS is put in a tidy struct. Methods on this struct act as the action nodes. Now if someone wants to adjust an agent behavior they only need to find the proper function. The decision-making process is modeled directly as a series of if and match statements making it easy for other developers to design new behaviors. Since the action nodes all belong in separate functions, multiple devs can work on different behaviors at the same time without worrying much about conflicting work. My hope for this system is that other devs will be able to jump in and design some neat behavior for Veloren's NPCs. This week I made some quality of life changes for NPC interaction. Most NPCs in the game world are created and destroyed as terrain is loaded and unloaded by the server. The exception to this rule are the RtSim entities (short for real-time simulation). These entities persist when unloaded and currently are visible as the travelers that roam between towns and castles (there are also RtSim birds that fly between dungeons). RtSim entities have a "Brain" that can store information that changes their behavior. This is where they store their destination and they now also store memories of interactions. If you talk with a traveler (press E to interact) the first time, it will give a generic response about its destination. The second time, it may greet you by name if it remembers your character. If you attack a traveler it will remember your name and attack you on sight if it runs into you again while that memory hasn't faded. I also fixed some issues with merchants. Merchants should no longer wander away while engaged in a trade with a player. When you interact with a merchant, it will offer to trade with you (press R to send a trade invite). Additionally, the price demands that the merchant says now appear in the chat box for players in the near vicinity. This is helpful as the merchant chat bubble is often obscured by the trading window. Villagers may also find your presence less tasteful if you walk around wearing cultist armor. Airships and Physics by @aweinstock</h2> @zesterer and I implemented airships this week. Currently, they can be spawned by an admin or in singleplayer with /airship, and we plan to have RtSim airships flying routes between towns as soon as some agent flight code is fixed (which also affects birds). Airships can be flown by mounting them, and act like terrain for other entities. You can climb on them, jump and glide from them, climb stairs on them, and so on. </figure> When I first added the airship model (which Pfau made, and Sarra added stairs and a second floor to) as a normal entity to the game, it had a Box collider, which meant you could push it around on the ground much like an item, but you couldn't stand on it (if you tried, you'd fall through, and push it aside). In order to find out how to make physics work for them, I refactored the physics system into functions (previously it had been a single ~1K line of code run function). In the process, I discovered that the terrain code could be made more generic: the specific type it was using was a TerrainGrid</code>, which is a statically sized grid of voxels used for chunks. By changing the function to accept anything that satisfies the trait bound T: BaseVol<Vox=Block>+ReadVol, it became capable of also accepting Dyna models, which are the voxel models used by the figure pipeline for entities. By translating and rotating an entity's collider into the reference frame of the airship model, it became possible to support airships collisions with floating-point positions and rotations while still using the same dense array of integer-aligned voxels. By combining the abstract physics states it became possible to climb both airships and terrain without interleaving the processing of their blocks. </figure> Once the collision was implemented, there were some more quirks with movement which were addressed by @zesterer. He changed friction and air resistance to make movement smoother, and to move the player along the airship with friction. This is more accurate than what many other engines do (coordinate locking), and makes it so that your velocity is still aligned with the airship when you're jumping on it or gliding from it. He also made various tweaks to the block hopping and block snapping parts of terrain collision, which facilitate walking uphill and downhill as if it were a curved surface despite being made of voxels. @zesterer also tasked me with implementing client-side interpolation for positions, velocities, and orientations, which make airships smoother to ride in the presence of network latency. Without interpolation, the clients assume that if they haven't received input from the airship in a while, it will have started falling due to gravity. When the server corrects the client, the airship jumps back up, which may cause the player to fall through the floor of the airship to their death. With position interpolation, the client predicts that the airship will keep going at its current velocity, causing it to move smoothly even if there's a delay in receiving the airships inputs (and likewise with velocity interpolation and acceleration, and orientation interpolation and rotation speed). Interpolation is currently linear, as we tried a cubic model called Hermite Spline Interpolation and found that it was less smooth with the settings we tried at the latencies we tested under (although it's intended to preserve derivatives better than linear interpolation once well-tuned). </figure> The physics improvements caused a few regressions in Agent</code> and RtSimController</code> movement, which @Sam and @James have been helping to diagnose and fix, due to those systems having been tuned against the old, physically unrealistic friction and air resistance values. @imbris has also been working on physics engine improvements such as reducing the number of allocation in the physics code, and adding chunk based broadphase pruning for making entity-entity collision detection faster. It's worth noting that the voxel colliders added for airships can support other features too. Possibilities include elevators (which could be generated as an alternative to spiral stairs), water orb attacks that cause swimming and slow movement for entities they pass through, temporary defensive fortifications with HP or timers, moving/floating platforms in dungeons, and possibly even doors. Since @Christof merged NPC merchants this week, I also made some improvements to the trading UI; in voxygen, each player's offer always appears on the right side of their screen (near their inventory), and I fixed a bug that @Mog pointed out where the crafting recipe cache wasn't getting updated on completion of a trade. In the process of developing a load-testing bot client for @xMAC94x, I found and fixed a bug where character creation allowed the creation of arbitrary tools due to a lack of server-side validation of client input. Hanging out with the gang. See you next week! </figcaption> </figure> This Week In Veloren 110 Mon, 08 Mar 2021 00:00:00 +0000 This week, final changes are merged as code freeze approaches. There are updates to the sceptre, fireworks, and economics. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Frinksy, @zesterer, @ccgauche, @Synis, @Pfau, @Sarra_Kitty, @aweinstock, @Sam, @imbris, @Snowram, @VincentFoulon, @Sharp, @Quibble, @James, @Slipped, @Tadabito, @XVar, and @heyzoos! @ccgauche and @xMAC94x have been updating the plugin ECS access to enable more parallelisation in systems and increase general game scalability. @Sarra_Kitty and @aweinstock made improvements to the fireworks code. @Christof has been continuing work on economic trade, with NPCs deciding value of their trades. @Sam has been working on (another) sceptre overhaul. Fireworks with @Sarra_Kitty and @aweinstock</h3> Shader code by @Sarra_Kitty</h4> I did a minor tweak on the shader code for fireworks, which gave them a proper colorful explosion, as the particles before, did not actually have the right colors for each firework. I also added a white-colored firework into the mix. @aweinstock did some more substantial work on the fireworks, they now explode into multiple bursts of color, recursively. </figure> Recursive Fireworks @aweinstock</h4> I extended fireworks to shoot copies of themselves recursively, to give them the effect of staged payloads. Both before and after, throwing a firework launches an entity with high initial velocity that is subject to gravity. It triggers an effect when its vertical velocity goes below 0 (i.e. it slows down due to gravity, and detonates at the peak). Previously, the trigger used ServerEvent::Destroy</code> to destroy the projectile, and ServerEvent::Explosion</code> to make an explosion (which uses the same machinery as the staff explosions; apparently, fireworks do 5 damage per explosion, so they're a reasonable anti-air weapon if you have enough of them). I added a ServerEvent::Shoot</code> event to shoot additional fireworks when the vertical velocity trigger is met. The Shoot</code> event had to be extended with a comp::object::Object</code> field, since it was previously only used for projectiles, which only have triggers when they hit an entity or block, (as opposed to fireworks, which have the vertical velocity trigger, and bombs, which trigger when they land on a surface). Relatedly, inventory-launched fireworks don't currently go through Shoot</code>, so they don't have a Projectile</code> component, which means they don't trigger when they hit a wall or entity. This can be seen at the 14 minute mark of @SavvyNik's recent stream</a>. To avoid runaway exponential growth with self-replicating fireworks, a firework has a 25% chance to shoot 2 additional fireworks, and a 45% chance to shoot 1 additional firework. This gives a 70% chance for each firework to replicate at least once (so you'll get a decent show from most usages of the item), and an average replication rate of 95% (which is less than 100%, so the show will almost certainly stop eventually). </figure> Economic decisions @Christof</h3> I was finally able to combine item rarity, economy's prices, and both inventories inside the agent code and decide whether to accept the trade or more value is needed. Sadly the agent doesn't yet know how to give the second confirmation and the item rarity table needs more balancing. </figure> First acceptance. Of course, all towns always need more food - if they had more the population would grow. </figure> Scepter overhaul @Sam</h3> I've overhauled the sceptre (again), it should merge in the next few days. The projectile heal is removed and the beam is split. There is also now a skill bar ability. New M1: A beam that damages enemies with a bit of life steal</li> New M2: A beam that heals allies, at the cost of stamina and combo</li> New skill bar ability: An aura that provides damage reduction to you and group members in range for a short duration</li> </ul> The skill tree for the sceptre has also been redone to account for the new skills. You'll have all the points that you've invested reset (meaning if you earned 34 points, and spent any number of them, you'll now have all 34 of those points available to spend again). Fog over a village in the morning. See you next week! </figcaption> </figure> This Week In Veloren 109 Mon, 01 Mar 2021 00:00:00 +0000 This week, we have many writeups. We hear from @zesterer, @Christof, @Sarra_Kitty, @Sam, @VincentFoulon80, and @aweinstock. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Slipped, @ccgauche, @heydabop, @xMAC94x, @imbris, @Lerg-exe, @aweinstock, @zesterer, @Snowram, @Pfau, @Timo, @Sarra_Kitty, @nwildner, and @AngelOnFira! As we prepare for the 0.9 release on March 20th, we've seen many changes getting merged. This week @zesterer worked on a site overhaul. @Christof has been continuing work on NPC merchants. @Sarra_Kitty has been improving the number of models that are in the water. @Sam made many changes around buffs and combat. @aweinstock has been continuing work on player-to-player trading, as well as modular weapons. @VincentFoulon80 has been working on icons for skill trees. </figure> Site Overhaul by @zesterer</h3> I've been working on the new site overhaul. As part of that, I'm working on a generator system that allows other developers to define their own structure generation rules with a system similar to CAD-style CSG (Constructive Solid Geometry</a>). CSG is pretty great because it allows you to define your geometry using simple primitives and then combine them using Boolean operators to produce new geometry. </figure> This new approach comes with a few notable advantages: It's much easier to define your own geometry than the old sample-based API that required a lot of boundary logic and reasoning in multiple coordinate spaces.</li> It's 'backend-agnostic'. Although right now we're 'rendering' the geometry into blocks, it might be possible to render it to other outputs in the future such as low-poly geometry for the LoD system.</li> It's modular and independent of the underlying structure of the building, so you can take a CSG-style structure and adjust it to fill whatever dimensions you require and the system can adapt accordingly</li> </ul> </figure> I've also been working on the layout of sites themselves. The new site system uses a tile-based grid for positioning 'plots' (buildings, roads, etc.). Each tile is 7x7 blocks and belongs to exactly one plot. This system is much more flexible since plots may define their own generation rules independently of other plots which makes modularising the generation code much easier and lowers barriers for other developers wanting to work on world generation. It'll also allow us to generate sites that take almost any structure we want, mixing and matching elements throughout history simulation as appropriate. We could, for example, generate a town with a castle-like perimeter wall, a fortress with a dungeon in the middle, or a port village surrounded by ruins. Because the only thing required to tie these elements together is the plot-based tile grid, the work required to allow different procedural elements to work together is significantly reduced and the brunt of the work now gets placed on the layout generator rather than the generators of the individual structures themselves. </figure> Trader NPCs @Christof</h3> I modified the town spawning code to generate merchants. They wear nice colorful armor, carry some local wares - determined by local economic numbers - and accept trading invitations. It makes use of the recent user interface additions by @aweinstock. Unfortunately, I will need to adjust the wares and balance the prices before this gets ready for inclusion into the game. </figure> Here is an updated merchant screenshot. A less beautiful merchant, but much nicer wares: a bag for each, filled with armor, weapons, craft material, food, potions. Side note: This town has spent all its coin in other markets, so they will gladly accept coins, but if you sell items they can only offer goods in exchange. </figure> Assets for Water by @Sarra_Kitty</h3> I implemented the spawning of coral reef and kelp forest sprites in all bodies of water at or below the world sea level. They are temperature-dependent, and the two environments transition between each other if the climate changes. </figure> Additionally, I added seagrass patches that can spawn along the coast, the grass actually spawns in the water, but pokes out above it, so it gives a nice transition from land to the sea. In the future, there will be more content underwater, new mobs, generated structures, and also plants and scenery for freshwater ponds and lakes that generate inland above sea level as well. </figure> Compared to what we had before with barren seafloor, this is a massive improvement and makes for a lot more of a welcoming environment underwater for players to explore. There already should be seashells scattered rarely around, for you to find, and I plan to add more you can do to keep the underwater areas fun and interesting, not just pretty to look at. Hopefully, we can give the lakes and ponds inland the same treatment soon. </figure> Lots of Work by @Sam</h3> I've changed the saturation buff from food to queue. This means that only the currently active saturation buff will tick its duration, and any inactive ones instead wait until they are active before their duration begins to tick. I finally integrated some sword and bow models that Gemu had created multiple months prior. Most of the previous sword and bow models were replaced. </figure> I've also changed how auras apply buffs. Instead of applying a buff only when an entity does not already have a buff of that kind and then applying the buff every second, it instead applies the buff and then doesn't tick the duration for that buff until the entity is no longer in range of the aura. I've added a combo component to the player (and other entities). Instead of combo melee scaling its combo only within that attack state, it instead increases the combo in the component. Combo then resets to 0 after 5 seconds of not increasing. This has a few advantages, but the one with the immediate effect is that the sword, axe, and hammer can retain the advantages of having some combo when you use an attack that isn't combo melee or when you stop attacking for half a second. It will also allow us to use combo for different things as well, including the potential to use combo as a resource for some attacks. I also fixed torvus a couple times when it broke earlier this week. </figure> Skill tree Icons @VincentFoulon80</h3> I finished implementing the new icons onto the skill tree. I also added the main and secondary attack as dummy skill at the center of each sections (top-left and top-right). I think these additional icons are handy to find out which skill you will improve. </figure> Trading and Modular Weapon Update by @aweinstock</h3> Regarding trade, I implemented the ability for each party to see the counter party's inventory and request items from it by dragging them into the trade window. Since trading works on any entity with an Inventory</code> and a Controller</code>, it should work with NPC merchants as soon as their AI (Agent</code>) emits the Controller</code> actions corresponding to trade. I also added a coin item, and made some finishing touches to @heyzoos's item stack splitting MR that allowed it to be merged. Regarding modular weapons, I added support for making the stats of a weapon or weapon component different based on the materials it's made out of, so a generic claymore blade recipe and a generic scimitar blade recipe can each make (bronze, iron, cobalt, etc) blades of the corresponding type, which can then be added to any hilt. Flying sky-high. See you next week! </figcaption> </figure> This Week In Veloren 108 Mon, 22 Feb 2021 00:00:00 +0000 This week, we see many contributions merged as we move towards the 0.9 release. @aweinstock gives a little insight into what modular weapons will look like. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @ccgauche, @xMAC94x, @Slipped, @Sam, @Snowram, @Dumbeldor, @imbris, @zesterer, @Overblob, @steanne, @aweinstock, @XVar, @clangdo, @AngelOnFira, @adalovegirls, @nwildner, @thethirdspartans, @huettner94, @Quellus, @Synis, and @Quibble! @Xvar has been replacing the usage of diesel with Rusqlite</a>, intending to make it easier for developers to make database related changes and to improve trace logging of SQL statements (a recent bug highlighted that this is basically impossible with diesel). @Snowram added animation to objects and made a turret as a proof of concept. They also added a system to make some species immune to specific (de)buffs. </figure> @OverBlob made humanoid characters use their gliders when falling to avoid fall damage. @TheThirdSpartan made sure that the player list is updated whenever an admin possesses another character so that their player alias is still visible in chat. @Sam got dual-wielding merged. It's not yet accessible to players though as it lacks animations @Sam also made food buffs queue. @Sarra_Kitty helped out a bit with modular weapons by starting to separate out the models. @Christof fixed another sign mistake in the trading code (coin got lost during a trade) and started relative item price computation using loot tables. This prepares the groundwork for an NPC trading prototype. </figure> Modular Weapons with @aweinstock</h3> </figure> Recently, I implemented most of what's needed for modular weapons (weapons made of multiple components, e.g. swords from blades + hilts). I've made decent progress on modular weapons (and have been incrementally merging it into master). I'll hopefully have it finished enough to demo with no purple boxes anywhere by next week (although it may still be unattainable by players until more crafting materials are in). </figure> The components have per-piece stats</li> They can be crafted into an item that sums the stats of the pieces</li> The pieces an item is made of are persisted in the database server-side</li> For rendering, the voxel models of the components are combined into a single model</li> </ul> Swimming with the fishies. See you next week! </figcaption> </figure> This Week In Veloren 107 Mon, 15 Feb 2021 00:00:00 +0000 This week, we had a general meeting to discuss the 0.9 release. Progress is moving forward on the trade front, both for NPC simulation and for player-to-player. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @lboklin, @AdaLovegirls, @imbris, @aweinstock, @zesterer, @Snowram, @Slipped, @DaforLynx, @Sarra_Kitty, @Quellus, @Quibble, and @Sam! This week, @Songtronix got the barebones for partial downloads done. @AngelOnFira got the repo mirror to GitHub fully working, so now any updates are sent over once an hour. @Snowram added a new batch of NPCs made by @Gemu and got NPC recolouring working for non-player models. The art and asset working group also had a meeting and settled on a list of craft materials for balancing purposes. NPC recolouring work </figcaption> </figure> @Christof got the inter-site trade code working and implemented a naming recommendation by @zesterer. A general meeting was held to primarily determine the release date of 0.9. It was decided that it would happen on Saturday, March 20th. You can read the meeting minutes here</a>. Update on Dual Wielding by @Sam</h3> I've started work on dual wielding, mostly backend stuff to more easily support it: - Weapons now have a Hands field on them - The check for having the prerequisite skill for a skillbar ability is no longer hardcoded - Handedness of the weapon automatically multiplies weapon power and speed, in the current iteration: - Two-handed weapons multiply power by 150% and speed by 75% - One-handed weapons multiply power by 67% and speed by 133% - Wielding a single one-handed properly accesses its abilities (the initial test for dual wielding a few months ago required that 2 one-handed weapons be equipped to use a secondary ability) - Dual wielding weapons gives access to skillbar abilities from both weapons - Weapon tooltips will display the handedness of the weapons </code></pre> </figure> Player Trading by @aweinstock</h3> I implemented player-to-player trading (bound to the R key by default). Trade has two phases. In the first, either player can add and remove items from their offers. In the second, the trade is made unmodifiable for review before acceptance. Both players have to agree to the trade before it can be reviewed/accepted. The server-side component of this should be generic enough to be usable for NPC trade. Currently, the AI just declines all trade attempts. A valley to fly through. See you next week! </figcaption> </figure> This Week In Veloren 106 Mon, 08 Feb 2021 00:00:00 +0000 This week, we see lots of progress on different meta tasks. The GitHub mirror is on its way to working, and Torvus is more stable than ever. @zesterer is experimenting with giant trees, and @LunarEclipse made some changes to the AUR packages. @Sam has been working on improvements to weapon states. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Snowram, @Sarra_Kitty, @AngelOnFira, @SWilliamsGames, @Imbris, @PhillippMevbenkamp, @James, @Ambien, and @azymohliad! @zesterer has been playing around with giant trees. Hopefully, they'll become sites containing villagers or even small towns in time. Lots of work yet to be done to get to that stage though. They're 100% procedurally generated, thanks to @ccgauche's initial work developing the original tree generator code. </iframe> </div> </figure> @Gemu is still working on basic one-handed weapons, and made a hydra concept model. @Pascal fixed a bug where the hammer leap with a low attack speed hammer would lead to a huge leap that caused fall damage even when on a flat surface. @Pascal also changed the damage and duration integers to floats throughout the ability & combat system to reduce typecasts. Hydra concept by @Gemu </figcaption> </figure> @James worked on a functional behavior tree setup that will allow for better modularization of the agent AI code. @DaforLynx created a system that varies cricket chirps with temperature. Relics from times long past </figcaption> </figure> AUR Improvements by @LunarEclipse</h3> This week, I made some improvements to the AUR packages: veloren-bin</code> actually works now. I had to write wrappers for the game and the server to make them store user data in the system-specific folders instead of alongside the executable. (When installed as a system package, the directory with the executable is read-only so the game just crashed before changing that).</li> Veloren and veloren-git</code> can now be compiled in a clean chroot. I tracked down all the needed compile-time dependencies, so the builds should never fail due to those missing.</li> All the packages now use the .desktop</code>, .metainfo.xml</code>, and the icon from the game assets instead of custom ones. I actually had no idea those existed until someone pointed it out in the comments.</li> </ul> Weapons Changes with @Sam</h3> I've been changing inventory manipulations that touch equipped slots (e.g. your weapons and armor) to go through control actions instead of control events. What this means is that it'll be a bit more limited in when one can change their loadout, no more swapping weapons from the hotbar while you're actively swinging a sword. Practically though, there should be very little difference observable as currently, you'll still be able to freely modify your loadout when not actively attacking. Eventually, this feature could also be extended to add a duration to changing loadout slots while wielding a weapon or something similar. Torvus Update by @xMAC94x</h3> Short Torvus stability update; thanks to Dumbeldor's metrics additions for Torvus we now can track operation easily. The change is now for 7 days operational. Our uptime is a whopping 99,98%! Though we see some errors on Friday between 2:00 UTC and 3:30 UTC. having those metrics is extremely important to get reliable data and analyse whether something doesn't work. Grafana dashboard</a> (the units are in operations per second) </figure> The Continued Mirror Issues by @AngelOnFira</h3> This week, I spend some time re-examining our GitHub mirror problems. The mirror had been outdated for several months; I last pushed it manually in November 2020. Historically, the mirror has worked. This stopped somewhere around the beginning of 2020 I think. Before then, GitLab would periodically send mirror requests as a built-in feature to our GitLab repo. This stopped once we went over our monthly limit for LFS files being sent to GitHub. Git is a tool that is meant for non-binary files. The version control method it uses keeps track of line differences through each commit. This means that if you navigate to any commit in our tree, it would have to build that commit from all of the previous changes since the beginning of a repo. On the other hand, binary files can't have recorded "line changes". Think of a PNG image, or 3D model file. They're stored in a way that changes drastically when small changes are made. There isn't a trivial way of breaking down the changes with the file formats we use for our assets. </figure> This problem is often only seen in game development projects that use Git. In the AAA industry, other version control tools are used instead. One of the largest is Perforce, which takes a very different approach to version control. Since its use case is for very large games with massive assets, its solution doesn't work the best for other software projects. So if you are a game that uses Git/GitHub/GitLab as your version control systems, you have to take a different approach. There are a few different ways around this. GitHub allows you to "check in" files up to 100 MB. This means that as long as we have no single asset files that are larger that 100 MB, we can just use Git like normal, and not care about the fact that any time one of these binary files change, it has to update the entire file in Git. Ignorance is bliss. However, this accrues technical debt. Each time we add a file, it gets stored permanently in the Git history. So after checking in asset files, and updating them over and over again, we eventually have a lot of files in the history. This means whenever someone clones the repo, they would have to download all of these files that have ever existed in the repo. Currently, this would mean around a 500 MB download for our entire repo. </figure> The alternative to the approach of checking in binary files is to use a tool called Git LFS, or Git Large File Storage. This will instead store each binary file as a "pointer" to an external server, and store the assets there. Whenever you check out a commit, if there are any pointers in the file tree, it will replace them with downloaded files from the LFS server. This means that you don't have to have all of the asset files throughout the history of the project, but instead only the ones for the commit you're on. It saves data for developers, but also from the Git servers that are hosting the repo. GitLab gives us unlimited bandwidth for LFS files, but GitHub only gives us 2 GB per month. This means that not only will we go against GitHub's limit as we mirror our repo, but anyone who clones the repo from there will tick our limit. I sent an email to GitHub asking if we could have the limit removed from the project, but it didn't get much useful feedback. </figure> So now we seem to be at an impasse. We can't just get the LFS files to redirect to the GitLab server that we're hosting our files on, since GitHub forces them to be internal. Also, there is really not a lot of documentation around this. The use case seems to be small enough that it's not worth GitHub's time to look into, even for open source projects. However, I did find a dirty solution to get around this. I manually set up a GitHub Action that clones the repo from GitLab, and uninstalls LFS from it. It then checks in all of the LFS files as normal Git files, and force pushes it to the master branch of the GitHub repo. This means that anyone cloning from GitHub will have to download the full repo with all of the assets, but at least we have an updated repo! Here is what the GitHub Action looks like. I currently have it delete any GitHub Action workflows, as a bot isn't allowed to push them to the master branch. Each run takes around 6 minutes, but because GitHub Actions are free for open source projects, we can run it once an hour without any worry. steps: - name: Install git-filter-repo run: git clone https://github.com/newren/git-filter-repo.git; ./git-filter-repo/git-filter-repo --help - name: Clone GitLab repo run: git lfs install; git clone https://gitlab.com/veloren/veloren.git; - name: Uninstall LFS run: cd veloren; git lfs uninstall; git lfs migrate export --include="" --everything; - name: Remove workflow files run: cd veloren; ../git-filter-repo/git-filter-repo --invert-paths --path .github --force; - name: Push changes uses: ad-m/github-push-action@master with: github_token: ${{ secrets.GITHUB_TOKEN }} branch: master force: true tags: true directory: veloren </code></pre> </figure> There is still more work to be done so that each job can properly run once an hour, but this is currently the best solution I could find to the problem. I do hope that GitHub works on making Git LFS more accessible to open source projects, as it's quite a necessity for open source games. GitHub has done well in recent years to support open source projects, but this alone is one of the largest reasons Veloren prefers GitLab to GitHub. Beauty and the Beast. See you next week! </figcaption> </figure> This Week In Veloren 105 Mon, 01 Feb 2021 00:00:00 +0000 This week we hear about the progress of an attack rework by @Sam. @Christof describes the progress on travelling merchants. @Dumbeldor describes recent changes to Torvus. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Blob, @zesterer, @James, @imbris, @DaForLynx, @xMAC94x, @Slipped, and @Entropy! @Redo started working on changing some sound effects. @Gemu has been preparing a bunch of models for one-handed weapons. @Rotsuoy is reworking the medium quadruped animations and tweaking the models so that there will soon be prettier grazing animals with smoother animations. @Snowram worked on adding more lights to dungeons. Lights in dungeons by @Snowram </figcaption> </figure> @James is working on some basic interactions with NPCs. @Entropy has been working on organizing the asset folder. @Capucho is trying to replace shaderc with naga on the wgpu branch. @zesterer added snow! Snow! </figcaption> </figure> Torvus update by @Dumbeldor</h3> I'm a new contributor, and this week I added some metrics to Torvus to fix sending messages from Discord to the Veloren server. You can check out the merge request here</a>. If everything goes well the bot will work and it will be possible to send messages to Veloren from Discord (and vice versa) without any problem, and we will have a lot of nice metrics at our disposal to monitor that. Travelling Merchants by @Christof</h3> This week, I got the inter-site trade planning finally right. Now (still invisible) merchants leave their town for a neighboring town. With wares to sell and a plan of goods to buy, of hopefully still matching total value at the destination market. Merchants are rated for both the actual wares they should bring as for additional wares, which currently exceed their transport capacity. The next step is to fully implement the trade at the destination. There was also a worldsim meeting where we planned the implementation of behaviour trees, group AI and moving agent code to the server. </figure> Attack Rework by @Sam</h3> Recently, I completely reworked how attacks functioned and how they are handled. Before, attacks that were applied via melee, projectiles, explosions, shockwaves, or beams handled applying the effects from an attack independently. There was also a lot of boilerplate in how things were handled as code had to be replicated in all 5 locations. This also meant adding or updating particular effects were troublesome as it had to be done in 5 separate locations. Now, each of those 5 systems has an Attack</code> struct attached to it. What happens now is that each of the 5 systems is only involved in determining if an attack hits. If it does a function takes that Attack</code> struct and creates a list of events that are handled by the server. While making this change, I also added support for each attack having variable critical chance and critical multiplier. Many other various effects (such as buffs, energy rewards, knockback, life steal, and more as needed) can also be tacked onto an attack much easier, and with more freedom in what values are used. A wandering vagrant off exploring. See you next week! </figcaption> </figure> This Week In Veloren 104 Mon, 25 Jan 2021 00:00:00 +0000 This edition of TWiV marks two years of weekly blog posts! Although not as large as the 100th post, this one is still special to me. I remember two years ago, I had a semester off school and I wanted to start working on a side project. I had found Veloren, and I found what at that point was a single prototype blog post. I saw a lot of potential in the format and started releasing a new one each week. Since then the project has changed drastically, and so many great new things have come from it. I'm excited to see how it changes by next year! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @SWilliamsGames, @Sam, @Snowram, @lboklin, @Slipped, @xMAC94x, @Pfau, @dryadee, @James, @imbris, @pizzaluc, @Rotsuoy, @Acrimon, @SarraKitty, @XVar, and @nheuillet! @Pfau has a new art blog post, you can check it out here</a> @Scott fixed up most of the NPC hitboxes to be more accurate to the models. @Sam worked on various balancing things related to skill trees. He also added a new attack to the golem and changed how dash ticked damage. Rather than ticking every duration, it now ticks every distance traveled. @Sam also Worked on making torvus (the bridge between the main server chat and discord) functional again. </figure> @Gemu Prepared different models for all different weapon-wielding new small bipeds. @heyzoos fixed a server message bug where <?></code> would appear if an entity that inflicted bleeding on a player died before the bleeding killed the player. They also made player spell auras only affect other players in the same group. Rotsuoy worked on adding more life to the savanna as so it's not as naked. @ccgauche got some help from @imbris with plugin API development by finding and resolving a bug @ccgauche was stuck on for one week. </figure> Economics by @Christof</h3> Besides playtesting the new skill system a lot during the past week, I implemented getting neighbor sites' prices and inventories and currently code the trade planning based on this (potentially outdated) information. I realized that most likely a simple trade planning strategy might be sufficient and give similar results to multi-dimensional optimization. Basically, traders try to get the most missed wares at the cheapest place and exchange for those wares, which are plenty here and have the highest price there. Also, you don't need to additionally plan selling your goods to other sites, because they will in turn send merchants to you to buy what they need. Since travelling has a cost there is no point in shipping extra goods to sell at low prices. A push daggar by @AlbinoAxolotl </figcaption> </figure> Generally, it looks like the following (potentially player visible) information can be provided by the existing economic simulation: Number of town inhabitants per profession</li> Local prices and stock amounts</li> Traded goods between sites (type and amount) using the in-game roads</li> Guarded and regularly used/visited chunks around the town</li> Loaned resources to other sites</li> Economic conflict lines (later also effects) between sites</li> </ul> This Week In Veloren 103 Mon, 18 Jan 2021 00:00:00 +0000 This week, we see lots of new art coming into Veloren. Skill trees have been merged. @Christof continues his weekly writeups on economic simulation. @Yakei talks about new improvements to CI. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @ccgauche, @XVar, @Pfau, @imbris, @SWilliamsGames, @xMAC94x, @James, and @ubruntu! @Rotsuoy and @Sarra_Kitty worked together to get some new items into the game. @Sam has been going through a lot of code review for skill trees. There are new bugs and issues to resolve now that it's been released. @James figured out what was causing NPCs to spam chat messages when fleeing and fixed it. @Songtronix worked on getting partial downloads working. The Florabite by @Rotsuoy</h3> I'm a new contributor and for my first big contribution I started tackling items that didn't have in-game models. I started working on models for critters as well, mostly variants of existing monsters like a green dragon and forest drake. I've also started working on a new monster, the Florabite, designed by my 9 year old daughter who also loves Veloren! So you can definitely say that multiple generations of people already adore the game! </figure> Trade Between Sites with @Christof</h3> Starting from last week's state of reading professions/raw materials/products from a .ron</code> file, I added uncontrolled land as a raw material and trading good (fief/tenure). I also added and included different types of guards for different types of ground/water (e.g. a Naval Guard needs more potions, but less Armor) which then produce Farmland</code>, Quarry</code>, FishingGround</code>... In turn, this enables normal workers to access resources there, producing the raw materials for their food. Having different types of Guards enabled the town's control board to (re-)assign tasks according to changing needs. This resulted in much more people living in the same city, due to a smarter usage of the same natural resources. Also, I designed a concept for trading between sites that take local prices on both sides into account. Merchants plan their wares according to the information from the last trip and local stocks and prices, then at the distant market updated local prices and stock amounts apply, so merchants will come back with new information and potentially a different amount than planned for. Coin will act as a generic ware (without other use) when direct exchange is not desirable. Unfortunately, both the planning and the auction will involve non-linear multi-dimensional (one dimension per ware) optimization. New items by @Rotsuoy </figcaption> </figure> CI Improvements With @Yakei</h3> For my first real contribution, I decided to work on the CI. Pipelines can take as long as an hour, which is definitely too long. The current system makes use of a cache that is manually built into the Docker image. This has several problems, the main one being the cache gets outdated fast when it comes to Veloren's rapid development. I decided to leverage GitLab CI's cache system to remove this factor. This system is fairly new, or at least not as stable as we would all like it to be. In fact, some of the main features I've used to reduce build time are still broken on the last LTS version, which means I'm using a release candidate version that was built about a week ago. Once I overcame this first hurdle, I found out the average time spent creating and extracting the cache for each step was very significant. This is due to the default Go ZIP library used by the runner. I swapped this out to fastzip with a feature flag and found negligible overhead, compared to entire multiple minutes before. Forest Drake </figcaption> </figure> The new workflow is the following: The Docker image is created when dependencies are changed (either by adding, removing, or upgrading them).</li> Each step, the cache is extracted to the compilation folder.</li> We iterate through the container cache and link each of the dependencies. This requires some overhead, but is needed as this step will always be called after the extraction of GitLab's cache. This means we cannot link an entire folder.</li> The normal step is now executed. Cargo will now take care of only changed source files, and compilation completes much faster.</li> When finished, the new cache is created if changes were detected. This workflow means only Veloren's modified source files will be compiled on CI.</li> </ul> While these improvements have mostly been completed, we have not yet decided on the cache policy that we will use. Recent talks with @xMAC94x and @XVar leads me to think we would introduce a cache only created on master and used on every branch, along with a special cache for Tarpaulin and benchmark. This policy ensures a decent max storage size on cache, as well as reducing again overhead on the cache by not creating a new cache on branches. We would also change benchmark and/or coverage behavior to manually trigger on branches as this is the main cause of time spent in pipelines. A lot of questions aren't completely answered for now (the correct git clean policy to adopt as we use fetch instead of clone, how to reduce link creation overhead, etc.), but I think the new CI should be ready either this week or next. I'm already seeing build times reduced by around 5 to 15 minutes. Hopefully we can stabilize runs to around 5 - 8 minutes each if we change benchmark + coverage to manually trigger on branch which is probably as good as we can get on this matter. My next goal will be to reduce the number of dependencies that Veloren uses and improve linking time. A short break from exploring. See you next week! </figcaption> </figure> This Week In Veloren 102 Mon, 11 Jan 2021 00:00:00 +0000 This week, skill trees were completed. We hear from @Christof about some more work on professions. @badbbad created a new song. Lots of new models by @Gemu and implemented by @Snowram. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @ccgauche, @XVar, @Pfau, @imbris, @SWilliamsGames, @xMAC94x, @James, and @ubruntu! Your browser does not support the audio element. </audio> New song by @badbbad, 'Sweet Water' </figcaption> </figure> This week, the latest edition of the Rust Gamedev Newsletter was released</a>! @Sam finished off skill trees. It still needs a few more visual tweaks and needs to go through code review, but then they'll be in the game! @Gemu modeled a lot of new creatures, and @Snowram has been implementing them into the world. In fact, there are now over 100 total NPCs! Modeling gear based on new crafting ingredients by @Gemu </figcaption> </figure> This week, @Acrimon and @Sharp started working on a new specification for the multiplayer authentication mechanism. @VincentFoulon has been working on all of the icons needed for the weapon skills. These are on their way to being implemented in the game. New skill tree icons </figcaption> </figure> Professions by @Christof</h2> I found the logic error (introduced by me) in the labor_value</code> computation and finally have reasonable economic numbers across sites! I implemented reading professions (very much like a tech tree) from .ron</code> files, which I've recently completed. Also, I had a lengthy discussion with @zesterer about the nature of money; I am especially curious whether and how my current idea (coins as a trade good with a value solely determined by the things a site can buy for it) will work out. Here is an example of what the professions .ron</code> file looks like. ( name: "Miner", orders: [ (Quarry, 0.5), (Tools, 0.1) ], products: [ (Stone, 0.5) ], ), ( name: "Fisher", orders: [ (FishingGround, 4.0), (Tools, 0.02) ], products: [ (Meat, 4.0) ], ), ( name: "Hunter", // Hunter operate outside of uncontrolled areas and resemble guards // due to the low number of products we tune down the Armor,Tools,Potions in comparison orders: [ (Armor, 0.1), (Tools, 0.1), (Potions, 1.0), (Woodland, 4.0) ], products: [ (Meat, 4.0) ], ), </code></pre> Basilisk by @Gemu. See you next week! </figcaption> </figure> This Week In Veloren 101 Mon, 04 Jan 2021 00:00:00 +0000 This week, we start 2021 off with lots of progress. Skill trees are completed and working towards code review, lots of new models are being worked on, and larger systems like economic simulation are pushing forward. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @a1phyr, @xMAC94x, @VincentFoulon, @Nobbele, @zesterer, @XVar, and @Acrimon! In last week's behemoth blog post</a>, we didn't cover lots of the contributor work that was going on. @VincentFoulon has started working at refactoring localization code to clean up the file and folder structure of it. @Sam has completed the skill trees for hammers, bows, staffs, and sceptres. Gnarlings by @Pfau and @Gemu </figcaption> </figure> @ubruntu is nearly done adding RTSim birds that fly around the world. @Pfau created a skill tree layout generator, and worked on gnarlings. The concept drawings were worked on by @Gemu. @Scott has been working on improving the look of the wiki. </figure> Water Models by @Sarra_Kitty</h3> I've been continuing to work on more models for coral and seaweeds. I added several more variants of coral, and a seashell item on my branch. You can find them scattered about on the sand on the reefs! The next step for these is to make their spawning temperature dependent, so coral reefs will spawn in warm water, and kelp forests in colder seas. I like the idea of having a distinction between fresh water and saltwater in the game as well, so that freshwater lakes and ponds can have things like waterlilies and pondweed in them, and save the coral for seas and the ocean proper. Currently, there exists no such system in the game, but I think it's something to think about! </figure> Work on Economic Simulation by @Christof</h3> Thanks to @imbris I was able to significantly reduce the code needed to load additional (economic) data on demand once a tooltip is displayed (over a site in the map window). But apart from getting a better understanding of the complexity, (i.e. anything short of a full political+military+site building+economy simulation will need manual tweaking to give reasonable prices), I didn't make much progress in the last two weeks. In the example below, Trig is lacking access to Wood/Logs to grow further (high value, low stock; and has an excess of Fish). </figure> Skill Trees by @Sam</h3> I just finished the general combat skill tree. This means that the old level and XP system has been thrown out. The UI is now mostly hooked up for purchasing skills. Finally, the last of the stuff I needed to do for database persistence and the migration is done. A pieceful village. See you next week! </figcaption> </figure> This Week In Veloren 100 Mon, 28 Dec 2020 00:00:00 +0000 This week we have the 100th edition of This Week in Veloren! We have writeups from many contributors, making this the longest edition yet. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @XVar, @Acrimon, @nwildner, @Pfau, @SarraKitty, @Slipped, @Pfau, @Snowram, @Entropy, @zesterer, and @Frinksy! This week we have a unique blog post. It's our 100th edition! For this blog, we had to make it the biggest one yet. We have writeups from 20 of Veloren's developers, artists, composers, and other contributors. Because of this, here is a table of contents with all of the topics. Enjoy! Prologue by @AngelOnFira</a></li> A Veloren Short Story by @zesterer</a></li> UI Progress by @Pfau</a></li> Glider Physics by @Slipped</a></li> @LunarEclipse's Veloren Journey</a></li> Modeling with @Gemu</a></li> Modeling with @Snowram</a></li> Work by @XVar</a></li> Combat Improvements by @James</a></li> Starting with Audio by @Badbbad</a></li> Network Analysis by @xMAC94x</a></li> The State of Graphics and UI by @Imbris</a></li> Skill Trees by @Sam</a></li> Procedural Trees by @CCGauche</a></li> New Website Design by @Songtronix</a></li> Why Veloren is Special (to me) by @Christof</a></li> Getting into RTSim by @Ubruntu</a></li> Finding Veloren by @Yusdacra</a></li> New Developer Experience by @Entropy</a></li> Looking to the Graphical Future by @Sharp</a></li> Combat System Design by @Silentium</a></li> </ul> Preface by @AngelOnFira</h2> I joined the Veloren project in January 2019. I was intending on making a very similar project myself, and in doing research, I stumbled across Veloren. I knew some Rust at the time; enough to solve the kinds of problems you'd find on HackerRank or Advent of Code. So I looked for other areas that I could contribute, and found TWiV. There was only a single post that had been made at the time, and it dated to a few months prior. So I started writing the blog. At first</a>, it there was just an art and programming section. Around the 12th edition</a>, we saw the first writeup. More structure started being added to the blog, and more content was coming in from contributors. We saw concept art, ideas in prototyping phases, new systems being described, and much more. </figure> We've seen many great benefits from the blog: people have found out about the project, aspiring developers have seen something they could contribute to, and it's created discussion around many elements of the project. Further, it's been great seeing what others have been working on in a curated format. So here's to the progress that has been made over the last 100 weeks, and here's to another 100 🍻 A Veloren Short Story by @zesterer</h2> You start your journey in a town named Mosswall. The town is small, but it has most of the essentials: a fletcher, a carpenter, a small open-air market, and a tavern. You realise that you have a few pieces of gold about your person so you decide to visit the market. Since you appeared to start in a small square, you do so via a narrow cobbled street, lined with houses. Townsfolk walk past and greet you as you go. </figure> Once you reach the market, you find several merchants flogging their wares. You walk over to the nearest: she's selling weapons, telling you that her swords came from a blacksmith in Cliffheim, a dwarf settlement to the north. Curious you pull out your map: sure enough, you can see Cliffheim nestled amongst the foothills of a mountain several days walk to the north. You like the look of this sword: it is sturdy and simple, with a leather grip. You feel that it'll serve you well. Satisfied, you pay the merchant, and she thanks you for your business. Curious about what you might need next for your adventure to truly begin, you enter the tavern on the opposite corner of the marketplace. It's dark and quiet, much as you'd expect from such a small town. The only light comes from a fireplace set into the wall and sunlight coming in through the window. </figure> There are a few travellers at the bar (as implied by their heavy backpacks and light travel armour). You walk over to one and ask them where they're visiting from. They say they've come from the west, a lakeside village known as Feastloch. The town had recently been having trouble with some of the wildlife: trolls from the northern mountains had expressed interest in the village's plentiful supply of fish and had invaded the town. Most of the inhabitants had been forced to flee. Those that remain are asking for adventurers to help them fend off the trolls. You bid the traveller farewell and they thank you for your company. This seems to you like an opportunity to make a name for yourself as good as any, so, after visiting the market for some food supplies, you make your way down the road that heads out of town. Cobble gives way to gravel, and gravel gives way to dirt: eventually, you find yourself wandering through an oak forest. </figure> There is birdsong and flowers, and a slight breeze in the air. The path continues for an hour's walk until you come to a fork in the road. A sign near the fork reads 'Feastloch, south-west. Cliffheim, north'. Encouraged by your progress, You set off to the west. The terrain begins to change. Broad oak trees give way to sparse pine, and the grass dulls. The air chills and the wind picks up as you climb to the crest of a hill. Staring down into the mist, you see the mirror-like surface of a lake, scattering the early evening sun across the valley. Smoke rises from the chimneys of a dozen houses on the lake's northern shores. This must be Feastloch. </figure> Some distance ahead you spot a figure walking the path. As the figure approaches, he yells a greeting, and asks you where you're headed. You tell him that you're travelling to Feastloch. He shakes his head and tells you that the trolls have taken the village for their own. An unprepared traveller like yourself would surely struggle to take them on. Undeterred, you tell him that you intend to free the village from the trolls. He protests, but wishes you well and hands you a flask of liquid, telling you that it'll heal you if you get hurt. You reach the outskirts of the village in time to hear a bellowing roar from the direction of the village hall. Carefully, you make your way toward the noise, taking care to remain hidden behind trees and marsh reeds. The bellowing continues, and you catch sight of an enormous troll attempting to break through the wall of the village hall. Thinking quickly, you dig through your bag. Amongst other items, you find a flash bomb: just what you need. The troll roars once more and you throw it toward the village hall. It's well-aimed: it hits the ground next to the troll, exploding with bright light and flames. The huge beast jumps in surprise and runs away into the tree line behind the town, dropping its huge club as it does so. You have scared away the troll, and obtained a heft club in the process! UI Progress by @Pfau</h2> As the only developer mostly working on UI design and UI frontend for Veloren I found myself contributing to two different branches lately. For the inventory upgrade branch, we needed to rethink and resort some of the bag elements, add a completely new system to expand the inventory view, and fit in new slots for bag items. Additionally, this involved planning out the game design of this exciting new feature and organizing some test runs. And this was just my (small) part in this. Everything going on "below the surface" took weeks for @XVar to fully flesh out until we could even think about UI. </figure> Another very interesting new feature I was involved in was skill trees. These first required a more or less fully automated way to generate a layout. Then, the developer (@Sam) writing the underlying systems just has to place simple button widgets onto the pre-generated layout and make them trigger events on pressing them. One can basically put in some values at the top of the file and the code below creates just the right amount of background elements and places them based on a certain ruleset. Working on this was really cool as it felt like creating a 2D level generator. All of this is especially amazing to me because I started out with just knowing a bit of CSS and LUA when I joined the Veloren Team in 2018. My last CS class dated all the way back to around 2008 when I started to learn graphic design. My origins are actually in the World of Warcraft UI modding community, which you may or may not recognize in some of the Veloren UI elements 😉 ~Pfau Glider Physics by @Slipped</h2> I'm working on an animation branch by @lboklin that adds realistic glider physics to the game. While the master setup only allows for turning with the glider, this adds aerodynamics that will simulate the movement down to details like air density and surface area of the aerofoil to calculate drag/lift and track pitch, yaw, and roll. You can pull back on the glider to enter a slow glide or lower yourself to the ground. Push forward on the glider to go into a fast dive. Banking properly allows for a ton of fun movement, even in tight spaces. The player is also now a lot more responsive to the movement, getting pinned to the glider at high speeds and hanging freely when coasting. </iframe> </div> </figure>@LunarEclipse's Veloren Journey</h2> I joined the project soon after @zesterer created the Discord server. I offered to help set it up and that's how I got involved. At the time I had very little programming experience, so I was open to learning any tools others would choose to develop the game with. After Rust was chosen as the language we would use, I started reading the official Rust book. It wasn't until the engine rewrite when I started working on the actual codebase. By that time I had read about half of the book, and with a lot of help from @zesterer, I took on the task of writing the networking code. The API was really simple - the server would have a PostOffice</code>, which would receive connections represented as PostBox</code>. The client would call PostBox::new(address)</code> which would connect to the server, and again yield a PostBox</code> instance. After that, utilizing the connection was as simple as calling .send(data)</code> and .receive()</code> on the PostBox</code>. Unfortunately, while it passed the unit tests I wrote, it didn't actually work. I couldn't find the issue, so @zesterer took over and managed to make it work. The overall architecture didn't change for quite a long time though, so I was a bit proud of at least getting that right. I learned a lot along the way as well, especially about multithreading and sharing data between threads. </figure> For some time after that, I contributed more minor things, or helped with things unrelated to the actual code. Even at times when I didn't contribute much to the actual game I've always been around on the discord server. I've dipped my toes into the world of voxel art - I actually created one model that is still in game the wheat model. At some point I learned how to create packages for Arch Linux, and have been maintaining a few for Veloren ever since (veloren</code></a>, veloren-bin</code></a>, and veloren-git</code></a>).</li> </ul> My biggest contribution was probably adding controller support. I initially started working on it around 0.3, but lost motivation for a while, and ended up starting from scratch sometime before 0.5. While it took me some time, I actually pulled through that time, and controller support was included in the 0.6 release. It required me to learn about multiple in-game systems like settings, the input system, and the code consuming the input events (that was especially the case for analog inputs like joysticks, since before the game only supported key press/release events with the exception for mouse movement). I used the GilRs</code> library</a> to handle the low-level implementation details, and after familiarizing myself with the examples I started plugging it into Veloren. There are 3 input types recognized by Veloren a controller can provide: (check out the code here</a>): Button</code> - binary input - like with a keyboard a button can either be pressed or not pressed, but nothing in-between</li> AnalogButton</code> - analog input which can be represented by a number between 0.0</code> and 1.0</code> - usually those would be for example triggers.</li> Axis</code> - analog input which can be represented by a number between -1.0</code> and 1.0</code> - an example of that would be one axis of a joystick.</li> </ul> For the purpose of configuring key bindings, each of them is represented by an enum</code> containing two variants: Simple(GilX)</code> where GilX</code> is an enum</code> provided by the library representing all Buttons/Axes it recognizes</li> EventCode(u32)</code> is used for inputs to which GilRs</code> assigns the Unknown</code> variant of the aforementioned GilX</code> enum</code></li> </ul> </figure> Due to the way the raw events from GilRs</code> are converted to the Veloren-specific types, for example Button::Simple(GilButton::Unknown)</code> will never match any button press, as all events corresponding to unknown buttons are represented by the Button::EventCode</code> variant. It's similar for the AnalogButton</code> and Axis</code> enum</code>s. This can be used to our advantage, as instead of using additional Option<T></code> wrappers in the key-mapping code, we can use the Simple(GilX::Unknown)</code> variants to signify not binding an action to any key. While this might seem confusing, I think it's a pretty neat solution, and I made sure to place comments informing about this in the relevant places of the codebase. Let's move on to the actions the inputs can correspond to. As you might expect, there are 3 types of actions depending on the input type. But in addition to that, they are divided into menu actions and game actions. The names are self-explanatory, the actions a controller can be bound to in menus are completely different than in-game actions. </figure> Now let's talk about settings</a>. As you can see, there are key-maps for each input type, one for the menu inputs and one for the game inputs. In addition to that, you can configure dead zones per-input, invert some axes, adjust the in-game camera pan sensitivity and sensitivity of the menu mouse emulation (more on that later). Those were some of the more interesting things about the controller support system, if you're interested in learning more about it, you can look at the merge request</a>. Most of the magic happens in controller.rs</code> and window.rs</code>. Some of the code has changed by now, but most of what I'm talking about here stayed the same. Now let's talk about some things related to controller support that I didn't implement. First off, a graphical configuration interface. Implementing it requires knowledge about the graphical parts of Veloren, which I haven't touched to this day. The other thing was proper menu navigation - with a controller the most natural way is to have one element be highlighted, and move the selection with a joystick. That would require a lot of work though, as it would probably require major changes to the way the GUI is handled, so I settled for mouse emulation, which while not optimal, was a much simpler solution to implement. </figure> Since implementing the above, the biggest thing I've worked on was planning a screenshot and trailer competition which was supposed to take place around the 0.8 release, but it turned out to require much more time than I had anticipated to properly prepare, so I have put that project on hold for now. I might take another shot at it in the future. No promises for now though ;) To finish up, I've learned a ton while working on the project and met lots of amazing people. I would like to thank everyone involved in making Veloren what it is today - a promising game, and an amazing community. I look forward to seeing what the future brings us! Modeling with @Gemu</h2> When I first found Veloren, I was a bit anxious to join and hadn't even considered being able to contribute. After I joined the Discord, I noticed the art section channels, which sparked something that made me want to try after all. After I posted my first model attempt, the nice reception kept me motivated to make more. By now, I have made many models that are present in the game through the help of others. The continuous support I've received kept me going, and I plan to contribute just as much next year as well. </figure> The biggest thing I've worked on was probably the creature model rework. I proposed the remodelling of the animal models at the time, which I took upon myself. Lately, I haven't been able to contribute much, due to being busy. I made a few voxel models of item drops, like crafting materials such as wood, ores and gems. When the new model-skeleton for smaller bipeds was introduced however, I got a surge of inspiration and made a bunch of models for demihuman creatures alongside others. As all dungeons were generally occupied by humanoid NPCs for now, I'm definitely looking forward to the diversity this will add to the content. </figure> Modeling with @Snowram</h2> Heya! It has been a year since I have discovered Veloren and its awesome community. This year has been crazy and I'm proud to have taken part in this adventure. I started to contribute to Veloren by creating some NPC models. Learning how to make them has been a really good learning experience as it was the first time I played with voxel modeling. After delving into the process to add these new species into the game, I discovered how to make skeletons and animations for them. At first, it was a time-consuming process but we achieved to make the workflow easier and easier to allow for complex animations. Now I am working with the art team to make voxels come to life and integrate them into the ecosystem. </figure> There are now almost 100 different species and we are only starting since new skeletons are often getting added. I have also started to learn some Rust basics to be more involved in the development process. So far I added some simple features like a weapon speed stat or allowing items to have buffs. For the future, I'd like to progress further and finally overcome the steep learning curve. The year to come will be very exciting and I'm eager to see what comes next! Work by @XVar</h2> I'm XVar - Technical Architect for a UK-based software company by day, Veloren developer by night (and often weekends...). I first came across Veloren on Reddit, it seemed like a pretty neat project and I'd been looking for a more substantial project to improve my Rust skills with, so I joined the Discord and more or less jumped straight in. At that point my Rust experience was fairly limited, comprising of a mostly finished Gameboy emulator and not much else. Bringing Clippy Back</h3> My first MR</a> came about when I ran cargo clippy</code> and was faced with hundreds of warnings, rendering Clippy</a> completely useless within the Veloren project due to the noise of the vast number of existing warnings. Cue me adding hundreds of Clippy suppressions to get to a baseline of 0 warnings and creating a tracking issue</a> that to this day still needs completing. Although many of those initial suppressions still exist, following this MR we added a zero-tolerance policy for Clippy warnings to our CI pipeline so Clippy continues to be a valuable tool (especially to developers new to Rust) within the project. </figure> Persistence Overhaul</h3> Following this MR I made numerous bug fixes and minor changes before coming across an issue that I considered myself fairly well qualified to deal with - Veloren's database persistence. At this point, Veloren had only had persistence for character data for a few months - a vast improvement over the previous complete lack of it but a fairly brittle implementation. With item data stored in the database as serialized JSON including a copy of the actual item definition itself this led to serious issues whenever item definitions were changed leaving "legacy" items in existing inventories and loadouts with only newly created items having the new properties from the asset files. The solution to this was to rework the database schema to only store the ID of item definitions rather than copies of the entire item, as described in this RFC</a>. As well as removing the issue of "legacy" items requiring complex JSON migrations whenever item definitions were changed I also introduced the concept of "every item can be a container" - more on that later. The persistence MR</a> was a bit of a beast, with development ongoing between August 2nd and September 18th with 77 commits total including an 800 line database migration</a> to extract all of the existing JSON blobs into the new database schema. @Sharp's input and collaboration on this MR proved to be invaluable particularly with regards to ideas on how to make the database schema even more robust. </figure> "Has the server crashed?"</h3> Anyone who spent more than a few days in #general on Discord prior to December 2020 will have been familiar with the frequent questioning from players of why the server just went down following the merge of an MR and the automatic server restart. That's to be expected when you're faced with an obscure networking error out of the blue, after all. Seeing this happen so often prompted me to investigate how we could give players warning of an upcoming restart, and it turned out our Docker infrastructure included all the required components already due to our use of Watchtower for pulling docker image updates. Watchtower by default sends SIGTERM to the watched container (in this case Veloren-server-cli) - which results in the server instantly going down. However, it also supports sending custom signals to processes rather than straight up killing them. I made use of this by adding functionality to Veloren-server-cli</a> which starts a two minute timer upon receiving a SIGUSR1 signal. For these two minutes global chat messages are sent to all connected players informing of them of the pending restart, before the server is finally shut down after the two minutes expire. Unfortunately, this feature didn't work as intended for a further two months as I kind of forgot about it after it went in and there was a bug</a> in our Dockerfile that prevented the SIGUSR1 signal from actually reaching the Veloren server process. Once this fix went in though, the calls of "has the server crashed?" were instantly silenced. </figure> Inventory / Loadouts</h3> After completing the persistence MR I vowed to avoid tackling such a large task for a while, so naturally, a month later I began work on a complete refactor of inventory/loadout handling. For as long as I've been part of the project, players have had a fixed 36-slot inventory with no way to upgrade the size of their inventory. Numerous discussions were had (and aborted prototypes</a> were made) before we settled on implementing inventory upgrades with 4 new bag slots in the loadout. Not only will this allow players to carry many more items than today, but it also introduces the concept of items acting as containers that hold other items. Every item that's in a slot other than the basic 18 slots of the the inventory itself will actually be "inside" the equipped bag item that provides that slot. </figure> This functionality won't have much of an impact when it's first merged, but it'll allow for some interesting possibilities in the future. For example, if weight is added to items combined with overburdening you might want to quickly drop a specific bag of stuff on the ground in order to run faster and escape imminent death. The requirement to have 4 loadout slots that could all hold the same kind of item (bags) necessitated refactoring to remove the previous design restriction of a 1:1 mapping between ItemKind</code> and EquipSlot</code>. This not only allowed us to implement the 4 bag slots, but after this MR is merged you'll notice that you can equip a ring on both hands rather than the previous single ring slot. This change hasn't merged yet, but it should be merged in early January 2021 😁 Pfau's blog post</a> has more info on the UI changes related to this change too. Closing</h3> While 2020 has been a pretty crap year by all accounts, I've had a blast working on Veloren and seeing it evolve over the past six months. I still don't consider myself a Rust expert by any means but working with it consistently has not only massively increased my productivity in the language, but also I frequently find myself thinking about problems from a different angle when working in other languages too due to Rust's disallowance of data races and such. Seeing all the work ongoing with world-gen, the transition to wgpu</code> and iced, the huge improvements to combat and the beginning of a plugin framework all make me excited to see what's next for Veloren and I think the game has a bright future in 2021 and beyond. </figure> Combat Improvements by @James</h2> Hi there! My name is James and I have been contributing to Veloren since August, where @Sharp was kind enough to let me volunteer my hardware to fix an NVIDIA shader bug. I have mostly worked on combat and AI code. For anybody who would like to contribute but is a little timid about it due to little experience or anything else, I encourage you to jump on in! The devs are very friendly and have helped me a lot. My first major contribution was adding additional skills to the hammer, axe, and bow. @Sam (combat lead) graciously wrote a guide for adding skills. With help from many of the other devs I managed to add two new character states to allow for charged melee attacks and ranged projectile bursts. This was my first time working on a project larger than a few files and was quite overwhelming initially. Since then, I have had fun programming humanoid NPCs to attack with all of their newfound skills. We currently use a state machine to determine NPC behavior. The only NPC programmed to use multiple attacks when I added these skills was the stone golem, which uses a timer and proximity to target to determine attack. I began by implementing human attacks in this manner as well. When NPCs were first added to Veloren, they were designed to take the same inputs as player characters (as far as the code is concerned). Minimizing the difference between players and NPCs is part of our attempt to heighten immersion in our simulated game world. Using an arbitrary timer works against this purpose and can make NPC attacks too regular and predictable. Since the humanoid NPCs use the same attacks as players with the same energy costs, I transitioned the conditions for firing the different attack skills to energy cost with a little bit of RNG to simulate stress-induced, split-second decision making. </figure> Currently, humanoid NPC attacks tend to be a little over-aggressive and in some cases play better than most players with the same weapon. I intend to give NPCs varying skill and adeptness with weapons to make combat against AI feel more like PVP. Before working on more considerations with the AI code, I plan to transition the state machine to a behavior tree for better control in the new year (assuming no one else does it before I get to it). I also got to work with @Slipped on some animal attacks. Currently, testing AI code to get it just right can be time-consuming with having to recompile after every change to see how it plays. I hope to modularize the code better with the switch to a behavior tree and perhaps move some tactic components into RON files. After working with combat for a while, I ventured into the land of audio. I play several instruments IRL but had no experience with audio software or coding. The first step was to allow for biome specific music. The biome of each chunk is stored in the terrain metadata. Querying that information was fairly simple. I then worked on some rather convoluted biome transition code before we decided to let the songs play to their end. </figure> Biomes, as defined in the code, are simply labels applied to chunks that meet certain temperature, altitude, humidity, etc. conditions. I tweaked these values a little to match the world gen. At the time, the soundscape of Veloren was being discussed. It was quite empty. Luckily for me, @zesterer had implemented a "blocks of interest" system that selects certain blocks from the loaded terrain to emit particles. These are used for falling leaves, beehives, fireflies, and fireplaces. I repurposed the system to emit sound effects from blocks. The sound effects can be emitted at different times of day allowing for leaf blocks to emit bird calls during the day and owl hoots at night. @Daforlynx worked on and provided me with a wind loop. I created a non-spatial ambient sound manager and set it up to play the wind sound at varying volumes depending on the altitude and tree density. In the future, this will likely be tied to weather simulation. As more people play Veloren, we hear all kinds of feedback. Many people asked for a passive health regen. Most of the core devs do not like the idea of a passive health regen for many reasons. To help the player situation out, I made campfires regen health when a character sits nearby. To accomplish this, I developed an aura system to apply buffs to nearby entities. While relatively bare-bones right now, this system will allow for things like poisonous gas vents, enchantments, and more. Most recently, I have been working on a poise system to complement Veloren combat. In many old school RPGs, combat is little more than firing off different attacks while the character remains stationary. In Veloren, we hope to develop a more dynamic combat system that rewards player skill with regards to movement and weapon skill use. The addition of i-frames for melee attacks to the roll/dodge was a major first step. The poise system will govern stuns and take-downs. With this system weapons have a poise damage stat in addition to regular power. This makes some weapons better for stunning while having lower DPS allowing for more play styles. </figure> Armor also will have a poise damage reduction stat. The exact balancing details are not sorted out yet, but the general idea is as follows. Character entities have a poise component similar to health. Different species have different base poise values. When poise is lowered below a predetermined fraction of the total (tentatively 50%) the entity enters a stunned state, interrupting their attack and affecting movement. The stunned entity's poise immediately resets to 100%. The further below the initial stun level, the larger the effects on the stunned entity. I am still experimenting with knockback as well. This system motivates the attacker to save up heavy attacks for when the defender is most vulnerable and provides further impetus to avoid being hit. With the addition of @Sam's skill trees I believe we will be well on our way to a fun, competitive combat system. Starting with Audio by @Badbbad</h2> I found Veloren at a point when I had a lot of motivation to write music for open-world games but I couldn't find an outlet to fulfill it. Finding Veloren community amazed me, how so many talented and hard-working people can team up for a passion project so organized and well-directed. I was immediately hooked by the concept, downloaded the game, and played. 5 hours later I already was done writing the track "Between the Fairies" and sent it to #audio. And today I'm one of the team leads of the audio team. Veloren really helped me learn to enjoy the process and cherish the progress step by step. It also showed me that people with passion and talent are a huge force, that can build an entire game only by volunteers! (that's crazy) Currently, I'm making and implementing sound effects for a free-to-play game called "Tadpole Tales". You can check out some more of my work here</a>. It's more than exciting to be a part of this community, and I'm looking forward for our future! The walls of Gronk Keep must be fascinating </figcaption> </figure> Network Analysis by @xMAC94x</h2> Follow-up Performance Analysis from devblog-93</a></h3> When I wrote this article it had the working title "how to make sure that the next release party can handle 100 players". During the investigation, I dived deep into the Veloren source code and found multiple regions that have difficulty scaling. The server only needs a single bad scaling component which is enough to slow down everything. I was even happier to actually see 100 people on our latest party. In its current state, none of the devs could dream of it scaling so well. Anyway, I owe you some physics and networking details. How we Calculate Physics</h3> Physics in this context describes handling positions, velocities, and hitboxes. We break it up into 2 parts: first, we do entity <> entity collisions. then we do terrain collisions and apply the movement. Entity <> Entity Collisions</h4> For this, we iterate over all entities. Technically, only those with position and velocity except for mounted entities and projectiles. For each of these entities, we check if it collides with another entity. We skip entities checking against themselves, other mountings, projectiles, beams, and shockwaves. Therefore we draw a cylinder hitbox around the entity. If we detect a collision we adjust the velocity so that our entity moves away from the collision. Entity <> Terrain Collisions</h4> For this, we iterate over all entities (technically only those with position and velocity except for mounted entities). We then apply movement parameters (gravity, friction, water physics) to the entity. Then we try to apply the resulting velocity in small steps, which doing collision checks with the terrain. Therefore we draw a rectangular hitbox around the entity. I used tracy</code> (see the previous devblog) to analyse the bottleneck of our physics coding. The more players are spread around the server, the more entities are loaded. The entity <> entity code scales very badly, as it needs to check each entity with each entity. For 1000 entities we have 1.000.000 checks. During load the server often has 3000 entities loaded, resulting in over 9.000.000 checks. In order to speed this process up we do a quick-check where we approximately some parameters, so quickly skip far apart entities, though this check is far from optimal. Additionally, we parallelize this calculation to profit from multiple cores. This is our main bottleneck for < 30 players, it will draw resources and burn CPU time (which costs us server host money to keep the server tick time at 30 TPS). </figure> Overview of new Network Backend</h3> Our old code had many bottlenecks that got fixed within the last 2 months. We used to actively wait for new players to connect, actually creating a "laggy" tick, that can take up to half a second. We only do this for the auth token check currently, but plan to even put this in a background task.</li> We send a big message on a single channel for all kinds of communication which got compressed always. We started to split this up in multiple channels, so we can process PING messages independently of CHUNK messages or GAMESTATE messages. Also we can apply compression algorithms more carefully and save some CPU time.</li> We no longer need to serialize the same message multiple times if we want to send it to multiple participants. This massively saves CPU time on the server.</li> </ul> In the future, we will apply separation into multiple channels even more carefully and optimize our ECS format, to reduce bandwidth usage by 75% profiting users with slow internet connections. I would like to take this opportunity on this special 100th blog to thank all contributors, artists, players, developers, musicians, and translators for their time and dedication spend on Veloren. There are 1000 different faces, and each of you is doing your unique but essential part for this project! The State of Graphics and UI by @Imbris</h2> We have two major transitions in the crates (Rust libraries) being used for rendering and UI respectively. For rendering, we are switching from gfx</code> to wgpu</code> and for UI we are switching from conrod</code> to iced</code>. One of the shared motivations for these switches is to move to crates that are being more actively developed. The old gfx</code> crate is pretty much inactive since the GFX team moved on to developing the much lower level gfx-hal</code> and wgpu</code> which is closer to the old gfx</code> crate's level of abstraction. While conrod</code> is more mature than iced</code> and is still maintained to an extent, updates are infrequent and there doesn't appear to be a significant driving force to fix the current missing features and rough edges. </figure> Wgpu transition</h3> Currently, we just use the gfx</code> OpenGL backend. wgpu</code> automatically supports multiple backends including more modern backends such as Vulkan, dx12, and metal. Hopefully, this should allow us to eke out more performance. The wgpu</code> rewrite is currently fairly complete, mainly with shadow rendering needing to be fixed as well as interpolation of LoD texture sampling. There are, however, a few other issues to consider: drawing into shadow cubemap textures</li> OpenGL support</li> Shaderc/SPIR-V</li> </ul> Shadow Cubemaps</h4> We use cubemaps to render point light shadows. Previously, we could render to all the faces using a single draw call via a geometry shader that duplicated vertices and selected a separate face of the cube for each duplicate. However, wgpu</code> doesn't provide support for geometry shaders so this isn't possible. To get around this we have to have a separate render pass for each face where we render all the terrain into that face. This works but potentially has an impact on performance. OpenGL Support</h4> Currently, we target OpenGL 3.3 with the goal that people on old machines should still be able to play Veloren. Unfortunately, OpenGL support from wgpu</code> is very limited and only exists on Linux/MacOS due to complications with surface creation</a> and I don't know what the minimum required OpenGL version would be and/or how much overhead there is to emulate the modern API of wgpu</code> for older OpenGL versions. One thing that will help us is that there is also support for dx11</code> which should cover many of our Windows users on older machines without dx12. </figure> Shaderc usage</h4> wgpu</code> consumes shaders compiled into SPIR-V. To get the SPIR-V shaders from our GLSL shaders we have to use shaderc</code> which is a non-rust dependency that introduces additional friction to getting compilation of Veloren set up. A potential workaround for this that many projects use is to precompile the shaders to spirv and track those in git along with the GLSL source files. This will make shader hot-reloading more complicated as we can currently just change the shaders and save them and the game will recompile them automatically. A potential middle-ground would be to include a new feature in voxygen</code> that enables the use of shaderc</code>/hot-reloading which is off by default that graphics developers can enable as needed. We could even have it enabled in the distributed version of the game if there are no complications for compiling in the CI with shaderc</code>. Iced transition</h3> As I think I wrote in a previous post, we have fully transitioned the main menu and character selection screen to using iced</code>. All that remains is to covert the HUD however this contains much more UI code than both the menus combined. > tokei -f voxygen/src/hud/ ---------------------------------------------------------------------------------- ---------------------------------------------------------------------------------- Language Files Lines Code Comments Blanks Rust 22 14609 12811 994 804 ----------------------------------------------------------------------------------- voxygen/src/hud/slots.rs 185 160 1 24 voxygen/src/hud/spell.rs 114 86 9 19 voxygen/src/hud/minimap.rs 465 387 39 39 voxygen/src/hud/social.rs 602 549 33 20 voxygen/src/hud/esc_menu.rs 182 162 6 14 voxygen/src/hud/overitem.rs 144 108 22 14 voxygen/src/hud/overhead.rs 603 519 53 31 voxygen/src/hud/group.rs 838 764 51 23 voxygen/src/hud/map.rs 820 724 67 29 voxygen/src/hud/util.rs 183 154 3 26 voxygen/src/hud/chat.rs 568 482 45 41 voxygen/src/hud/popup.rs 243 212 12 19 voxygen/src/hud/item_imgs.rs 192 166 13 13 voxygen/src/hud/skillbar.rs 1020 905 94 21 voxygen/src/hud/bag.rs 930 848 57 25 voxygen/src/hud/crafting.rs 514 465 30 19 voxygen/src/hud/buffs.rs 515 466 23 26 voxygen/src/hud/img_ids.rs 402 309 40 53 voxygen/src/hud/hotbar.rs 118 102 4 12 voxygen/src/hud/buttons.rs 408 388 8 12 voxygen/src/hud/settings_window.rs 2832 2486 167 179 voxygen/src/hud/mod.rs 2731 2369 217 145 ----------------------------------------------------------------------------------- Total 22 14609 12811 994 804 ----------------------------------------------------------------------------------- </code></pre> Some of this code is reusable but most of it is conrod</code> specific UI code. In order to break this down into surmountable bytes, we will need to have a way to incrementally transition the hud code. The first step is implementing a custom iced</code> widget that can manage a list of windows to allow easily laying out a HUD like UI. This can then be drawn alongside the conrod hud. Then we can reimplement each major portion of the hud as one of these windows (e.g. the map screen, the chat, the skill bar, etc). One other thing we will need to keep an eye on is the performance of text widgets. Unlike iced</code>, conrod</code> requires an ID for every widget. It is nice to not have manage IDs when writing iced</code> UIs; however, in our conrod</code> rendering backend, IDs are used for caching text rendering information for efficient lookup. conrod</code> itself also keeps some state associated with each text widget</a> which allows it to identify when the text is changed or when previous computations can just be reused. There is a proposal</a> for iced</code> retain information about the widget tree between frames which could be helpful for this issue. We could also create a custom widget that grants IDs for text either managed by the user like in conrod</code> or automatically derived (e.g. using #[track_caller</code></a>) or perhaps we will find some other way to efficiently cache and retrieve this state. Fontdue</h4> On the topic of text there is another crate that I have been considering transitioning to at some point. fontdue</code> is the fastest text renderer</a>. Currently, we use glyph_brush</code> which currently uses the ab_glyph</code> rasterizer crate (a rewrite from the developer of rusttype</code> which glyph_brush</code> used to use). While fontdue</code> is much faster than other rasterizers, glyph_brush</code> provides a glyph and layout cache which we would need to find or implement to be able to use fontdue</code>. </figure> Skill Trees by @Sam</h2> For the past month and a half, I have been working on skill trees, and they are finally beginning to near completion. Skill trees will completely replace the current leveling system where you get a few points of max health every level. In my branch, I will be adding a general combat skill tree, as well as a skill tree for each of the six weapon kinds. Each skill tree will have its own experience bar and skill points (which can be considered somewhat equivalent to levels). Skills will naturally be purchased with skill points, and the amount of experience required to get a skill point will always be constant and will not scale with the number of skill points earned. Currently, skill trees for each of the six weapons are done, support for prerequisite skills is done, leveled skills are done, and database persistence for skills is done. The general combat skill tree, UI for skills, functionality for refunding skills, balance testing the skill trees, and creating database migration templates still need to be done before skill trees can be merged. </figure> Procedural Trees by @CCGauche</h2> I wanted to add procedurally generated trees to Veloren since the current ones have to be created manually. I’ve started iterating on tree designs. The main problem while developing was Veloren's compile times. It took about 2 minutes for each change, plus 1 minute to get in-game. To solve this, I designed a wrapper for Rust and Java Minecraft plugin and used a custom Minecraft server to lower this time to around 3 seconds. This helped speed up prototyping a lot. The first ones were T shaped as you can see: </figure> I decided to work on a leaf growth algorithm and obtained a very symmetric trees. This first algorithm was simulating realistic leaf growth with variables like sun exposure, position, and precipitation: </figure> Then @zesterer came to help and together we designed a new branch generation algorithm! After lots of work, iterations, and optimizations we were able to generate very unique, good looking, and fun to climb trees! The leaf algorithm has been updated to match performance constraints. We removed all the original variables and instead added a health parameter that is different for each branch and based on the soil and sun exposure. I also revised the branch generation algorithm to use vector projections that reduced block updates and managed to give a 5000% improvement. </figure> There is still a lot of optimizations to do so the game can generate trees at chunk load. @zesterer and I are working on interpolation to reduce the number of computations for leaves gen. You can’t see it on the graph but on the 5th iteration, we are at 7ms for branches and 130ms for leaves. </figure> Special thanks: @zesterer | Help for branch algorithm and optimization ideas</li> @Sharp, @zesterer | Code reviewing</li> @Pfau | For the general tree design</li> @Pfau, @Gemu, @Treeco, @Slipped, @James, @Sarra_Kitty, @Scott, @XVar, and @Snowram | For the tree design corrections</li> </ul> New Website Design by @Songtronix</h2> We can't hide the fact that our website isn't the prettiest one. It works perfectly fine but also misses a lot of links, information, and content. So I've been prototyping a new website you can check out here</a> or just take a look here: </figure> It is pretty bare-bones right now, but there will be things added like a feature section (combat, vision, general gameplay aspects and what makes Veloren special) and a lot more. Suggestions are welcome! Furthermore it's fully responsive</a> too. And as a side note, the green download buttons are not Linux exclusive don't worry. They adjust based on your OS automatically. The layout is pretty good although I'm still tinkering around to maybe match the feeling of my website</a> more as I like the background and look of it. Let me know what you think! Now onto other work which I haven't mentioned that much in the blogs: </figure> </figure> </figure> A while ago I wrote a Discord bot that allows you to control the Veloren server it manages (which I'm able to pay for with the help of my patrons - thank you!). You can adjust/view all settings including downloading the database, switch/update a branch of your choosing as long as it's on the main repository and view the logs live! As it seems it greatly improved the speed of development or rather testing of new features so it serves its purpose well. As it's the 100th edition of the blog a lot of time has passed! When I started on Veloren, I was a Rust beginner and I hadn't worked on anything open-source related at all. Now I'm the UX working group lead, I've revamped the book</a>, redesign the website, created a test server with a Discord bot, wrote Airshipper</a>, and I've learned so much during that time and continue to do so! Why Veloren is Special (to me) by @Christof</h2> Watching this year’s news covering more and more Rust I decided to take a look into this new language, to augment two decades of professional C++ experience. So I started following the weekly Rust newsletter, which brought me to "This Month in Rust Game Dev" where Veloren showed up with beautiful screenshots. After reading some chapters of the Rust book, I then looked for an open-source project to gain practical experience and remembered this promising project. The sheer size of Veloren’s codebase was intimidating at first, so I was more than happy to get a shorter tour around the concepts by reading the few hundred lines of teloren source code. This let me quickly become familiar with the tooling and enabled me to add some small patches to teloren. From there on I got more confident to not break anything when modifying Veloren’s code. Of course, I initially stayed more with databases which I already had gathered experience in beforehand. </figure> Up to now, I have seen a significant portion of the code and mostly feel at home with it. To me the codebase is clean and most times easy to understand, with the exception of the conrod</code> UI. Dwelling into the code taught me a lot of Rust idioms, of course most in-depth when modifying the code and from the valuable feedback on merge requests. Also, I found that Rust indeed makes it easy to change unknown code; once it compiles the most basic problems are solved. From my experience, a C++ project with that many contributions by non-core developers would suffer from significant quality issues. Most of the complex code is yet less visible to players (procedural world generation, erosion, economic simulations) but form a good basis for future in game features. And I fully agree that Veloren is one of the most beautiful open source games around. The community has always felt welcoming to me and I still haven’t figured out how the main developers manage to read and even answer the huge number of messages in the Discord server. Just judging from the number of participants online (at times more than 2000), I see that Veloren is a very active project. I can tell that contributing artwork, e.g. voxel models, is a low bar and a very satisfying experience. The project team and players are really persistent at celebrating beginners' contributions and thus I have high hopes that the next year in Veloren will be as bright as what I have seen from this one. Getting into RTSim by @Ubruntu</h2> Congrats to the Veloren community on the big 💯 I started playing Veloren about 4 months ago, around the 0.7 launch. It already feels like a completely different game today than it did when I started my first character. With some big branches in active development, the game will feel completely different again soon. I really like that Veloren is under constant development and there’s so much active discussion around it. I’m happy to see Veloren getting more popular, and also getting more and more talented contributors. As someone who contributes code, I like that Rust was the chosen language for the project. Rust is my favorite programming language and I find Veloren to be a very approachable large Rust codebase. Rust has amazing tooling and offers the compile-time checks so that new changes I make likely won’t introduce catastrophic bugs that cause players to set the game aside and wait until a patch is released. </figure> Speaking of contributing code, I’ve recently been experimenting with the real time simulation (RTSim) code. It started with the idea that the game has travelers, and the game has birds that can fly, so why not turn some of the travelers into birds and make them fly? I posted some screenshots of birds in the air and got some positive feedback so I kept working at making this a feature in the game. It also sparked some discussion around the RTSim implementation in general and how we can move it forward as a core part of Veloren. The 0.8 release was a lot of fun. It was exciting to see over 100 players online, and to form a dungeon party with about 15 of them to raid one of the highest difficulty dungeons. Afterwards there were some discussions around issues that only MMORPGs usually deal with. If some people consider Veloren an MMO now then that’s great news to me, because I personally love the dungeon party experience of MMOs. Happy 100th blog post Veloren. I’m excited to see what’s to come in 2021. Finding Veloren by @Yusdacra</h2> I found Veloren while I was searching for projects that use Rust about 1.5 years ago. I wanted to see if the language was mature enough for me to pick it up, as I wanted something that could potentially replace C# and C++ for my use cases. I was pretty surprised to see such a video game project existed, and it was build on Rust, which was the perfect candidate for me to see how the language was practical. The community was very welcoming and I got up to speed to do my first contributions, most of which were low hanging fruits fit for a beginner to the codebase. As time passed, I moved onto my own projects, but I'm still maintaining the Nix expressions and Turkish translation. Compared to 1.5 years ago, I now feel pretty confident with my Rust code, it was not too hard to get into, but also provided enough challenges, while also being fun to write. And it's all thanks to Veloren and it's community! </figure> New Developer Experience by @Entropy</h2> Honestly, I started working on Veloren with literally no programming knowledge whatsoever, so when someone said "this is an easy fix but we’re all too busy!" I took the opportunity to just... go for it I guess. It’s been definitely a new experience, but going from "I looked at the code and it might as well be Latin" to "I actually kinda understand what’s going on here" has been real satisfying and encouraging. Looking to the Graphical Future by @Sharp</h2> Recently I've been working on the wgpu</code> branch. My most recent change was switching to reversed depth buffers which lets us theoretically avoid all clipping while extending views far enough to see for hundreds of kilometers with better quality than we have now. The biggest system I've worked on is still initial worldgen (erosion). The project is far from finished, but being able to use realistic simulation techniques to produce rivers, mountains, hills, and valleys that actually feel real and don't just feel like noise has been incredibly rewarding. However, I've also touched a lot of the graphics stack, in particular in helping add level of detail (LoD) and shadows to the world, which really helps make its scale look visually breathtaking. I didn't know much of anything about graphics when I started working on Veloren, but doing more with it has given me a real appreciation for the math behind it as well as how shaders work and how to write code that's efficient for the GPU. I'm really looking forward to Veloren continuing to become more immersive in many different ways. For worldgen to improve further, especially in terms of large scale structure (i.e. mountains no longer randomly popping up everywhere using tectonic and glacier simulations, much larger worlds), performance improvements (many are now available to us after switching to wgpu, including potentially thousands of dynamic lights with deferred rendering), and more. I will especially be happy when upcoming work simulating economics, NPC history, and human structures start to become better integrated into the game, together with graphical improvements to things like LoD that reveal more of the world. </figure> Combat System Design by @Silentium</h2> Veloren’s combat system is a combination of dedicated programmers and many hours worth of game design meetings. It’s not finished, and it won’t be for some time, but it’s a fantastic start. The Game Design group has seen many people come and go, but the current team is very capable. The core mechanics for our combat prototype is looking extremely promising, and I’m so excited to see the rest of our vision come to life. I have so many people to thank for contributing to the design and development work that has gone into the current Veloren combat system. Cheers, -Silentium Watching the full moon. See you next week! </figcaption> </figure> This Week In Veloren 99 Mon, 21 Dec 2020 00:00:00 +0000 This week we see new models coming into the game. We hear from @Christof about how economic simulation is being done for different items. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Slipped, @XVar, @lboklin, @BenoitduGarreau, @imbris, @Frinsky, @Entropy, @xMAC94x, @jiminiycrick, @zesterer, @ccgauche, @Pfau, and @HiggsTardigradeTau! This week, @Pfau posted another edition of his Veloren art blog, you can check it out here</a>. @ccgauche has been putting in a lot of work into procedurally generated trees. They are also working on the new backend of the plugin API. Procedural trees by @ccgauche </figcaption> </figure> @AlbinoAxolotl made serpent carnyx and brass boumbek models. @Scott worked on some bigger updates to the wiki. @Sam got the axe skill tree finished up. @XVar has the inventory/loadout overhaul nearing completion. The UI changes can be seen in @Pfau art blog. @Sarra_Kitty worked on several new glider variants and learned how to use Git for the first time. @Slipped animated stuns and staggers for the poise system that @James implemented. Next, @Slipped will be moving on to making the system fun to use. Current state of the wiki </figcaption> </figure> Economic Simulation by @Christof</h2> Last week</a>, we saw that prices are determined by supply and demand. But if you happen to be an adventurer coming back from a dungeon where you risked your life to loot better weapons and armor, you'll also end up with some less potent spare items in your inventory and want to exchange them for new food and potions. Typically there are two solutions to this within a program: Handcrafted, neatly balanced hardcoded prices (with some spatial or temporal variation)</li> Economy simulations</li> </ul> Depending on the situation, the first shows a tendency to either feel too random or too fixed. On the other hand, getting a simulation that works well enough is a considerable piece of work. A core question that emerges is; why would a person living a happy life in a town that farms crops ever want to exchange your spare armor and weapons for their food, as only food offers a direct value to feed the family? Serpent Carnyx by @AlbinoAxolotl </figcaption> </figure> This question has left me puzzled for some time as I wanted to find a way to determine an exchange rate between armor and food to create reasonable prices for trade. In June, @zesterer created the second generation of economic simulation (see TWiV-72</a>) which calculated the need for different professions among a town’s population and the exchange rates between sites. But an exchange price for wheat and meat does not suit adventurers that well as they will hardly be able to provide these goods in exchange. The idea I followed to get prices for martial equipment is to restrict access to natural resources by a concept of a controlled area. The more area a town controls the more natural resources it has access to. Subsequently, the more secondary and tertiary goods it can produce, the more mouths can be fed. With this in mind, we can get some exchange rate between armor and food, as one controls the available amount of the other. The current production chart of this model looks as follows: </figure> Rectangles show professions, ellipses show goods. Natural resources (which are collected from surrounding areas) are colored in green, produced goods in orange. The numbers indicate the number of goods needed and produced by a single person. There are two special nodes at the bottom: “Everyone” literally means any inhabitant of a town and “controlled area” corresponds to patches on the map allocated in radial order by the amount of guards employed. So each town will have its own pattern of surrounding natural resources, depending on its location in the world. An economic simulation step (see tick_site_economy</code>) looks like this: demand</code> is the sum of the goods (including food) needed by all the workers (and non-working people)</li> supply</code> is the sum of produced goods (taking last step’s availability of resources into account)</li> marginal_surplus</code> is supply - demand (indicates whether stock is increasing of decreasing)</li> surplus</code> is stock + marginal_surplus</code> (the amount of missing (negative) or unneeded (positive) goods)</li> relative good value</code> is a smoothed exponential function of the relative amount of missing resources</li> labor</code> is redistributed according to the smoothed sum of the value of the produced goods</li> labor_productivity</code> is the minimum of the relative availability of resources from (last step’s) stock</li> materials_cost</code> is the sum of (last step’s) labor_value</code> of the resources consumed, per produced unit</li> labor_values</code> is the sum of materials cost and wage cost (fixed 1.0 per worker), per unit</li> </ul> As the last step, some of the stock decays and is then replenished by naturally grown resources. The population is easily simulated by a death rate of 0.5% and, only if there is enough food to feed the inhabitants, a natural birth rate of 5%. New glider by @Sarra_Kitty. See you next week! </figcaption> </figure> This Week In Veloren 98 Mon, 14 Dec 2020 00:00:00 +0000 This week, lots of work is being done on many systems. We hear from @Christof about some economic simulation debugging. Work on a modding system has also kicked off. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Pfau, @ccgauch, @zesterer, @Snowram, @Yusdacra, @Sam, @xMAC94x, @nahua, @Entropy, @DaforLynx, @TheJackiMonster, @VincentFoulon, @XVar, @lboklin, @Slipped, and @HiggsTardigradeTau! The yearly Rust survey</a> results are out for 2020! @Snowram changed model offsets to be editable from RON files so that they can changed in real-time in the game. @Scott created a range of gems that will replace the shiny gem. @Moschopper got their first MR merged. It changes the way delta time is calculated so characters don't teleport after brief lags. </figure> @lboklin converted the Nix files to use "flakes" (which is an experimental Nix feature). This can allow people to install Veloren Voxygen by running nix profile install gitlab:veloren/veloren</code>, which uses the latest commit to the master branch (more instructions in nix/README.md in the Veloren repository). Note that we have kept backwards compatibility, so even if you can't enable the feature (I recommend you to enable it and use it!) you will still be able to use "legacy" Nix commands with the Nix files. </figure> @Entropy has been preparing a crafting overhaul, starting by defining a whole bunch of items. @Sam made skill trees persist in the database. He also completed the sword skill tree. @Pfau has been working on many items, including skill trees, bag UI, a prompt dialog, and group member position indicators. @zesterer spent some time this week setting up water reflections for LoD water. This makes mountains off in the distance look much more realistic! </figure> @zesterer and @ccgauche spent a few days working on the initial implementation of a plugin system that would allow modding Veloren through both server-side and client-side mods. Mods would be written in a variety of languages (Rust probably being the only officially supported one for a long time) and then compiled to Wasm, executing in a sandbox. This means that mods can be automatically sent over the network when you connect to a server without risk. The plugin API is still in its infancy and will no doubt go through many, many changes and refactors until we're ready to announce it as being ready for use, but before then we hope to encourage discussion about modding and get people excited about writing plugins for Veloren! A new movement ability that is being worked on by @Offspec </figcaption> </figure> Economic Simulation Update by @Christof</h2> This week, I debugged infinite prices (and material costs) in the economic simulation. I found that it came down to hyperinflation caused by high costs on natural resources. This caused increased food prices, which in turn caused increased labor costs to secure natural resources, and it repeats. I masked natural resources from the production of Guards (securing them) once an increase in controlled area will no longer provide more of this good. Then I changed the produced amount of natural resources (by Guards) to reflect the annual replenishment instead of a minimal placeholder and the prices got stable. This is quite understandable as the labor and material cost of guards gets distributed among more resources. I see that the overall economic system needs rebalancing of material input and production output, to get a better overview I plan to add economic values to the tooltip in the map window. Thus I am currently working on getting dynamic tooltips on settlements into the map window - to quickly check the economic situation in different sites (with different access to natural resources). Flying through the valley to the ocean. See you next week! </figcaption> </figure> This Week In Veloren 97 Mon, 07 Dec 2020 00:00:00 +0000 A new edition of This Month in Rust Gamedev is out. The worldgen WG had a meeting. Lots of progress was made on systems all around the codebase. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @XVar, @Sam, @James, @imbris, @ubruntu, @xMAC94x, @Yusdacra, @Stu, @iOddishGX, @AngelOnFira, and @Weldar! This week, a new edition of This Month in Rust GameDev</a> was released! @Songtronix worked on preparing for Airshipper 0.4.2. @lobster gave a hand by improving font readability. There was a worldgen meeting that looked at where worldgen should be worked on in the future. @imbris and @Capucho rebased the wgpu branch and made some progress on it. </figure> @Sam worked on adding support for skills to have levels, and began moving the configuration of things to RON files. @Valtameri is working on the wiki and adding many weapons and items to it. They are also adding pages explaining the weapon types and their three different attacks as well. @James added an aura system to allow entities to supply radial buffs to surrounding entities. Currently, it is only used at campfires. You can now sit next to one to slowly regenerate health! In the future auras will also be able to affect terrain and environment parameters like temperature. @James also began work on a poise system to govern stuns and take downs. @Christof removed the old copy of the economic simulation (which still got executed even though it was never used) and started implementing adaptive access to natural resources (more military personnel secures a larger area around a town). Thus you get an economic value to military and thus to weapons and armor, resulting in market prices relative to food items. </figure> Worldgen Meeting by @zesterer</h3> On Saturday, we held a world generation meeting. I'm keenly aware that the world generation code can be intimidating and unfriendly to new contributors. For this reason, we made sure to focus the meeting around introducing the concepts that currently exist in the worldgen code, what direction we're likely to push them in, and then thoughts about what aspects should be prioritised. No hard decisions came out of the meeting (I plan to leave such things to a follow-up meeting) but hopefully it acted as a route for contributors to develop an interest in world generation and think about where we might go with it in the future. As the sun rises on an empty ocean, you think to yourself... where is my boat? See you next week! </figcaption> </figure> This Week In Veloren 96 Wed, 02 Dec 2020 00:00:00 +0000 This week, Veloren 0.8 was released! We take a look at how the release went, and some of the feedback. We also hear from /u/o11c about some of their experience on large multiplayer projects. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Yusdacra, @ubruntu, @Nicknakin, @XVar, @azymohliad, @AngelOnFira, @imbris, @Sam, @Snowram, @Treeco, @zesterer, @timsueberkrueb, @Pfau, @DaforLynx, @James, and @Slipped! 0.8 was released last weekend! There is a new article on GamingOnLinux</a> about the Veloren 0.8 release. This was our biggest release ever, and it amazed the entire core team that so many people came out. @ubruntu has been working on small bug fixes and is currently working on adding chat commands for inviting, kicking, promoting, and leaving a group. @Snowram worked on adding and animating fish. </figure> @Christof asked around for help on how to die less quickly in combat against bow wielding bandits, and then collected the answers into a beginner' hint section of the book. They also started to work on a minimum viable solution for selling inventory items that you gather over time and buying stuff you need instead. @Christof also got teloren, Veloren's terminal frontend, working on 0.8.0. </figure> @Sam worked on abilities being automatically greyed out when you have insufficient energy. Previously, the UI had hardcoded values it checked, leading to some abilities greying out at incorrect values since they were checking outdated numbers. @Sam also fixed a bug with the leap potion of the bow's skill bar ability, and did a few miscellaneous combat tweaks. These primarily affected energy regen of melee weapons, and the bow's primary attack. @Yusdacra improved the Nix dev environment so now it has a Cachix setup meaning that Veloren dependencies can be stored globally and everyone can benefit since they won't need to compile the same stuff again. It now also sets up git-lfs automatically, adds a direnv setup, and includes nixGL commands for non-NixOS users. This means they can actually run Voxygen now, since OpenGL programs on non-NixOS compiled via Nix is problematic. The Voxygen package now includes a .desktop file too. Veloren 0.8 Launch</h2> Veloren launched 0.8 this weekend! This launch includes some massive new systems, as well as a multitude of other changes. Here is a small part of the changelog, but make sure to check out the full changes here</a>. - New level of detail feature, letting you see all the world's terrain at any view distance. - Point and directional lights now cast realistic shadows, using shadow mapping. - Added leaf and chimney particles - Some more combat sound effects - Beehives and bees - Fireflies - Fullscreen modes now show two options (exclusive and borderless) - Added banlist and `/ban`, `/unban`, and `/kick` commands for admins - A new dungeon boss (venture there and discover it yourself) - Adaptive stride setup for more dynamic run behavior - Several new animals - Buff system - Flight - Persistent waypoints (start from the last camp fire you visited) - Ambient SFX emitted from terrain blocks - Initial implementation of real-time world simulation - Travellers that explore the world - Innumerable minor improvements to world generation - Aurora Borealis (localised entirely within the kitchen) - Block-based voxel lighting - Animals now have customized attacks and AI </code></pre> Launch party! </figcaption> </figure> This was not only the biggest update to Veloren yet, but also the biggest launch party. At the peak, there were 112 players online. This gave us a lot of insight into how scaling works. Here are some quick facts: 5 minutes before the release party, we had to restart the server as we forgot to increase the player cap past 40.</li> We used a 32 core dedicated server from Hetzner. Although we had 128GB of ram on the server, we only used around 5GB.</li> The release party had the peak number of players 30 minutes after it started.</li> Normally, release parties go for around 2 hours before we get down to fewer than 10 players. This time, we went down to 30 players after two hours, and hovered there for around 24 hours.</li> We used around 100GB of bandwidth for the launch.</li> The server cost around 4 Euros, or $4.84 USD for the 7 hours it was up.</li> Players started reporting higher latency and some rubber-banding issues at the peak player count, but it was still playable.</li> </ul> </figure> </figure> </figure> </figure> </figure> We learned a lot from the release, and got a ton of important feedback. The most important item is how balance works for new players entering the spawn town. It was very difficult to spawn in and make it out of the initial area alive. There were also a lot of comments about how we could work on other character balance in the future. From the stress test and release, we found many areas that need improvement on the scalability side. Our main game thread struggled a lot, which implies that we aren't assigning tasks to other threads as much as we need to be. Further, there are lots of improvements to be made within physics, AI, and other compute-heavy tasks. We also need to work on how we are sending data over the network to players. There are likely massive gains we can make, which would allow bandwidth to be improved significantly. What People Are Saying About the Launch</h2> GamingOnLinux</a></h3> Release party just now was chaos, in a good way :) I think there were around 100 players fighting a giant dragon </blockquote> - Julius Installation was super-smooth though, totally unexpected. It's just ~125MB, I expected something measured in GB. But then, makes sense, voxels + procgen... </blockquote> - riidom Going to snag this for my boy to check out. He was watching all 15 minutes and really liked what he saw. Great to hear this in Rust! </blockquote> - techieg33k Looks amazing. Definitely the most impressive FOSS RPG project that I have seen to date (no offense to Flare). </blockquote> - nate The timing of this release is funny for me because I just played the game with my kids yesterday before I knew there was a big update. I was pleasantly surprised to see a lot of things added to add interest to what was a more empty game. We used the Airshipper launcher which updated the game and then we played on a local server that was launched by browsing to the installation folder and running the server-cli program. </blockquote> - 14 </figure> Reddit</a></h3> Veloren is shaping up beautifully, can't wait to see what's to come. </blockquote> - /u/SmurfTaters Idea Drop by /u/o11c</h2> Context: On a Veloren 0.8 release post to Reddit, /u/o11c gave some insight from their own development experience. Although not all of it will be the path that Veloren takes, the points are valuable nonetheless. </blockquote> LPT: don't ban botters too harshly, you want to get them to work for you. Also, be aware that people will use a bot client just because they want to avoid some particular pain point with the official client. So, steal their patches. Finally ... no matter what you do, you will never block all bots. So instead focus on making sure bots don't ruin people's fun. Also a random dump of other things I've learned, mostly from doing everything the wrong way (some items already filtered because I saw you did them right already, but I admit I haven't looked hard yet): Never use TCP. ISPs will rudely inject RSTs into long-running streams, and you can't realistically ask people to install a firewall rule to drop them. </li> Likewise, always encrypt everything. QUIC made life easier but there are numerous alternates. Multiple streams are probably overrated. </li> Always have a "frontend" server that proxies client connections from the start; this allows transparently moving them to a different backend server when they move between in-game regions (which is essential for scalability). You cannot rely on clients to successfully connect to a second server themselves. Not all players need to use the same frontend server either. Load typically isn't an issue, but this may be useful for working around crappy ISP peering in some countries. </li> Think about ways players can organize: A friend is a one-way, individual, relationship. There should be user-labeled levels of friends ("rivals" might be a level). Some of this should sensibly be viewed from a web interface, not just in-game</li> </ul> </li> A guild is a large long-term group of many players, possibly with ranks. Sometimes it would be convenient if it's possible to join multiple guilds, but not too many. </li> A party is a small short-term group of players intending to do combat together; they may or may not be part of the same guild. In practice, people often treated them as long-term. I suspect that it would be smart to systematically discourage that (e.g. by automatically breaking parties on logout ... but perhaps adding them to a "recently partied" friend group so that people can re-party them easily), and encourage creation of guilds. </li> Most dungeons can reasonably be set to take (or even create/enforce) a single party, but particularly large dungeons might not, since it's hard to keep track of too many people. </li> </ul> </li> People might cooperate in combat even without joining a party </li> People or parties might compete in combat ("kill-stealing") </li> Make sure people who play support get XP/loot appropriately </li> </ul> </li> Figure out (in-world) instancing so that guilds/individuals can have private space, multiple groups can run a dungeon at once if enabled, ... </li> Figure out how accounts can have multiple characters, how that interacts with friendship and server privileges, and what happens when they are deleted. Please do it in a sane way, I still have nightmares of that code ... (hint: "character id" should almost always be what is used, "account id" might not even exist at all except as a database-internal detail) It may even be feasible to share accounts between official servers and third-party servers, but this may cause concerns about identity leaking if not done carefully</li> </ul> </li> </ul> </figure> Consider eliminating username/passwords entirely in favor of public and private keys; invent a system of securely sharing an account between your computer and your phone that is immune to user error. (computer to phone is easy enough with a QR code, but you need two-way communication - if you think you don't, you don't understand the problem yet. Perhaps use the server as mediator? Should each device have its own private key that the server aggregates into a single account?) </li> If you allow in-app signup, someone will spam you and create millions of accounts and waste both storage and namespaces. Use a web browser so it can do it with captchas etc. </li> Always make sure each logical packet's size is known directly (this will generally not be the same as underlying UDP packets). This allows both skipping of totally-unknown packets, and size increase of existing packets. It may be useful to have a special packet that says "wait for the next N packets (or bytes?) together before handling any of them"</li> </ul> </li> Have a "display a message" packet that works no matter what the state of the client (on the login screen, in-game, ...). Possibly they should include a text domain (I favor client-side translation - just send the MO files as part of your updates (remember to include the fallback language-without-country stuff if you download only needed languages); that way, the client can log the not localized version; multiple languages in a single process is hard anyway). This should be distinct from "display message in chat" (which may be translated if it's from the server, but set no text domain if it's from a player), "display message in NPC dialog" (also translated). Support for formatting and pluralization must be included. </li> You will have at least 3 text domains involved (client, server code, server script), might as well make it unlimited (different scripts (dungeons?) or even different parts of the server code might have different text domains) - think about people running a fork. </li> </ul> </li> Make "connection to the server" a separate class than "info about the player", even though they both need to point to the other (Rust will probably fight you here too - neither owns the other (connection is owned by the event loop; player is owned by the map), but the former limits the latter's lifetime). The latter should not even exist until auth'ed (no more "spoof or eventual segv" if you don't tape up all the holey ducts). </li> </ul> </figure> Player shops are best done with special server support, not pure scripting or client hacks based on the trade dialog. Trust me, it has been tried. </li> As a rule, always limit things by configuration-file policy, not code (user name length, packet size/buffer/throughput; in particular, not having a hard inventory limit removes a lot of special cases in scripts) </li> Make a "transaction" script command to gain/lose items at once and handle failure cleanly (consider stacking and equipment) </li> Have a general-purpose "object inventory" class that gets reused sanely, with a special UI for moving objects between them arbitrarily. Don't specially implement player inventory, player storage, chest inventory, monster inventory, ... A few cases are special, but should still share a lot: shops (have prices and maybe randomness too?), equipped items (know what slot they're equipped in - note, I'm increasingly leaning toward equipment-separate-from-inventory as opposed to equipment-as-part-of-inventory; really only the "transaction" script command should care), mob drops (might be random, maybe combining sub inventories?) - maybe use "struct of arrays" rather than "array of struct"? I wish languages gave support to that. </li> Make everything stackable if all properties match (padding bits are evil; upgrade slots are tricky), even if you want it to display unstacked (Rust probably helps you here) </li> Large arrays are slow! we've all played games like that. At the very least, if you display by category you should consider storing it by category. </li> </ul> </li> Whenever you have jagged "array of arrays", be sure all the arrays share an allocation to keep the cache happy (also applies to set/map contents). E.g. load item definitions in the order given, then make a map pointing to them (Rust might fight you here, but with split arrays you probably don't have usable references anyway). Packet dispatch similar since IDs should be chunky. </li> Lots and lots of "hard typedef"s for all the IDs/indices floating around where pointers are inappropriate. </li> Consider what happens to a "high-score list" if a character is deleted (and possibly recreated) (merge this into the other list's entry about charid). </li> XML is a wonderful thing if you keep it away from humans. </li> </ul> Cave exploring at night. See you next week! </figcaption> </figure> This Week In Veloren 95 Mon, 23 Nov 2020 00:00:00 +0000 This week, the code freeze for 0.8 is in progress. We see some progress gifs from @Timo and @James. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Christof, @Snowram, @Treeco, @imbris, @Pfau, @Sam, @Knarkzel, @ubruntu, @xMAC94x, @James, @Slipped, and @XVar! This week, @Knarkzel fixed an issue with campfires and other entities duplicating. @Snowram worked on changing dungeon spawns and layouts depending on their level. @Songtronix put a lot of work into Airshipper, releasing 0.4.1. @Christof added cave entrance icons and and names to the map. @zesterer merged the worldsim branch after long last. He also added voxel lighting so that certain blocks can emit to the area surrounding them. You can now see in towns at night! Cave entrence icons by @Christof </figcaption> </figure> @Sam worked on some backend changes to how loadouts are built to make assigning a weapon less hacky and to allow armor to be better specified. @Pfau, @Treeco, and @zesterer added a lot of UI map functions. </figure> Particle Improvements by @Timo</h2> </figure> </figure> </figure> Animal Attacks and AI by @Slipped and @James</h2> </figure> </figure> </figure> Just you and the clouds. See you next week! </figcaption> </figure> This Week In Veloren 94 Mon, 16 Nov 2020 00:00:00 +0000 This week we have a lot of content. Lots of work has been done in preparation for the upcoming 0.8 launch. @zesterer goes over lots of the work he's been doing on many systems. @imbris talks about the transition work from conrod to iced. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sam, @Knarkzel, @imbris, @xMAC94x, @zesterer, @XVar, @Treeco, @JasonLee, @Pfau, Yusdacra, @CapsizeGlimmer, and @Slipped! Veloren will be speaking at MiniDebConf this weekend! It will be at 18:30 GMT+0 on Sunday, the 22nd of November. You can find out more about it here</a>! @Eden made a new song for the ocean biome. @Knarkzel fixed a bug where you could spam special attacks on certain weapons while out of stamina. @Snowram added some new animals and made overworld spawns saner with the help of @zesterer's new spawning system. Hopefully, this should be ready real soon. @Snowram also made a slight correction to NPC stats so they don't fire beams from their chest or their crotch. @Gemu modeled the animals that @Snowram put in. </figure> @Christof developed a hotfix for broken persistence, which then got replaced by a much better solution the next evening. @Christof had a lengthy discussion with @zesterer about the complex economic simulation in Veloren. @Christof hopes to make NPCs at least talk about local prices and stock amounts in the next few weeks. @Sam moved all weapon abilities from code to ron</code> files, which allows for them to be more modifiable as tweaking values won't require a complete recompile. @Sam also began work on skill trees. There was already a skeleton of a system implemented by @XVar which allowed for multiple skill groups, and for skills to be associated with each. To that, @Sam made it so that XP is properly split between skill groups, and so that skill points are automatically earned when reaching a threshold of XP. @XVar continued to work on the modular inventory/loadout feature and got sidetracked into refactoring a lot of how Loadout</code> is used externally around the codebase. @James and @Slipped worked on a bunch of cool animal attacks and AI for them. @James also added a biome specific music system which can weight songs based on their likelihood to play in a given biome. They made it possible to have cave and dungeon specific songs and added a bunch of ambient SFX by emitting SFX from blocks. They removed the SfxEvent</code> bus in the ECS in favor of simply playing the SFX from voxygen, where the code is already, and finally added a wind SFX system. </figure> 0.8 Release Schedule</h2> Veloren will be releasing 0.8 next weekend, on the 28th. To prepare for this, the project will go into code freeze on the 24th. Keep an eye out for the stability testing; we need lots of people to find potential bugs in the version we'll release! 2020-11-24 18:00 Feature freeze - At this point no features will be merged 2020-11-25 18:00 Public Stability Testing with many people 2020-11-26 18:00 NEW - relaxed 0.7 throwback event 2020-11-27 18:00 Fixes freeze - Nothing will be merged except gamebreaking fixes 2020-11-28 09:00 Final Build 2020-11-28 12:00 Prepare a Release Server 2020-11-28 18:00 Release Party </code></pre> Veloren Screenshot & Trailer Competition</h2> In this upcoming event, we will be reaching out to the community to create a trailer for the release of Veloren 0.8! The idea is simple, the winning video will be used as the official trailer for the game. If recording or video editing isn't your strong suit, don't worry! We will also be running a screenshot competition with multiple categories alongside it. The winning trailer and screenshots will be used to promote the game. More details on the event to come in the following weeks, so stay tuned! </figure> Chest of Goodies by @zesterer</h2> I've been working on the initial implementation of rtsim</code>, a server-side component that allows tens of thousands of NPCs to be simulated simultaneously across the world without being within the player's view distance. While the initial implementation's use is quite simple (just a few thousand travellers walking between sites in the world) in the long term I'm planning to use this for economic simulation, demographic change, simulates wars, battles, migration, and more. I've also been doing more work on the cloud shaders. Part of that included implementing upscaling so players with less powerful computers can run the game, albeit at a lower internal resolution. I've also been implementing HDR rendering. It also allows players with slightly better hardware to render the scale at a fractional higher resolution, allowing them to get some of the advantages SSAA with a smaller performance hit. Additionally, I've reimplemented the Level of Detail 'fake voxel' effect in a way that much more closely fits patterns visible on actual voxels and reduces the artifacts that previously appeared. I've also added a secret feature for 0.8. </figure> I've also been working on the game's map with @Pfau. Together, we've got it to the state where sites are now shown on the map as icons that can be clicked rather than the original 'brown spot on LoD'. In worldgen, I've made adjustments to the game's tree spawning algorithm. It now uses a Whittaker map to determine appropriate tree biome placement, something that generally results in much more interesting spawn patterns, along with adding a new birch forest kind. I've also removed the old Snow Pine forest kind and replaced it with fully procedural snow. This means that trees can be partially covered with snow at the borders of a snowy area and also that any kind of tree can have snow cover (this is often visible on oaks and birch trees that are close to the tree line). I've also added procedural sand dunes to deserts to improve their look and am working on adding soil undulation in forests where tree roots would bind together soil, causing the ground to be less smooth. Iced Transition by @imbris</h2> I finally merged the first step of the iced transition. A core part of the MR is a custom iced renderer built on top of voxygen's rendering abstraction. This gives us flexibility by allowing us to control the details of how the UI is rendered. It also makes it easier to implement novel custom widgets that might need special rendering code as well as allows us to control the types used to specify fonts and styling. </figure> Furthermore, by going through voxygen's rendering abstraction, we don't have to worry about whether the UI renderer is compatible with the rest of the rendering stack. This allows transitions to the voxygen rendering backend (e.g. to wgpu) without having to switch up which crates we are using for the UI. Much of the code for the iced renderer is based on what we were using to render the conrod UI primitives (except with iced we now get to define our own primitives). This MR converted the main menu and the character selection screen UIs to using iced. The HUD UI code continues to use conrod as it would be a fairly massive undertaking to convert especially all at once. My current plan is to have an incremental conversion of the HUD by setting up a system to route events to the two UI systems based on which one is currently focused and/or under the mouse with one of them being drawn on top of the other. In the process of switching the main menu and char selection to iced some key fixes and improvements were made: Passwords are no longer limited in length by the size of the input box</li> Tabbing between login fields was added</li> Language selection was added to the main menu</li> </ul> </figure> This week I also merged several fixes/improvements: Fixed an issue where projectiles created with speeds > 80 m/s would appear to veer up from the aimed direction when aiming downwards. Code which limited the negative z velocity after applying gravity would cause the direction of the projectile's velocity to change. I switched this to just make gravity not be able to increase the negative z velocity past this limit while allowing existing non-gravity related velocities to remain unclamped. Eventually, we may add a global velocity limit which could replace this specific limit here, we could also look into tweaking air friction to produce a suitable terminal velocity (although care will need to be taken to ensure that this interacts nicely with other stuff like jumping physics).</li> Made changing the UI scale in-game propagate properly when going back to the main menu.</li> Fixed a panic related to a invalid aspect ratio when minimizing the window before the game starts up by adding the same aspect ratio validity check used by the Camera when changing the aspect ratio to the function which initially creates the Camera.</li> Made voxygen save the currently selected character for each server so that the character will still be selected when you return to the char selection menu instead of having the first on no character selected. Also made voxygen automatically select newly created characters.</li> </ul> Something special in the sky. See you next week! </figcaption> </figure> This Week In Veloren 93 Mon, 09 Nov 2020 00:00:00 +0000 This week, we hear from @xMAC94x about analyzing performance issues in Veloren, as well as how we have fixed it in preparation for the 0.8 release. We also present the 0.8 release schedule, and the important times to join in on the server. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Slipped, @zesterer, @xMAAC94x, @Sam, @James, @cpetig, @imbris, @AlKabir, @TheBoredProgrammer64, @Snowram, @Pfau, and @Ubruntu! The monthly Rust Gamedev newsletter for October was released</a>! @zesterer worked on removing legacy code, speeding up terrain generation, and improving tree spawning and deserts. @Ubruntu and @James worked on improving sneaking and rolling so that you can get closer to enemies before being detected. @Christof completed waypoint persistence. Now, the last waypoint is the player's starting point. @Sam did some work on the backend that caused some bugs, and fixed some bugs. @AngelOnFira recorded the Veloren talk for MiniDebConf, which is coming up on the 22nd. </figure> 0.8 is scheduled to release on the 28th of November. There will be pre-release testing on the server at 18:00 GMT+0 on the 25th and 26th, and the full release party will take place at 18:00 GMT+0 on the 28th! Here is the release schedule: 2020-11-24 18:00:00 GMT+0 Feature freeze - At this point no features will be merged. 2020-11-25 18:00:00 GMT+0 Public Stability Testing with many people 2020-11-26 18:00:00 GMT+0 NEW - relaxed 0.7 throwback event 2020-11-27 18:00:00 GMT+0 Fixes freeze - Nothing will be merged except gamebreaking fixes 2020-11-28 09:00:00 GMT+0 Final Build 2020-11-28 12:00:00 GMT+0 Prepare a Release Server 2020-11-28 18:00:00 GMT+0 Release Party </code></pre> Performance Analysis with @xMAC94x</h2> I wrote a couple of articles this week. They reflect on how we've been doing with server performance, especially during releases. Analysis Tools</h3> Prometheus</a> is a monitoring tool that I've talked about quite often. It runs in the background with every veloren-server (even when you host it yourself). It theoretically allows for a Prometheus/Grafana server to attach to it, as long as you set up port forwarding. You can gather real-time statistics about the CPU or hard drive usage of your server. We also included Veloren info: number of players connected</li> number of chunks loaded</li> number of entities</li> incoming chunk requests</li> detailed network stats per player</li> server tick time</li> </ul> The fact that it's always running with almost no performance hit allows us to perform analysis anytime, especially during events like the release party. Those big events have unusual constellations (e.g. many players) that developers don't see when introducing a feature. Bigger events are the perfect occasion to see if your code scales. Tracy</a> is an awesome performance analyser that got included in Veloren by @imbris and is even mentioned in our book</a>. You can compile the Veloren server with Tracy support and you will get an executable that you can attach the Tracy GUI to. It records server ticks and their respective timing. It can tell us how many milliseconds we spend in which function and even better you can define spans in the code and it will be even more detailed. Tracy even has GPU and memory measurement features, although I haven't used them so far. </figure> Release Party Statistics</h3> Our high score of concurrent players on the server at a release party so far was 53. However, the server is still far away from its full potential. We released the Prometheus stats from 0.7 release party in a previous blog post</a>. As you can see, it includes the averages of our server tick. Veloren uses a 30 tick server, so we do 30 ticks per second. Since 1s/30 = 33.3ms</code>, 33ms is our time budget per tick. The server can spend it on multiple tasks such as handling messages, generating terrain, and calculating physics. However, if the server did not finish within 33ms we are running behind. We are becoming laggy. For the release party the average was around 280ms</code>... Prometheus metrics from 0.7 release party </figcaption> </figure> So we need to make improvements! These are the detailed tick times: message handling: 80ms</li> handle server events: 60ms</li> terrain: 42ms</li> state tick: 35ms</li> entity sync: 35ms</li> new connections: 10ms</li> terrain sync: 7ms</li> </ul> Since the 0.7 release, we improved message handling</code> by a large factor. Though it still can be parallelized. We estimate that we've cut the time in half. Handle server events</code> probably wasn't updated and is still quite a bottleneck. As those events are handled in a single thread, we need to find a better way to scale here. There was a recent change by @zesterer which sped up terrain generation</code> by more than 100%. The state tick</code> includes the physics simulation, which is quite slow. It can probably reduce down to 10ms. New connections are no longer handled at all as part of the active game loop, they are handled in a separate thread. This allows longer TCP disconnects to not cause issues. Next week I will write in-depth about what was wrong with physics and how to make use of our new network backend. I will also use more images, promised :) </figure> Smoother Frames</h3> Let's leave the performance optimisations and talk about scheduling. Scheduling is crucial for every game because you have to define exactly when to render a frame or do physics calculation. If your pattern is irregular, the perceived framerate is much lower and users notice lag. Therefore every game has a Clock</code>. The clock tries to keep the framerate constant, e.g. at 60 FPS for voxygen or 30 FPS for the server. If a tick is a bit slower the clock will sleep for a short time to smoothen out the curve. Until now we used a clock that tried to compromise for slow ticks, it tried to calculate the average speed and sleep so long that we reach our framerate. The problem with that algorithm is when spikes occur. You can see below that after a lag spike, there are heavy fluctuations. Ignore the timing on the image, it refers to something else </figcaption> </figure> We see a gigantic lag spike at the beginning (2nd large red spike) which takes over 200ms. To compensate the server tries to make 10 faster ticks. Now the tick time is too fast and the server slows down. It makes 10 slower ticks. After 60 ticks we are back to normal. The whole wave took 2s and is noticeable by the user. So what can we improve? First of all, we need to get rid of the lag spike in general. That would be ideal, but is not always possible. So we have to find a better way of handling them. Imaging we just had a lag spike, what should the server do next? Or a better question; imagine you just froze for 2 seconds, what is the best thing to do now? Does it help when the server speeds up for 300 ms? No, the server should just continue normally, and smoothly. We want to get rid of the ripple through the tick times and get back to a stable tick ASAP. New clock </figcaption> </figure> The new algorithm simply tries to keep the tick time constant. It can't prevent the lag, but it also can't help. It just goes back to work. Additionally, we now use a feature suggested by @imbris. Imagine our calculations for a tick took 9ms, we want our full tick to take 33ms, so we need to sleep for 24ms. Till now, we told the operating system: wake me up in at least 24ms. This could mean we were woken up after the 24ms, resulting in small imperfections of the tick time. Our new approach is, to only sleep for 23.8ms and actively waiting the last 0.2ms. This takes almost no performance, as the waiting time is so short (0.2ms), but it greatly stabilizes our tick time to 33ms. I hope you not only notice these effects on the server, but also with your frames being delivered (just a bit) more smoothly than before :) Campfire at night. See you next week! </figcaption> </figure> This Week In Veloren 92 Mon, 02 Nov 2020 00:00:00 +0000 This week we hear from @ubruntu about being a first-time contributor. We also have a community spotlight with @Kalculate. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Pfau, @Fausk, @Sam, @ubruntu, @imbris, @Bbenton91, @zesterer, @YuriMomo, @Tadabito, @Adam, and @BottledByte! </figure> Veloren was just accepted to speak at MiniDebConf</a> in late November! This week, @ubruntu implemented applying buffs on projectiles. Now bow attacks cause the bleed debuff just like melee weapons. @zesterer made some subtle improvements to clouds. @Fausk rewrote some item descriptions. @Sam worked on some backend combat improvements. @Slipped worked with @Snowram to continue the long-overdue process of purging a huge chunk of the animation codebase. @TBG has been working on some small issues with the help of @Sam. @Snowram added the ability for consumables to cause buffs and effects. The diff for the animation codebase </figcaption> </figure> @XVar is starting some early work on inventory upgrades. This will ditch the "bag space as a stat" concept and instead base it on equippable loadout items providing slots. A backpack could give you a large number of inventory slots, while a toolbelt would give a small number. But when you drop or store the bag, all the things that were in its slots would stay inside it. First Time Contributing by @ubruntu</h2> Hello! My name is Bryant, and my nickname in Discord is @ubruntu. A few days ago I made my first code contribution to Veloren, which added the bleed debuff to bow attacks. I’m not going to pretend I jumped in the code by myself and opened a merge request in a day. The hardest part was getting started. Three months ago I joined the Discord channel after reading about the project on Reddit. At first, I wasn’t thinking about contributing at all. I just wanted to experience the game, and follow in Discord about what it will become. It’s almost embarrassing, but my character on the official server is level 96. Like, why am I enjoying a pre-alpha game so much? So one day @Sam, the combat team lead, mentioned in #general how it would be an easy task to improve bows by adding a bleed debuff to their attacks, and he listed a couple of files where the change to add a bleed debuff would be. He offered to help anyone that wanted to take on the work so I said I was interested in trying it out. It took me a few tries to get my coding set up right for the project. There were some steps to setting up my IDE and GitLab fork but in hindsight, that stuff wasn’t too difficult. </figure> I can’t say enough how helpful @Sam was. I sent him an empty code block from a match expression and said I had no idea what to do. He told me what was needed and how to do it, and for the rest of the night he was immediately responsive when I had questions. By noon the next day the code was reviewed, merged, and deployed on the official server. Now is a great time to contribute to the project. There are plenty of opportunities for addressing issues, moving the game forward on the roadmap, and rethinking how we do what’s already there. I think everything I’ve coded so far requires only the first 8 chapters of the Rust book, so anyone looking to contribute code shouldn’t feel like they have to become code masters first. </figure> Community Spotlight: @Kalculate</h2> Hi, @Kalculate here! I'm a Software Engineer by trade, a league axe thrower, and I've always wanted to build games. I honestly spend more time thinking about the design and systems inside of games than I actually spend playing them. To me, games have an incredible capacity to inspire and propel people to follow their own progression in life and being a part of something like that is a deep personal dream. I originally found out about Veloren on Reddit. So far, I've worked on NPCs and combat implementations. I bought Cube World when it became available years ago and saw so much potential in it. I thought it was insane that 2 people were working on it and one guy built the absolutely gorgeous map that generates in a way that had me enraptured. Veloren is the promise of a new, endless adventure where we could see engaging gameplay on top of the deceptively simple (and charming) voxel graphics. I want to be able to help the core maintainers build out the design of the game by being a part of the design team. I'm also very excited to be working in Rust and building a game with other passionate people, so I intend on contributing code as often as I can, on top of answering questions and being active in the Discord channel. On top of that, I also think I could help by documenting design changes along to way to keep a good image of what kind of game Veloren could be at the end of the tunnel. Resting at night. See you next week! </figcaption> </figure> This Week In Veloren 91 Mon, 26 Oct 2020 00:00:00 +0000 This week, we have lots of writeups. @Sam talks to us about the buff system. @Adam is working on designing an improved alignment system to improve hostility calculations between entities. @xMAC94x wrote about the CI issues we've been having for the past few months, and what has been done to resolve them. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Sam, @Bbenton91, @imbris, @Adam, @Capucho, @AngelOnFira, and @zesterer! This week, @James has been working on a way for SFX to be mapped to blocks. This will be used for ambient sounds like crickets, birds, etc. This system is still in the works. @LunarEclipse has been working on updating information about Veloren on the IGDB, which Twitch uses to categorize its games. </figure> @Pfau created 2 new sets of armour, finished the buffs UI, and added the first underwater sprites. This week he'll create box art for Twitch, draw some ring concepts, and add more underwater sprites. @Sam has been doing a lot of work on the buff system. @Gemu finished up some sword models, and is working on a few new animal models to improve biome diversity. Buffs by @Sam</h2> Hey, @Sam here. Recently I've been working on player buffs. Buffs are separated into several components: kind</code>: the main identifier of what a buff is. It is used to construct what effects the buff has. Kinds could include bleeding, enflamed, crippled, and stunned.</li> data</code>: contains data common to all buffs. Currently consists of the buff strength and the buff duration, but may expand later to include other fields.</li> effects</code>: what effects the buff has. The currently implemented effects are a health change over time (so this covers both damage and healing), and changing max health.</li> time remaining</code>: time remaining on the buff. It is different from the duration stored in data though because the duration in data is static and references the initial duration.</li> categories</code>: a list of descriptors to the buff, such as physical, heat, environmental, etc. They don’t currently have a use, but will be used later when spells and other abilities are added that may have effects such as: immune to all heat-related debuffs, or something similar.</li> source</code>: what applied the buff. If it’s a player, this can be used to award XP if something dies due to damage over time effect.</li> </ul> </figure> Buffs will not stack, but instead the strongest buff of each kind will apply its effects, and the other buffs of that kind remain "inactive". While inactive, they still tick down their duration, and will replace the stronger one if it decays before the weaker one. Note that the stacking of buffs applies to buff kinds and not buff effects, so for example, you can be under multiple damage over time effects, such as bleeding, enflamed, and poisoned, you just cannot be under the effects of multiple bleeding debuffs. The branch that added buffs was primarily focused on getting a buff system into the game. Now that it has merged you won’t notice to much difference yet. Currently, the only buff you will encounter for now is a bleeding debuff, which has a 10% chance to be inflicted by melee attacks. However, more buffs are on the way. Specifically, food is being reworked to provide a regenerative buff instead of an instant health restoration. </figure> Alignment and Hostility by @Adam</h2> This week I began looking into how we could refactor the alignment system to support more complex scenarios. I haven't any solution in place yet, but I'm going to provide a bit of background on the problem itself. Current State</h3> The alignment system as we have it is just a simple enum: pub enum Alignment { /// Wild animals and gentle giants Wild, /// Dungeon cultists and bandits Enemy, /// Friendly folk in villages Npc, /// Farm animals and pets of villagers Tame, /// Pets you've tamed with a collar Owned(Uid), /// Passive objects like training dummies Passive, } </code></pre> However, this is too restrictive, even for simple ownership. Imagine something is Owned</code>: despite having the Uid</code> of the owner, we don't have the information about who that owner is hostile to. If we wanted to have owned entities to divert to the owner's hostility, then we would then need to pass possible owners' hostility information for both entities when we wanted to check hostility. And then what happens if those owners are also owned? You can start to see that this current implementation needs to be more robust. From here I will outline what the system needs to be able to do. </figure> System Requirements</h3> System needs to support dynamic Settlement hostility. A world may have any number of settlements, but an aligned entity may only be aligned to one settlement at a time.</li> System needs to support racial hostility. An aligned entity always has a race. Races have varying hostility toward other races.</li> System needs to support individual hostility. An aligned entity may have overrides for specific other entities. For instance, if a neutral NPC is hit by a player entity, that NPC should be able to become hostile to that player entity.</li> System needs to support ownership. An aligned entity may be owned by another entity. If an entity is owned, it may or may not want to divert to the owner's hostility.</li> A reputation system may or may not be implemented. If it is, this system need to be able to incorporate that.</li> </ol> Analysis</h3> An additional requirement that I want to achieve is a single lookup between entity Uid</code>s, something like: hostility.is_hostile_to(Uid)</code> So we do not need to pass in the other information that an entity may or may not have, such as Ownership</code> or Settlement</code> data whenever we want to check hostility. Looking forward, we will likely have many components (i.e. Race</code>, Settlement</code>, Ownership</code>) that will affect one entity's hostility to another. Because we don't want to require hostility checks to ask for all these different components, how do we manage all these memberships when these components are updated? </figure> So really, this problem boils down to two challenges: How do we effectively manage the hostility of an entity given the various sources of that determine it, without requiring developers to remember to update hostility any time they update those other sources?</li> How do we keep the hostility check call as simple as possible? Ideally entity_a_hostility.is_hostile_to(entity_b)</code></li> </ol> In the next few weeks, hopefully we can find some resolution to these questions! Fixing CI by @xMAC94x</h2> Two months ago we broke our CI. This included documentation generation and code coverage. We lost information on how our test coverage was doing and our documentation was frozen. Fixing it required some fiddling with various public crates and some communication with external maintainers. We even found a bug in Rust itself while doing so. Long story short, we needed to switch our Docker CI image from debian9 to Ubuntu 18.04 as the git lfs</code> package was causing problems on Debian, and newer versions require a higher glibc</code> version. We had to upgrade the Rust toolchain as this fixed a problem in macro handling which caused a big in the documentation cargo doc. </figure> To fix tarpaulin we had to fix multiple errors. First of all, wayland-client</code> 0.23 was causing problems so we had to update this to 0.27. However, we depend on some crates which have not done this update, so we did it ourselves. As glutin</code>, winit</code>, and conrod</code> are quite dependant on each other. packed_simd</code> also had a problem that was fixed. The RustC compilation problem</a> we found isn't yet fixed, so I introduced a workaround in our affected vek</code> code. All in all, many things broke - I hope we can simplify our custom clone repos</a> in the future: winit</code>, vek</code>, gfx-rs</code>, rusttype</code>, and conrod</code> can hopefully all be replaced with iced</code>. Now our CI is faster, down from 55 mins to 35 for a full run. I will look at it further after I do some performance fixes for Veloren 🙂 The mountains to explore. See you next week! </figcaption> </figure> This Week In Veloren 90 Mon, 19 Oct 2020 00:00:00 +0000 This week, we see how some of the combat animations are improving. @zesterer gives us an in-depth look into the new and improved cloud system. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Slipped, @xMAC94x, @jiminycrick, @Snowram, @UMR1352, @Sam, @zesterer, and @imbris! @James has continued work on new attacks for the bow and axe. There is a new M1 combo for the axe, but it hasn't been merged just yet. @Sam and @imbris worked on the buff system that was started by @BottledByte over a month ago. It's almost ready to merge! @Namp007 contributed Dutch translations, which are on their way to being merged. New hammer attack </figcaption> </figure> @James is also working on biome specific soundtracks. They were recently made possible along with separating ambient sounds from music. However, this probably won't be merged to master for a while until we have decided on a way to blend between biomes and have it work more efficiently. </figure> Cloud Improvements by @zesterer</h2> In current nightly builds of Veloren, we have clouds. I introduced clouds almost a year ago, to mixed responses. Although most people enjoy the more 'realistic' clouds that the game has, a common complaint is that they don't fit the voxel style of the game so well. Although I appreciate and understand this perspective, I personally believe that the core reason for this nervousness about clouds lies in the uncanny way they look. It's clear that we aim for realism, but they often fall short. I'm also determined to see clouds take a bigger role in Veloren's atmospheric look and feel. </figure> There are a few reasons for this: Our current technique uses an optimised form of raymarching that only works within a very narrow plane. As a result, clouds often appear as a thin layer to players close to the ground.</li> The lighting and shader overhaul a few months ago 'broke' their appearance because much of the existing code fudged physical properties with magic constants in a rather unprincipled way.</li> Clouds don't have effect lighting. This means that they feel disconnected from the world; a backdrop to fill space in the sky rather than an interactive part of the world.</li> </ul> I felt it was time to resolve this situation. First and foremost it gave me an excuse to put off more pressing work refactoring and improving the world generation and simulation code, but it also provided an opportunity for me to revisit the clouds (I've always felt that they don't live up to their potential). I started by adapting the existing code. I figured that it might be possible to enhance the shaders by playing with magic constants until something that looked better appeared. I did have a little luck with this, as shown below. </figure> These new clouds still didn't solve the underlying problems, however. I put things to the side for about 2 months. Last week, I came back to them. I decided to almost entirely rewrite the ray marching code. Where previously we calculated very narrow bounds within which ray marching occurred, I removed those bounds and allowed rays to sample the entire sky. However, it quickly became clear that this was too expensive to be viable in the long term. To alleviate the issue, I began experimenting with ways to more cheaply compute the procedural noise required to create the cloud density field. I found that with a few careful tricks I could tease shapes that felt realistic out of the code with just a fraction of the cost of the previous cloud code. I also discovered a very cheap way to compute low quality 3D noise several times faster than conventional techniques for generating noise in shaders using a small tiled 2D monochromatic texture and some careful interpolation. The next thing I did was to move the location that cloud shaders were applied. On current nightly builds, cloud shading is computed in the fragment shader for all models (sprites, figures, terrain, LoD, the skybox, etc.). Although we've been careful to optimise our draw order as much as possible, overlapping fragments still meant that we were calculating cloud shading for fragments that simply didn't get shown on the screen. To alleviate this, I moved cloud shading to the post-processing shader by extracting the depth buffer and using it as a texture input. I then used the inverse view/projection matrices, along with the depth from the depth buffer, to reconstruct the world position for each fragment (thanks to @Sharp for helping me fix a persistent bug along the way). I could then do cloud shading on only fragments that appear on the screen. With these techniques, combined with a few extra mathematical shortcuts, I was able to make 'floor-to-ceiling' cloud tracing viable. Here are the results: </figure> I still wasn't happy with it. Although having clouds appear at multiple z levels was a serious improvement on what was there before, I still felt that they didn't look appropriately realistic. To alleviate this, I ended up tearing up most of the raymarching code to rewrite it in a way that more closely mirrored how light scattering occurred in real life. Although it's not a perfect representation of reality (a lot of calculations are still rough approximations of physical parameters), the end results speak for themselves. The new code... Uses the trapezium rule to approximate the integration of cloud density with respect to distance over the course of projected rays</li> Includes a (poor) approximation of Rayleigh scattering, making distant objects appear much further away than they looked before</li> Has multiple graphical settings: None, Minimal, Low, Medium, and High. Minimal clouds should be fast enough for almost any hardware.</li> Tracks cloud shadows on terrain; skies can look overcast now!</li> Incorporates moving mist</li> Performs significantly better than the currently nightly's cloud code on lower settings</li> </ul> Since clouds are now shaded in a (more) physically accurate way, they also continue to look good under differing environmental conditions. No hackery was required to make them look good during sunrise, sunset, or night: the results just fall out as a natural consequence of calculating them in a more accurate way! </figure> </figure> </figure> </figure> </figure> The new clouds are not yet on the latest nightly build. There are still a few minor issues to address and it has not yet been fully reviewed. With any luck, they should be landing in the game within the next week or so. New bow attack. See you next week! </figcaption> </figure> This Week In Veloren 89 Mon, 12 Oct 2020 00:00:00 +0000 This week we hear from @Sam about a staff overhaul. @Pfau gives us an update on how UI changes are coming, and some concepts for future consideration. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Pfau, @Imbris, and @XVar! Staff Overhaul by @Sam</h2> I have a staff overhaul that'll be in-game shortly. </figure> The new M1 will be an explosive projectile similar to the old third ability. It will do a smaller amount of damage, and will restore energy on hitting an enemy. It will also be affected by gravity. </figure> The new M2 will be a flamethrower-like attack. It uses the same beam system as the healing sceptre M1, however with a much wider cone, and a faster tick rate. </figure> The new 3rd skill will be a radially directed fire shockwave. It'll have a short range though. New Skill Bar and Buffs Visuals @Pfau</h2> Hello, Pfau here. Recently I've mostly worked on UI-Code and visuals, 3D models, and 2D pixel art for Veloren. Normally you’d find my (free!) blog entries on my Patreon</a> but this week it’s time to get you guys an update in the Veloren general blog. I’ve been working on finally implementing the UI concepts I showed off some months ago. Concept, not functional UI! </figcaption> </figure> We are working on switching our UI library from conrod to Iced, however it is being held up as Iced still lacks some features needed for Veloren. Once it is ready, these looks will be implemented concurrently to the switch. Why am I bringing this up then? While working out a concept to display the player’s buffs and debuffs I realized that I needed a way to save vertical space to not block the view on the game world. Our current skill bar visuals are around a year old and still the same as in version 0.3. The health and stamina bar (previously the mana bar) had options to show different colours for "focus" and "rage". </figure> While this bar has good overall visibility of objects it isn’t really made to save vertical space or add any new parts. So how do keep our currently used space, add buffs, and get a style fitting the other current UI elements? Like this: </figure> This new skill bar design merges our current style with the features shown in the concept while only making our skill bar 2px vertically taller than the one we currently use. It has: "Blobs" for the experience-bar to see more easily at how much % experience you are currently.</li> A display of the current level</li> Smaller health bars to make room for buffs/debuffs above them</li> Left and right mouse button icons to indicate what the middle slots do</li> </ul> We are currently hard at work integrating buffs into the UI. The groundwork and functionality is done so you can expect the feature to be added to master in the next weeks. Here are some images of the working buffs. </figure> </figure> This is me testing the sorting logic and placing. These little squares are fully animated. They show the remaining time in little clock-like slices. And start flashing when their remaining duration is below 10s. The maximum amount shown is 22 per side (internally there can be more) </figure> ...this happens without a limit and sorting being messed up! Exploring a large cave system. See you next week! </figcaption> </figure> This Week In Veloren 88 Mon, 05 Oct 2020 00:00:00 +0000 This week, we get a deep dive into the modelling process by @Gemu. A new edition of This Month in Rust Gamedev is out. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @XVar, @Sam, @pablosoler, @Pfau, and @Sharp! The September edition of "This Month in Rust Gamedev" is out! Check it out here</a>. @XVar has been working on inventory slot upgrades which will allow players to obtain and craft items that increase their number of inventory slots. @Pfau has been helping out with the UI for this. </figure> </figure> Work on the bag UI </figcaption> </figure> Gemu</h2> Hello! Gemu here from the assets & visual design team. I'm responsible for the majority of Veloren’s creature models so far. Even though I have no experience animating and coding, the modelling itself is more of my jam. The rest is done by other wonderful contributors such as @Snowram and @Slipped. In this section, I'll explain a bit about this process. One important part of voxel modeling is the style you’re setting. Veloren has a semi-realistic style, while being slightly stylistic. Because of this, it’s fairly straightforward modeling non-fictional animals. When modelling animals, references are very important. Using references, modelling the animal is all about making directly what you see, rather than making what you know by heart. To make the model stand out, recognising the unique traits of the animal and stressing those parts in the model will make the animal model stand out more, especially within the stylized limitations of voxels. For fictional animals, there is no "correct" reference. Which means there’s an entire world of possibilities for these creatures! Aside from creating your entirely made-up creature, there are of course famous fantastical creatures that everyone likes to see. This includes dragons, trolls, golems, you name it. Treant by @Gemu </figcaption> </figure> What’s most fun about modeling these is that you have to find the balance between recognisability and own interpretation. This can be done using the same method as for making real animals, by pinpointing their more characteristic property and experimenting on that aspect. A golem, being a man-made construct of stone, could look like a typical man-made stone structure such as a castle, for instance. From that point, it basically comes down to trial and error, until the model comes out close to what I had envisioned. For the model to be functional, it is of course important that it fits the body rigging animations within the game, or the “skeletons” so to speak. There are various skeletons, such as that of various quadrupeds of various sizes, or bipedal creatures, for instance. While modeling, it’s important that the various individual body parts will fit corresponding ‘bones’ within the skeleton, to make the animation work. Sticking to these separate bones, I model every body part individually, then piece them together to see if they fit well together. It’s good to keep in mind that for a quadruped to look good while running, there has to be enough space between the front and back legs, for instance. Raptor by @Gemu </figcaption> </figure> As the creature will move and bend its body, body parts need proper attachment points to one another. If the attachment points between body parts are solely flat surfaces, jarring gaps might appear whenever the creature moves. However, trial and error is prevalent within this branch as well, as we continuously find newer and cooler ways to animate the animals. Seeing the models come to life within the world of Veloren has been an amazing experience so far. This Week In Veloren 87 Mon, 28 Sep 2020 00:00:00 +0000 This week lots of work has been done on Veloren infrastructure. @Sharp discusses some recent optimizations he made to chunk compression. @Sam talks about the current state of the healing sceptre. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sharp, @imbris, @XVar, @nwildner, @xMAC94x, @Slipped, @Snowram, and @zesterer! A stress test party was held last weekend to test how the game server would work with limited resources. We gathered a lot of data from a few different crashes. @Sharp worked on some massive improvements to how we store chunks, resulting in ~7x in chunk memory. @lobster worked on adding SFX and particles for leveling up, death, and voxel destruction. @Sam worked on a sceptre rework. @xMACx and @AngelOnFira have been working on big changes to the Veloren server infrastructure. This included getting the main game server into a datacenter, as well as exploring technologies that will help us scale our services in the future. They have also been re-examining CI to see where potential improvements could be made. @xMAC94x and @AngelOnFira hard at work this week on cloud infrastructure for Veloren </figcaption> </figure> Sceptre Rework by @Sam</h2> </figure> The sceptre rework completely changes how both abilities on the sceptre function. The new M1 skill is a beam, and while active, it hits all entities within the beam two times per second. When an enemy is hit, they take damage, and you gain energy and a bit of health. When an ally is hit, they are healed but it costs energy. The new M2 skill is an explosive projectile. Similar to the M1, it both damages enemies and heals allies. The projectile functions similarly to the current 1st ability on the staff, however it has gravity and slower projectile speed. </figure> Memory Optimizations by @Sharp</h2> This week, I fixed some bugs in worldgen that saw a huge (~7x) reduction in chunk memory. This should hopefully reduce crashes due to Out Of Memory (OOM) when people have high view distances. The underlying cause for the order of magnitude blowup was that we were not choosing the "default" block type effectively for most chunks, resulting in lots of extra space used for completely identical blocks even though the format supports compressing these a lot. So my change was to explicitly find the highest frequency compressible block in each subchonk and use that as the default, after chunk generation is done. Which resulted in the big win. There is still more to do there, but this is a good start. Realistically, I think we should have swap enabled. We need to be able to handle situations where our estimates on average chunk size were off. Swap would allow us to mitigate OOM crashes. This is because we can't really predict an upper bound to chunk memory usage it right now. That doesn't mean we're going to stop improving memory usage. The fix I made was low hanging fruit, but it's hard to notice if you don't start from a root cause analysis like "how much do memory do I think chunks should take?". Then you can look at the metrics and see if there is a large discrepancy. Otherwise, it's hard to say how much space chunks "should" take up. Which is kinda the issue here. </figure> There are lots of potential areas where we could find large speedups. What I'm trying to do right now is simplify and disentangle all the different systems we have running. That way, we know how they're scheduled and they aren't interfering with each other. Then we can get clean benchmarks and actually understand how much time each system is consuming and how it scales. Right now a lot of the CPU metrics are just hard to interpret because of how much interference there is between different systems. We know physics shows up high in the profiler, but when @imbris profiled it separately, its scheduling pattern didn't make any sense in isolation. So that means there's stuff going on we don't understand. </figure> Disentangling isn't about improving measurement tactics, but rather rearranging how our systems run so we have better control over the resources involved. This includes spawning fewer threads, using precise worker pools, pinning to cores, etc. Also, simplifying protocols that involve communication or synchronization between systems. This can lead to nondeterminism that is difficult to diagnose. Solutions for this include fewer channels, queues, and mutexes. We also need more deterministic communication (function calls or fork/join parallelism), and much more tightly controlled I/O. For all of this, there isn't one simple thing we have to do. However, here are some paths that can be taken: Making better use of the ECS</li> Explicitly controlling worker pools (rather than using globals)</li> Moving to libraries that don't spawn pools behind our backs</li> Passing config parameters from server and client start so the application can be aware of how many resources it's supposed to take up</li> Splitting up all our tasks into logical sets</li> Replacing synchronous with asynchronous I/O in networking contexts</li> Separating out systems that don't need to block the game server from systems that do</li> </ul> Again, these options will help to disentangle systems and make it easier to isolate specific issues. Memory is a lot easier to analyze for issues like this, except for some stuff like fragmentation or overcommit. This is because it's often pretty tightly bound to whatever requests the memory, at least in Rust with strict ownership. So it's "easy" to reason about those resources even in a very tangled up app, in Rust. But no such guarantees exist for CPU or I/O resources, or for contended access to memory. Well, we already knew chunks were using a lot of RAM. What we didn't know is how much they were supposed to be using. Which isn't something Valgrind or any other automated tool can necessarily tell you. </figure> Unfortunately, there are so many factors that can affect runtime performance, that I don't think metrics alone are going to help resolve CPU and I/O issues. At best they can vaguely point us to areas of the app (like physics) that look slow, but they won't tell us why. There are indicators that could tell us that there was jitter in areas like page faults, instruction throughput, and memory bandwidth. But since we already know all that stuff is contended I don't think it would reveal too much useful information to us right now. It's like science, you have to have an actual hypothesis first if you want to gain real knowledge from metrics. Right now we have no hypothesis for how long systems like physics should be taking except for "not that long". So it's hard to say what part is surprising. And then there are other times we measure that seem short... are they realistically short? Are we even measuring them correctly? It's really hard to say, especially with so many threads being assigned to the same core. Hence, disentangling is currently the best path forward. This Week In Veloren 86 Mon, 21 Sep 2020 00:00:00 +0000 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</h2> 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</code>. 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. Overhaul of the settings window, new language tab </figcaption> </figure> PSA: Privilege Escalation Bug</h2> 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</h2> 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).</li> All those critters were given fresh new models and moved over to quadruped_small</code> which is much more fleshed out (thanks to @Gemu).</li> We also built in a pacing system for animals, only implemented on quadruped_medium</code> 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.</li> </ul> </figure> 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. </figure> Attack Updates by @Sam</h2> 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. </blockquote> 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! </blockquote> - @Slipped </blockquote> </iframe> </div> </figure> 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. New loading screen background images and art </figcaption> </figure> 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. Button to randomize appearance and name by @Snowram </figcaption> </figure> 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. FPS counter in the graphics settings </figcaption> </figure> Beam Collisions by @Sam</h2> 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</li> Directly above or below the cylinder</li> Everything else</li> </ul> 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. Case 1 </figcaption> </figure> 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. Case 2 </figcaption> </figure> 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. Case 3 </figcaption> </figure> 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! New boss was merged! See you next week! </figcaption> </figure> This Week In Veloren 85 Mon, 14 Sep 2020 00:00:00 +0000 This week, we have a new art blog by @Pfau. @xMAC94x goes into detail on how we measure networking statistics. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94, @Sharp, @tylerlowrey, @Imbris, @Slipped, @TheThirdSpartan, and @mttmartin42! @Pfau is back at the Veloren art blogs! You can check out No. 7 here</a>. @Capucho is still trudging through the magic that in WGPU. @Awkor has been doing work on an inventory autosort proof of concept. @James is Working on new hotbar skill for the axe and a new m2 for the hammer (moving current m2 to the hotbar). @Sam is working on a sword overhaul. @Songtronix wrote a discord bot (@Veloren) to control his testing server. It includes: Switching branches easily</li> Querying the status of the server (updating, compiling) at any time</li> Downloading the database</li> Viewing server settings</li> </ul> Retouch of a repeating crossbow by @AlbinoAxolotl </figcaption> </figure> Improved Server Metrics To Improve Server Performance by @xMAC94x</h2> The first step of optimizing Veloren's server code is to know what runs the slowest. If we were to optimize less impactful areas, they wouldn't impact the end-user as much. We are using Prometheus metrics to gather data in real-time from our main server. </figure> With some recent additions, we are now able to get the following metrics: Chunks requested from the server: every time a client asks for a chunk we will see how the server reacts. We can see if it need to compute the chunk or if it can just send a chunk which is already loaded because another player is already there.</li> Chunk generation: when a chunk needs to be generated it is queued. This metrics will help us to see if this queue is getting bigger over time or if it remains at a healthy size.</li> Active players: players online is now split into players connected and disconnected. This makes it easy to detect single events and even lets us detect when a client joins in the same time other leaves. The online players will be calculated with the difference. For disconnect, we now also track the event (i.e. Gracefully Close, Timeout, Network error). Though currently, under some conditions a network error is thrown for what is actually a graceful close.</li> State timings: Even deeper look at our engine's State</code> timings. Before we only had a total time for our entire state. Now we can get the state timings based on each subsystem. It shows that physics likely needs the next optimisation.</li> </ul> Theory Of Continuous Prometheus Metrics</h3> Metrics are generated every tick, but are actually only polled by the Prometheus server every 2 seconds. This means we only get a metric for every 60th tick. There are now multiple ways to handle this, especially in relation to timing data. Until now, we have always exported the last tick's timing. This meant we got 100% accurate timings on 1 out of 60 ticks, and no timing information on the remaining 59 ticks. We just had to assume that all the other 59 ticks are probably the same as this one tick. But we have no way of knowing if the tick we received was part of the 95th percentile, meaning much faster or slower than the rest. This information is important, as super slow ticks are the ones that cause lag. Another way to tackle this problem is by summing up the timings. We can still poll the data every 2 seconds (60 ticks). So we get the total time spend for our all of these ticks, but aggregated together. However, just take the average and assume each tick was just 1/60 of that value. Or if there is a slow tick and 59 fast ticks, there is no way of knowing. A Steppesman's recurve bow by @AlbinoAxolotl </figcaption> </figure> For this case, Prometheus has histograms. They provide buckets for different time ranges, lets say <1ms, 1-5ms, 5-10ms, >10ms. With Histograms, each tick will increase a number in its corresponding bucket. So if we have a super fast tick, it will increase the number in the <1ms bucket. if we have a super slow tick we increase the number in >10ms. We will be using a combination of BOTH. summing up all ticks AND histograms in the future to detect the average time we spend in a certain part of our code as well as make sure, that we don't have any spikes causing lags. Altogether, these new techniques will allow us to get much better telemetry about the outliers. Often it's hard to make networking work well purely from what seems to be best in theory. Veloren's application is unique in many ways, and so we will have to keep striving to analyze how it runs from the data. Deer by the river. See you next week! </figcaption> </figure> This Week In Veloren 84 Mon, 07 Sep 2020 00:00:00 +0000 This week, lots of small updates were made. Airshipper 0.4.0 was released! We take a look at a photo gallery of what has been going on. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @imbris, @DoctaRay, @TheThirdSpartan, @zesterer, @notoria, @Pfau, @Sharp, @Capucho, @termac, @law4x, and @scottc! The August edition</a> of the Rust Gamedev Newsletter is out! We also hit 5000 commits on our GitLab repo! We also have 5000+ members on our Discord, and most importantly, less than 450 crate dependencies! @Capucho got the new server-cli</code> merged and it is working on the WGPU branch. @TheThirdSpartan worked on personalizing chat messages, and added more detailed death messages. @Pfau interacted a lot with the active players to see what could be improved in the short term. Hopefully, these can be addressed in the next few weeks. Treehouse </figcaption> </figure> @zesterer has been working on improving the developer workflow surrounding sites. He wants to make them faster to generate, and more accessible to other devs. @Sam created a system that can handle beam-like attacks. He and @Slipped are doing some research on how to implement keyframe animations. More on this in the coming weeks. @DoctaRay refactored how fullscreen toggling works. Compilation Breakdown by @AngelOnFira</h2> I was reading an article</a> about speeding up Rust compilation. It then led me to another article</a> that was more specific to visualizing how fast Rust compiled your program. In the context of Veloren, this could be quite useful. We are dependent on over 500 crates, and clean builds take often around 20 minutes on most computers. A breakdown of what takes the longest could help improve compile times. This particular visualization came from just adding -Z timings</code> to cargo build. Specifically, cargo +nightly build -Z timings</code>. Nightly is required, as it is an unstable feature. This creates an HTML file that you can open in the browser. You can download it here</a> if you'd like to take a look at it yourself. If you want to read more about the timings flag, you can read the documentation on it</a> Input information </figcaption> </figure> Above is some of the preliminary information. We can see what binaries and libraries we're building by default. We can also see how many items have to be compiled from scratch, the "dirty units". I'm using a CPU with 16 threads, so the total compile time is significantly lower than what we would see on our CI runners, or other contributors' computers. Unit compilation timeline </figcaption> </figure> Next, I took a look at all of the individual compile jobs that took more than 13 seconds. Most jobs take significantly less, so this only shows the 27 most impactful of the 509 jobs. veloren-voxgen</code> is a good benchmark to look at, as it's the final unit that has to link any previous dependency units. This cannot be done concurrently. Anything that approaches the amount of time veloren-voxgen</code> takes should really be looked into. Looking at this graph, we also see that each job has a blue section and a purple section. The purple represents the amount of time that a unit is spending on codegen. The blue is the rest of the time, presumably waiting for dependencies to be ready. </figure> Here we have another breakdown of the timing of each unit. We can see how much time it took just for codegen, as well as the features it was compiling. </figure> Finally, we can see a graph of CPU usage over the entire process. Happy Birthday to @Gemu this week! See you next time! </figcaption> </figure> This Week In Veloren 83 Mon, 31 Aug 2020 00:00:00 +0000 This week, lots of small updates were made. Airshipper 0.4.0 was released! We take a look at a photo gallery of what has been going on. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Songtronix, @Pfau, @Sharp, @xMAC94x, @imbris, @termac, @black-silence, @AngelOnFira, @scottc, @zesterer, and @notoria! This week, Airshipper 0.4.0 Released. Lots of small updates were made, which can be seen in the section below. @Gemu and @Slipped worked on improving the way quadrupeds run. New weapons were modeled by @Gemu and @Pfau. A healing sceptre is being worked on by @Sam and @Pfau. Lots of balancing changes were made so that the game would be easier for new players. This was an effort by @Scott, @Snowram, @Savvynik, and @Pfau. </iframe> </div> </figure> Loot tables are now species independent. @Sharp has been working on small tasks, including driver debugging, moving figure meshing to the background, refactoring config data out of Rust, and significantly improving the speed of terrain collision detection. Notable changes to Airshipper 0.4.0: Uses the same font as Veloren</li> Option to retry if download/install failed</li> Offline support</li> Screenshots, logs, game saves all centralized in profile folder</li> No more terminal window floating around if you just want to play</li> And a ton more...</li> </ul> Photo Gallery</h2> This week, we don't have any writeups, but we do have a lot of images! Beehives </figcaption> </figure> Nice rivers </figcaption> </figure> </figure> New bow models and animals by @Gemu </figcaption> </figure> Work by @Slipped and @Gemu to improve adaptive running for quadrupeds </figcaption> </figure> New Velorite weapon by @Pfau </figcaption> </figure> Improved head size on female orcs </figcaption> </figure> </figure> New healing scepter M1 that will heal allies and damage enemies. Colours done by @Pfau </figcaption> </figure> The M2 for the scepter will be an explosive projectile that damages enemies. See you next week! </figcaption> </figure> This Week In Veloren 82 Mon, 24 Aug 2020 00:00:00 +0000 This week, we had the 0.8 intro meeting. We hear from @Ellinia about the process being used to create sound effects for the game. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @xMAC94x, @Pfau, @james, @imbris, @sovareign, @Songtronix, @Sam, @rdbaker, @AngelOnFira, @Sharp, @Spyros, @T-Dark0, and @marius! @Felixader has been working on lore for cities, cultures, and races. New colours were merged in this week, with help from @zesterer and @Pfau. @Pfau also rebalanced the behaviour of monsters, improved loot tables, and made lots of small UI and UX fixes. Tooltip borders now fit the UI theme and you can see account names in the social menu by hovering </figcaption> </figure> @Capucho was working on wgpu a bit, however there were some compiler blockers preventing continued work. 0.8 Intro Meeting</h2> This weekend, we held a 0.8 intro meeting</a>. This included the normal discussions of what we want to see for the version, summed up into a "definition of 0.8". We also examined what we achieved since 0.7, and what we missed out on. Completed</h3> LoD!</li> Networking?</li> More advanced UI</li> Combat feedback</li> Particle systems</li> SFX</li> Animations</li> </ul> Didn’t do</h3> Quests</li> Interactions in settlements</li> Story</li> </ul> </figure> Definition of 0.8</h3> As a player, I want more interactions with settlements and NPCs. I want to be able to see a mountain off in the distance and be told to go there and complete a task. I want to feel like I’m a part of the world around me, and making a difference. While in combat, I want to feel like I synergize with the players around me. I want to team up, and be able to use my unique skills to be a valuable member of the team. I want to be more immersed in what I hear and see. Budget</h3> We also examined what a budget for Veloren might look like. Since we are receiving donations on open collective, we want to come up with a healthy pipeline making use of the funds, and transparently tracking them. The primary item we want to secure is infrastructure. We will be getting a server, likely from Hetzner, that will allow us to run CI, the game server, as well as other services we use. You can see the budget here</a> Audio with @Ellinia</h2> The Audio Team has been busy filling Veloren with many of the SFX that help make a game feel immersive and provide the player with tactical feedback while exploring. When done right, this kind of work should typically go largely unnoticed or taken for granted (that means we have done our job!). But we thought it would be fun to peel back the curtain a bit on some of Veloren's newest sounds. </figure> @Eden and I have been gathering Foley recordings in a DIY isolation booth constructed with rockwool insulation absorption panels and utilizing an Audio-Technica AT-2035 condenser microphone. We've done plenty of mixing and synthesizing plugins in FL Studio as well. SFX that are on their way into Veloren are: new level up sound</li> swinging and slashing sounds for the sword, axe, hammer, dagger, shield, and staff</li> projectile sounds for the bow and a fire shot for the staff</li> experience gained sounds</li> </ul> Further down the timeline are: snow footsteps</li> swimming/splashing</li> climbing</li> dive roll</li> </ul> When approaching the design of a sound, I often will get right into Veloren and just think about it from a player's perspective. Sometimes it's easy as swinging a toy sword in front of a microphone (and adding a knife scrape to it in post). Other times I have to get a little more creative. For example, the upcoming roll SFX I have been working on has been a trial of rolling myself, a pile of clothing wrapped around a hammer, and various other items in an attempt to get a satisfying combination of body 'thunk' and armor/clothing rustling as the character hits and rolls on the surface. </figure> A lot of sound effect design for me is thinking about how something sounds within the physics of real-world acoustics. For example, when planning a sound for an action that carries the player character or another in-world entity away from a starting position (like the roll), you have to think about how higher and lower frequencies behave. Lower frequencies are stretched out longer than higher frequencies. Think about hearing an annoying neighbor's subwoofer. The wall or the space between you and their home/apartment is often enough to deaden those higher and mid-range frequencies, but the low-end makes its way to you still. So when designing something like the roll effect, I apply a low-pass filter to automatically begin to muffle some of the higher frequencies of the sound. This adds to the perception of movement within the sound. Cloudy mountains at night. See you next week! </figcaption> </figure> This Week In Veloren 81 Mon, 17 Aug 2020 00:00:00 +0000 This week 0.7 was released! However, not everything went well with the release party, and @xMAC94x wrote a section on that. @Sharp's colossal branch is getting merged at long last. The description of all the changes is below. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Rdbaker, @Pfau, @Songtronix, @Slipped, @yusdacra, @imbris, @zesterer, @WelshPixie, @scottc! We had our largest release party yet, with a peak of 57 players concurrently! Although Veloren has been in feature freeze and locked down quite a lot, there was still a lot of work done! @LunarEclipse updated the AUR packages to 0.7. @Sam is working on a new boss, and focusing on a shockwave attack that it will have. @imbris is helping with collision detection on the shockwave, and @lobster is working on particles for it. It's been a long road, but the time has finally come to merge @Sharp's behemoth branch. Read more below for all the details! </figcaption> </figure> @Ellinia got a good amount of SFX work done. @DoctaRay added borderless and exclusive fullscreen options. @lobster got the particle MR merged right before the 0.7 release. This included fireworks items, which used the bomb item as a template. </figure> 0.7 Release Party Statistics</h2> With the 0.7 release this past weekend, we held our largest release party yet! Unfortunately, not everything went smoothly. Be sure to check out the section below by @xMAC94x to read more about this. Here are the stats from the rest of the party though! </figure> </figure> </figure> </figure> 90% uptime... or was it? Read more to find out </figcaption> </figure> 0.7 Release Party Kick Disaster by @xMAC94x</h2> Last Saturday we had our 0.7 release party. A release party is usually a 2-3 hour-long event where we celebrate a new release, play around, and have fun. Preparation for such a party usually starts a week before and the last 48 hours we were all focused on preparing the release build, testing, setting up a server to handle ~40 players. The server started at 18:00 GMT+0 within 5 minutes we had 53 players coming online! One minute later I had to kill the server as it froze. (see A) Suddenly the whole event changed. From what was going to be a fun party changed to focus on stability for the next 3 hours. </figure> The problem (part 1)</h3> It took us about 15 minutes of investigation to figure out what was happening. We noticed players suddenly dropping, all at once. But the server didn't restart. This was bothersome, a crash would give us a clear error message, but we had nothing. I had 2 thoughts: networking or new bug introduced in the feature freeze period. Networking hasn't been changed for a month, so I was pretty sure it's unrelated. We saw that try to connect, but their requests weren't picked up by the server. We also noticed that our metrics are still available but didn't update. Countering the "crash"</h3> In order to find a quick solution, we did multiple things simultaneously. As a team, we discussed and tried to analyse the process as well as attach a debugger to the process. We also started to build a local version of Veloren to apply a potential fix. At this point we were 30 mins in the release party already (see B). 10 minutes later we had a compiled local build and to pure luck, the server was stable for 30 mins (see C). During this time we achieved the most players simultaneously on the server at 57. We attached the gdb debugger to collect backtraces once the bug occurred again (see D). We were still pretty unsure what caused it, as we haven't seen such a bug outside this party. Emergency mitigation meeting </figcaption> </figure> End of the party without a fix</h3> The party ended after a total of 3 hours (see E) with the remaining 15 players transferring to the official Veloren server hosted by me. Sadly we didn't have a fix for the "crash" yet. Analysing the Backtraces</h3> Analysis was pretty hard as we didn't have debuginfos enabled, so I collected new backtraces on the official server. I found that 2 threads doing something with the same std::sync::Mutex</code> which made me think it might be actually related to a Deadlock. That would fit the pattern we saw (main thread didn't update metrics, but we didn't crash). With debuginfos I found the problem: Thread 1 (Thread 0x7fa0a9b37c40 (LWP 19872)): ... #5 std::sync::condvar::Condvar::wait () at src/libstd/sync/condvar.rs:200 ... #10 0x000055a1ffe16733 in futures_executor::local_pool::run_executor (f=...) at /home/b-server/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:83 #11 futures_executor::local_pool::block_on (f=...) at /home/b-server/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-executor-0.3.5/src/local_pool.rs:317 #12 veloren_server::events::player::handle_client_disconnect (server=0x7ffd0ddc6490, entity=...) at server/src/events/player.rs:84 #13 0x000055a1ffdcd7df in veloren_server::events::<impl veloren_server::Server>::handle_events (self=<optimized out>) at server/src/events/mod.rs:105 #14 0x000055a1ffdd8354 in veloren_server::Server::tick (self=0x7ffd0ddc6490, _input=..., dt=...) at server/src/lib.rs:400 #15 0x000055a1ffcb4e9e in veloren_server_cli::main () at server-cli/src/main.rs:56 </code></pre> The problem (part 2)</h3> That backtrace told us a lot about what was going on: Thread 1</code> is the main thread, the one that was doing the critical phase of the server. See line #14.</li> wait()</code> in line #5 tells us that it's waiting for an event to happen.</li> handle_client_disconnect()</code> in line #12 gives us the exact thing what we are trying to do: it's in line server/src/events/player.rs:84</code></li> </ul> So lets look at the source code: 84: if let Err(e) = block_on(participant.disconnect()) { 85: debug!( 86: ?e, 87: "Error when disconnecting client, maybe the pipe already broke" 88: ); 89: }; </code></pre> The error seems to be blocking on the client.disconnect()</code> function. This function is there to cleanly shutdown a client after they disconnect or are kicked. It should try to send all relevant info to them and once this is done close the connection. For some reason, it took way to long (I haven't analyzed why yet) and blocks the main thread sporadically. New armor set by @Snowram </figcaption> </figure> The solution</h3> Resolving the error was quite easy once we isolated it. We just move the teardown to another thread. In a background thread this can take as long as it wants without interrupting any player again. Further investigation will show why it takes so long: Aug 19 08:15:43.126 WARN veloren_server::events::player: disconecting took quite long elapsed=2.534882113s Aug 19 08:16:20.984 WARN veloren_server::events::player: disconecting took quite long elapsed=3.543180779s Aug 19 08:28:19.724 DEBUG veloren_server::events::player: disconecting took elapsed=23.553655ms Aug 19 08:29:38.784 DEBUG veloren_server::events::player: disconecting took elapsed=21.045099ms Aug 19 08:35:02.043 DEBUG veloren_server::events::player: disconecting took elapsed=25.217615ms Aug 19 08:37:39.406 DEBUG veloren_server::events::player: disconecting took elapsed=19.948233ms Aug 19 09:19:16.508 WARN veloren_server::events::player: disconecting took quite long elapsed=23.326647409s Aug 19 11:29:26.872 WARN veloren_server::events::player: disconecting took quite long elapsed=18.663718063s Aug 19 12:00:04.742 WARN veloren_server::events::player: disconecting took quite long elapsed=972.050707757s </code></pre> As you can see often the disconnect is done within 25ms, but sometimes it requires multiple seconds, or even up to 15 minutes. @Sharp's Lighting and World Changes Branch</h2> The following is the description of @Sharp's massive branch as it is being merged into master. It covers LOD, shadow maps, greedy meshing, new lighting, world size refactoring, and other performance fixes. Pretty much a Veloren fork at this point. Here's a high-level overview of the changes. At a high level, this MR incorporates roughly two groups of changes. The first group consists of new game features: more flexible map sizes, level of detail terrain, shadow maps, and a new lighting engine. This is "feature work" that (mostly) only adds new things to Veloren, and mostly shouldn't affect old stuff. The second big group of changes are those addressing the fallout from all the new features. These include performance fixes of various sorts: the addition of multiple graphics options and optimization of the cheap ones to avoid work, switching all voxel models to use some variant of greedy meshing, switching over much of our CPU-side vector math to exploit SIMD instructions (coinciding with a fork of vek</code>), and a rewrite of how the UI handles text rendering (coinciding with updates to our fork of conrod</code>). Making Veloren's hardcoded colors appear correct under the new lighting engine also required considerable changes. The second category of changes often heavily touches code owned by other people, including frequently modified code "owned" by a handful of people, so I recommend that this code be reviewed particularly carefully. </figure> Table of Contents</h3> At a high level (each will be described in more detail below): The world map has been refactored The world size is no longer hardcoded</li> The map generation code was made generic to allow using it outside of the world</code> crate</li> On world creation, we now compute horizon maps</li> The way we pass the world from the server to the client has been updated</li> Artifacts related to image rotation were fixed</li> Multiflow rivers were enabled</li> In the process of making changes related to the world map, various incidental fixes and optimizations were required</li> </ul> </li> The new level of detail feature was added A new LOD terrain rendering step was added to the pipeline</li> The LOD terrain quality was made configurable via a graphics setting</li> Horizon maps were used to cast shadows from LOD chunks on both LOD and non-LOD terrain</li> A "voxelization" effect was incorporated into rendered LOD terrain to make it blend better into the world</li> In the process of making changes related to LOD, various incidental fixes and optimizations were required</li> </ul> </li> Veloren's lighting has been completely overhauled A semi-accurate index of refraction was assigned to our materials</li> A new, more realistic, physically-based approach to lighting was used using solar panel light exposure</li> We attempt to compute realistic light attenuation in water using its real material properties</li> In the process of making changes related to LOD, various incidental fixes and optimizations were required</li> </ul> </li> Point and directional lights now cast realistic shadows, using shadow mapping Point light shadow maps were added to the rendering pipeline, using geometry shaders and seamless cube maps.</li> Directional light shadows were added to the rendering pipeline, using LISPSM together with disabling depth clamping.</li> "Shadow-only" chunks and NPCs were added to prevent shadows from models behind you from disappearing.</li> In the process of making changes related to shadow maps, various incidental fixes and optimizations were required.</li> </ul> </li> </ul> </figure> The addition of shadow maps, LOD terrain, and the new lighting all led to significant performance degradation, on top of other changes happening in master. Therefore, a large number of performance improvements were also needed: The graphics options were made much more flexible and configurable, and shaders were optimized New options were provided for how to render lights and shadows</li> Graphic setting storage and configuration were overhauled to make adding new features easier</li> Shaders were rewritten to utilize GLSL's preprocessor to avoid overhead</li> In the process of making changes related to providing additional rendering options, various incidental fixes and optimizations were required.</li> </ul> </li> Voxel model creation was switched to use greedy meshing A new voxel meshing method, greedy meshing, was added</li> Uses of the older meshing methods were migrated to use greedy meshing</li> New restrictions were added to terrain, figure, and sprites to future proof them for further optimizations</li> Most positions are now relative to either chunk or player position for better precision</li> In the process of making changes related to greedy meshing, various incidental fixes and optimizations were required</li> </ul> </li> Animation and terrain math was switched to use SIMD where possible Fixes were made to vek to make its SIMD feature usable for us</li> The interface and types used in bone animation were changed in various ways</li> Redundant code generation for body animation is now partly taken care of by a macro</li> Animation code was modified to use vek's SIMD representation where possible</li> Terrain meshing code and shadow map math were also modified to use vek's SIMD representation</li> SIMD instruction generation was enabled</li> In the process of making changes related to greedy meshing, various incidental fixes and optimizations were required</li> </ul> </li> The way we cache glyphs was completely refactored, fixed, and optimized Our fork of conrod</code> was optimized in various ways</li> Our fork of conrod</code> now exposes whether a widget was updated during the current frame</li> Our use of the glyph cache was rewritten for correctness</li> A text cache was introduced that lets us skip remeshing glyphs that have not changed</li> Various changes were made to reduce pressure on the glyph cache, with more planned</li> In the process of making changes related to the glyph cache, various incidental fixes and optimizations were required</li> </ul> </li> Colors were changed to keep Veloren's look consistent with master Some older tree models were brought back</li> All hardcoded colors were extracted and made hot-loadable.</li> Hardcoded colors were fixed to conform to Veloren's style.</li> Color models were fixed to conform to Veloren's style.</li> </ul> </li> </ul> A detailed description of the involved changes follows. </figure> World map information was refactored</h4> The world size is no longer hardcoded. All functions dependent on world size now take a WorldSizeLg</code>, which holds the base 2 logarithm of each actual world dimension and is guaranteed to maintain certain properties (outlined in common/src/terrain/map.rs</code>). Additionally, many utility functions that utilize the world size were moved into common</code> as well (mostly common/src/terrain/mod.rs</code>). Finally, the world map format was updated in order to store its size explicitly, with a migration path from the old format that should work whenever the old formatted map was a square (practically always). See world/src/sim/mod.rs</code> for these changes. </li> The map generation code was made generic to allow using it outside of the world</code> crate. The parts of the map generating code that do not need to query the world were moved over to common/src/terrain/map.rs</code>, allowing them to be used from the client without creating a dependency on world</code>. The rest of it was turned into helper functions in world/src/sim/map.rs</code>, which can be passed as closures to the generic map generation code to complete its construction. This also means that colors are now passed in separately to the map generation function. See devblog 78</a> for more details. </li> On world creation, we now compute horizon maps. See the function in world/src/sim/util.rs</code>. Given a height map and a plane intersecting that height map, our horizon maps allow us to encode enough information to reconstruct shadows for each point on the height map using only the horizon angle (the angle at which the sun starts to become visible). As Veloren's sun only covers one plane, this is sufficient for encoding sun shadows for LOD terrain, by encoding two angles per chunk (one for each 90 degrees the sun covers). We can also use this for the moon, if we want, since the moon follows the same path. Additionally, we store the height of the furthest occluder, to try to make the shadows volumetric; so this means 4 bytes in total for each chunk. </li> </ul> </figure> Support for horizon maps has been merged into the map functionality in common as well. The way we pass the world from the server to the client has been updated. Rather than passing the prerendered map, we instead pass three maps with values for each chunk; one with the color information, a second with altitude information, and a third with horizon map information. We then reconstruct the map on the client, together with some additional information we send from the server (like the sea level and maximum height). See common/src/msg/server.rs</code> for a detailed description of the format of WorldMapMsg</code>, and server/src/libr.rs</code> and client/src/lib.rs</code> for details of the map construction and parsing.</li> Artifacts related to image rotation were fixed. See the commit message for commit SHA cf74d55f2e3d2ae7d25fd68d5c73b01a6afde86e</code> for a detailed explanation. This involved changes to shaders, the addition of a new type of graphic (also reflected in the graphic cache) that allows specifying a border color (which automatically makes the associated texture immutable), and some related fixes. I reproduce the first two paragraphs of the MR description as well:</li> </ul> Fix map image artifacts and remove unneeded allocations. Specifically, we address three concerns (the image stretching during rotation, artifacts around the image due to clamping to the nearest border color when the image is drawn to a larger space than the image itself takes up, and potential artifacts around a rotated image which accidentally ended up in an atlas and didn't have enough extra space to guarantee the rotation would work). </code></pre> Multiflow rivers were enabled. This does not really need to be part of this MR, and would be easy to revert, but since it seemed to provide a nice improvement it's currently packaged with it. We already computed multiple outflows from each chunk for erosion purposes long before this MR. However, we never modified river rendering to be able to handle this case (just a single downhill river flow is complex enough!) so this was not exposed when deciding which chunks were rivers.</li> In the process of making changes related to the world map, various incidental fixes and optimizations were required. Some examples of fixes include making sure terrain is never lowered to below sea level (to make the shadow maps report correct values), fixing map altitudes and colors to understand things like cliffs and "block level" coloring (that doesn't exist on the column level), and fixing a crash bug when rendering images for the UI where source pixels are strongly rectangular. Some examples of related performance fixes include avoiding allocating a fresh vector for all the maps (i.e. copying it over to change the format from [u32; n]</code> to DynamicImage</code> and then copying again to convert to RgbaImage</code>), and instead using the gfx::memory::slice</code> function to accomplish the same thing. These sorts of changes are spread all around the code.</li> </ul> </figure> A new LOD terrain rendering step was added to the pipeline</h4> This includes the addition of a new scene, voxygen/src/scene/lod.rs</code>, a new pipeline voxygen/src/render/pipeline/lod_terrain.rs</code>, and new shaders assets/voxygen/shaders/lod-terrain-vert.glsl</code> and assets/voxygen/shaders/lod-terrain-frag.glsl</code>, as well as associated changes to the renderer in voxygen/src/render/renderer.rs</code>. The main idea behind our initial approach to LOD was to take the world data we now get from the server (altitude, color, and horizon mapping). In the process of making changes related to LOD, various incidental fixes and optimizations were required</h4> Some previously computed values were turned into shader uniforms for better prediction on weak processors.</li> Calls to power or trig functions were removed or replaced with multiplications, where possible.</li> </ul> Voxel model creation was switched to use greedy meshing.</h3> Veloren-specific considerations</h4> We explicitly designed the greedy meshing system with figures and sprites in mind. In both cases, we want to be able to efficiently pack many different models into the same texture, especially in cases where we know we will either not be removing any of the grouped-together from the models from the texture, or will remove all of them at once (so they can be packed into some specific subtexture). For sprites, since we know every model in advance and never intend to deallocate them, we currently pack them all as efficiently as possible into one giant texture atlas. However, in the future, we might opt to pack them slightly less efficiently in exchange for shrinking the sprite vertex size. For figures, we pack all the textures for each model into the same atlas. This is a global texture atlas used for every sprite, and for figures which is why we have the ability to mesh multiple models to the same texture area (using the simple texture atlas allocator) without requiring intermediate vector allocations. This is accomplished by delaying the time when we actually write the color and light data to the texture until after all the model vertices have been meshed; then, we can just allocate the whole color/light array at once, making the atlas we use an exact fit. In computer science-y terms, we accomplish this delay by not continuing to create the texture data after we perform the initial greedy meshing (without texture information). Instead, we construct a continuation. That is, a function that, when called, will execute the rest of the computation. In Rust terms, this continuation is a FnOnce</code> closure that takes the ColLightsInfo</code> that it is supposed to write to as context. </figure> In the process of making changes related to greedy meshing, various incidental fixes and optimizations were required</h4> Matrix multiplications in the shader were reduced for figure data</li> Vertex "waves" for fluid data were removed</li> Terrain "bending" near edges was removed</li> Scaling was fixed to make sure empty space was not introduced in a space previously occupied by a block. It was also changed to take ownership of its voxel data, rather than sharing it, to let it be used with meshing</li> Rust's nightly version was bumped in order to use the array_map</code> function, which lets us reuse more code between the simple map and FigureModelCache</code></li> </ul> References</h3> I tried to cite sources in many cases where I needed features from elsewhere but I am particularly grateful for the following resources, especially where they have accompanying source code. I linked all of them that are accessible to the public (those that are not were obtained through legal means). Eisemann, Elmar, Michael Schwarz, Ulf Assarsson, Michael Wimmer. Real-Time Shadows. A K Peters/CRC Press (T&F), 20160419. Lloyd,B. 2007. Logarithmic perspective shadow maps</a>. PhD thesis, University of North Carolina. Wimmer, M., Scherzer, D., and Purgathofer, W. 2004. Light space perspective shadow maps</a>. In Proceedings of Eurographics Symposium on Rendering 2004, pp. 143– 152. Pharr, Matt, et al. Physically Based Rendering: From Theory to Implementation</a>. Third edition, Morgan Kaufmann Publishers/Elsevier, 2017. mikolalysenko. Meshing in a Minecraft Game</a> 0 FPS, 30 June 2012 blackflux. Meshing in Voxel Engines – Part 1</a> Blackflux.Com, 23 Feb. 2014 I am also especially grateful to Khronos, Wikipedia, and Stack Overflow for answering many of my specific questions while writing the MR. The most interesting bag. See you next week! </figcaption> </figure> This Week In Veloren 80 Mon, 10 Aug 2020 00:00:00 +0000 This week we prepare for the 0.7 release. With the code freeze, we don't have too many new features to talk about, but we get a rundown on particle timing from @lobster. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @yusdacra, @Songtronix, @scottc, @Imbris, @IBotDEU, @Slipped, @nepo, @zesterer, @Pfau, @xMAC94x, @Varpie, @Sharp, @AngelOnFira, @Sam, @Silentium, @BottledByte, and @JudgeGriesa! 0.7: "The Progression Update" is releasing this weekend! In this version, many changes have been made to combat, animations, worldgen, and a lot more systems. The release party will be happening this Saturday at 18:00 GMT+0. Come join us on the main server to check out all the new changes! Your browser does not support the audio element. </audio> A Solemn Quest by @Eden </figcaption> </figure> @nepo added Dullahan into the game with help from @Slipped and @Snowram. The model was created by @Gemu. @lobster wrote a basic scheduler for particles, so we have emitter-like functionality. @PlaneCat has been working on adding a weapons guide to the book. @Slipped merged swimming improvements including controlling and animations. @zesterer added @WelshPixie's furniture models into the game. Swimming improvements </figcaption> </figure> Particle Timing by @lobster</h2> Since we got rid of our ECS particle emitter component, we also lost our timing mechanism to generate particles at the correct time. Which means our particle spawn rate is now tied to the framerate. So if the frame rate stutters, it can cause changes in particle density or other weird visual artifacts. To fix this we need to track the last time a particle was created for any given effect, so we can have consistent timing between particles. And because we have a lot of particles, reducing the work done per-particle is important because it's multiplied 10,000 times or more, which can have a big performance impact. New furniture by @WelshPixie </figcaption> </figure> Since many particles are generated using the same or similar timings, we can optimise this by putting all particles that spawn at the same rate into frequency buckets. So now instead of tracking last created time for a single particle, we can do it per frequency. for _ in 0..self.scheduler.heartbeats(Duration::from_millis(10)) { // spawn a smoke particle } // ... /// Accumulates heartbeats to be consumed on the next tick. struct HeartbeatScheduler { /// Duration = Heartbeat Frequency/Intervals /// Instant = Last update time /// u8 = number of heartbeats since last update /// - if it's more frequent then tick rate, it could be 1 or more. /// - if it's less frequent then tick rate, it could be 1 or 0. /// - if it's equal to the tick rate, it could be between 2 and 0, due to /// delta time variance etc. timers: HashMap<Duration, (Instant, u8)>, } impl HeartbeatScheduler { /// updates the last elapsed times and elasped counts /// this should be called once, and only once per tick. pub fn maintain(&mut self) { for (frequency, (last_update, heartbeats)) in self.timers.iter_mut() { // the number of frequency cycles that have occurred. heartbeats = (last_update.elapsed().as_secs_f32() / frequency.as_secs_f32()).floor() as u8; // Note: we want to preserve incomplete heartbeats, and roll them // over into the next tick. last_update += frequency.mul_f32(heartbeats as f32); // alternatively expressed as: now - remaining_partial_heartbeat_time } } /// returns the number of times this duration has elasped since the last /// tick: /// - if it's more frequent then tick rate, it could be 1 or more. /// - if it's less frequent then tick rate, it could be 1 or 0. /// - if it's equal to the tick rate, it could be between 2 and 0, due to /// delta time variance. pub fn heartbeats(&mut self, frequency: Duration) -> u8 { self.timers .entry(frequency) .or_insert_with(|| (Instant::now(), 0)) .1 } } </code></pre> The newly added cultist hammer by @Pfau </figcaption> </figure> Another advantage to this approach is now we now have a larger and more consistent batch of particles that can further avoid memory fragmentation (dead particles wasting memory) by grouping even more particles with the same lifespan together. They can then be more efficiently arranged and uploaded to GPU, by taking advantage of bulk operations such as replacing an entire slice of memory with another set of particles. But the downside to this approach is that all effects with the same frequency will be in sync and might look weird on the screen. But this is not an issue for effects that have a fast particle spawn frequency, because it's imperceptible to most humans. But for particles that have slow spawn rates, such as 100ms and above, it starts to become noticeable. Dullahan standing tall. See you next week! </figcaption> </figure> This Week In Veloren 79 Mon, 03 Aug 2020 00:00:00 +0000 As 0.7 is wrapping up, we see some bigger systems getting ready to be merged. We hear from @Slipped about progress on animations. @Songtronix also gives us an update on Airshipper 0.4. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @JudgeGriesa, @imbris, @Songtronix, @BottledByte, @Sharp, @StansTec, @Shandley, @Sam, @Slipped, @Snowram, and @VZIKL! This week, the inaugural episode of the Rust Gamedev podcast aired. It was an interview with the Veloren team! Be sure to check it out here</a>. We're on the final stretch to the 0.7 release, which will come out on the 15th. Veloren also recently passed 1000 merge requests, big milestones this week! @Du has been continuing work on the concept of a Veloren wiki</a>. Contributions to it are welcome to help speed up its development. </iframe> </div> The first Veloren speedrun, from level one to killing a Cult Leader. Can you beat it? </figcaption> </figure> @Felixader has been hard at work on the Lore Bible</a>, it has reached over 61 pages! Be warned, it has spoilers that are eventually supposed to be discovered throughout the game. @BottledByte worked to remove hardcoded weapons, so that adding new content doesn't require recompiling. @JudgeGriesa is working on the translation to Latin American Spanish. @w3yden added item names displaying if they are in pickup range. Work on the cave systems </figcaption> </figure> @Zesterer has been hard at work with a few different tasks. He's added stalactites to caves and improved castles significantly. He also is working on an "outcome" system so the client can listen to world events and produce particle effects or sound effects when certain things happen. @Zesterer also worked on a bunch of minor pathfinding improvements. NPCs won't tend to jump off things now, and they're also more reliable at navigating complex structures. Color changes. Left is base colours, right is adjusted colours </figcaption> </figure> Current state of groups </figcaption> </figure> Airshipper 0.4 Progress by @Songtronix</h2> In my recent sprint, I've added a ton of small tweaks to Airshipper which will be released with 0.4 and can be viewed here</a>. One thing to mention is that it will allow you to retry in case of an error instead of having to restart the launcher. Furthermore, it will now place everything into the profile folder including screenshots, logs, game saves to avoid the deal of playing hide and seek and guess where a file has gone. Airshipper 0.4 (WIP) </figcaption> </figure> While these are great quality of life improvements this isn't the main feature 0.4 will introduce. In the next few weeks (hopefully before 0.7 release but no promises) I'll try to add profile support, both server and client side. This will involve quite a lot of work as the server will need to expose an improved API which is aware of the difference between stable (0.7, 0.6, 0.5) and nightly releases. It will also need a way for me to add a new release as currently, I can't automatically detect it. On the interface front, thanks to ongoing work for a different project I've gained enough knowledge to quickly set up a fancy but moderate UI to create/edit/delete profiles. Though wiring it up to make it work will be a different story. Work on boss monsters by @Gemu </figcaption> </figure> Animation and Movement Updates by @Slipped</h2> Hi all! Wanted to give a short update on where I've put some of my focus going into 0.7 release. I'm trying to focus on cleaning up a few areas and making some improvements that should really compliment a lot of the other recent work that has gone into the game. First, Snowram, Gemu, and I were able to merge another quadruped rewrite this week, this time focused on the quadruped_small</code> body. This was similar to a rewrite we did earlier for the two larger quadruped bodies. There is some pretty great stuff in it, including new models, reimaginings of the old models, rewrites of the run and idle animations, and the addition of some of the more fancy techniques like orientation tilt. One other neat addition specifically to this body is a variable called spring</code>, which is species-specific (we can customize for any animal that uses the quadruped_small</code> skeleton). This variable allows for a bounce factor in the run animation. That enabled us to add rabbits and frogs, which hop as they run, and it's a pretty convincing result! Hippity hoppity, rabbits and frogs now have this property! </figcaption> </figure> This MR also added new mobs to other bodies that aren't exposed to the player yet, including a wendigo and troll addition to the biped_large</code> body. We're working towards making the biped_large</code> body suitable for Veloren's first real bosses (outside of placeholder bosses that are scaled-up versions of existing enemies). More on that in the next week or so as we try to progress on boss preparation, including custom attacks and animations. </figure> Finally, I'm hoping to improve some of the movement in Veloren in an upcoming MR. The work I've done so far includes a better climb mechanic that allows you to slide down quickly, along with improved swimming so you can dive down properly rather than waiting for gravity. We definitely want to make exploring the depths a big theme of Veloren and this is one of the steps to get there. Work on castles. See you next week! </figcaption> </figure> This Week In Veloren 78 Mon, 27 Jul 2020 00:00:00 +0000 This week has seen lots of progress from lots of developers. @Sharp gives us some perspective into refactoring the world dimension constant. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @imbris, @yusdacra, @Sam, @Snowram, @lausek, @Pfau, @Slipped, and @T-Dark! @Ellinia has been working on some SFX with help from @Eden. @lausek worked on German translations and refactoring auth. @lobster has been cleaning up the number of draw calls for particles and added an option to disable them completely. @Pfau was working on adding a UI for the group system implemented by @imbris. He was also working on a social window overhaul. @zesterer has been working on caves. Secondary bow attack by @Sam </figcaption> </figure> @Sam added a new secondary attack to the bow. They are also completing work on diverse weapon stats. @Capucho threw together a small site</a> to display info about the official Veloren server. @Felixader finished a format spec draft to follow when writing quests. @XVar integrated imgui-rs into Veloren as a test for flexible debug UIs. It's still in the air if it will be fully integrated. Quadruped rework by @Gemu </figcaption> </figure> @T-Dark worked on the character alias substring filter. This will help server owners ban certain works from character names. @Sharp did a lot of work to support arbitrarily sized maps. @Snowram helped with the latest animation rework. @Gemu reworked all of the small quadruped animal models. @Songtronix figured out where the auth 500 error came from. @Capucho has been revamping the server cli. Debug UI test by @XVar </figcaption> </figure> Refactoring WORLD_SIZE by @Sharp</h2> For at least as long as I've been part of Veloren, we've had a global variable called WORLD_SIZE</code> that determined the size of the map at compile time. Initially, it was only used in a handful of places localized to WorldSim, however, mostly due to me, we ended up using it all over the place. In my branch, it was even starting to creep into the client. This was due to generating the map directly on the client, rather than just using an image (for complicated reasons I don't want to go into). Obviously, that was not good, since a client couldn't even host a map of a different size from the server. And it also meant that hosting maps of different sizes from the default required code changes and recompiles. No test server could keep a different-from-default-size map, which a lot of people wanted. It wasn't just laziness that was stopping me from doing this refactor, though. We also have several invariants on the world map size. For example, each chunk dimension has to be a power of 2, the product of the chunk dimensions must fit in a usize, each block dimension must fit in an i32, each chunk dimension must fit in a u16, no chunk dimension can exceed 2^14, and so on. Catoblepas model by @Gemu </figcaption> </figure> And, since doing arithmetic around WORLD_SIZE is on the critical path for a lot of performance-sensitive stuff, I wanted to make sure that if we switched to using dynamic values, we did it in a way that we could (in theory) recover the performance we lost due to missed compiler optimizations. So, my solution was to create a new type, MapSizeLg</code>, storing the number of bits for each dimension. The type verifies at construction time that all invariants are satisfied, so for any instance of that type we can freely assume all of those invariants. We can also encode those as optimized methods and functions that operate only on values of that type, enforcing that code practices good hygiene and doesn't accidentally mix non-world-map-size values in. A rectangular map in the new format </figcaption> </figure> Not only that, since we verify the invariants on construction, in the future if we need to we can use unsafe LLVM assertions or integer arithmetic in order to let the compiler perform the same optimizations it would have in the constant case (outside of stuff like constant folding of course). So this design both simplifies a lot of existing code (making it much more robust to issues like overflows, since we have consistent methods we call for given operations), and ensures that we can claw back any performance we lose. Ultimately it was a lot of work--the diff was about 2.5k lines--but it made the next step easy: updating our map format. This is actually the first time we've updated the format since its inception, but it was built from the get-go to support forward migrations, so the process was pretty straightforward. For maps without dimension information, we make an educated guess at the actual dimensions. We do this by insisting that the map dimensions be the square of a power of 2 in order to perform the migration, and if they are we assume the map is actually square with that dimension. For new maps, we directly save the real dimension information. We also include a "continent scaling hack" that's used as a factor to our world generation and is usually based on world size, to help keep outputs consistent with the initial map that was generated without sacrificing flexibility. Because the migrations occur automatically and in memory, no changes to any existing files are required. Just like before, you can set a map in your server_settings.ron</code>, but unlike before this will work for maps of arbitrary size with no code changes. </figure> In the end, we have zero remaining instances of WORLD_SIZE, and only one use of its replacement. The replacement is a default map size for use in the initial generation, which can be updated to produce maps of different size. In the future, when generation is more stable, we will provide hooks so that modifying code to set this value, along with other generation parameters, is not needed to produce a new map. Finally, since I thought it was cool: we exploit Rust's new ability to panic in constants to make sure that the default map size respects the invariants we mentioned, at compile time. If our validation function fails when initializing the constant, we will panic! This is the kind of extra assurance that makes me love Rust 🙂 In fact, the refactor itself did not (appear to) introduce any new bugs at runtime! Only two runtime issues surfaced, and both of them were due to writing the migration too hastily. For me, this really illustrates why Rust is such a powerful tool for collaborative development. First, Rust's design makes abusing global variables difficult, pushing coders towards a much cleaner design. In a language with a pervasive global mutable state, I might have been tempted to try to just make the world size updatable somehow, but that would've been a big mistake. </figure> Secondly, being able to perform large-scale refactors on a widely shared codebase without introducing significant bugs is really important for avoiding tech debt, especially on a fast-moving project like Veloren. I've used a lot of languages in my career, and Rust is the only one where I can routinely perform a large refactor without breaking tons of existing code. While some have IDEs that make refactoring faster than it is in Rust (for now, anyway), in none of them has refactoring been as "safe" as it is in Rust. This is not an accident. From day one, Rust's mission has been to provide strong mechanisms for enforcing strict isolation boundaries; mechanisms powerful enough to actually enforce the invariants that occur in large, real-world programming projects. Ownership, eschewing exceptions and global state, explicit type annotations at function boundaries, mutex poisoning, explicit casts, floats lacking Ord, and so on are all aimed squarely at this target. It's not just about type safety, it's about working as hard as humanly possible to avoid footguns. And it only works because the whole community buys into it. So, while refactoring may not be the most "sexy" kind of programming out there, for me it's where Rust really shines through 🙂 Sun setting on the mountains. See you next week! </figcaption> </figure> This Week In Veloren 77 Mon, 20 Jul 2020 00:00:00 +0000 This week we hear about @lobster's progress on particles. @AngelOnFira discusses multithreading gamedev. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @AngelOnFira, @Sharp, @Pfau, @imbris, @Menko1437, @zesterer, @Slipped, @Sam, @xMAC94x, @T-Dark0, @yusdacra, @Songtronix, @lausec, and @PatatasDelPapa! @Songtronix has been doing lots of work on Airshipper. He also ran the first UX working group meeting! @YuriMomo has been doing lots of UX work. @Felixader has been working on the city, town, and village descriptions for the brushwood elves. @imbris merged the winit upgrade, which consisted of a monumental amount of work. Beginning of the fishing animation by @Snowram </figcaption> </figure> @XVar is working on an RFC proposal with @Sharp to improve how persistence works. Primarily the goal is to figure out how to deserialize items from inventories and loadouts. @lausec improved some German translations and fixed a bug where you could mount pets from very far away. They're also working on allowing admins to join a server even if they aren't on the whitelist. @Gemu modeled around 50 new axes and hammers to go with more diverse weapon drops. Particle Improvements by @lobster</h2> @lobster is still working on improving particles. Recently, they scrapped the particle emitter component, because particles are a visual representation of the already existing game state. It's better to use the existing game state than to create an unnecessary duplicate state. It would have eventually lead to state desynchronization bugs, as well as a waste of memory. @lobster also scrapped the configurable particle idea, because of performance concerns with uploading data to the GPU. Instead, we upload the bare minimum for the particle instance to function, in addition to some particles having different context dependencies. There isn't a nice way to have a generic config that will allow for use of those dependencies in any meaningful way. Instead, we can write shaders, which are hot-loadable and more flexible because they allow for data values like a config to be able to also have expressions, statements, and use the context dependencies that are passed in etc. Basically, it's the same as animation code, except instead of bones, there are vertices, instances, and fragments. GLSL instead of Rust. </figure> CPU Workloads by @AngelOnFira</h2> Earlier this week I saw a post</a> on /r/opensource asking if a piece of software could distribute single core games over multiple core. I wrote this long-winded reply. </blockquote> I think this is actually quite a good question. The short answer is no, a piece of software is bound to how it handles computation. For a longer answer, I should mention that although I've been exposed to some of these topics, I haven't implemented them myself, and so I'm open to corrections or further details. My experience comes from an open source game I'm contributing to, Veloren. The programming language we use, Rust, allows us to make quite good use of multiple CPU cores to their full capabilities. </figure> First, it's important to know why it's difficult for code to work on different cores, or threads, or more fundamentally, processes. The key factor this comes down to is the idea of "thread safety". At the ground level, many larger program architectures break down to how the variables manipulated in them. If I have a variable, and I allow multiple pieces of running code to access it, then I'm very likely to make mistakes with how this variable is used. There are a few questions to be asked about this: If a thread deleted this variable, do other threads know that it was deleted?</li> Did a thread read the variable before another thread updated it? If so, was that the right order that I wanted?</li> What if one thread overwrites an update that another thread just made to it?</li> </ul> These questions are not easy to answer without guarantees, like the ones that Rust provides: If multiple threads try to have "ownership" of a variable at the same time, the program won't compile.</li> Once the "owner" of a variable goes out of scope, that variable is also deleted. No one else except the owner would expect it to be still there.</li> </ul> Further, there are some other ways that Rust helps you: Variables are immutable by default. This means that if you don't explicitly allow a variable to be changed, you can be sure that it won't change under your nose, and that you can rely on it being the same.</li> </ul> </figure> When a game is only using 1 thread, it doesn't have to worry about any of this. Will anyone change this variable before I use it next? No, because only I can change it. What if the variable is deleted? Well, that's my fault and no one else's. This next section is purely speculation on my part, I don't have any industry experience. Next, why don't AAA games make use of these extra cores? A primary reason is that the engines these games uses are often very large and have many moving parts that prevent them from changing their core architecture. It would require a fundamental overhaul to introduce functionality that would allow it to distribute the workload to multiple threads. Further, lots of research into distributed and parallel computing was still going on while these engines were being created. On top of this, AAA games are quite used to working within hardware constraints. This is because when you are leading a game's development, you need to explicitly tell each team how much compute or graphics processing time they are allowed to use each frame. For AAA games on consoles, this is even more clear. Each PS4 has the exact same CPU and GPU, so you can be sure that if you run the game at the required 30 fps, anyone else will be able to as well. Back when these engines were being created for PC games, many computers only had one core, one thread. If you're suddenly telling these teams that they have double the compute power across two threads, or maybe 4 times on a different CPU, it wouldn't really change the engine that has to cooperate with consoles. Finally, many games are not actually CPU bound. It is often the graphics card that is the limiting factor. Some tasks are best suited for each type of processing. For example, rendering lighting at each pixel is great for a GPU that has thousands of "dumb" cores. AI pathfinding that requires a lot of "smarter" compute is best on CPU. This doesn't hold true for all games, but it's much easier to improve algorithm runtime for CPU tasks than it is for GPU, which intrinsically has to do work on 19201080 = 2073600 pixels each frame. Anyways, I hope that most of this is correct and helpful. I'll send it to my team as well and add any edits if there is anything that is very out of place. Many mountains to explore. See you next week! </figcaption> </figure> This Week In Veloren 76 Mon, 13 Jul 2020 00:00:00 +0000 This week we see lots of progress on UI as the crafting screen is coming together. @lobster gives us an overview of their progress on the particle system. @xMAC94x gives us a tutorial on how to get started writing translations for people who know other languages. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @xMAC94x, @XVar, @yusdacra, @Fexii, @Songtronix, @Sam, @gSpera, @.c, and @Slipped! @Pfau has released another art blog</a>. @Goldenrevolver is working on implementing opening and closing doors. @Kalculate is working on fixing a UI bug with the language selector. @Pfau finished the first implementation of the crafting UI alongside @zesterer. @Pfau is now working on groups with @imbris. WIP particle system. Check out the writeup to see how it's progressing! </figcaption> </figure> @Sam has been working on diversifying creatures by changing how much health they have, how much damage they do, and how much XP they give. They are also working on adding a protection stat to armor, which will reduce incoming damage. @Fexii added a free-fly camera mode for debugging purposes. @Sharp has been doing some cleanup on his LoD/lighting branch to prepare it for merging. </figure> </figure> </figure> Crafting preview </figcaption> </figure> Particle System by @lobster</h2> </figure> I've been working on creating an ECS particle emitter component. It can be configured and attached to an entity, like smoke trail emitter component on a fireball entity, or a campfire entity. Below you can see what types of parameters we can currently change on particles: // spawn X particles per Y, that live for Z, at W location pub struct ParticleEmitter { pub count: u8, pub frequency: Duration, pub initial_lifespan: Duration, pub initial_offset: (Vec3<f32>, Vec3<f32>), // range; upper-lower pub initial_scale: (f32, f32), pub initial_orientation: (Vec3<f32>, Vec3<f32>), // ... WIP ... // initial_velocity etc } </code></pre> And then I implemented a system that handles the emitting of particles and the particle lifecycles, for each of the emitter components. Below we can see what some of the math looks like when rendering particles: Mat4::identity() // initial rotation .rotated_x(rng.gen_range( particle_emitter.initial_orientation.0.x * std::f32::consts::PI * 2.0, particle_emitter.initial_orientation.1.x * std::f32::consts::PI * 2.0, )) .rotated_y(rng.gen_range( particle_emitter.initial_orientation.0.y * std::f32::consts::PI * 2.0, particle_emitter.initial_orientation.1.y * std::f32::consts::PI * 2.0, )) .rotated_z(rng.gen_range( particle_emitter.initial_orientation.0.z * std::f32::consts::PI * 2.0, particle_emitter.initial_orientation.1.z * std::f32::consts::PI * 2.0, )) // initial scale .scaled_3d(rng.gen_range( particle_emitter.initial_scale.0, particle_emitter.initial_scale.1, )) // inition position .translated_3d( pos.0 // relative to parent entity + Vec3::new( rng.gen_range(particle_emitter.initial_offset.0.x, particle_emitter.initial_offset.1.x), rng.gen_range(particle_emitter.initial_offset.0.y, particle_emitter.initial_offset.1.y), rng.gen_range(particle_emitter.initial_offset.0.z, particle_emitter.initial_offset.1.z), ), ) </code></pre> </figure> This is only a very basic implementation without many optimisations. I am using instancing and trying to avoid communication between the CPU and GPU, which is expensive. So once the particles are configured and uploaded to the GPU it's best to let them be independent, without further communication from the CPU. However, this means the particle having a fixed trajectory. There are many optimisations to be made around efficiently managing particles regarding the hardware properties and limitations. This includes buffer management and scheduling. We need your help for translations, this is how it's done (by @xMAC94x)</h2> </figure> This is a tutorial on how to extend Veloren with new languages. It is targeted for everyone who wants to enjoy Veloren in their native language. In Veloren we are using the i18n</code> technique to translate text in the game. For every language, there is a file in assets/voxygen/i18n</code></a>. Veloren developers tend to only update the English version when they add a new feature. Other languages are not updated by us developers. We simply don't speak all the languages to be able to do this. So rather we need your help, if you are a native speaker and have good English knowledge you can check what needs to be updated in your language to include the latest features. Fix Missing Translations</h3> To help you, @yusdacra fixed and improved a language test which is automatically executed every time a feature is added to Veloren. This tutorial shows you how to use his awesome test! </figure> Open (1) this link</a> where you see a list of pipelines currently running in our CI system. Try to find a relatively new (top is new) pipeline which is already green and contains the title unittests</code>. Not every pipeline might have one and it is not essential to get the newest one, just unittests</code> and you are probably good enough to go (2). Click on it (3). A page will open with a black box and a lot of text. You have to scroll up a bit and find something like what we see below: ----------------------------------------------------------------------------- Overall Translation Status ----------------------------------------------------------------------------- | up-to-date | outdated | untranslated tr_TR.ron | 206 | 11 | 19 pt_PT.ron | 123 | 15 | 98 es_ES.ron | 213 | 5 | 18 fr_FR.ron | 100 | 18 | 118 it_IT.ron | 120 | 17 | 99 ru_RU.ron | 198 | 6 | 32 de_DE.ron | 223 | 10 | 3 pt_BR.ron | 199 | 8 | 29 73.20% up-to-date, 4.77% outdated, 22.03% untranslated ----------------------------------------------------------------------------- </code></pre> This is the indication that you did everything right and got to the statistics. This is an overview page that shows you the available languages and if there are some missing or outdated translations. Let's say we want to focus on the German one, de_DE</code>. We have to scroll further up till we get the detailed info: ----------------------------------- "assets/voxygen/i18n/de_DE.ron" ----------------------------------- Key hud.bag.stats_title does not have a Git line in its state! Skipping key. Commit ID of key hud.bag.stats_title in i18n file assets/voxygen/i18n/de_DE.ron is missing! Skipping key. State | Key name | assets/voxygen/i18n/de_DE.ron | assets/voxygen/i18n/en.ron [Unused ] | char_selection.chest_color | 1af82604b55839275998d6afe7ee51a9ffbfdfe4 | None [Unused ] | char_selection.create_charater | ecb7963730ad2eb8d6e10f6df5dfaf99abccca5b | None [Outdated ] | char_selection.eye_color | 1af82604b55839275998d6afe7ee51a9ffbfdfe4 | ddaa0a9246abddcd623d32c2c1fcf4cd794882df [Outdated ] | char_selection.plains_of_uncertainty | 1af82604b55839275998d6afe7ee51a9ffbfdfe4 | ecb7963730ad2eb8d6e10f6df5dfaf99abccca5b [Outdated ] | char_selection.skin | 1af82604b55839275998d6afe7ee51a9ffbfdfe4 | f7d6f76a0458716ceaf5a53d3a70ee7f0fb9eda6 [Outdated ] | common.sound | 1af82604b55839275998d6afe7ee51a9ffbfdfe4 | 45217915911ddf1b5ea6a8ff36c2394fd755fcc6 [Outdated ] | gameinput.slot2 | f24ba71d9446ea8bcf259020125eaa4290bfde49 | ddaa0a9246abddcd623d32c2c1fcf4cd794882df [Outdated ] | hud.auto_walk_indicator | 9b2785aeae5b60984691c18a324b1d62ce2b9ed2 | ddaa0a9246abddcd623d32c2c1fcf4cd794882df [Unknown ] | hud.bag.stats_title | None | 88a938653be9a95128e938d24afba559bf57fdf5 [Outdated ] | hud.chat.loot_msg | 89400264dc0fb9babb93bcdd04f97c4252dcd772 | ddaa0a9246abddcd623d32c2c1fcf4cd794882df [Outdated ] | hud.chat.offline_msg | 89400264dc0fb9babb93bcdd04f97c4252dcd772 | ddaa0a9246abddcd623d32c2c1fcf4cd794882df [Outdated ] | hud.press_key_to_toggle_debug_info_fmt | 1af82604b55839275998d6afe7ee51a9ffbfdfe4 | e10f27f4806d9c9493bda4b5990a3d44b317fe10 [NotFound ] | hud.settings.reset_keybinds | None | 8e523364ac8b3a155938c98010562c664d577c57 [Outdated ] | hud.settings.toggle_shortcuts | 1af82604b55839275998d6afe7ee51a9ffbfdfe4 | ddaa0a9246abddcd623d32c2c1fcf4cd794882df [NotFound ] | hud.settings.unbound | None | 198c875559dbb1895249ea5d959b61dbff8901bf 223 up-to-date, 10 outdated, 2 unused, 2 not found, 1 unknown entries 94.49% up-to-date, 4.24% outdated, 1.27% untranslated </code></pre> Here we have detailed information about all language keys used in the German de_DE</code> file in comparison with the standard en</code>. Unused</code>: The key exists in German but not in English, these can probably be removed in the German version.</li> NotFound</code>: The key exists in English but doesn't exist in German. Here we need your translation!</li> Outdated</code>: The English name was changed and the German wasn't updated. This might be a hint that the German version is outdated and needs an update.</li> </ul> Okay, let's say we want to add the correct name for hud.settings.reset_keybinds</code>. So we first want to look it up in English: assets/voxygen/i18n/en.ron</code></a> Behind the key we find the English sentence: Reset to Defaults</code>. We know that the German equivalent would be Standarteinstellungen wiederherstellen</code> (Well, some of us do :P). So we open the German file: assets/voxygen/i18n/de_DE.ron</code></a>. If you are already a developer in GitLab you'll now see an edit button. If you are not familiar with GitLab or Git, you can also ask people on our Discord to help you, we are happy to support you any time :) Feel free to ping @git-wizard</code>, who will always be on deck to help with this. You can click on the edit button here </figcaption> </figure> Once you are editing the file on GitLab, go to the respective place where our entry is missing and add it here: "hud.settings.awaitingkey": "Drückt eine Taste...", "hud.settings.reset_keybinds": "Standarteinstellungen wiederherstellen", </code></pre> When you're done, enter a specific commit message such as update the German translation</code>. You'll then create a target branch with <yourname>/<language></code>. For example, mine would be xMAC94x/update-de</code>. Finally, you'll need to create a merge request. Check the boxes to agree that you're code will be under GPL3 license. You now requested to change the file, and we will then take a look at it and if we found it okay we will merge it into the game! From that point on your contribution will land in the master</code> branch, and in the next few days will be shipped to you via Airshipper. Thank you for your contribution! Help Review Other Translations</h3> Maybe someone already did a translation for your language. If so, you'll find a pending merge request with your language (e.g. de_DE</code>) this list: https://gitlab.com/veloren/veloren/-/merge_requests</a>. Ask us in Discord for reporter privileges and you can open it and add your thoughts to it. </figure> When clicking on the Changes</code> tab you can see the details of this change. Red lines are old ones that are removed and replaced by green lines. If you disagree with something that was added, you can start a discussion by clicking on the respective line. If you don't see any issues with the proposed changes, feel free to approve the MR or comment on it. It's important that you approve MR for translations as we the developers don't have the knowledge to verify the language (and we don't want to put everything through Google Translate). So you help us to verify others contributions resulting in improving the game quality :) Thank you! Watching an unbelivably rare harmonic convergence of celestial bodies. See you next week! </figcaption> </figure> This Week In Veloren 75 Mon, 06 Jul 2020 00:00:00 +0000 Welcome to the longest Veloren blog post so far! This week we hear from @xMAC94x about the network switchover. @imbris discusses an interesting bug. @zesterer overhauled pathfinding and wrote about how it's better. @Sharp shares some insights about how GUIDs might not always be the best. Timo went hiking and biking. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @xMAC94x, @lobster, @Songtronix, @imbris, @ProTheory8, @Slipped, @Snowram, @Qutrin, @AngelOnFira, @XVar, @Sam, @Pfau, @KevinGlasson, @Nancok, @theduke, @Patro, @Redo11,and @Swedneck! There is a new Rust gamedev newsletter</a> to check out! @Pfau also has a new edition</a> of his weekly Veloren art blog. The team met this last weekend for a 0.6 halfway meeting. Testing knockback values on a new hammer attack </figcaption> </figure> @Songtronix fixed an error with preventing the book</a> from working with Zola 0.4.1. The art team worked on improving spell and attack icons. They decided on a colour code system for icon backgrounds so that the player instantly knows what category it is in. For example, red means physical, while green means healing. Qutrin implemented a loot table system that allows choosing drop rates for items. @lobster was working on one-handed weapon fixes, and started working on particle effects. @WelshPixie had to resort to proofreading lore docs since there is currently a technical block on adding lots of sprites like she wanted. @Snowram helped @Slipped to finish the quadruped rework. Skunk by @Gemu </figcaption> </figure> @XVar the foundational backend implementation of skills and skill groups, and is now waiting for game design to come in with some preliminary skills to get into the game. @Gemu has been making progress on the small-quad reworks, such as the skunk. @Felixader is working on a few things. First is the design description and history behind the ideals of how the different cultures construct their cities. Second is cultural design philosophies for items. Finally, he is working on a structure for writers can format ideas for quests, lore items, and other writing items. This will have to be discussed with other groups to make sure it fits nicely. @Sam finished a new hammer attach which has been merged. They are now working on a new spinning axe attack. @JackRubino has completed an update to the Italian translation. @Sharp is still hard at work their monumental LoD and shadows branch, otherwise known as sharp/small-fixes</code>. There is hope that this branch will be merged soon! </iframe> </div> </figure>Networking Milestone by @xMAC94x</h2> In the blog we've covered a lot about networking recently. Last Friday we reached a networking milestone. The alternative networking backend got implemented into Veloren and will be active from now on. While no additional features are activated yet, everything is prepared to have it enabled seamlessly in the future. Rolling mountains by @Treeco </figcaption> </figure> Network Switchover</h3> The switch itself was quite a success considering it was switching the whole networking layer under the hood. There were a few problems, however: Server had a problem of too much logging which was fixed within an hour of discovery</li> Clients would panic if the server disconnected them, which was also fixed within an hour</li> When a clients disconnects from a server they had to wait 20 seconds for the timeout before reconnecting</li> </ul> None of those errors caused game-breaking behavior. Unfortunately, we had a further difficulty as our network frontend was sending way to much data (10 Mbit/s per player even on idle). This required lz4 compression to be reenabled to serve more than 4 players at a time on the official server. New icon for the axe skill </figcaption> </figure> Beside that, we were doing a lot of testing and found multiple other unrelated bugs in Veloren: Some messages from the server were getting dropped for a while now. Additional logging is now provided so this can be prevented in the future.</li> Entities are no longer in sync when you leave spawn and come back</li> Our netcode sends way too many inventory syncs, @imbris pushed a fix on Monday</li> Crash due to missing green pants item</li> Render distance not adjusted correctly</li> </ul> Next Steps for Networking</h3> The next steps for Veloren networking are quite clear: Improve stability</li> Work on the great list of stuff to improve from @Songtronix, @zesterer, and @imbris</li> Enable the multi-stream channel which will allow faster entity sync transfers even while there is a heavy bandwidth load</li> Better network statistics in Grafana, which will be beneficial for development and release parties</li> Invest in testing and scaling with multiple players (automated tools for high player-load tests)</li> Enable the UDP backend, which will decrease latency significantly</li> Network feedback to its ECS systems e.g when bandwidth is slow in order to reduce a player's tick count. This might enable higher tick servers)</li> </ol> Those steps will be tackled within the next weeks and months, so stay curious 🙂 The Case of the Disappearing Entities by @imbris</h2> A bug was found that caused entities to randomly vanish. At first, it was thought to be caused by some NaN in the code or a malfunction in the region system used to select what entities to sync to each client. This could be reproduced with the following: Open the game</li> Go from far enough from spawn town that you can't see it</li> Go back to spawn town</li> Try rolling, shooting bow, or spawning entities</li> </ol> The culprit can be seen in the image below. On login, the client</code> sends its requested view distance to the server</code>. The server</code> makes sure that it's constrained to a maximum allowed view distance. The code handles this by sending the client</code> an updated view distance if it was over the maximum. If you look carefully at the map</code> the two parameters are disordered leading to the client</code> always receiving a message telling it to use the max view distance. </figure> However, if the client</code> initially requested a smaller value the server</code> will still think that is the value being used. Additionally, the view distance in voxygen</code> is never updated because the client</code> uses an event returned from tick</code> to inform voxygen</code> of this change. At the time of the bug, voxygen</code> ignored all events from the client</code> while on this screen because they were previously not relevant. So we end up with a scenario where the server</code> and voxygen</code> both have the selected view distance, say 10, while the client</code> thinks the view distance is the max configured on the server</code>, say 30. Thus, the terrain renders as you would expect but the client</code> doesn't unload chunks farther out since they are still within the view distance that it knows. However, these chunks are unloaded on the server</code> since it sees them as being outside the client</code>'s view distance. Then, once the player goes back to the spawn town they will see the terrain chunks that the client</code> held on to but the client</code> won't request the server</code> to reload them. Additionally, since the area is not actually loaded on the server</code> any non-player entities will be deleted. Pathfinding with @zesterer</h2> I made a bunch of changes to pathfinding this week. The biggest improvements come from three places: heuristic modifications, velocity alignment, and cubic spline motion planning. Previously, pathfinding worked something like this: </figure> Getting from A to B used the A* algorithm with a basic distance heuristic. This resulted in paths that felt a bit odd. Enemies wouldn't run towards you in straight lines and pets would make bizarre robotic movements in order to catch up with you. This happens because the pathfinding only considers the most 'locally' efficient path to the goal: and since it can only consider the 8 neighbouring blocks, the best it can do is to choose the block that moves closest to the target from the source block. To solve this problem I modified the pathfinding heuristic to make A* prefer to use paths that are closer to a straight line to the target. This means that they now prefer paths that are shorter from the perspective of an agent that can move freely rather than one that can only do King moves in chess. This adjustment to the heuristic is actually very small: in most decisions it has almost no impact, but it's enough to act as a tie-breaker between two options that appear to both be optimal from the local perspective. The result is that it now produces paths that look like this: </figure> This feels a lot more natural: enemies run towards you in relatively straight lines, as do pets. However, there were still problems. In fact, this method introduces even more problems. Agents follow path nodes one at a time, aiming for the centre of each block. This resulted in lots of small turns appearing in the paths agents took. Where the old system created paths with lots of straight lines like this: </figure> The new system created paths with lots of small turns like this: </figure> This results in a lot of jerky movement: agents zig-zagging as their run, and a lot of ugly rapid rotation. To alleviate this problem I came up with another solution. I realised that the primary problem was that agents were aiming for the centre of each block and that the resulting motion would look much smoother if the agent instead aimed for the 'most convenient' position to hit within that block. 'Most convenient' can be a little hard to pin down, but a very good approximation of it can be found by looking at the agent's current velocity vector. The most convenient position within a block will be that which requires the least deviation from the current velocity to reach. This might initially seem like a daunting problem: agents move with smooth movement using floating-point numbers, so the number of points in the block to consider would be, in practical terms, infinite. However, this actually boils down to a simple linear optimisation problem. It turns out that an optimal solution will always appear on the edge of the block. To solve this, we can instead just find the intersection between the current velocity vector and the line that represents each edge of the block. The result is that we can achieve smooth motion even if the pathfinding itself remains grid-aligned. As a result, the path the agent actually takes looks like this: </figure> There's a secondary advantage that comes with this technique too. As it turns out, considering diagonal blocks makes pathfinding much more expensive. This is because validating that a diagonal block is accessible first requires that determining that at least one of the two blocks adjacent to the source and target blocks is accessible as well. This adds a lot of overhead to pathfinding. The original reason for adding diagonal pathfinding was to create smoother paths: but this new technique blows diagonal pathfinding out of the water for that! As a result, we can actually remove the diagonal pathfinding and get away with adjacent cardinal pathfinding instead. The result of this is a path that looks like this: </figure> Although this path has more nodes than the previous one, it's also much faster to find (it might also be possible to do post-processing cleanup on it afterwards but to be honest this isn't really needed due to the aforementioned velocity-alignment pass). The result of this is that pathfinding has become a lot faster and can do more useful work per frame. This allowed me to up the per-frame pathfinding iteration budget significantly meaning that agents discover complex paths in far fewer frames than they previously could. Lastly, I noticed some problems with the new animals. Many new animals, such as wolves, got introduced recently. I wanted to make them (and other creatures) feel a bit more natural so I added per-species movement speeds. The problem is that wolves now run at almost twice the speed that they used to: and the existing pathfinding code simply couldn't cope. It tended to overshoot path nodes, understeer on corners (leading to wolves falling off a lot of things), and it turned them into terrible hill climbers since they kept moving too fast down slopes, causing them to fall and hurt themselves. The previous approach to pathfinding involved moving in a dead-straight line towards the next path node. This worked fine for slower animals but, as mentioned, breaks down completely here. The agents would attempt to follow the following path: </figure> But in practice, this didn't take into account the reality of their own momentum, which resulted in them taking something closer to this path: </figure> I reality, this problem was even worse: wolves would willingly hurl themselves off narrow paths to their deaths with surprising vigor. To counter this problem, I made them decide on a movement direction by constructing a cubic Bézier spline (i.e: a curve) that took into account the following things: The agent's current position</li> The agent's current velocity</li> The positions of the next two nodes</li> </ol> The result of this is a curve that goes from the agent's position to the n + 1th</code> node in the path, but curves to take into account the current velocity (to keep movement smooth in the general case) and the nth node (to avoid erroneously cutting corners). </figure> This seems to work quite well for keeping movement smooth but unfortunately, it doesn't help slow agents down on corners to avoid their untimely death. To solve that problem, I added one last feature: agents now regulate their movement speed by taking the cubic path tangent a little into the future and performing a dot product against their current movement direction. This slows the agent down if their current movement direction deviates significantly from the direction of the path that they'll soon be needing to take. This, for the most part, solves the problem. It's not a perfect solution: it doesn't (and shouldn't - agents shouldn't always have access to this information) take into account the physical properties of the world around them - friction with the ground, air resistance, their own movement capabilities, etc. - but it's good enough that agents move in a manner that feels relatively reliable and realistic. I've also made a tonne of extra tweaks to pathfinding, too small to mention here, but these 3 changes were the big ones that had the most significant impact. There's still more that can be done and I plan to improve pathfinding further in subsequent feature branches. For now though, this is a significant improvement. GUID Insights by @Sharp</h2> GUIDs, or UUIDs, are a type of ID that uses 128-bits numbers to identify information. GUID stands for "Globally Unique Identifier", while UUID stands for "Universally Unique Identifier". They take the form 123e4567-e89b-12d3-a456-426614174000</code>. @Sharp and I had a discussion about their potential downsides, and the misconception that sequential primary IDs are outdated. - @AngelOnFira </blockquote> First and foremost, this is not arguing that GUIDs should never be used. Rather, I'm more arguing that you should think carefully about the kind of key you use and choose the right one for the job. So basically, the primary issue with GUIDs is that they're very large and very spread out in keyspace. These are of course exactly the properties you want from GUIDs, so this is a fundamental tension. Any methods that rely on data being "almost sorted" or the ability to quickly find a page on the hard drive containing a GUID will not work. For pretty much any index type other than a hash index, you are going to have pathological behavior for any update operation you care to think of as a result. Secondly, due to the space increase, foreign keys and indices are larger (often 4x or more larger). This makes it much harder to normalize your database and get good performance. I've found many instances where people told me they had to denormalize their database for performance, but it turned out to just be about GUID overuse. New axe spin attack by @Sam </figcaption> </figure> This also applies to other operations like aggregation. Even if they don't need to touch the GUID column, they're slower because they need to read more information from disk. Note: this doesn't apply to OLAP databases with column storage, but these are usually not what's used for most applications during regular operations. So you're paying a very large penalty on essentially every operation on your database other than nested hash lookups for the privilege of using GUIDs. The nested hash lookups, while the only available query plan in a lot of key value stores, are often suboptimal for industry-strength relational databases. There are other performance concerns as well. Often, host languages have even worse support for GUIDs than the database; in many dynamic languages the GUIDs end up being read as strings. This introduces substantial serialization, network, and parsing overhead over integers (and it's measurable). Work on @Sharp's shadows </figcaption> </figure> One thing that's often argued in favor of GUIDs is that it's virtually impossible that they will ever overlap. However, most databases will want you to create a primary key anyway which guarantees uniqueness, so this advantage doesn't really benefit you except in a very distributed context. Moreover, the advantage is very easy to get with mostly-sequential IDs too; you just include a "core" or "machine" identifier in your generated ID. This still produces compact IDs in the same local domain, but without requiring synchronization. This can also be extended to secure contexts; IDs are sequential within an organization or other security domain. Since your security should never be based on someone knowing a particular ID value in the first place, this also encourages much better secure design (in my experience). People who rely on GUIDs have a tendency to assume that, since it's so unlikely that they could be guessed, they themselves function as a security barrier. They forget about all the side channels through which they can be passed. Starry night by @Treeco </figcaption> </figure> GUIDs excel where loose synchronization is needed and there isn't a centralized registry, or where the GUID can do double duty (for example as a hash of its contents). Git is a database that would make absolutely no sense with sequential IDs. GUIDs of some sort (or at least, much larger keys) can also be really useful in a database with a different mechanism for achieving performance. For example, distributed key-value stores. However, they will still not achieve nearly the kind of performance that a small-key-optimized one can no matter how much you scale out, but they can often store far more data. However, even then, it's useful to be able to specify ranges so that you can redirect key lookups to the correct partition without having to do a full hash lookup. This kind of value-based partitioning scheme works best when values with high locality are clustered. So just doing a global GUID is usually not the best approach even there. Anyway yeah, for a tiny database or a system that doesn't get much traffic, I realize this is mostly academic. I just have seen way too many people get bitten by GUID performance and not realize it. I think a lot of people assume that sequential IDs are outdated and GUIDs are just categorically better now. At least that's the impression I've gotten. It's mostly that idea I want to fight back against. Ocean of Clouds by @SoullessTeacloth. See you next week! </figcaption> </figure> This Week In Veloren 74 Mon, 29 Jun 2020 00:00:00 +0000 This week we get a large update from the animation team. @Gemu talks modeling, @Snowram skeletons, and @Slipped technique. @XVar gives us a rundown on the progress being made on the skill system. We also have another art blog by @Pfau. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @XVar, @theduke, @AngelOnFira, @Slipped, @Patro, @Redo11, @swedneck, @samuelkieffer, @Treeco, @Nancok, @Pfau, @zesterer, @CapsizeGlimmer, @WelshPixie, @Imbris, @Songtronix, @Shandley, and @yusdacra! @zesterer has been working on castles this week. A #ux working group was created, and it is finding its footing. It will focus on improvements to how the player interacts with the game. @WelshPixie has been working on new shoulder armour. @XVar added chat messages when items are picked up, and the possibility to play different SFX depending on what was picked up. There are two placeholder sounds for swords and staves so far. New item interactions by @XVar </figcaption> </figure> @xMAC94x has been continuing work on networking. He also upgraded the Rust toolchain version as the Cargo MacOS error has been fixed. @lobster worked on the ability to wield 2 one-handed items. More to come on this soon. @Pfau also has a new art blog #4, which you can check out here</a>. @AngelOnFira has gotten around to lots of the translations that have been waiting to be merged for a while. </iframe> </div> Playthrough by paulsoaresjr! </figcaption> </figure>Skill System Work by @XVar</h2> This week I started work on implementing skills</a>, the server-side foundation of a skill system for Veloren. Today there is only a basic EXP/LVL system in the game - you get EXP for killing monsters, and then you can level up. However, there isn't any concept of skills or abilities for players yet. A game design meeting on Discord over the weekend resulted in the decision that adding skills to the game should be a top priority. It will allow us to start implementing all sorts of abilities and skills to flesh out the actual gameplay side of Veloren significantly. After this meeting, I drew up a quick concept of how the UI for a skill group might look. This was primarily to make sure I'd understood what the game design team actually wanted (a "skill matrix/grid" was frequently mentioned in the meeting). This is in no way representative of how the end result will look! Concept of the skill grid </figcaption> </figure> Not all skill groups will be in a grid form, or have this kind of progression path where you can only learn skills adjacent to already known skills, but all skill groups will have some things in common - an EXP bar, a skill point pool, and a list of skills that have been learnt in that group. So distilling this down into what needs to be done for an MVP, we get this: Building on the existing Stats</code> component that players have to include a list of skill groups the player knows, their current EXP and SP count in those groups, and a list of skills that they have learnt in that group. </li> Transferring this data between the client and the server. </li> Persisting the new skill groups and learnt skills to the database for each player. </li> Adding new messages that the client can send to the server to request a skill unlock or a skill point refund, with associated logic for the server to accept or reject this request based on the current state of the player. </li> </ul> </figure> While this might sound like a lot, I was actually surprised by how little work is required to implement this on top of the existing infrastructure within Veloren. Since it already has a robust client<>server messaging system, a full-featured ECS synced between the client and server, etc - there's not really much "plumbing" required to add new features. I think when a new developer to the project like myself can say this, it's a testament to the hard work put in by the Veloren team over the past few years. Once this basic implementation of skill groups/points is in place, there will still be a fair amount of work left until players actually get usable skills - Pfau is working on the design of the in-game skill book UI. Of course, there's actually designing/implementing the skill groups/abilities which I'm sure will continue on for the foreseeable future as the game continues to grow :) Skill book UI mockup </figcaption> </figure> Animation updates</h2> Modeling by @Gemu</h3> Hello, my name is @Gemu. I have been remodeling a lot of the old creature models from Veloren, so far having focused on the reptilian and several quadruped animals. My contributions so far have been solely on the modeling side of the reworks. I joined Veloren a few months ago. It was then when I first started creating voxel models and have received amazing support and feedback from the community. I offered to rework the old dragon placeholder model, and went from there. As I created models, the skeleton and animation progress made by @Slipped and @Snowram truly makes the models come to life. Since I have very little development experience myself, I've mostly stuck to making the models so far, and breaking them up in usable parts for animation. Seeing the finished models move around has been absolutely great. Therefore I plan to learn how to help @Slipped and @Snowram and contribute to the technical aspect as well. So far, the reworked models of all existing reptile models and medium-sized quadruped creatures are pretty much finished. Aside from the pre-existing models, I have created additional creature models based on the same skeletons, which thanks to @Slipped and @Snowrams' hard work were able to appear as well. So far I've continued working on other old animal model reworks, this time focusing on the smaller quadrupeds. Once the larger quadrupeds will be all finished up, new models will be ready to go. I hope the players will be excited to see all these different kinds of creatures wandering around the world as they play. Working on the model reworks together with the others has been very enjoyable and a great learning experience. The future will definitely bring more of that, and I look forward to expanding my horizon and experience towards other areas as well. </figure> Skeletons by @Snowram</h3> Hey, I am @Snowram. I helped to implement new quadrupeds skeletons into the game. A few weeks ago I decided to dive into Veloren animation by trying to improve some existing skeletons and animations. It has been a pleasant experience and the community has been very supportive. We have been working together with @Gemu and @Slipped to bring new life to the old mobs. While I don't have a developer background, the Veloren codebase is clear enough for everyone to take a poke at it. I started by adding a new skeleton to improve the look of reptile-like creatures. They previously used the "medium" quadruped one that is shared with mammals. Reptiles have a very different gait and morphology so a "low" quadruped skeleton was definitely needed. I imported every new models made by @Gemu and approved by the art team. Adding new skeleton parts is a tricky process where you have to declare all the offsets and rotation points for each new mobs. While these offsets are mostly the same for a given skeleton, you have to account for some specific outliers. For example, a crocodile tail is long and segmented while a turtle is short and made using a single bone. After that, I made several improvements to the "medium" quadruped skeleton. I broke all their legs into 2 bones in order for them to have feet. This change allowed for more complex animations. Veloren can't use animations made using a dedicated software yet so all of them are hardcoded, fortunately, it is quite easy to animate voxel models using some basic math. Some time ago @Imbris added a way to hot load animations and it made the whole process more seamless than ever. I made some basic animations and @Slipped did his magic to make them awesome. In conclusion, I very much enjoyed working as a team with everyone involved. This has been a great learning experience and the fact that each person has brought their own skillset into the collective effort is motivating. You always want to give the best to make the whole picture as great. </figure> Technique by @Slipped</h3> Hey, @Slipped here! Been a while since I've written anything up so this seemed like a good spot to jump back into the blog. My main branch for the last month or so has been the quadruped rework with @Gemu and @Snowram. It's been great to work with a team for a change as usually my work has been pretty isolated, and we certainly needed one here as the change has been massive. As @Snowram described, the main goal is to separate the low, reptile-like quadrupeds from the taller wolf-like quadrupeds. At the same time we're reimporting all of @Gemu's reworks (every mob has been rebuilt from the ground up), as well as building in a much deeper animation setup for the mobs. This includes the breaking of the leg into leg/foot for quadruped_medium</code> as @Snowram mentioned, and also a general internal rewrite of the skeleton to adjust every bone to be a child or grandchild of a single parent bone (an important concept that I mostly neglected until recently). The branch also has the addition of some new techniques that I've learned from the humanoid skeleton in the last few months. These include adding orientation tilt so that the body rotates smoothly on turns, and also using a ground-based foot movement model instead of using pendulum rotation as we see in main. We're also differentiating strides for the first time. Animals have been moving around at varying speeds in-game but their animation has not reflected that. Now in the branch, we differentiate a trot and gallop for varying mob speeds, with different movement frequencies and intensities of motion to highlight the changed gait. One last piece we've got in now is a basic set of attack animations for the quadrupeds. They're in a pretty plain state currently, it makes the combat feel a good bit more engaging when you see that feedback from the monster you're fighting. New wolf animation. See you next week! </figcaption> </figure> This Week In Veloren 73 Mon, 22 Jun 2020 00:00:00 +0000 This week, we have a lot of updates from external platforms. @Pfau has another art blog to show off. There is a lot of updates from the writing working group. We hear about testing and documentation from @AngelOnFira. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @kevinglasson, @AngelOnFira, @Songtronix, @imbris, @Slipped, @xvar, and @scottc! Recently, Veloren has made it to the front page</a> of most-starred projects on GitLab! Our YouTube channel has made it to 1000 subscribers as well. @Pfau has released another art blog</a>. @Pfau has been working on a trading window concept. @Felixader completed a design document</a> for the direction of the writing working group. He is also working on a document detailing the cultural design philosophy. @WelshPixie wrote race descriptions</a> for inside the character creation menu. They also added lots of new lines for when villagers get hit by players. @Gemu is still reworking some old models. So far, all larger quadrupeds and reptilians are done. @Snowram and @Slipped have been working on the animations and implementations of these new models. New mobs by @Gemu, implemented by @Slipped and @Snowram </figcaption> </figure> @kevinglasson added persistence of the hotbar, allowing it to be saved when the game is exited. They also worked with @xMAC94x and @Songtronix to change logging over to use the tracing crate. @Slipped is working on adding sneaking, rebuilding climbing to be more fun, and adding glider wall running. @mainCharacter was working on proofreading content that the player would see. New mushroom models by @WelshPixie </figcaption> </figure> Improving Test Coverage by @AngelOnFira</h2> In the last few weeks, I've been interested increasing test coverage and documentation of the project. I've worked with @Kevinglasson and @Shandley on this endeavor. Test coverage allows us to catch errors and regressions before merging our code into the main branch. Documentation gives better information to developers who touch many different parts of the codebase, or who are learning about a new section. Rust offers a great workflow for both documentation and test coverage. In fact, you can build tests right into documentation for functions. This has two benefits. First, the code that makes up this test can be used to show how a function works. Second, if the tests in the function's documentation fail, likely the documentation needs to be changed at the same time. Steppesman's helmet by @AlbinoAxolotl </figcaption> </figure> On top of doc tests, Rust has a great way of generating readable documentation. It collects comments that are above functions and adds them to a static site that it generates. You can see what that looks like here</a>. On this site, we see information about what this function expects as parameters, and what type these parameters are. We then see the documentation written for this function. Finally, we see the doc test written at the bottom. We can see an assert_eq!</code> at the end. If someone changes how equip works, and this assert fails, then they would have to fix the documentation to reflect the change. Below is what this entire function looks like in the codebase. /// Equip an item from a slot in inventory. The currently equipped item will go /// into inventory. If the item is going to mainhand, put mainhand in /// offhand and place offhand into inventory. /// /// ``` /// use veloren_common::{ /// assets, /// comp::{ /// slot::{equip, EquipSlot}, /// Inventory, Item, /// }, /// LoadoutBuilder, /// }; /// /// let boots: Option<Item> = Some(assets::load_expect_cloned( /// "common.items.testing.test_boots", /// )); /// /// let mut inv = Inventory { /// slots: vec![boots.clone()], /// amount: 1, /// }; /// /// let mut loadout = LoadoutBuilder::new().defaults().build(); /// /// equip(0, &mut inv, &mut loadout); /// assert_eq!(boots, loadout.foot); /// ``` pub fn equip(slot: usize, inventory: &mut Inventory, loadout: &mut Loadout) { use item::{armor::Armor, ItemKind}; let equip_slot = inventory.get(slot).and_then(|i| match &i.kind { ItemKind::Tool(_) => Some(EquipSlot::Mainhand), ItemKind::Armor { kind, .. } => Some(EquipSlot::Armor(match kind { Armor::Head(_) => ArmorSlot::Head, Armor::Neck(_) => ArmorSlot::Neck, Armor::Shoulder(_) => ArmorSlot::Shoulders, Armor::Chest(_) => ArmorSlot::Chest, Armor::Hand(_) => ArmorSlot::Hands, Armor::Ring(_) => ArmorSlot::Ring, Armor::Back(_) => ArmorSlot::Back, Armor::Belt(_) => ArmorSlot::Belt, Armor::Pants(_) => ArmorSlot::Legs, Armor::Foot(_) => ArmorSlot::Feet, Armor::Tabard(_) => ArmorSlot::Tabard, })), ItemKind::Lantern(_) => Some(EquipSlot::Lantern), _ => None, }); if let Some(equip_slot) = equip_slot { // If item is going to mainhand, put mainhand in offhand and place offhand in // inventory if let EquipSlot::Mainhand = equip_slot { swap_loadout(EquipSlot::Mainhand, EquipSlot::Offhand, loadout); } swap_inventory_loadout(slot, equip_slot, inventory, loadout); } } </code></pre> I've worked on documenting and adding tests to a single file so far, specifically slots.rs</code>. I plan on doing more in the future. It is a good way for me to get better at Rust as a low to mid level Rustacean. Hopefully, other developers will work to document what they're doing as well. It's a lot easier to add a few lines as you're writing rather than for you or someone else to come back to it later :) Cultivating a Healthy Open Source Community by @AngelOnFira</h2> </iframe> </div> </figure>New Villager Retorts by @WelshPixie</h2> "Tis but a scratch!" "Heinous wretch, be gone with you!" "Stop it! Go away!" "Oi! Who do you think you are?!" "I'll have your head for that!" "I'll set my brother on you, he's bigger than I am!" "Nooo, I'm telling mother!" "Your weapon works, you can put it away now!" "Today is turning out to be a very bad day..." "Eek!" "A pox upon you!" "This isn't fun." "You must have me confused with someone else!" "Guards, throw this monster in the lake!" "I'll set my tarrasque on you!" </code></pre> New shoulder armour by @WelshPixie. See you next week! </figcaption> </figure> This Week In Veloren 72 Mon, 15 Jun 2020 00:00:00 +0000 This week, we have work from new contributors. We hear from @zesterer about test economic simulations. @xMAC94x has been working on merging networking, and wrote about the process. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @Pfau, @WelshPixie, @scottc, @xMAC94x, @Shandley, @AngelOnFira, @xvar, @Songtronix, @Slipped, @yusdacra, and @JamesTai! @Acrimon has been rewriting the authentication server. He is transitioning from a microframework and tiny_http to warp and hyper which is more robust and gets rid of the currently possible slow loris attack by being async. @Songtronix has merged most of the changes to the book. There are still sections that need to be worked on, but it now has a lot more information. @lobster has been working on improvements to combat. This includes energy regen resetting properly, and ability usage. Executioner sword by @AlbinoAxolotl </figcaption> </figure> @Slipped has been hard at work this week. He added a secondary bow attack and made arrows visible when holding the bow. @Slipped also worked on completing the glidewield branch with @imbris for carrying the glider around on the ground. @Slipped, @Snowram, and @Gemu work on quadruped overhaul branch. @AVeryLostNomad is continuing work on an indoor camera mode. New quadrupeds by @Gemo and @Snowram </figcaption> </figure> There have been lots of new contributors joining recently. @WelshPixie has been working on lots of new flora. @mainCharacter is working on proofreading some of the writing with the lore blogs. @RENCURELI is going to be working on a document proposal for level design. It will also include some ideas for world generation guidelines. New flora by @WelshPixie </figcaption> </figure> Economic Research by @zesterer</h2> Recently, I've been doing a heap of research: Marginalism, the Lange–Lerner model, and various other models for centrally-planned economies. I've attempted to implement aspects of Lange–Lerner into Veloren's economic simulation. I think I've got site economies converging on Pareto-efficient production configurations now so that's nice. Below is a graph of the rationalised values (roughly analogous to internal economy prices) of various commodities over the 500-year lifetime of a site. A site in this case is an arbitrary village or city type of object. Note that the natural environment and worker productivity is remarkably stable, hence the manner in which value rationalisation converge toward stable values. Also, the value is in arbitrary units (i.e: it's not "per Kg" or something like that) so comparing values isn't really worthwhile right now. Internal economic prices of commodities for a site </figcaption> </figure> Next, we have a graph of the same site, this time the stocks are maintained by the site of each commodity. In practice, the stock of a commodity is roughly proportional to the demand for that commodity (in arbitrary units) over the course of a year. Stocks maintained by site of commoditiy </figcaption> </figure> Since the Lange-Lerner model involves deriving commodity values by trial-and-error, you can see that the initial values are necessarily arbitrary and so the site goes through a period of economic instability before converging on values that are Pareto-efficient (in a market economy, this would be the market equilibrium). And, for that same site, below is the workforce allocation for each occupation. The units now are not arbitrary and actually correspond to a number of individuals (fractional values are taken to mean that an individual only performs the given labour for a fraction of the year). Workforce allocation for each occupation </figcaption> </figure> Note that all of these graphs are relatively meaningless right now since I've not set up industries and natural resources correctly yet. I'm basically just using them to ensure that the economy reaches Pareto-efficiency rather than misallocating resources and spiralling off into producing far more wheat than could ever be turned into consumable food (as was an issue I had before). Interestingly, the economy seems to go through cyclical periods of economic instability. This is expected since it's a chaotic system. You might say that these are analogous to boom-bust cycles that we experience under modern capitalism, although in this case value rationalisation goes through a damping process that should get rid of most of that. </figure> I just added some random seasonal variation for the supply of natural resources and as you can see the respective commodity values fluctuate accordingly to compensate for this (including for goods that are derived from natural resources). Seasonal variation of natural resource supply </figcaption> </figure> Networking Work by @xMAC94x</h2> The new veloren_network</code> crate was merged into the main source code by @xMAC94x this week. The merge wasn't as easy as it sounds, as there were some still errors in documentation, metrics delivery, and the implementation. Luckily these were found by @imbris and @Songtronix. Additionally, I noticed some timing behavior that occurred on PC's with less than 8 cores. It appeared in CI and was hard to track down. The code has been merged for a week now, and running tests in the background without any problems. The next step towards new networking is to actually start using it in the Veloren codebase and see how it works out. Mouflon by @Snowram </figcaption> </figure> MacOS Linking Error by @xMAC94x</h2> Recently I found a toolchain blocker that prevented building for MacOS. Usually we update our rust-toolchain once a month. Last time we tried, we ran into some errors in the MacOS pipeline as there was a linkage error. After writing a Rust bug report</a> it seems to be finally someone who wants to fix it, so that we can upgrade again 😄 Expedited fix by the Rust team! </figcaption> </figure> Compilation Improvements by @xMAC94x</h2> Following the CI improvements from last week, this week now had a series of compilation improvements. This was mainly done by removing multiple versions of the same crate, removing unused features, or switching over to other crates which are more low level and suit our task better. As an example; until now we shipped a full-blown web-server AND web-client with veloren-voxygen</code>. We used a web-server</code>, build for handling hundreds of simultaneous connections to serve our metrics to a single consumer! We replaced rouille</code> by tiny_http</code> as our server. Also, we use a full blown web-client</code> which was build complex tasks to make a few calls to the auth</code> service. We replaced reqwest</code> by ureq</code> as our client. The result was a reduction in 40 sec in compile time, 12% in total CPU time (across all cores) and 2 GB of cache for each runner: </th> </th> </th> Old</th> New</th> Diff</th></tr></thead> Dependencies</td> cargo build</code></td> 589</td> 480</td> -19%</td> </td></tr> </td> cargo test</code></td> 959</td> 791</td> -18%</td> </td></tr> Cpu time</td> cargo build</code></td> 3076s</td> 2680s</td> -13%</td> </td></tr> </td> cargo test</code></td> 6118s</td> 5351s</td> -12.5%</td> </td></tr> Time</td> cargo build</code></td> 4:45</td> 4:05</td> -12%</td> </td></tr> </td> cargo test</code></td> 7:30</td> 7:04</td> -6%</td> </td></tr> </tbody></table> A whole world to explore! See you next week! </figcaption> </figure> This Week In Veloren 71 Mon, 08 Jun 2020 00:00:00 +0000 This week, there is a lot of external work to check out. This includes the Rust Gamedev monthly newsletter, an interview with GamingOnLinux, and @Pfau's art blog. We also have new contributors to our Open Collective! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @yusdacra, @xMAC94x, @xvar, @Shandley, @Songtronix, @Imbris, @Pfau, @JoeyMaher, @Slipped, and @scottc! Lots of external updates this week! We did an interview with GamingOnLinux</a>. It covered many questions about Veloren's development with open source management and Rust. The Rust Gamedev May newsletter</a> has come out. @Pfau has written his second blog</a> about artwork in Veloren. Our Open Collective</a> has some new contributors! With the initial donations, we're going to start looking at how we're handling infrastructure. This will include reimbursing those who are voluntarily running our servers. It will definitely let our release parties run on the best hardware money can rent! Airshipper now supports Mac thanks to @Songtronix's hard work! @CapsizeGlimmer has added group chat and regional chat functionality. @AVeryLostNomad worked on some minor features and bug fixes. These include an auto walk key, and lanterns no longer staying on when dropped. @xvar is working on improving how we use clippy, allowing us to catch a lot more potential errors in the future. @Shandley has been continuing work on SFX. 120 bookcases by @SausageRolls </figcaption> </figure> GamingOnLinux Interview</h2> If you haven't checked it out already, here is a snippet from the interview</a>! </blockquote> GOL: Why not go with an off-the-shelf game engine?</h3> F: "The big game engines like Unity or Unreal are great for general-purpose games. They’ve been heavily optimized for genres like first-person shooters, or games with meshes that you just import from your modeling software. However, once you want to dictate the rules on how the complex fundamentals of your world are created, you can run into some issues. Engines have a lot of overhead and provide you with high-level abstractions. It’s as if you’re given Steve from Minecraft to control, but you really want to be controlling Qwop from QWOP. It’s a lot more work, but you have more precision in moving the way you want. Among other things, these engines would have a representation of what an “object” is. In Veloren, we would need each voxel in the world to be represented by this “object”. Internally, we represent voxels with as little data as we can, of which is very specific to our needs since we have that level of control. On the other hand, engines would store a lot more metadata about it, since engines need to work more generally for any type of game. It might include unneeded physics abilities, or the functionality related to meshes other than cubes. Veloren group and regional chat </figcaption> </figure> On the other hand, there are other game engines that are more specific, such as the Amethyst engine, which is also written in Rust. It offers lots of modular functionality, where we could pick and choose systems that we like, or use the engine as a whole. However, Amethyst is still being developed, and wasn’t far enough along when Veloren was started. Our approach to custom engine development has resulted in some unique systems. The land formation is sculpted by an erosion system that simulates over millions of years, and creates realistic features such as downhill rivers. Our procedurally-generated villages already have some simple economic simulation. This comes from attracting developers that are interested in experimenting with ideas that are niche and novel, and have an incredibly flexible engine to work with." By @Zukel </figcaption> </figure> GOL: Your ultimate goal for Veloren?</h3> F: "For each of us, it’s different. The project was originally started by people who wanted to make an experience that would fill the void created by Cube World. However, since then, many people have joined who had never played Cube World before. The project founder, @zesterer, wants to create a dynamic world where settlements and cities interact economically and politically. @Songtronix’s goal is to improve the user's experience with Veloren, primarily by working on our launcher, Airshipper. @Pfau, wants to create a vivid world from the art of our many artists. @Slipped wants to create a captivating animation system. @Timo wants to create a dynamic experience that friends can have. @Sharp is using real-world natural processes to simulate our world generation system. With everything that inspires each one of us, I think we can create the game we are hoping for." A visored sallet by @AlbinoAxolotl. See you next week! </figcaption> </figure> This Week In Veloren 70 Mon, 01 Jun 2020 00:00:00 +0000 This week, we hear from @xMAC94x about the state of CI in Veloren. @BottledByte has analyzed modding possibilities in Veloren. @Capucho is working on an animation proposal, and @Pfau has an art blog post. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Imbris, @Shandley, @zesterer, @Pfau, @scottc, @Slipped, @xMAC94x, @Songtronix, @qrazhan, and @CapsizeGlimmer! This week, @lobster added more information to the character window. @xMAC94x has been working on lots of CI improvements. He also has been continuing work on networking, and some changes are currently in review. @badbbad has created a new ambient night audio track. @Capucho is working on an animation proposal, you can check it out here</a>. Social window work by @lobster </figcaption> </figure> @Shandley merged inventory and layout persistence. @Pfau has been working a lot on the UI, and has a new art blog post, which you can check out here</a>. @Snowram has been working on adding a snake and worked with @Slipped to improve small quadruped animation. Your browser does not support the audio element. </audio> I'm Home by @badbbad </figcaption> </figure> Mod Analysis by @BottledByte</h2> I have been trying to add a WASM interpreter to the Veloren's codebase. Also, because I was curious, I did more research on both Wasmtime and wasmer. As per @Capucho's proposal, I have tried Wasmtime as the first option for Veloren's WASM integration. After about 3 hours, I gave up, as my attempts to integrate wasmtime failed. This was because most of Wasmtime's structures are not thread-safe. I was unable to figure out a nice and easy way to implement design for its use. It appears to me that Wasmtime is not designed to be used in multi-threaded environments without additional work on user's side. Maybe they will make it thread-safe one day, but that is the future. As an example of this, here is a quote from their documentation: It is intended that Memory is safe to share between threads. At this time this is not implemented in Wasmtime, however. This is planned to be implemented though! </blockquote> So, I tried to integrate wasmer instead, and it only took 10 minutes! This was because wasmer's internals are thread-safe by default. So I was interested in pros and cons of Wasmtime and wasmer and did some primitive benchmarks. Here are rough results using relative measurement: > Compilation wasmer was ~120% slower than wasmtime > Instantiation wasmer was ~120% slower than wasmtime > Execution wasmer was ~25% slower than wasmtime </code></pre> Well, that could not be more obvious, wasmer is just slower than Wasmtime. However, both compiling and instantiating can be alleviated somewhat. These benchmarks are not of real-life cases, I admit. However, even in case of a simple for loop, wasmer was slower. Micro props for details in houses by @SausageRolls </figcaption> </figure> Also, the background and goals behind Wasmtime and wasmer are different. Wasmtime's creators, Bytecode Alliance, is a syndicated effort of industry giants to "push WASM forward". On the other hand, Wasmer Inc. tries to bring WASM into production and "real-life" applications. In my opinion, Wasmtime will have high ground in features, while wasmer will have nicer APIs. Despite its current synchronization quirks, Wasmtime seems like a good bet for the future. wasmer is there, too, and it makes things a lot easier, but sacrifices speed and features. Or the Veloren project could wait some more time until Wasmtime gets polished. In the meantime, some data-driven modding methods could be used. This means exposing more functionality through config files. It is simpler, both for modders and for API implementors, and it still reduces compile times a lot. Improving CI by @xMAC94x</h2> @xMAC94x spent the week improving the current CI situation. Over the past year Veloren has grown a lot. However, we didn't focus enough on keeping the project clean. The result is that CI is a bit dusty right now. What is CI?</h3> CI stands for Continuous Integration. It means that our code is integrated through tests every time we want to merge code. Most of our testing is done automatically, giving the devs more time to focus on creating new stuff while consistency and stability guarantees are provided by the CI framework. It's the responsibility of the contributors to write these tests. Usually, you try to define many tests, including benchmarks, performance tests, functionality tests, and integration tests. When a contributor wants to change something, all tests written by all contributors are run in the CI. If a test fails, the developer will be notified and can fix their bug. This must be done before the code can be merged and go live. New hourglass by @Pfau </figcaption> </figure> What's wrong with our CI?</h3> We are missing tests, we only have 1.17%</code> of our source code covered. Is that bad? Yes and No. While 1% itself doesn't mean that we have bugs in Veloren, it means a bug could hide happily in 99% of our source code without us noticing. This number should go up. Having more than 80% is recommended and projects tend to profit in the long term from good test coverage. (Note: A high test coverage itself is no guarantee for a good project). Our CI is slow. CI is required to run for developers to merge. If a contributor changes something they have to wait for feedback from CI, which can take up to 2 hours currently. Our CI is error-prone as well, but isn't consistent with the problems. Imagine your CI is like a traffic light, it either sends you a red or a green signal. You want to be able to trust that signal. It should be reliable and not fail. If it shows red to all 4 directions, people are annoyed why they have to wait. But if it falsely shows green to the wrong people this could lead to a catastrophe. Luckily in our case, the later one doesn't happen often. Snake by @Snowram </figcaption> </figure> How to fix CI?</h3> Okay, we identified some issues with CI, how will the Veloren team improve it? Improving code coverage. this has to be aligned with core devs first, but the only way to get it to work is to encourage people to always add tests. An extreme case would be to forbid changes without tests, however, we would rather not enforce that. </li> More effectively using caches. Our codebase is quite large currently, and changes are small. When any change comes in, our CI computers often restart from scratch. We can configure CI to cache the results in order to speed up the tests. However this hasn't worked out until now. (more below) </li> Fix broken runners and include verify post-merge result</code> (more below) </li> </ul> </figure> What was done this week</h3> I spend a lot of time today working on improving caching. We are using GitLab CI as it provides the awesome functionality to host own runner and configure them as needed. A few months ago @Acrimon switched our toolchain to use docker and @Songtronix just recently enabled the new powerful GitLab rules to modify behavior our CI tests. As compiling Veloren is slow, CI is also slow. We tried to use all kind of caches, including the GitLab internal ones. This doesn't work though, because they zip everything, as we have up to 15 GB of generated files. Zipping them takes more time than just having no caches at all. For now we are going with prebuilt caches. Once a week we prebuild the cache in a nightly job, this will then be reused every time. Such a prebuild can really be super efficient end eliminate all dependency compilation, only keeping the linking times. However, this simply doesn't work. We couldn't figure out why, but some cache where just ignored. What it took was some testing. As I spend some time with cargo</code> I got to know that it's far from perfect. cargo</code> had separate caches for debug</code> and release</code> build no matter what. However, we are generating much more builds than just debug</code> and release</code> complicating this even further. We are running the following tasks in CI check</code>, build</code>, test</code>, benchmark</code>, clippy</code>, tarpaulin</code>, audit</code>, windows release</code>, linux release</code>, and macos release</code>. All these try to use the same cache. I found out that this just didn't work. One would expect that if we already filled the cache with the check</code> job that the next build</code> will be sped up, unfortunately this is not true. It will just ignore everything and reinvent the wheel. At least this is not destructive. When we ran test</code> once, then ran tarpaulin</code>, it destroyed all cached data till now, so a second test</code> would have to start all over again. The same goes for the multiple release builds</code>, somehow windows release</code> was resetting all progress on a linux release</code>. </figure> So how did we fix it? The solution might sound too stupid to function, but it does work. We just use different directories to store the results. We make sure that tarpaulin</code>, windows release</code>, linux release</code>, and macos release</code> all get a separate directory to store their builds. All the other jobs are fine to share the same directory, their caches work as intended. With this, compile times goes down to under 30 minutes for all those tests. Besides saving some electricity, this really saves the sanity of our contributors 😊 (and my sanity ofc, it was annoying me so much that I had to do something) What needs to be done</h3> We disabled some jobs on master this week. This removes the ability to check if our merged result is still functioning correct. The usual Git Merge workflow is the following: A contributor creates a new branch off of master</li> The contributor adds some new changes to their branch</li> In the meantime, other people work on master</li> The contributor merged their changes back to master</li> </ol> We should be running tests for both 3. and 4. before it is merged into master. However, we only run tests on the contributor's branch, without a simulated merge. Therefore, errors can occur during the merge. If this would happen, we would have a bug in master. And master is the version distributed to the server and via Airshipper. So this should never happen. A feature called verify post-merge result</code> would help here. It would kick in on step 3 and simulate step 4 before executing it. If an error would appear now, it could be addressed before it goes to the players. Next Steps</h3> To achieve better test coverage we probably need to discuss with developers what's the best approach to take. It's not essential to force there to be more tests everywhere, but we need to take a more proactive strategy for testing. I will be continuing my work on networking. Additionally, I will try to reduce Veloren's compile time by reducing its dependencies, I am happy to present them in the next post 😃 Chunky boi chillen, see you next week! </figcaption> </figure> This Week In Veloren 69 Mon, 25 May 2020 00:00:00 +0000 This week, we had our 0.7 meeting. @zesterer gives us a run down on how chunk generation and loading works. @imbris discusses progress on switching to iced for the main menu. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Treeco, @Pfau, @Songtronix, @AngelOnFira, @zesterer, and @Sharp! This week, Gaming On Linux wrote an article</a> about our 0.6 release. @imbris has been working on the UI library switch to iced. He is working on moving over small pieces of the codebase at a time. @CapsizeGlimmer has been working NPC speech bubble functionality. @Slipped has been working on some animation fixes. </figure> New hairstyles and eyes for Danari and Dwarfs </figcaption> </figure> Your browser does not support the audio element. </audio> Into the Dark Forest by @Aeronic </figcaption> </figure> 0.7 Intro Meeting</h2> Lots of attendees at the meeting! </figcaption> </figure> We had the 0.7 intro meeting last Sunday. You can find the meeting notes here</a>. We decided that 0.7 development will start on June 1st, and release August 1st. Like always, we wrote up a definition of 0.7 of what we would like to see from the perspective of a player: As a player, I want to get quests from NPCs in settlements. I want to be sent to kill enemies, collect objects, or complete dungeons. I want to be sent from village to village and become familiar with the region. </blockquote> I want to be able to open the map and get information where I need to go for a quest. I want to be able to easily find where dungeons, villages, and other points of interest are. I want to be able to open a trade window with NPCs in villages and buy and sell items. I want to be able to craft items with ingredients that I have. </blockquote> I want to be able to see and hear more while in combat. I want to feel good while doing combat. I want to see particle effects from magic, and hear swords clashing together. I want to be able to add people to my combat party and interact with the game UI to do this. </blockquote> </figure> New updated models by @Gemu </figcaption> </figure> We also discussed version numbers as we approach the higher numbers of 0.X.0. We decided that after 0.9.0 would come 0.10.0, followed by 0.11.0. This will allow us more versions to make the game we've dreamed of without feeling pressured. Also, we would have to make 0.7, 0.8, and 0.9 much larger to accommodate for 1.0 right after. As we saw with 0.6, large versions are best to stay away from. We also wrote down systems that are likely to be included, as well as experimental systems that could be explored further: # Things it could include - Quest system - World sim - More interactions in settlements - More advanced UI - Implementing design team features - Story elements - Audio system for combat to add more layers of music # Experimental systems to look at - Modding support (Mun, other scripting languages) - LoD - Settlement sim - Animation system extensions - SFX framework - Networking system </code></pre> We also officially announced the rollout of our OpenCollective account. For those who want to donate to development, this is the way to do it. It will help us support the cost of infrastructure for now. However, in the future, it may be used to compensate core developers for full-time work. You can check out our Open Collective account here</a>. Work on iced with @imbris</h2> Main menu switch to iced progress </figcaption> </figure> Was it a pain to get working? Or was it easier than to work with conrod? </blockquote> In my opinion, iced is a lot easier to work with. A lot of the effort I put in was trying to get the scaling with window resizes to look nice. With conrod I would just scale everything down but iced's layout offers the potential for smarter scaling which first compresses empty spaces before shrinking the UI elements. There are some issue though. For example, the text widget does not have a way to adjust its size based on the available space. So I had to make a custom widget that does this. I think once I get all the foundations worked out it will be really nice to work with. Another pain was figuring out text rendering. That's not an iced issue though. Chunk Generation by @zesterer</h2> There are a bunch of things going on behind the scenes that enable chunk generation to be relatively quick. In something resembling an ordering that goes from the 'core' of the engine out to the periphery of it: We have a very efficient in-memory chunk storage format that not only allows us to use very little memory when storing chunks, but also allows chunk data to be very cache-friendly (more information here</a>).</li> The world generation code has been optimised to cache important data at various stages (although there's still a lot of work to be done here) as well as only performing generation calculations for ranges of blocks that it knows in advance are noteworthy (no point wasting time generating blocks that are 100 metres in the air, for example). New skillbar design in progress </figcaption> </figure> </li> When sending chunk data to clients, the data is always compressed due to point (1) but gets compressed even further by running it through the LZ4 compression algorithm. After all of this, chunks that might easily require 300 KB of memory with a naive approach to storage now require perhaps only a 10th of that on average.</li> Clients have a thread pool that is used to quickly siphon heavy-duty work such as meshing off the main thread and on to to a worker thread running on (hopefully) another core. This means that the rendering thread can continue to run smoothly without interruption. A falcata by @AlbinoAxolotl </figcaption> </figure> </li> When handing chunk data off to clients, we use a COW (Copy On Write) system to immutably reference chunk data during meshing. This allows multiple threads to refer to the same chunk data at once (including the main thread) without copying the data (in most cases).</li> The meshing code is very optimised. For each chunk, we carefully pre-calculate the range of blocks that need checking when performing surface extraction to avoid doing work for blocks that we know in advance do not have exposed faces. In addition, we move through the chunk data through the primary axis, z, to allow for good cache coherency. In the process we also do our best to avoid accessing block data multiple times, caching block solidity information between each face test.</li> Chunk meshes have a very compressed vertex format. We're able to squeeze x, y, z, r, g, b, AO, volumetric lighting, and surface normal information all into just 8 bytes per vertex. There's still a lot more to be done in this space of course, but this means that the chunk vertex buffers are fast to upload to the GPU and also fast to render once on the GPU since we can fit more vertices within the cache.</li> </ol> Level 200 achieved by @Redo! See you next week! </figcaption> </figure> This Week In Veloren 68 Mon, 18 May 2020 00:00:00 +0000 This week 0.6 was launched! We take a look at the telemetry from the launch party. @AngelOnFira has done some network analysis on Veloren. A lot of bugs were squashed before the 0.6 release. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @jbeich, @Slipped, @Silentium, @Pfau, @xMAC94x, @imbris, @zesterer, @treeco, @Songtronix, @Shandley, @LunarEclipse, @mockersf, @CapsizeGlimmer, @AngelOnFira, and @Acrimon! 0.6 was finally released last weekend! This update was the combination of many contributors' efforts, and focused on adding content to Veloren. The release party saw nearly 50 concurrent players on the server at once. It turns out that the 0.6 release has brought more players to Veloren as well. Before the update, there were on average 1.57 active players on the server at once, whereas now that has increased to 3.2. The team will be meeting next weekend to have the intro meeting for 0.7. Your browser does not support the audio element. </audio> Leap of Faith by @badbbad </figcaption> </figure> Vestal Cleric Set by @AlbinoAxototl </figcaption> </figure> @Redo11 has been working on adding polish translations. @LunarEclipse fixed bug that caused crashes in the packaged versions of Veloren, and also updated the AUR for 0.6. @DaddyDemon started hosting an NA Veloren server which you can join at 24.36.42.4</code>. @Silentium got their armor branch merged. Persistence saw some quick improvements in anticipation for the launch, including saving the level of players. @YuriMomo and the team working on WGPU found a memory leak in the crate, and created an issue that you can check out here</a>. Your browser does not support the audio element. </audio> Game On! by @sharpie </figcaption> </figure> Big Boy by @Gemu </figcaption> </figure> 0.6 Release</h2> </iframe> </div> </figure> Another few months, another Veloren release! The launch server was run on Digital Ocean. Below you'll find lots of telemetry from the launch party. The changelog is quite long, but this is the place for recognition of the efforts made to Veloren, so here it is verbatim! ## [0.6.0] - 2020-05-16 ### Added - Added music system - Added zoomable and rotatable minimap - Added rotating orientation marker to main-map - Added daily Mac builds - Allow spawning individual pet species, not just generic body kinds - Configurable fonts - Configurable keybindings from the Controls menu - Translation status tracking - Added gamma setting - Added new orc hairstyles - Added SFX for wielding/unwielding weapons - Fixed NPCs attacking the player forever after killing them - Added SFX for collecting, dropping and using inventory items - New attack animation - Weapon control system - Game pauses when in single player and pause menu - Added authentication system (to play on the official server register on https://account.veloren.net) - Added gamepad/controller support - Added player feedback when attempting to pickup an item with a full inventory - Added free look - Added Italian translation - Added Portuguese translation - Added Turkish translation - Complete rewrite of the combat system into a state machine - Abilities like Dash and Triplestrike - Armor can now be equipped as items - Fireball explosions - Inventory supports stacking - Many new armors and weapons to find in chests - Fleshed out "attack" animation into alpha, beta and spin type attacks - Fleshed out range attack into charging and shooting animations for staff/bow - Customized attack animation for hammers and axes - Added German translation - Added a silhouette for players when they are occluded - Added transparency to the player when zooming in - Made armor and hotbar slots actually function - Added dragging and right-click to use functionality to inventory, armor & hotbar slots - Added capes, lanterns, tabards, rings, helmets & necklaces as equippable armor - 6 new music tracks - Added basic world and civilization simulation - Added overhauled towns - Added fields, crops and scarecrows - Added paths - Added bridges - Added procedural house generation - Added lampposts - Added NPCs that spawn in towns - Added simple dungeons - Added sub-voxel noise effect - Added waypoints next to dungeons - Made players spawn in towns - Added non-uniform block heights - Added `/sudo` command - Added a Level of Detail (LoD) system for terrain sprites and entities - Added owl, hyena, parrot, cockatrice, red dragon NPCs - Added dungeon entrances - Villagers tools and clothing - Cultists clothing - You can start the game by pressing "enter" from the character selection menu - Added server-side character saving - Player now starts with a lantern. Equipping/unequipping a lantern has the same effect as the `/lantern` command - Added tab completion in chat for player names and chat commands - Added server persistence for character stats - Added a popup when setting your character's waypoint - Added dungeon arenas - Added dungeon bosses and rare boss loot - Added 2 sets of armour. One Steel and one Leather. ### Changed - The /give_item command can now specify the amount of items. Syntax is now `/give_item <name> [num]` - Brighter / higher contrast main-map - Removed highlighting of non-collectible sprites - Fixed /give_exp ignoring player argument - Extend run sfx to small animals to prevent sneak attacks by geese. - Decreased clientside latency of ServerEvent mediated effects (e.g. projectiles, inventory operations, etc) - Started changing the visual theme of the UI - Merge of the Bag and Character-Screen - Merge of the Map and Questlog - Overhauled icon art - Asset cleanup to lower client-size - Rewrote the humanoid skeleton to be more ideal for attack animations - Arrows can no longer hurt their owners - Increased overall character scale - `/sudo player /tp` is short for `/sudo player /tp me` - The `/object` command can create any object in comp::object::Body - The `/help` command takes an optional argument. `/help /sudo` will show you information about only the sudo command. </code></pre> </figure> </figure> We almost hit 50 players for this launch party! </figure> </figure> </figure> </figure> </figure> </figure> </figure> Above we see persistence running on the launch party server. In the week leading up to the launch, we started seeing many issues caused by delay in persistence. Below you can see what the length of the delays was. This was likely caused by the fact that normally our main server run on a unit with a hard drive, whereas the launch party ran on a server with a solid-state drive. The times taken for saving are still quite high, since disk input/output takes significantly longer than accessing either RAM or the CPU Cache. </figure> Network Analysis by @AngelOnFira</h2> After playing with Wireshark during the NorthSec CTF last weekend, I felt inspired to check out what Veloren's network packets look like. I started by playing on the server, and running through a few different scenarios. First, I started by just standing in the spawn village. Then, I started flying over unexplored territory. Finally, I fell into a lake and sank to the bottom. </figure> Initial Server Connection</h3> At first, we have a high burst of data being sent and received while connecting to the server. Upon analysis of the packets in that region of time, we find that many packets are making up a larger message. This message appears to be between 30KB up to around 100KB. Standing in Spawn Village</h3> Here we see two different sections. First, when you load in, you start downloading many chunks of the surrounding area. This sees about 600KB/s of bandwidth use. Once all of the surrounding chunks have been downloaded, the bandwidth goes down to around 300KB/s. There are still packets being sent that update us on all of the entities around us. </figure> Flying Over Unexplored Areas</h3> Similar to the previous chunk downloading, we start asking the server for more areas. We can see that there are some larger and smaller amounts being downloaded. This section stays quite consistent. Sinking in a Lake</h3> Finally, we see a large drop in the data being sent from the server. All of the chunks around us have already been downloaded. Also, there aren't as many entities around us as in the village, and so we don't get as many updates. Here we are only seeing around 60KB/s of incoming data. Recived data rate from server </figcaption> </figure> In the coming weeks, I hope to get more into the code behind networking in Veloren. I'm also going to be exploring how we handle authentication, which might include another writeup on some of it's concepts. The new banner for our GitLab repo. See you next week! </figcaption> </figure> This Week In Veloren 67 Mon, 11 May 2020 00:00:00 +0000 0.6, the content update, is slated to be released this week! Join us for the release party at 18:00 GMT on Saturday the 16th. This week, we hear from @Sharp about the move to WGPU. This Month in Rust GameDev has a new edition for the month of April. In other news, here be dragons. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Songtronix, @imbris, @CapsizeGlimmer, @AngelOnFira, @Slipped, @YuriMomo, @Snowram, and @Shandley! Your browser does not support the audio element. </audio> A new boss battle piece by @sharpie </figcaption> </figure> Lots of bug fixes this week as we approach the 0.6 launch this Saturday! @ProTheory8 found a bug was found where rapidly changing items in the eq slot would crash the server. @imbris is working on a fix. This Month in Rust GameDev #9</a> has been released for the month of April. New dragon mob by @Gemu, implemented by @Snowram and @Slipped </figcaption> </figure> Persistence has finally been merged! Although @Shandley built the final implementation, this has been an ongoing effort by many developers. The current level of persistence only allows a character's looks to be stored on the server. The plan is to expand this out to a character's level, position, and stats before 0.6 is released. 'Programming' is simply the act of adding bugs to an empty text file, don't fear. - @zesterer </blockquote> By @Zukel </figcaption> </figure> Move to WGPU by @Sharp</h2> Concretely, the move to WGPU, at least in the long run, lets us do two things: Access newer graphics card features on cards that support them (where "newer" means anything added since OpenGL 3.2, which came out literally in 2008) without giving up cross-platform compatibility.</li> Exert far more control over the way we interact with the GPU than was possible with OpenGL, opening up previously impossible performance optimizations without sacrificing safety.</li> </ol> The mechanism allowing for both of these changes is that we target the (in-progress) WebGPU API. The API is being designed to provide a target for browser applications that want to interact with the GPU. Unlike APIs like DirectX or Metal, which are explicitly intended to be proprietary, WGPU is designed to be cross-platform. Vulkan, on the other hand, tries to be a universal standard capable of representing all possible interactions with all existing graphics cards. It aims to provide a common interface between all the new APIs; unlike OpenGL, it is aimed at modern graphics cards. Unlike all of these APIs, WGPU is not intended as a "final" target language implemented by the GPU vendor, but instead treats low-level APIs like Vulkan, Metal, or DirectX as compilation targets. This gives it some independence from vendors changing or abandoning their implementations (like Apple did with OpenGL). The mechanism for all this is the gfx-rs project. It both implements a low-level Rust API over all the backends I mentioned, and provides a safe Rust implementation of the WebGPU API on top of each one. WGPU is a unified interface to all these backends that automatically selects the best native target. By @Gemu </figcaption> </figure> In practice this whole vision is not yet reality: There are older machines that don't expose a more modern backend, but still support OpenGL. Thus, an OpenGL target is needed (this is in progress).</li> Since it's still relatively early, there are still a fair number of bugs in the WGPU implementations--safety, performance, etc. But with how high quality the old gfx-rs is, I have little doubt these will be ironed out.</li> There are features of OpenGL, or the target languages, that aren't yet exposed but could be very beneficial to performance. As time goes on and the WebGPU standard develops, I expect a lot of these concerns to lessen over time, but apparently there is a way to write native plugins for the time being if you don't care about the web.</li> One very important part of this vision is missing; how to handle shaders. Currently, WGPU does not have its own, working shader compiler that can translate from SPIR-V to the relevant backend languages, or from a language like HLSL or GLSL to SPIR-V. Instead, WGPU relies on a C++ library called spirv-cross that (in our experience) is much more difficult to integrate into a typical Rust workflow, both in terms of compiling it and developing against it (e.g. it's much harder to deal with a bug in it than a bug in a Rust dependency). Work is ongoing on addressing this in the naga repository, which @Capucho is apparently helping work on!</li> A related problem is that (AFAIK) there is no standard intermediate language that's been chosen for shaders (I think SPIR-V is just a convenience thing). This doesn't affect us that much though.</li> </ul> Despite these concerns, it's already very promising and I am really happy we were able to get Veloren working using its API, even if it's only a proof of concept! By @AlbinoAxolotl </figcaption> </figure> WGPU's current approach leverages the borrow checker to provide a Rust API that can be significantly more efficient without sacrificing safety, at the cost of being significantly harder to use (a tradeoff we're happy to make). However, just because you rewrite code to use the new API doesn't automatically make it faster. Mostly, it does make all the steps that are costly more explicit, which makes it a lot easier to design for performance, but there are also some quirks of the API itself that may make it harder to do this. I think the API (both Rust side and interface side) will probably continue to evolve to hit the right balance of safety and performance. It also seems possible to me that WGPU alone will not be a high level enough target in some languages to use sanely (for instance, it seems very hard to use safely in a language like C++). Scale of the new cyclops. See you next week! </figcaption> </figure> This Week In Veloren 66 Mon, 04 May 2020 00:00:00 +0000 This week, new lantern functionality was added. We've seen some new progress on the wgpu front, with some of the game being rendered. There is also new audio progress with some SFX and a new track. - TWiV Editors: Slipped and AngelOnFira Contributor Work</h2> Thanks to this week's contributors, @Zesterer, @Julian, @Pfau, @CapsizeGlimmer, @Songtronix, @Silentium, @Capucho, and @ProTheory8! @CapsizeGlimmer added functionality to the lanterns in the game. @Pfau has been cleaning up NPC behavior, and adding assets. @Juli199696 has been working on new SFX, including new item pickup, and wield sounds. @Silentium has been working on a huge increase in the number of weapons in the game. @Capucho and @Sharp continue to progress the wgpu branch. Currently, the main menu and character selection work. The game itself can be rendered, but there is a lot of work to go. Dragon model by @Gemu </figcaption> </figure> Lantern Functionality from @CapsizeGlimmer</h2> A few weeks ago lanterns were merged into the game. However, they were simply items to be equipped and carried around. Having real light in dungeons and at nighttime still relies on the /lantern command. That changed this week with @CapsizeGlimmer's MR which not only makes lanterns functional, binding them to a key, but also adds colors to lanterns and light flickering animations! A blue lantern at night </figcaption> </figure> In addition to lantern flickers, the waypoint bonfires will now do the same. The atmosphere of Veloren at night is starting to really come together. Audio Work from @Juli199696 and @badbbad</h2> @badbbad has gone to work this week on a new audio track for the game. Titled Highlands of the Hawk, it's seen as a wasteland type tune, meant for an orc village type environment. Give the WIP track a listen here</a>! The next big task for audio is going to be battle themes. This includes trying to devise a way for the music to be able to shift naturally into a faster paced and more intense style of music when combat starts, without feeling disjointed. One solution is to create music with multiple layers, and having those layers fade in and out depending on the player's situation. Adaptive music is challenging, but @badbbad is looking to experiment with it soon. @Juli199696 tweaked some of the sound effects in the game this week, moving away from more realistic metallic weapon sound effects for wielding into something a little more fitting to the overall style of the game. Pickup and drop sounds have also been tweaked. Enemy progress from Albino Axolotl </figcaption> </figure> Progress from the wgpu branch! Now playable, somewhat! </figcaption> </figure> This Week In Veloren 65 Thu, 30 Apr 2020 00:00:00 +0000 This week, work has been done on Airshipper and wgpu. @AngelOnFira gives us a look at external work on Tarpaulin. We also hear from @Sharp on the progress of LoD, as well as from @zesterer about work on sprite and entity LoD. - TWiV Editors: Songtronix, Slipped, and AngelOnFira Contributor Work</h2> Thanks to this week's contributors, @Zesterer, @Pfau, @Slipped, @CapsizeGlimmer, @Songtronix, @xMAC94x, and @Treeco! @Zesterer has been hard at work with projectile collision fixes, as well as a new level of detail system for entities and terrain sprites. @Capucho has been trudging through lots of work to get wgpu working for different systems in Veloren. They are currently working on the main menu UI, as well as the character menu. @Songtronix is working through many improvements to Airshipper. The next version will offer macOS builds, as well as stable versions of Veloren rather than just nightly. Game design met to discuss the schools of magic, possibility of spell crafting, "endless" sky islands and caves for exploration, as well as touch on the goals for the Points of Interest. They also decided to address equipment and crafting during the next meeting. Tarpaulin and toolchains by @AngelOnFira</h2> Tarpaulin has broken recently on our continuous integration (CI) pipeline. Tarpaulin is used to keep track of "code coverage" on the project. When we run tests, we want to make sure it touches as close to 100% of the code if possible. That way there isn't code that is completely ignored. In practice, we really don't have that much code coverage, but that's not the problem here. Tarpaulin breaking is! Diagnosing this problem took some work. Although I love working with CI, my Rust skills aren't amazing. And this problem was starting to look more like a Rust one. Luckily, I was able to follow a trail of breadcrumbs through areas that I would normally get stuck. In our CI, we were getting this error while running Tarpaulin: [INFO tarpaulin] Creating config [INFO tarpaulin] Running Tarpaulin [INFO tarpaulin] Building project error: toolchain 'nightly-x86_64-unknown-linux-gnu' is not installed Error: "Failed to report coverage! Error: No coverage results collected." </code></pre> With my limited knowledge of how Rust toolchains work, I set off to learn more about them. I knew our CI had a version of nightly installed, so I first tried to lock down exactly which version. We use the rust-toolchain</code> version to specify a date of nightly that we want. Since the toolchain would be the same on my local version of Veloren, I could just run rustup toolchain list</code> to see the exact version. nightly-2020-04-17-x86_64-unknown-linux-gnu</code> Interesting, it appears that Tarpaulin is ignoring the date. I did some research</a> to find out more about the Rust toolchain specification. Next up was to figure out how Tarpaulin gets the toolchain name. After cloning the Tarpaulin repo, I didn't really know where to look. I searched for "toolchain", "is not installed", and "nightly". I didn't really know what I was looking at, but I stumbled across this function: fn create_command(manifest_path: &str, config: &Config, ty: &RunType) -> Command { let mut test_cmd = Command::new("cargo"); if ty == RunType::Doctests { test_cmd.args(&["+nightly", "test"]); } else { if let Ok(toolchain) = env::var("RUSTUP_TOOLCHAIN") { if toolchain.starts_with("nightly") { test_cmd.arg("+nightly"); } else if toolchain.starts_with("beta") { test_cmd.arg("+beta"); } } ... } } </code></pre> There was some stuff in here that looked sort of useful, but it wasn't until I came back to it a few times that I started playing with it. I had to learn how to install a cargo command from a local path, which wasn't too bad: cargo install --path <path></code>. Then I could debug nice and quickly! I added an info message that would print the toolchain it was getting from the env variable, and low and behold, it was what we wanted! Next, I changed test_cmd.arg("+nightly");</code> to be test_cmd.arg("+nightly-2020-04-17-x86_64-unknown-linux-gnu");</code>. Running this fixed the original problem, and the right toolchain was being used. Great success! Now that I had a fix, it's time to get it into Tarpaulin. I swapped out some code to just use the env variable if it was available. if let Ok(toolchain) = env::var("RUSTUP_TOOLCHAIN") { test_cmd.arg(format!("+{}", toolchain)); } </code></pre> As far as I know, this solution should work any case. I'm waiting on it to get merged, but we should be able to patch our CI manually in the meantime. This wasn't that complicated of a problem, but I learned a lot on the way! Snowram merged in some new animals this week, the ram, snowy owl, hyena and parrot! </figcaption> </figure> LOD and lighting progress from @Sharp</h2> A view of the distance horizon utilizing the level of detail system </figcaption> </figure> The LOD branch has been progressing nicely over the last few weeks. One of the factors increasing the workload involved in it is that an overhaul of the lighting system is being performed with the LOD additions, as the two complement each other well. Proper time-dependent lighting has been implemented, providing a more physically realistic interpretation for the sun's effect on the terrain. Better atmospheric scattering along with point-light dependent HDR is also being worked on to improve the overall look and feel of the lighting throughout the game. After replacing magic constants with derived quantities, most of the current focus is on tweaks to the implementation to work out the exact look we want. Morning time under a rewritten sun </figcaption> </figure> Another portion of the LOD work was geared towards making the low detail terrain feel more natural. Most of the work there involved manipulating the shaders to create a look with more shadow and texture, with the goal of both improving the aesthetic of the far terrain and blending the LOD better with the nearby voxels. The work is very experimental but promising so far. Before </figcaption> </figure> After </figcaption> </figure> </figure> Finally, the last LOD branch focus this week was on underwater visuals, where Sharp is also implementing a realistic approach. The new handling of lighting provides a very atmospheric environment in the oceans and lakes. One of the main ideas is to filter out wavelengths on the red end of the spectrum faster than green and blue wavelengths, much like in reality. We have a lot of ideas for ocean gameplay and discovery later, so getting this right is important. test </figcaption> </figure> Treating one block as one meter, reds and browns will quickly fade, and while that might sound like dulling the terrain, the results are quite colorful. An underwater dungeon entrance </figcaption> </figure> </figure> </figure> Sprite LOD from @zesterer</h2> This week zesterer added a sprite and figure LOD system, while Pfau built it into the UI to make it configurable in the settings. Working independently from the terrain LOD, this is an important follow-up to the towns addition, because it makes the farms much easier to handle, especially on weaker machines. a low detail dwarf! </figcaption> </figure> The system applies downsampling to the models we use for sprites and mobs in the world. The number of voxels we have on the screen (specifically voxel faces) all impact how the game is able to perform, and since we can't notice small detail from far away, it makes sense to simplify the visuals at distance. Several levels of LOD now exist in the game, providing just the right detail at incremental distances to aid your performance while maintaining a believable impression of the assets. </figure> Flatpak</h2> As a little side note Veloren will now be packaged as a Flatpak</a> which can be installed with flatpak install flathub net.veloren.veloren</code> to support multiple Linux distributions. Please note that due to our frequency of updates the package might occasionally be outdated. We do our best to ensure the best experience for you all! It already gets downloaded! </figcaption> </figure> Villager work from @Pfau</h2> Pfau is working towards making the villagers much more interesting by the next update by giving them some personality through clothing and tools. With farms being the defining element of the towns thus far, some farm equipment felt right. A villager in overalls with a rake </figcaption> </figure> Although the villagers won't have complex activities yet, giving them the appropriate equipment has helped the towns feel much more cohesive and real already. In the works are rakes, shovels, brooms, pickaxes, fishing poles and more for them to carry around. A wise village elder. See you next week! </figcaption> </figure> This Week In Veloren 64 Wed, 22 Apr 2020 00:00:00 +0000 This week we take a look at the work put in on dungeons, the details added to towns and progress with wgpu, Iced and persistence - Slipped, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @zesterer, @Pfau, @Songtronix, @Imbris, @Capucho, @CapsizeGlimmer, @xMAC94x, and @Shandley! This week the grind to 0.6 release continues. @zesterer has put a lot more work into the civsim branch. Basically Veloren 2, in addition to towns the branch now contains multi-level dungeons with optional paths, loot, bosses and ranged enemies with new AI. We also have seen progress from @Shandley to add character persistence to the game, along with huge steps forward from @Imbris and @Capucho to integrate iced</a> and wgpu</a>! Towns and Dungeons</h2> Paths have seen a major step forward this week. In earlier blogs we've shown off the map of paths around the world that civilizations use to trade between each other and help themselves develop. While world simulation is still largely an invisible background process, the paths created by the formed civilizations are now able to be seen! You can find these paths anywhere around the world and use them to trace back to multiple towns. </figure> The roads are also pretty smart in how they work. Following them you'll notice that they take you through the easiest paths between mountains, or go around them completely. They like following rivers. They'll bridge over water when they need to, and when they enter a town you can stay on them to explore the whole town itself! They also have streetlights. </figure> </iframe> </div> A look at the new paths and procedural towns </figcaption> </figure> </figure> Dungeons are new and already pretty complex. They have around six floors and are fully procedural with an increasing difficulty as you descend. Each one is a unique experience with a main path that you can follow to the bottom along with offshoot rooms. The new AI provides some challenges and strategy, with enemies now working with line of sight detection. Dungeons are a ton of fun so far, especially with a group. Future plans include traps, platforming, puzzles and much more! One of the big visual changes is the new block shader, giving a 3x3 noisy texture to blocks in the world The new block shaders </figcaption> </figure> The shaders help bridge the gap between small and large voxels in fields </figcaption> </figure> </figure> wgpu with @Capucho</h2> wgpu is a graphical backend that we've been eyeing for a long time, looking forward to a conversion to it as it provides access to APIs like Vulkan, DirectX and Metal. Now, I barely know anything about wgpu but I do know that converting to wgpu is very advantageous for Veloren and also a super hard task to do. I've built a compilation showcasing Capucho's heroic struggle, which started to yield visible results this week! Since wGPU is an API that covers more ground and is vastly more capable than our exist gfx pre-ll based API, moving everything to the new API is proving to be a struggle. We'll get there though. It's been a trip </figcaption> </figure> Other work</h2> Shandley has been working a ton on persistence this week. This is one of the main features we're targeting before 0.6 release as character saving is going to be a huge complement to some other recent features like changes to inventory, combat and the loot found in the world. More on that next week! The same main menu, but in Iced! The conversion to the new GUI library has progressed nicely so far, text is next. </figcaption> </figure> New music has been completed and heading into master this week from @badbbad! 6 new tracks will nearly double the game's playlist. All of them probably land on our SoundCloud: https://soundcloud.com/velorenofficial</a> Sharp continuing work on the LOD branch </figcaption> </figure> Chilling with the flax. See you next week! </figcaption> </figure> This Week In Veloren 63 Wed, 15 Apr 2020 00:00:00 +0000 @Imbris made the inventory slots more functional with drag & drop support, functional armor/hotbar slots and @Zesterer has been working on procedural town generation. - Songtronix, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Capucho, @Carbonhell, @Imbris, @Zesterer, @Slipped, @xMac94x, @Olexorus, @Pfauenauge, @Songtronix and @Treeco! Inventory & Hotbar</h2> As promised in the last blog post, @Imbris made the inventory slots fully functional which means this isn't just a dream anymore (note the use of the hotbar!): It's free real estate! Play singleplayer and enter in the chat: /debug </figcaption> </figure> 0.6 Meeting</h2> In the meeting we refined our goal for the 0.6 release and agreed upon that we have one important goal: persistence. Many players join the server just to find out that all their progress will be lost when they leave the server. We want to solve this but we cannot guarantee that throughout the development progress things get lost. However a simple server restart or logging back into the server shouldn't reset your items. This will be our most important goal and if needed will delay the release. Worldgen</h2> @Zesterer has been hard at work to improve towns! </iframe> </div> Take a look at the new procedural towns! (WIP) </figcaption> </figure> Words cannot describe the beauty of creating towns</a> with pure code therefore take a look at these screenshots (keep in mind that many things are still in flux and might change before being made available in our nightly release): </figure> </figure> </figure> </figure> </figure> </figure> </figure> </figure> See you next week! </figcaption> </figure> This Week In Veloren 62 Mon, 06 Apr 2020 00:00:00 +0000 @Carbonhell made it possible to change your key bindings in-game and @Pfau with the help of @Imbris are working on improving the inventory with working armor slots while @Capucho gives us a look into how to make yourself transparent. - Songtronix, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Imbris, @Pfau, @Songtronix, @Capucho, @AngelOnFira, @Zesterer, @Qutrin, @Shandley, and @yusdacra! Capucho</h2> </figure> Recently, I implemented player transparency. As you can see above, this allows the player to become transparent when you zoom in far enough. When first developing this feature it was more of some toying around. I created a simple shader that would display a dark silhouette when the player was beyond things. It works by rendering after everything else. It would pass the depth test and then the player was rendered. This way if the player wasn’t occluded by a tree or something, it could render over the player. Otherwise the silhouette would be shown. I posted a screenshot and called it a day. Next day I go check out the discord and there was a lot of positive responses, so I thought to myself that adding some sort of transparency effect when zooming would be cool, so I disable the shadow effect and modified the player shader to reduce the opacity when zooming in. Then I tried to put everything together but when you zoomed the shadow appeared because the player now was also rendering things that were behind him, so I was searching for something to make it work and found about stencil buffers. Stencil buffers are like a Depth Buffer but the developer has full control over it, so I made that when the player was rendered the buffer would write a 1 and the shader only rendered if there was a 0 and then I tried to run and it crashed right after startup, it wasn’t supposed to have happened and it took me 2 days to figure it out. The OpenGL spec says that a depth buffer and a stencil buffer can exist separated, but it turns out almost no graphic cards manufacturers implement it so I joined them together and it worked, I shared my work, it was merged and I went to sleep. </figure> Next day I get a message, Slipped had turned Jesus, this was caused by the circular dependency in the depth buffer, the player was transparent and the water too but the player was drawn last onto the screen so it seemed like it was hovering over water. It was no easy fix because if you changed the order the player would have x-ray vision on the water when it became transparent. Slipped had turned Jesus </figcaption> </figure> To solve this Imbris suggested dithering. Dithering simply discarded pixels on a pattern and there was no circular dependency because there was nothing to be rendered and It also gave a nice transparency effect with some sort of film grain applied on top. A number of small changes were also made, the shadow also got dithered, the position was taken from the player location and not from the fragment which made it more uniform and this was made the final version of the effect. </figure> Language, Combat and Armor</h2> Veloren is now available in Italian, Portuguese, Turkish and German! Thanks to the recent merge of Combat, we now have far better fighting experience than before. Try it out! Another great addition is Armor: inventory support for Armor will follow shortly but it's already equippable and can be found in chests! </figcaption> </figure> Are you worthy to wear it? </figcaption> </figure> In need for some calming tunes? Checkout our SoundCloud</a> and tune your controls: How to make a good game: Make Controls adjustable. Thank you @Carbonhell! </figcaption> </figure> Exclusive cape just for $9999.99. See you next week! </figcaption> </figure> This Week In Veloren 61 Mon, 30 Mar 2020 00:00:00 +0000 This week, @Zesterer gives us an in-depth look into the mentality behind the design, development, and goals of worldsim. @xMAC94x gives us another look into the new networking prototype. Lots of progress was made in combat as well. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Capucho, @Songtronix, @Imbris, @Zesterer, @AngelOnFira, @jackrubino, @Slipped, and @Shandley! This week, @Zesterer has been putting a lot of work into worldsim. This includes sites, settlements, trade routes, and basic economic simulation. @Capucho finished free look and some other fixes. @yusdacra is working on a Turkish translation. @Juli199696 is working on a test server as well as finding bugs. @Timo has quite a list this week. He worked on many bugs from the combat branch. He's done lots of playtesting and has worked on issues that have come up. Some fixes include attacking animations, better combat movement, and glider physics. @Pfau has been working on adding new armour and weapons. He has also worked on improving some icons, as well as a new map background. Animation work by @Slipped </figcaption> </figure> World Simulation Process by @Zesterer</h2> One of the goals of Veloren is to have interesting and complex world simulation. We don't have any illusions of grandeur - world simulation on the same level of Dwarf Fortress is unlikely - but we do want to create a world that fulfills the following criteria: 1. It encourages the player to ask questions when encountering new things by providing answers to those questions</h3> World simulation should be internally consistent and driven by cause and effect. When a player encounters a peculiar feature of the world, deciding to investigate further should warrant actual answers rather than "because it just is like this". This means placing aspects of the world in a historical context such that the ripples of past events can be explored by the player. If the player comes across ruins, they should have a name and an event in history that led to their abandonment. What happened at this place? Why did it happen? How has this had an impact on the surrounding settlements? All of these questions should have answers that can be discovered by interacting with NPCs or observing aspects of the world. Mustache work by @AlbinoAxolotl </figcaption> </figure> 2. It provides unexpected and unique situations</h3> Existing procedural games tend to suffer from two key problems. The first, a lack of depth, I have already mentioned. When there exists no depth to features of an environment it becomes meaningless to investigate them. Players don't feel like they have a stake in the world around them and don't bother trying to satisfy their curiosity. They become conditioned to accept that things 'just are' without question. The second problem is homogeneity. Random variations in existing content do not lead to meaningful gameplay and players quickly become accustomed to the scope of the variation that the game permits. By combining elements of variation in a way that interact with one another, it's possible to create an environment that throws up a far greater number of combinations of mechanics than would otherwise be possible. 3. It is dynamic and reacts to decisions made by the player in a way that feels meaningful</h3> Many procedural games suffer from either a lack of interactivity (No Man's Sky) or a lack of interactivity that produces a meaningful effect on the world (Minecraft). Players want to explore a world where their actions have far-reaching ramifications. To do this, the game world must be complex and interconnected such that those effects may propagate through the world in interesting and unexpected ways. Changing the world should change the behaviour of agents within the game world. Too often we see wooden-headed NPCs that blissfully ignore the player's actions in games. We will do our best to avoid this. </figure> How do we achieve all this? Sadly, there is no silver bullet. Procedural systems are difficult to get right, but I've come up with a few basic principles that I've found to be useful. First, to create content, don't create more variations of existing content. Instead, create new ways in which existing may interact. Minecraft often provides good examples of this: the addition of a single extra block to the game often has a multiplicative effect where players find thousands of ways in which it may interact with existing mechanics to create new things. Next, randomization is not good procedural generation. In fact, the very opposite: games such as No Man's Sky suffer badly from this misnomer and it created environments without depth or meaning. Instead, variation should be a product of the interaction of a small number of existing elements. Just take a look at how Conway's Game of Life produces incredible emergent behaviour from an absurdly simple set of rules. Players should be able to reason about the circumstances that led up to a particular situation and use that information to change the way they play in the future. If your game is informed by randomization, there is no common thread that players can use to reason about the game. Instead, they become a 'back-seat driver', beholden to the disorganized chaos of the random rules you've created. Finally, create 'meta' rules. Games that stick to a strict set of rules tend to be rather dull. Instead of trying to spice things up by making the rules more complex (which just leads to confusion and frustration for players), it's better instead to come up with consistent rules about when other rules might change. You can build up a hierarchy of rules that is both simple to understand but permits a vast amount of variation. </figure> With this in mind, I've begun work on simulating civilizations in Veloren. I've not got a huge amount to show yet, but I envisage something that looks like this: A world full of 'sites': these are places of interest in the world that may take on particular characteristics. Examples include villages, towns, ruins, farms, hideouts, towers, caves, dungeons, or magical places. The world simulation code will be aware of these sites and will influence them throughout the course of world generation and gameplay. Sites may get invaded, develop an economy, play host to various creatures, or otherwise play a part in the world's story-telling. </li> A dynamic simulated economy where prices are determined by regional supply and demand. This feature will permit a lot of gameplay, allowing players to become merchants and trade goods across the world. The economy should react to various economic stimuli, with prices rising and falling according to the availability of goods. If a dragon decides to lay siege to a town, demand for weapons should spike! </li> Simulation of social and material conditions: Ethnic and political groups within the world should interact with one another. Wars, battles, uprisings, plagues, and famines should occur and inform the behaviour of groups within the world. </li> </ul> Simulating population growth, yellow being the highest population, black being the least </figcaption> </figure> To facilitate these things, I've made the decision to split world generation into 4 distinct stages, each of them adding more 'colour' to the world: World generation. We already have this stage: it takes place over the course of millennia simulating erosion, river formation, ecology, etc. </li> Antiquity. This stage will involve the founding of civilizations and the simulation of basic economic relationships between them. This stage will take place over thousands of years. </li> History. In this stage, we'll be creating and simulating actual characters in the world. Legends and myths will be created, significant figures will live and die, wars and battles will occur between settlements and civilization. Diplomacy will be simulated too. This stage will take place over a number of generations and probably a few hundred years. </li> In-game world simulation. This stage will occur throughout the duration of gameplay. It will be an extension of the third stage, with small details added that players can interact with. Characters will persist and can be interacted with by players, changing their behaviour accordingly. Diplomacy will include events triggered by players and will permit a certain level of player interaction. </li> </ol> </figure> These stages will be run one after the other for each world. In theory, the results of each stage should be layered on top of one another in a manner that produces a rich, interesting world with a meaningful history. Of course, all of this is going to take a lot of time to develop. Do not expect this content to suddenly appear in the next update: however, I do want to get a basic skeleton of this architecture working for 0.6 such that it can be fleshed out in subsequent updates. Networking with @xMAC94x</h2> Networking is currently in a transit stage between the implementation I had</a>, and a newer async-std based variant. I noticed the implementation had a few difficulties, which are not trivial and didn't come up in the beginning. My initial plan was to have multiple worker-threads. Each worker thread could get multiple channels, like TCP or UDP, and handle their requests simultaneously. This would allow a single participant to have an opened TCP and UDP connection and both are handled by different threads. </figure> This requires a lot of locking and careful synchronising. Also, the old coding had some limitations. A packet could only ever be sent over a single channel, TCP or UDP. But mixed mode, like HEADERS via TCP, or UDP for Data (which isn't that big of a deal). But prioritisation of outgoing messages was only possible inside a single worker thread which could use up all the network capacities. Additionally, these workers would need to be balanced if one has a high load while one a low load. Those all are not simple tasks, which lead me to the idea of a redesign. Instead of multiple worker threads, we could use a single thread and then use async_std. This has the potential of stopping the synchronisation problems as I include everything in the state machine of async. For example, the code that handles TCP gets reduced to a small amount, as most of it was manually building a state machine that async already provides. Unfortunately, I don't have any numbers yet to compare those both approaches yet, nor is the new one really usable yet. Making big friends. See you next week! </figcaption> </figure> This Week In Veloren 60 Mon, 23 Mar 2020 00:00:00 +0000 This week we check in with @Sharp about some improvements to the map. Many contributors have been putting good work into combat, and there is progress to show! @Timo does a design analysis article on Zelda: BoTW. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Acrimon, @Songtronix, and @Capucho! @Adam, @Slipped, @Pfau, and @Timo have been working a lot on combat. This work has lead @Slipped to compile "8,000 times", while @Timo was never able to compile in time before someone else pushed a new commit to the branch. Here are some items that they covered: - Abilities like dash and triple strike - More work on the new inventory by @Pfau - Inventory supports stacking - Armor as items - Many bug fixes - Fireball explosions - Animations for hammer attacks, axe attacks, sword spins, arrow firing, and spell casting </code></pre> Explosions in action! </figcaption> </figure> @Comfy has worked on exporting most of the models used in the game. Many were saved instead of exported, so this will cut down on file size. @Capucho is working on implementing free look. Analyzing the Map of Zelda: BoTW by @Timo</h2> As part of game design, @Timo has written an article</a> on the map in Zelda: BoTW. This analysis is a good way to get inspiration and ideas for things we could make use of in Veloren. Here is a short excerpt of this article: Maybe you've heard of the 40 second rule of open world games. It says that there has to be something that catches the players attention every 40s on average. Luke Stephens did an excellent video on this, where he tries to find out how well the 40s rule applied in a variety of open world games. This article is meant to expand on the idea to find out how open world games manage coming up with so many interesting ideas. </blockquote> </figure> Map improvements by @Sharp</h2> This is only a small update for maps, but worth mentioning. We switched from shadow maps to horizon mapping. This means we can store just two angles per chunk to get proper lighting across the sun's whole arc (ideally I'd like to keep this to 1 byte each), plus two bytes of "occluder height" to give us an approximation we can use for soft shadows. </figure> This theoretically uses considerably more space per chunk than the implementation of binary, sharp shadow maps for height fields as described in the other paper. However, sharp shadows usually require much finer granularity (possibly column level rather than chunk level) to look decent, which we probably don't want. Since our characters can also be in the air, I also wanted to make sure we could come up with some plausible estimate for the height where a chunk stops being in shadow, which requires the extra height data anyway. Item stacks and new visuals. See you next week! </figcaption> </figure> This Week In Veloren 59 Mon, 16 Mar 2020 00:00:00 +0000 This week, we see some work that is being done on the UI. We hear from @imbris about their work on winit, as well as server events. @Timo has been working on quite a few smaller issues. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @xMAC94x, @Songtronix, @Acrimon, @Imbris, and @Shandley! @Timo has been working on quite a lot. He added a loadout struct to store weapons and their selected abilities. In combat, @Timo added a slight bouncing animation in first-person mode, added a shield item, and added a sword dash attack ability. He also fixed bugs for most weapon types, such as bows and boost. Finally, he improved character creation so the chest armor slider adjusts to available assets dynamically. @Songtronix has ongoing work to improve the book. @Cedric is working on an external programming language called WLambda</a>. @Octo, @Pfau, and @Slipped have been working on some upcoming UI changes. Work of @imbris</h2> Status of the winit Update Branch</h3> Previously, the issue blocking updating to the latest winit branch was mouse movement input lag occurring on macOS. To dig deeper into what was going on I created an example program to print out when events were being received from winit (see this</a>). With testing by @Shandley we saw an output that looked like this: Generating mouse event: (8.000, 0.000) Generating mouse event: (19.000, -5.000) [DeviceEvent::MouseMotion(8.000, 0.000)] @ 0.193 us, 342.641 us after winit created [DeviceEvent::MouseMotion(19.000, -5.000)] @ 41.391 us, 178.440 us after winit created [MainEventCleared] @ 50.862 us [MainEventCleared] @ 34315.527 us Generating mouse event: (42.000, -8.000) Generating mouse event: (83.000, -16.000) [DeviceEvent::MouseMotion(42.000, -8.000)] @ 70504.492 us, 319.739 us after winit created [DeviceEvent::MouseMotion(83.000, -16.000)] @ 70528.703 us, 153.272 us after winit created [MainEventCleared] @ 70541.742 us [MainEventCleared] @ 106441.617 us Generating mouse event: (80.000, -11.000) Generating mouse event: (133.000, -14.000) [DeviceEvent::MouseMotion(80.000, -11.000)] @ 141973.828 us, 366.537 us after winit created [DeviceEvent::MouseMotion(133.000, -14.000)] @ 141990.969 us, 123.327 us after winit created [MainEventCleared] @ 141999.312 us [MainEventCleared] @ 177216.766 us </code></pre> (Note: the "Generating mouse event" lines come from a println!</code> I inserted into the winit codebase). As you can see, there seems to be a bug in the macOS event loop such that mouse events are only generated every other MainEventsCleared</code>. This was an issue because I am using MainEventsCleared</code> as the point where we run update code, render, and sleep to regulate the framerate (this is using ControlFlow::Poll</code>). </figure> So mouse movement events were only received every other frame. Alas, digging around in winit</code>'s macOS code and staring at this code</a>, I could not suss out what was causing the issue (I learned to call a method in Objective C is also referred to as "sending a message"). Nevertheless, I then realized we can just respond to every other MainEventsCleared</code> which seems to mostly work just fine :D (to follow this issue see here</a>). Now, we need to figure out why arrow keys are producing RecievedCharacter</code> events on macOS and what those characters are so that they can be filtered out. Also, there may be some sort of fps degradation over time on macOS that needs to be investigated. Latency improvements for ServerEvent</code> mediated effects</h3> I made some improvements to the latency of ServerEvent</code> mediated effects last week. Notable examples of such effects include inventory manipulations, terrain manipulation, and projectile generation. Essentially, what used to occur is that the ServerEvent</code> handling would be performed after all ECS systems were run each tick on the server. This included server-specific systems that sent sync data to clients. Since syncing was performed before server event handling, clients would not see the effects of that handling until the next server tick. To remedy this I rearranged when sync systems were being run so that they would run at the end of the server's tick. You might notice that shooting a bow is slightly more responsive now. UI Improvements by @Pfau and company</h2> Recently, a small group has been working on some UI changes. This is being done by myself, @Slipped, and @Octo. The aim was to reduce the number of windows in the UI and start introducing a more artistic theme for it. So we decided to merge 4 windows: The character menu and the bag</li> The map and the quest log</li> </ul> In the last two weeks, we worked on the first item. I started by making a concept with our old assets. </figure> This is just the character menu above a slightly stretched bag. So far so good. Then we started cutting bits and pieces off and tried to condense the information. </figure> This... slightly crowded window was the result. We decided to give the stats a whole tab of the menu you can switch to. Some minor changes followed, with the decision to move the gem item into slots inside the armour later. </figure> Next, we added a scrollbar, a currency counter, and an indicator to show how much inventory space is left. We also added tabs you can open to only show certain types of items. </figure> Then, we started to think about a general colour and design theme. We decided on "Runic Blue" </figure> </figure> These changes are making use of the function to be able to colour within the code itself. We created a bunch of greyscale PNG files for this and then coloured them with a palette from the code. We could even let the player choose from some colour themes, or modders can come up with their own palette as well. </figure> This is what we already have running in Veloren. Nothing is final yet, and more work will be done on this front in the near future. See you next week! </figcaption> </figure> This Week In Veloren 58 Mon, 09 Mar 2020 00:00:00 +0000 This past week, many contributors are still working on long term items. Lots of small issues are being worked on as well. We hear about work that @imbris has been doing on external crates. There is also a new edition of This Month in Rust GameDev! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Acrimon, @imbris, @Capucho, @Songtronix, @Slipped, @Shandley, @xMAC94x, and @Snowram! @Capucho has been working hard on many issues. This includes pausing the game in singleplayer when in the menu, as well as storing screenshots and logs in a better location. @Kalculate has been working on addressing mobs that spawn camp. This will need some revision to be compatible with changes that @Zesterer is working on. </figure> @LunarEclipse was working on the final stretch for controller support, and it was just merged! Along with that, @Acrimon got auth merged as well. @Slipped and @Pfau are working on some changes to UI, and hopefully, we can see the progress in the next few weeks. @Timo has added energy gains while attacking enemies. @LunarEclipse and @xMAC94x have been working on CI. With the changes, contributors now need to make sure that their Cargo.lock</code> is up to date. CI will fail if not. There have also been various repairs to runners. This Month in Rust GameDev</a> has just been released for February! This edition was had many different contributors, as you can see in the tracking issue</a>. Keep an eye out for another one next month if you want to lend a hand yourself! The External Work of @imbris</h2> @imbris has been putting in some work on crates that Veloren uses. At the end of January, @imbris contributed some performance improvements to the rodio crate. They optimized how silence is sampled so it doesn't need to be adjusted. This lead to improvements of around 20% to dynamic mixers with silent sources. You can check out that PR here</a> Secondly are contributions to winit. The following is written by @imbris: I have been trying and failing to get the latest winit to work nicely on all platforms. I actually made a one-line fix for a freeze when pressing modifier keys on windows and it was merged</a>. Now that they have fixed the panics on Windows, everything seems to be in order. Everything also works fine on x11. I suspect that Wayland might actually almost work. This is an improvement from where it is at right now. Note; I think there is an env variable Wayland users can set to tell winit to go through x instead, next time users report issues on Wayland this might be useful. Finally, there is MacOS for which the update seems to have introduced lagging of mouse motion events when using ControlFlow::Poll. This is where we are now. On top of the world! See you next week :) </figcaption> </figure> This Week In Veloren 57 Mon, 02 Mar 2020 00:00:00 +0000 This week we hear from @xMAC94x about his work on the new networking protocol. We also have another contributor spotlight, this time with @Songtronix! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Lorage, @xMAC94x, @AngelOnFira, @Artem, @imbris, and @Shandley! @Kalculate is working through the NPC spawn code to fix spawn camping issues. Some of the core developers are working on figuring out a suitable modding language to handle animations. This is being headed up by @Zesterer and @imbris. @xMAC94x worked on automating Docker builds for the game server and Torvus. He is also working on networking systems and benchmarking them. @untouchedhappiness is working on Japanese translations. New mob by @Shimox </figcaption> </figure> New Networking Protocol by @xMAC94x</h2> @xMAC94x has been working on the networking systems for quite some time. Here, he discusses a new communication protocol that he is prototyping. </blockquote> The new networking protocol will add some layers above a simple TCP stream. Right now, I'm focusing on testing this protocol with benchmarks. The most basic TCP benchmark would contain two programs. One, the server, is running and listening on a local port, while the other, the client, connects to it. After the connection is made the client sends a ton of bytes. The server reads the bytes and promptly discards them, as their contents don't matter for the benchmark. You can then measure how much bytes the clients could send in a minute and then calculate the bandwidth throughput. For TCP networking basically two factors are important: The number of bytes per second</li> The number of messages per second. You can either send fewer big or a lot of small messages. Big messages are faster.</li> </ol> When mom says you're a handsome boy </figcaption> </figure> Simple TCP Networking has some disadvantages though, the major two being: It cannot make use of the faster but unreliable UDP. UDP is great for sending data quickly, but it does not provide any guarantees that it will make it to the destination properly.</li> When a big message like a Chunk comes in, all other messages have to wait. This leads to high ping or latency.</li> </ol> That's where Veloren's new network protocol will fit in. It allows an abstraction over multiple Protocols at once: TCP, UDP, and direct mpsc channels. The Networking Layer knows which Ports belong to the same participant (client or server) and can send messages most efficiently. Also, big messages are split up into smaller parts which can be sent with a respective priority. The stack is quite complicated and for the first time during development, I got it in a working state for a minimal example. That means, only 1 client each, only 1 protocol each (TCP) and only a single stream of messages. Before investing time in continuing to add more protocols or more clients I wanted to test the performance. If my way should prove to be inefficient, I can adjust it directly. That's why a benchmark at an early stage sometimes is a reasonable choice. </figure> So what does the benchmark do? It's a program that can be either client or server (depending on the command line arguments). A, the server, will be launched and listen in a sperate thread for messages. B will connect to it and will start sending messages in a separate thread. The first result was; it didn't crash. This means we have an integrated pentest (or how I like to call it, Yuri-Test ;) Every message is a simple ID, which increases, plus 1000 bytes of zeros (just to give it some work). These messages will be encoded and decoded twice, once when sending them. This allows the framework to handle messages like a large collection of bytes. These bytes will then be sent to the networking layer where routing and decisions are done. When the networking layer decides the TCP layer is ready to send, it takes a small part of the messages and brings it to the TCP layer. Here, it gets encoded a second time. The message is sent to the other side. On the other end, the stack is applied backwards. It will get decoded, routed to the client and decoded again. In the end we get around 100.000 messages per second and about 800 Mbit/s. For a single client, both results are more than Veloren will ever need. But they are far from perfect compared to the big players in networking. So there are 2 things to do in the future: Increase those numbers, to more like 500.000 messages/s and multiple Gbit/s</li> Focus on multiple clients, sending and receiving as this will be similar to the workload of a real Veloren server</li> </ol> Contributor Spotlight: Songtronix</h2> Hey everyone, it's @Songtronix! I'm a 20-year-old guy living in Germany. I strive to learn more about what interests me: code, UI/UX/Graphic Design, and music/video production). I started working on Veloren in mid-February 2019. I found it while exploring the Rust community on Reddit/the web. Veloren was linked, and so I checked it out. I'm the developer behind Airshipper, the Veloren launcher! It looked frustrating to explain for the 10th time how to download the latest version of Veloren. As such I've tasked myself to ease these kinds of experiences all around Veloren. I've made a download page which has the latest and greatest version of Veloren. I've made the launcher which currently does its job of automating the updating experience. Written in one of the best languages, Rust, Veloren as an open-source project has opened me up to a lot of opportunities to improve myself. I've learned to work together with people who have different skill sets than me. I've learned to compromise but also bring in my own views and challenge myself to grow beyond my skills. I want to make Veloren a first-class experience, not necessarily in-game but all around it. I want to improve the book, the documentation, and the onboarding process to make your first contribution that much easier ^^ Sunset. See you next week! </figcaption> </figure> This Week In Veloren 56 Mon, 24 Feb 2020 00:00:00 +0000 This week we keep pushing onwards towards The Content Update. Work on server persistence is being done, and we take a look at its progress. Level of detail changes are on their way, and we see some of their screenshots. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Slipped, @Pfau, @Shandley, @AngelOnFira, @imbris, @Juli199696, and @Songtronix! @Songtronix is hard at work on Airshipper. This week, self-updating for Windows was completed, and it also now prunes outdated assets to save disk space. @xMAC94x is working on benchmarks for networking, which should be completed in the next week or so. @Juli199696 is working on a server configuration tool that will help users set up their own servers. </figure> @imbris has taken up the torch on auth this week. They worked on some user-friendliness fixes, such as case sensitivity and hidden password text. @octo and @Snowram have been working on potential theme music, as well as other tracks. @Timo has been working on the character state branch. Now, climbing and rolling require stamina. This is not yet on master. @AngelOnFira, @TheDip, and @Griffin have been putting in lots of work to player persistence. All of them are new contributors to the engine, so a lot of mistakes were made along the way. @Zesterer and @Treeco are continuing work on level of detail. There will be more news on it next week as it becomes more ready to merge. Your browser does not support the audio element. </audio> Celestial Arch by @Snowram. It's their first track for Veloren! </figcaption> </figure> Persistence by @AngelOnFira</h2> Hey everyone! This week, I stepped away from my main meta focus. There was a call for a proof-of-concept (PoC) on server persistence, and I thought I would take the reigns. It was a task without a large scope, and it shouldn't need to touch too much of the codebase. Along the way, I got a lot of help from @TheDip and @Griffin. The goal of this PoC was to create a way for the server to save a player's level when they leave the server. It just needed to be implemented for the server, since singleplayer actually runs a server in the background anyway. There are a few steps to this entire process: Figure out a database to use</li> Set up simple database interaction test</li> Hook up the player stats</li> Optimize method used</li> </ol> Mountains off in the distance. More to come on LoD next week! </figcaption> </figure> 1. Database Options</h3> This step is important to get right. We want to make sure we choose an option that will be sustainable for future development, and scalable where needed. It also needs to be as concealed as possible, and shouldn't require setup for someone running a server. We chose to go with SQLite as the database. SQLite saves the database as a file anywhere you like, and doesn't need to be hosted separately from Veloren. On top of that, it can be bundled into the server executable, and so it is pretty much invisible. We are also using the Diesel library to interact with the SQLite database. This gives us a lot more features, such as migrations and data models. Migrations allow us to add and remove tables in the database over different updates, so that we don't have to wipe the database with each version. Data models give us a separation between our use of the data in-engine and how the database views it. Instead of having to deal with datatypes when we fetch it from the database, Diesel takes care of it for us. </figure> 2. Sample Database Interaction</h3> For this, we just followed the Diesel tutorial. We had to make some notable changes to the default architecture, however. Our persistence module is a child of the server. Diesel expects itself to be on the top level of a crate. We had to set up the migrations and schema directory to be on the same level as the module. 3. Player Stats</h3> This step allowed us to look a bit more into what we would be storing in the database. At first, we just stored the exact exp. After showing this off to others, it was mentioned that we should just store a Stats</code> object in its entirety. This includes everything about a player, such as a name, level, and items. After hooking this up, the PoC was ready. 4. Optimizing</h3> Throughout the implementation, we fell down rabbit holes of trying to optimize too early. This is easy to do, and speculation on this kind of tech can be really fun. But it can get very abstract quite quickly. We were already talking about query optimizations and read speed when we weren't even sure how the architecture would look. Since this was our first time really implementing something on the engine, we must get good feedback. So although the PoC is ready, it must be regarded as something that should be torn down if it doesn't complete its objectives properly. That's why it only implements a small subsection of everything that should be saved. We can see if it works and how it performs, but not be too invested to restart. Over the next few weeks we'll work at integrating it in more places and running tests to explore what restrictions we might run into. Along with auth, this task will be a big part of 0.6, the content update. Rolling mountains at dusk. See you next week! </figcaption> </figure> This Week In Veloren 55 Mon, 17 Feb 2020 00:00:00 +0000 This has been an exciting week. We had a huge boost from a Reddit post, and the Rust Game Dev WG released its January blog. Lots of good progress was made towards the goal of 0.6, "the content update". We hear from @AngelOnFira about Mac builds and @TheDip talks about the state of achievements. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @TheDip, @AngelOnFira, @Pfau, @imbris, @iMarv, @Zesterer, @Treeco, @Acrimon, and @Sharp! The Rust Game Dev Working Group released its January blog</a>! A fan of Veloren posted on /r/pcgaming this week about Veloren. The post</a> got lots of attention, and we've seen a large influx of users on the Discord because of it. We also learned a lot from what people were commenting on the post. Although it was not all positive, lots of it was very constructive on ways we could improve. @TheDip is working on implementing achievements, as @Felixader is working on their icons. You can check out those icons here</a>. @AngelOnFira has completed preliminary work on Mac builds, the next step is to integrate it with Airshipper. He is currently working on a proof-of-concept for server persistence. At first, this will allow the server to store player levels, but might also work to store world chunks. The game design working group met last weekend to discuss the skill unlock system. @Zesterer has been working on improving glider physics. @Pfau fixed a visual bug with health bars. @YuriMomo is working on implementing a custom cursor. @Sharp has been working on coloring the map. This shows off some altitude perspective and might include shadows later on. Map without and with color </figcaption> </figure> Off-topic from Veloren, but one of our expert graphics contributors @Vercidium has just released a large new update to their game, Sector's Edge. Show them some love and check it out</a>! @Vercidium has done some novel graphics analysis and debugging for Veloren with skills they've learned from the industry. The Mac Build Situation by @AngelOnFira</h3> Over the last half-year, I've been working on and off to get Mac builds working. This week, I finally made it happen by taking the easy way out. Previously, I had been trying to cross-compile from Linux. For Windows builds, this is quite easy. You tell Rust to target Windows, and you're good. However, with Mac, you require a lot more work. Mac requires that you have a special SDK that can only be compiled from a Mac computer. Not the worst, someone made a GitHub repo</a> with them. The next step is using the SDK to target Mac. Someone else made OSXCross</a> that helps with this. This is where I got stuck. Mountains </figcaption> </figure> There were a lot of dependencies that weren't lining up properly, and it was becoming an increasingly difficult task. I trudged through this on and off over many months. During this time, GitHub Actions released for the public. Actions are GitHub's built-in CI/CD tool. It can be used to run tests automatically, build executables, and much more. The biggest upside; it has Mac runners. Mac runners execute from Mac servers. This means that they have all of the requirements built in to be able to target other Macs. @Songtronix has used this method to build Airshipper for Mac, and it worked flawlessly. I copied @Songtronix's code, tweaked it a little, and it worked (almost) right away as well. Success! Messer by @AlbinoAxolotl </figcaption> </figure> Even though we have Mac builds, there are still a few issues to iron out. A build should be run when code is merged into master. However, since GitLab is our primary Git hosting platform, it can't easily tell GitHub Actions to run a build. This is supposed to be solved with webhooks, however there are some complications there as well. So right now, the builds run once a day at midnight. Not sure which time zone. On top of that, we currently don't have a way to get the latest link to this build, which means that Airshipper can't automatically distribute it. Finally, when Actions pulls the repo, a custom step had to be built to pull from GitLab instead, since the LFS files are stored on GitLab's LFS server. Hopefully, in the coming weeks, we'll see some improvements on the ease of use of these builds. Catch you next time! Achievement Implementation by @TheDip</h2> Since 0.6 is the "Content Release", it's important that we hit the ground running where we can. @TheDip is one of the first to push forward on this front. </blockquote> Achievements give players goals to work towards while playing Veloren. Some of the early ones can be for learning, as they teach core mechanics to the player. After early game, achievements can just be for the completionist players. Some might include leveling up to level 20, or completing 3 dungeons. As of right now, achievements will be displayed in a menu. Hovering over any achievement will bring up a "tooltip" menu that gives a description and requirements. As for "alerts" when you unlock an achievement, I was thinking of putting an arrow above the achievements button. It will flash to let you know to take a look. Since the UI is getting overhauled, all of this is temporary. Current achievement layout </figcaption> </figure> Triggering an achievement is done with a flag or value. For example, we can count the number of dungeons a player has completed, so that when they hit 3, they get the achievement. Extensions can be that achievements can also be used to give the player something, although I'm not quite sure yet what those would be. That will be left up to the design team. Felixader also had an idea of making the achievements menu look like an “open book”, per-say. I have yet to attempt that, but that may be something we consider. Chonker chicken. See you next week! </figcaption> </figure> This Week In Veloren 54 Mon, 10 Feb 2020 00:00:00 +0000 Contributors met this week to start discussing what will be done in 0.6. @Zesterer has some cool progress on new settlements. We take a look at the results of the Rust GameDev Working Group survey. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @Zesterer, @xMAC94x, @Songtronix, @Sharp and @Pfau! This week, contributors met for a 0.6 intro meeting. @Zesterer has started working on settlements, the next step in worldsim. @Sharp got the new minimap merged, with the help of @Pfau. @imbris has been working on updating the winit crate within Veloren. It just had quite a large update</a>. This should help fix issues with Wayland support, which prevents some users from playing Veloren. The new eventloop structure that @imbris is working on integrating will make it easier to potentially run Veloren in a webpage, as well as allow for smooth resizing. </iframe> </div> A visualization of Veloren development over 1 year </figcaption> </figure>0.6 Intro Meeting</h2> This weekend, the team met for a 0.6 intro meeting. The intro meetings are a great way to rally contributors and get excited about what we want to see in the next release. A large focus of this version will be player objectives, and so 0.6 will be known as The Content Update. You can take a look at the meeting Google doc here</a>. This meeting, we focused heavily on ways we could implement content into Veloren. It has been a goal for many releases to add objectives for the player. In the meeting, we brainstormed some ideas of how we could achieve this most easily. Here are some of the questions that we aimed to answer: As a player joining the server, what should you be told to do?</li> How can you be introduced to mechanics at this point?</li> How should the game tell players to accomplish tasks?</li> </ul> For the answer to these questions, there are many underlying systems that we'll require. These include NPC dialogues, waypoints, mob spawning control, and mob inventories. Moving forward with 0.6, hopefully we can see these implemented. Explorers burning the midnight oil </figcaption> </figure> @Songtronix started a thread on Reddit that is focusing on asking the community what they want to see in future versions of Veloren. Feel free to take a look at it here</a>, as well as contribute any ideas you have. We love to hear them! Settlements</h2> @Zesterer is picking up the worldsim/worldgen torch again with settlements. Although it's in very early stages, here are some images to show off some progress. </figure> </figure> </figure> Rust GameDev WG Survey</h2> Last August, the Rust GameDev Working Group ran a survey to gather information on the developer ecosystem within Rust. This week, they released the results for this in a post</a>. We tried to get our developers to contribute information to the survey, so let's take a look at the results! Only half the participants</a> currently use Rust for game dev, while most of the other half are considering doing so. For many, the game dev ecosystem within Rust isn't mature enough for what they need. However, Veloren escapes the issue of maturity (mostly). We are working on a lot of systems from the ground up, and so we know that when something isn't available, we are capable of making do ourselves. Other projects might rely on underlying engines like Amethyst, while we are creating our own. The newly-merged minimap </figcaption> </figure> This topic of maturity is echoed in the next section</a> which focuses on the negatives that the participants see. More than anything else, developers want maturity. This is followed by mobile, web, and console support. A great response from one user reads: From playing in the space I know it's possible to make games using Rust. However in the ecosystem my biggest negatives is the [lack of] case studies and demonstrations of it working. </blockquote> This cannot be truer. Many developers' ideas of "maturity" are based on what they can see done in a language. Rust has few flashy projects to show off, especially within the game dev field. Veloren is in a great place to surge forward and become a flagship example of what can be achieved with Rust. Not only does it show how Rust acts on the graphical level, but also within game dev architecture. Finally, from another survey participant about the Rust community: [There is a] collective community effort to "build the right thing" and "build the thing right" </blockquote> Some quality content from u/George_gekor8 on Reddit. See you next week! </figcaption> </figure> This Week In Veloren 53 Mon, 03 Feb 2020 00:00:00 +0000 Happy Global Game Jam to all those who participated! This week, 0.5 released. We take a look at how it went and go over new additions to this release. We also have another Contributor Spotlight, this time with @Silentium. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Zesterer, @xMAC94x, @Sharp, @Songtronix, @Slipped, @Shandley, @Vechro! This week, 0.5 was released! Not only that, but we just passed 3000 commits on the repo. Not only that, but there are (nearly) the same amount of stars on both the GitLab and GitHub repos. The hardest choices require the strongest wills </figcaption> </figure> @AgentAl has been working on some music pieces with "cold" and "ice" themes. @Zesterer has been working on patching lots of small issues and made a game for the Global Game Jam. @Shandley has been back at work on the music system, and is looking at ways to make it more performant. @LunarEclipse is nearly finished getting controller support to work. They are also working on updating the AUR with the stable 0.5 package. @DoNeo wrote a new article</a> on dtf.ru about Veloren's 0.5 release. @Timo is continuing work on character state, this is needed for future combat abilities. @Aeronic got an official Soundcloud account set up for Veloren. Be sure to check it out</a>! </iframe> </div> 0.5 feature video by @DoNeo </figcaption> </figure>0.5 Release</h2> Since we adopted a proper changelog structure, we can easily see what has been achieved during 0.5. The list is super long, so you should check it out for yourself</a>. Here are some of the big items: Include license in assets Added dropping items Added initial region system implementation Added /giveitem command Added moon Added clouds Added proper SFX system Added changelog Added Scrolling Combat Text (SCT) & Settings for it Added a Death Screen and Hurt Screen Added randomly selected Loading Screen background images Added options to disable clouds and to use cheaper water rendering Added client-side character saving Added a localization system to provide multi-language support to voxygen Added rivers and lakes which follow realistic physical paths. Added a default map, which is used to speed up starting single player. Added fullscreen and window size to settings so that they can be persisted Added coverage based scaling for pixel art 28 new mobs Added waypoints Added pathfinding to NPCs Overhauled NPC AI Pets now attack enemies and defend their owners Added collars to tame wild animals </code></pre> Unfortunately, the launch party wasn't as big as we had hoped. At peak, we had just over 30 players online, compared to over 40 for 0.4. It also didn't help that Digital Ocean started having issues creating new droplets right as we were trying to increase our server's compute capacity. This called for a quick switch over to AWS for hosting. </figure> Below are some more statistics from the launch party. You can compare them to the 0.4 launch party</a>. The total server costs for this launch were around ~$12.50 USD. This includes the server and bandwidth. Players online </figcaption> </figure> Chonk count on the server </figcaption> </figure> Bandwidth used </figcaption> </figure> Contributor Spotlight: Silentium</h2> Hey everyone, Silentium here! After 4 years of college, I started a career in biotechnology and currently work in a start-up pharmaceutical company in Boston. I have a love for science and learning that rivals my love for fantasy in almost any form. From D&D podcasts to Anime and Novels, I've had a real seeded connection with anything fantasy since I was young. As such, I run a D&D campaign with some of my friends and it's been going on for over a year now, but the world it's set in hasn't stopped growing and developing since 2016, when my girlfriend and I first started world-building. The name Silentium actually comes from this world, as he is a major player in world history and current events. I've been expanding my fantasy novel reading experiences ever since I decided to create my own world for a D&D campaign, and now have an appreciation for writing that I never had as a youth. In progress jungle structure by @Shimox </figcaption> </figure> I have loved video games all my life but my experience with them is much more limited than I would like it to be. My taste in games is limited to a few specific types, and as a result, there are many popular games that I have no interest in playing. I have always been critical of the game design choices made in any game I have ever played, and as such I have always dreamed of having a hand in the design of a game that I would personally like to play. I was falling off the Cube World hype train after it released late last year, and was directed to Veloren from Reddit. I started my contribution to the game a few weeks earlier than November, but only in a minor way. I designed about 100 weapons in the MagicaVoxel program uses to create the assets for the game. I have many more unsubmitted weapons waiting for submission as soon as I flesh out my designs a bit more. Since the beginning of November, I have been working with many of the very creative and talented people within the Veloren community on game design. We have started with the combat system because there was already a working group dedicated to creating and implementing that system for the game, but we definitely plan on branching out to other topics as we go. Pipa instrument by @AlbinoAxolotl </figcaption> </figure> Essentially, every week we get together and design the mechanisms and definitions of important aspects and elements of the game's core gameplay features. I create a write-up following the meeting that outlines everything we specifically designed without branching out too far into out of scope topics, and include sections for why we created things in a specific way. All of it is recorded in a single document for reference, and each complete topic has its own document as well. The end goal is to have a master document that contains everything we design, so it can be referenced when the programmers develop these aspects of the game. In this process, I mediate the meetings, organize the discussion topics, and provide the environment for the design discussions to take place in the most inclusive and constructive way they can. As the team leader for the Game Design workgroup, I'm always looking for new contributors who have a passion for game design and a desire to help. I've never heard of a game created by a large community of unpaid people, rather than a company. I may have been living under a rock, but this is a brand new concept for me, and the potential for a game created by such a community has my hopes very high. The art style and world generation that I saw when I first arrived had me convinced that this game could become amazing if it has the right direction. That's all for this week, see you next time! </figcaption> </figure> This Week In Veloren 52 Mon, 27 Jan 2020 00:00:00 +0000 This week 0.5 will be releasing! It's also the 1st anniversary of the blog, so we look back at what some contributors are most proud of. @Tub talks about the new website design and @Songtronix shows us some great progress on Airshipper. @Ender gives a run-down on how text localization is working. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Sharp, @Zesterer, @Pfau, @imbris, @Slipped, @Acrimon, @Payload1, @Timo, @Treeco, @flyingfryingpan, @Friz64, @Ender, and @Songtronix! With the release of 0.5 coming up this week, we will be having a launch party this Friday, January 31st at 18:00 GMT. You can check out our countdown here</a>. We had 50+ concurrent players at the last launch party, and we expect it to be much higher this time! If you're considering streaming the launch, please reach out to any admin or core dev so we can announce it. Here are some of the changes you can expect for this version: Many new worldgen features</li> More diverse mobs with better AI</li> More immersive combat and character progression</li> Tons of performance improvements</li> </ul> @Zesterer has done a lot of work this week on AI. This includes pathfinding, aggro switching, and pet AI. @Sharp got their new worldgen merged just in time for 0.5 as well. @Slipped merged their work on new animals. @Qutrin started working on the switch to wgpu as the new graphics API. @AlbinoAxolotl has been working on some musical instrument assets, as well as dwarven haircuts. 1 Year of This Week in Veloren by @AngelOnFira</h2> This is TWiV #52! That means that one year ago, I had just put out the first edition</a>. At that point, I was just looking for something that I could contribute to on the project. I didn't know the direction the blog would take, just that I wanted to do one every week. If I didn't, I knew I wouldn't write the next one either. So while on vacation in Europe for a month, during exams, and other busy times, I kept up with the weekly, Monday (or Tuesday) devblogs. This was great for me, as it helped give structure to a lot of the rest of my week. I'm super proud of being able to do this for an entire year! It is my biggest achievement on Veloren, but while we're at it, let's take a look at some of the other contributor's achievements. @Songtronix is happy about their progress on making Veloren easily distributable with Airshipper. They've taken it on themselves to continually work on improving the Veloren experience. In this coming year, @Songtronix wants to keep working on this by improving documentation in The Book, as well as stabilizing many of the current technologies on the go like auth. @LunarEclipse has spent much of the last year improving their Rust skills. They have worked a lot on to do with package distribution of Veloren, specifically with the AUR. They also did lots of work on The Book, controller support, and Polish translations. @LunarEclipse is excited about the prospect of content in Veloren this year, and determined to stabilize controller support throughout the game. Some performance boosts made this possible </figcaption> </figure> @Shandley has been working through many small issues mostly in the SFX area. They're excited about questing and where it's headed, since community-driven content will be a major part of Veloren. This year, @Shandley wants to continue work on the music and sound system. Also, fishing as a side goal 🐟 @Slipped is proud of their work on the new animals in the game. As an early voxel artist of the game, they are now focusing on heading up the animation efforts of Veloren. @Slipped is excited about the future of the animation system, as well as worldsim. "We have a really cool simulation base with the physical simulation of the world so far. Seeing history layered on top of that in a way that has real-world, dynamic consequences will be amazing to see. The devs planning in that area have some really great visions for Veloren". @Slipped is excited to see more biodiversity in the game, and will also be focusing on combat animations. @Tub is happy about the new website design they've been working on. It was a good experience getting feedback from other developers, and iterating on the design. @Tub hopes to start working on the engine itself this year when they can find time. @Silentium's biggest milestone was becoming the lead of the game design working group, for which they are super honored. After iterating on the design process many times, @Silentium is excited for the next step of development; implementing the designs. @Silentium is working to finish the combat design, and start working with other groups on other design needs such as exploration and crafting. @Adam has used Veloren as an opportunity to learn Rust. They have also done a lot of work on combat, ability, and condition state systems, which they will be working on improving in this coming year. They are quite excited about this! </figure> @Sam has recently joined the design team, and has worked on progress through their design proposals. Like @Silentium, they are excited to see their designs be implemented in the game, as well as the form the weapon system will take. @Sam's goal this year is to dive deeper into design concepts surrounding damage types. Although @Shimox doesn't have a lot in the game, they did get one of their flowers implemented. They are excited to see the transition from getting Veloren to work towards a more content-based focus. This year, @Shimox hopes to work on getting more assets into the game. @DoNeo is proud of their work starting up the Russian community. They have done a lot of work translating the devblog every week. @DoNeo is excited to see a more integral history and lore system through worldsim. In the coming year, @DoNeo wants to focus on developing the Veloren community through articles, translations, and videos. @xMAC94x somehow made it through their job, life, and relationships to find time to work on many systems in Veloren. They want to be surprised with where Veloren goes in this coming year. @xMAC94 wants to continue working on networking and macro-scale worldsim. @Qutrin is proud of the contributions they managed to make this year. They are excited to see the content that will be added to Veloren this year. One of @Qutrin's big focuses will be the switch to the wgpu graphics API. @Acrimon worked hard on user authentication, which has required a huge amount of collaboration from the team. They are excited to see what the rest of the team will be working on this year. After deploying auth, @Acrimon plans on hot-reloading support to help devs, as well as building out an extensive modding system. Knight's tomb by @AlbinoAxototl </figcaption> </figure> @Timo is proud of their work on the combat system. They've been focusing on this for many versions now. @Timo wants to see Veloren grow from a prototype into a game with a steady player base and long-term gameplay. This year, they want to dive deeper into the combat system as well as design features around it. @Aeronic has worked on many musical pieces for Veloren, as well as getting a strong audio team together. They are excited to see where audio will go this year, through both music and sound effects. @Aeronic wants to see a fully encompassing audio experience be implemented in this coming year. @Yuri broke lots of things. They are excited for more features to break, as well as "Zest branches" and the new contributors that will join the project. They plan on finding many more bugs and exploits this year. For @Zesterer, their biggest milestone was the 0.2 release. For them, this was the culmination of many months of refactoring and rewriting to produce the new engine. Like many others, @Zesterer is excited to see what will happen with worldsim. @Zesterer's goal is to keep the engine running fast, as they enjoy doing the optimizations. @Pfau was amazed by the 50+ people that took place in the last release party. He is excited to see combat and equipping become more fleshed out. He wants to learn more Rust so that he can start using the Iced library for some more advanced GUI elements. @Sharp has spent a lot of time on erosion through many different methods. They are excited about the ways that world simulation systems will react with one another. This coming year, @Sharp plans on getting some other developers up to speed on the erosion systems so that the work can be distributed more. Website Update by @Tub</h2> A project that has been idling on my desk for months has finally been finished: the website redesign. The most obvious change is that the giant header has been removed and used as a background instead. The second most obvious one (and the whole point of the redesign) was to add a proper start page that's more than just a list of devblogs. Behind the scenes, a lot of cleanup has happened. Unused features were disabled and removed, some JavaScript was removed in favor of modern CSS features, CSS files were restructured and minified. Shortcodes were added, alleviating the need to write custom HTML code in the pages, and giving a more consistent layout. All of these result in faster page loads with less jitter, slightly better SEO and accessibility, and cleaner code going forward. Once these things were done, several community members jumped in with suggestions, bug reports, and ideas, many of which I was able to implement during the past weeks. Being my first contribution in this community, it has once again shown me the value of collaboration - together, we created a better site than I could have created alone. Now that the site is live, I expect more ideas to pour in, paving the road for future improvements. Airshipper Progress by @Songtronix</h2> Last time I showed some concept art on how Airshipper might look: Airshipper Design </figcaption> </figure> Thanks to the wonderful help of @Timo with his constant effort to make it real we're finally approaching a consumer-ready GUI. Before spoiling you with the final version, let's follow us on our journey on how we have done it! @Timo started to work on the layout of the UI: Initial layout. Ugly but a start </figcaption> </figure> And already after a little bit of time he has almost done it: We even show the changelog now! </figcaption> </figure> After some finishing touches, he's done the layout of the UI! Looking good so far! </figcaption> </figure> Well, if you look closely you can see a slider beside the play button. Why? Well until then there was no progress bar in the GUI library which can fill up nicely while downloading the game. As I always wanted to contribute to iced</a> I thought this is the chance. So I've done it and I loved the process of doing so! After my Merge Request</a> has been accepted I played around with it for about an hour. I still do this every day... </figcaption> </figure> And then with some customization efforts by @Timo: and songtronix is the coolest ^^ </figcaption> </figure> Leaving out all the backend horror like making the download button do the actual thing, I have put some efforts to get the UI closer to the design. This is achieved by showing the blog posts and even adding buttons that link to the respective blog. For all the poor souls with a bad internet connection: Do not worry, we cache the news and changelog and only download the whole thing if it actually has changed. UI with news and changelog </figcaption> </figure> Now let's watch airshipper actually starting the game: Starting the game </figcaption> </figure> Soliloquy of @Pfau</h2> [ADMIN][Pfau] what needs adjusting [ADMIN][Pfau] is the min and max value you can zoom in and out Sharp went offline. [ADMIN][Pfau] off he goes* [ADMIN][Pfau] Sometimes I wonder what my role on veloren is [ADMIN][Pfau] Quality Control? Art Director? Clown? Pfau died </code></pre> Veloren For All Of Us: Localization System by @Ender</h2> Even if English became the de-facto standard on the internet, there is still a majority of the worldwide population is not able to learn it or just prefer to enjoy cultural content in their native languages. This is even truer for video games like Veloren as you can play it before a polished "complete" version is released. Translations are thus an important step to increase the popularity of the game and make it accessible to the greatest number. More personally, it was for me a great opportunity to discover the Veloren source code and develop my first feature in Rust. I really enjoyed working on this subject as it allows other translators to contribute to this great project. So, what is the road from an English specific application to an internationalized one? At first glance, it doesn’t seem so complicated: it’s all about text right? So first, how many files and lines of source code does a translator have to work with? Let's take a look at these stats in the 0.4 stable version: </figure> In total there are 107 files in Veloren client application containing 931 lines of text among 23855 lines of code. This increases by around 20% in the upcoming 0.5 version. With this architecture, translating Veloren for non-technical people would be very overwhelming. It is like looking for a needle in a haystack. So the first step to simplify this process is to separate the displayed texts into a unique file and access them with a key-value system. </figure> With this system, new localizations can be easily added. Since the process consists of a simple file to add in the Veloren source code, even non-developers can contribute by taking the English file as an example. So how does this look? </figure> Yeah! Our text is translated and we can now enjoy Veloren in French... or any other language. But there is still an issue here, what are these weird character “F” wrapped in a white box? Well, the current version of Veloren uses a set of font with partial support of the worldwide available characters. In fact, even common Latin languages like Spanish or French are not completely compatible. A quick workaround we implemented for the 0.5 is to convert these unsupported characters to standard letters (A to Z), giving a more readable output. </figure> And here is the result you will have in the 0.5: a pretty translated version, but still incorrect regarding the language rules. So, what is planned for 0.6 version and beyond: Add a way to use different fonts depending on the language to have a correct display</li> Add translations of the bag items</li> Find better fonts supporting a wider range of characters</li> Add MOAR localizations! (Contributions are welcome!)</li> </ul> Here is a preview of the font customization feature: Your browser does not support the video tag. </video> Configurable fonts for the localization system by @Ender </figcaption> </figure> See you at the release party! </figcaption> </figure> This Week In Veloren 51 Mon, 20 Jan 2020 00:00:00 +0000 This week, we take a look at some of the finishing touches to 0.5. Lots of progress has been made on quality of life changes, such as translations and visual flares. We hear from @Sharp about map migrations, and from @AngelOnFira about their talk at CUSEC. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @Pfau, @Timo, @Acrimon, @JosephG, @Zesterer, @Sharp, @Songtronix, @Payload1, and @Shandley! @LunarEclipse has gotten controllers to partly work. In-game works, but no menu support, and key binding still has to be set up. @Pfau worked on some nice visual flairs, like colored frames for activated skills, and darkened skills when they are charging. He also worked on scaling character creation to your window size. @Sharp has been working on the map that will be released with 0.5. @Ender has been working on a localization system. This will allow translations of the game to be easily created. Both English and French translations are nearly done, with the ladder at 75% complete. Your browser does not support the video tag. </video> The localization system </figcaption> </figure> 0.5 Map by @Sharp</h2> I'm almost done creating the versioned infrastructure for maps. This will allow us to load old maps with when the format changes. The basic idea is that we "chain" migrations of old map types. So each map type just has to know how to convert into the next version, and it will follow the chain until we hit the latest version of the map. The world file format is defined as an enum with a variant index that we set explicitly (this is an available feature on Rust nightly). That way, we can extend their backwards compatibly while still using bincode. I also support the "legacy" map types that don't have this field, but you have to explicitly know you're loading a legacy one. For every other map created after this change, that shouldn't be necessary. This still doesn't cover invalidating old maps when the code changes, but it at least makes sure people won't be left unable to use their world files. At least, not if they make them on major releases; I don't guarantee backwards compatibility for random changes between releases. On the plateau </figcaption> </figure> It shouldn't increase the binary size much unless we start to gather a truly absurd number of versions. Postgres supports compatible migrations for something like 5-10 years and it doesn't cause any problems. And if people really want to migrate old maps that have been removed from the binary, they can always grab an older version of Veloren and perform the process manually. This entails migrating up to the latest supported version was that also knew how to read their old file, then jump to the latest version of Veloren that knew how to read that file. So I don't really see much of an issue either way. That's the nice thing about chaining and supporting migrations from the get-go rather than adding it after there are already several incompatible map types, or using a file format that doesn't know its own version. 128 x 128 km map rendered by @Treeco. 24+ GB of ram recommended to play </figcaption> </figure> CUSEC 2020 Talk by @AngelOnFira</h2> Hey everyone! Last weekend, I gave a talk at CUSEC (Canadian University Software Engineering Conference) in Montreal. The title was "Cultivating a Healthy Open Source Community". I spoke about lots of interesting ideas that I learned from working on Veloren, both from a management and development view. You can check out the slides here</a>. In the future, I might get the recording of the talk as well. I reached out to some developers to get other ideas to add to the presentation, but I also feel that all of the contributors who added to Veloren were an inspiration for the talk as well. Thank you all <3 The sun sets on this blog. See you next week! </figcaption> </figure> This Week In Veloren 50 Mon, 13 Jan 2020 00:00:00 +0000 Happy 50th edition of TWiV! We have a lot of progress and content for this week. We get to take a look at scrolling combat text with @Pfau, and skeletons with @Slipped. @Sharp has been hard at work, and we get to hear about some new updates to erosion and worldsim. We also examine an interesting optimization that the team has come across this week. Finally, the Rust Game Dev Working Group released their monthly newsletter, be sure to check it out</a>! - AngelOnFira, TWiV Editor Contributor Work</h2> @Acrimon is still working on solidifying auth, it has been tested quite well in the last few weeks. @yusdacra worked on improving frustum culling. This will give performance gains as chunks out of view of the camera were being rendered before, and now they are being culled properly. @LunarEclipse has been working on controller support, and it should be ready soon. @Timo has been working on resolving some issues with how fog moves around erratically. @Slipped added a lot of new animal types, take a look at their writeup below. You can check out some galleries that @Felixader made showcasing their work on artifact icons</a>, and berry icons</a>. @Shimox also created a gallery show off their work, check it out here</a>. @Silentium and the design team are still working on the skill tree structure. New trees by @Vechro </figcaption> </figure> Thanks to this week's contributors, @Acrimon, @Pfau, @imbris, @Songtronix, @Shandley, @yusdacra, @payload1, @Qutrin, and @Timo! Scrolling Combat Text by @Pfau</h2> Hey everyone! Recently, part of the team has been helping me with Scrolling Combat Text (SCT). This is another element that will make Veloren more immersive. The first thing to show off is quite obvious. Single hits get displayed as soon as they happen, and they fade out as they pan upwards. Their colour goes from white to an aggressive orange/red tone depending on how much damage percentage your hits caused at the enemy. You can see this in the image below. </figure> Another way to set up the SCT is to sum up the total damage you did. Again, the higher the percentage of the enemy's health you reduced the more orange the colour becomes. Along with showing this text when you deal damage, it will be shown when you take damage. Below is an example of the summed damage taken by the player. </figure> We also implemented experience and healing text. The XP you gain after the fight will be shown at a random position in the upper half of your screen. The higher the percentage of the gained XP from your currently needed XP to level up the bigger the number. Healing gets displayed like experience; a random position in the lower half of the screen. It's shown as either single or cumulated numbers and doesn't get added up with the damage numbers. This system has only the basic functions and will be expanded later. </figure> Finally, a little unrelated piece of progress. The map becomes slightly translucent when you start moving while having it open. Anyways, see you next time! </figure> Skeletons by @Slipped</h2> Hey! @Slipped here, I've been working on the same MR for quite a bit now so I figured it was a good time to post an update. I've been working on the animation skeletons and setting up the foundations to allow for a ton of new NPCs in the game. Most of the credit goes to @imbris and @Lawtonfogle who set up skeletal sharing to work for humanoids a few months ago. All I had to do was transfer this to animals, so this writeup isn't technical because they handled all the hard stuff. The key part of what I've done here is giving a species trait to all the different body setups. For our purposes, we'll call this the skeletons. This means that, unlike before, any time we load in a new mob it will have a set species. Previously, we could load in a wolf and get a wolf, or a pig and get a pig, but that only worked because they were two different skeletons and they only had their own body parts to choose them (i.e., they were randomly choosing a leg from a pool of one leg). Critters </figcaption> </figure> We don't want this long term because creating new skeletons for individual mobs is super over-complicated for what we need. The new set up also moves a lot of the critical animation info like 3D placement and pivot point into config files, which is hugely useful because it lets us to hot load these things, with different placements per species. This will remove the strain off the compilation times and making this MR take a few years less than it would have. One of the things I've really fleshed out in this MR is exactly how we want our skeletons to look, how many we will need and what makes them all different. One thing that has become clear as I progress is that even more important than how something looks, or how big it is, is how it behaves. Birds </figcaption> </figure> Obviously, we want an animal that has 4 legs to be wired into a skeleton that has 4 legs, but almost as important is behavior. Predator vs prey, speed of movement, style/rigidness of movement are important questions when working out where something fits. Because of this, I've been pretty picky with the models that I'm adding into this MR. It's easy to plug a new mob into a skeleton that mostly fits, but if we can put it into a skeleton that fits it well later, then that's what I'm trying to do. Larger quadrupeds like deer, horses, and buffalo require more than one leg bone to seem alive, so they will come later. Current quadrupeds are all pretty low to the ground, which works with an easier setup. Current skeletons in my working branch are: critter: quadruped, 5 bones. very simple movement, the left and right feet are modeled together because they move together and this streamlines them. Scaled down in animation, for very small mobs.</li> quadruped_small: quadruped, 7 bones. Normally prey. Slightly more cartoony feel, lots of cute models.</li> quadruped_medium: quadruped, 11 bones. The most complex animal skeleton right now. Generally predators. Usually a bit bigger than quadruped_small, but more importantly allows for flexibility and realism. Splits the head into 4 parts, the torso into 2. Things like movable jaws give us a lot of freedom to animate better attacks. Split torso allows us to simulate things like turning better, or even breathing in idle animations.</li> bird_medium: biped, 6 bones. Simple and functional, useful for things like ducks, gives them heads, chests, tails, wings and legs.</li> biped_large: simplified in some respects from the humanoid, but made more complex in others. To support something this big we split the "pants" bone into two actual legs, so we'll get some more realistic looking movement. A tricky one. Hopefully I finish this eventually :P</li> </ul> There are others lying dormant (some rumors say there's a dragon skeleton laying around) but those will be in for after 0.5 is released. </figure> Here is an example of a medium quadruped. This is a Tuskram. You can see it looking to its right, and with the bone setup we've built for it we're able to represent a simple head twitch with 4 different angles: the neck at less of an angle than the head, even less for the front torso, and no angle on the rear torso. For now, it's just a cool little detail that's too subtle to notice, but for something like a lunge attack to the side it will be more extreme and the payoff should be good. This MR brings the total number of animals in the game from 2 to 30, which will be pretty cool. We also add gender to each i-game mob, giving us full customization capability, so the total number of variants possible will be 60, though not every mob will do gender variation. Small quadrupeds </figcaption> </figure> Iterator Problems with @AngelOnFira and @Sharp</h2> The team came across an interesting bug that is being resolved. In Rust, if you want a sequence of numbers, say (0,1,2,3,4), you could use the iterator notation 0..5</code>, where the first number, 0</code>, is inclusive, and the second number, 5</code>, is exclusive, or not used. This is useful when going through things like arrays, where an index starts at 0 instead of 1. However, in some cases, you might want the iterator to include the second number, so you would use 0.=5</code>, which would give (0,1,2,3,4,5). The problem is Rust has to do a lot of checking to make sure that this is safe, and so it is incredibly inefficient. Instead, 0..(5 + 1)</code> is much quicker. An even better option is to use for_each</code> statements to allow the compiler to handle it, but this isn't always possible. @Qutrin has been going through the codebase to resolve this issue wherever possible. For more information on this issue, check out this Reddit post</a>. View distance is on the rise! </figcaption> </figure> The section above was written by myself, @AngelOnFira. After asking #programmers to proofread it, @Sharp gave a much more in-depth summary of the issue. Here is is: It's worth clarifying that the issue is not exactly with Rust, it's with codegen. Rust uses lazy iterators by default, which means it has to assume next() can be called at any time, not just one after the other. And similarly, to avoid dynamic dispatch, the iterator itself always has just one implementation. Therefore Rust won't send LLVM code that does the efficient thing (check just once whether the upper bound can overflow, and branch based on that); it has to branch every time you call next. Unfortunately, LLVM usually isn't smart enough to work out that these are equivalent. However, there is another solution that is almost certainly better than replacing ..=X with ..x+1 (which you should only do if you know you won't overflow anyway). Some of the new pine forests </figcaption> </figure> What I just described is part of a broader class of problems caused by Rust using lazy iteration; there are other things that cause similar performance impacts (like chain(), or zip() on arrays). However, if you call .for_each() (instead of using a for loop or calling the iterators directly), Rust knows you are doing internal iteration. So many of the ForEach implementations are specialized for the iterator type to take advantage of the fact that they know the iterator will be run to completion. These implement all the optimizations you'd expect and LLVM generates much better code for them. I've already seen dramatic speedups in some parts of the codebase that I didn't realize were unoptimized by replacing for loops with for_each, and unlike the other replacement, it is always semantically equivalent if the transformation is possible at all (i.e. you weren't using break; or return; for nonlocal control flow). So I think a good extension of this project would be to go through the codebase and clean up as many for loops as possible. Erosion Worldgen Updates by @Sharp</h2> </figure> Here's a map (128x focus, so it exaggerates small z differences) showing some of the new stuff I've been working on improving. This is in addition to other stuff not on master: hillslope diffusion, sediment transport, debris flow [replacing thermal erosion], soil production, map saving, and significant map rendering improvements. The main thing is multiple receivers for drainage computation--that is, allowing some of the water to flow downhill in directions other than the very steepest. The drainage per direction is presently automatically weighted across all downhill directions from each chunk by a factor of: (slope to neighbor in that direction)^(0.5 + 0.6(avg slope across all neighboring downhill chunks)</code> Note that doing this is quite computationally expensive. Making it significantly cheaper is nontrivial, to say the least--I even tried SIMD-ing it and haven't had success yet. So I'm working on making it easy to switch between this and the old method of drainage computation. Mountains off in the distance </figcaption> </figure> Currently, this is only performed for erosion purposes, since we can't render it well yet--so in the rendered map, we're still using the old drainage computation for river flows (but the humidity calculation does use it, so it does a much better job of making sure wet areas are wet than the current map does). The other significant improvement since the last time I shared a map is that we are using a nicer (for our purposes, anyway) algorithm to determine downhill directions for lake chunks. They now try to point directly at the closest pass rather than either always point downhill except the lake bottom (master), or do so except for a single line from the lake bottom to the pass (this branch previously), which produces somewhat nicer underwater erosion. Combined, these two effects really clamp down on linear artifacts. The particular map shown above has 128x128 chunks (4x larger distance per side than the current map), and doesn't use the plates from before for much (uplift=old altitude^2, kf constant). </figure> Here, I'm also including a second image of the overhead map where the multi-receiver drainage is also used to decide where there's a river. This looks quite nice from overhead, but it renders ugly in game and I haven't yet decided how I want to approach it. I also don't want the overhead map to differ from the world map. So I'm using the old method for the time being. The new method basically gives us wide rivers "for free!", though since we currently deliberately underestimate how much flow is needed to make a river by a large factor it makes the map a bit busy. The sun is setting for this week. See you next time! </figcaption> </figure> This Week In Veloren 49 Mon, 06 Jan 2020 00:00:00 +0000 PUBLIC SERVICE ANNOUNCEMENT Are you looking to spend your new year's motivation on something cool? Well then make it the year of working on Veloren! We have many beginner issues available right now to get you started. Ask anything you like in #learning, the team will be happy to help! </blockquote> Happy new year! We've seen a great push this week on lots of fronts. Authentication is reaching stability, and lots is being added to Veloren both in assets and fundamental systems. We also hear from @Silentium about principles of writing design proposals. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @Zesterer, @LunarEclipse, @Pfau, @Shandley, and @Songtronix! @Acrimon is working on hardening authentication. Security audits are in progress, as well as lots of client integration and testing. @Slipped has been hard at work getting lots of new creatures into the game, including boars, sheep, foxes, and sabre teeth. @imbris, @Timo, and @Pfau started working on scrolling combat text. It's almost done! There is also a new death screen as well, which has more information about respawning. @Timo has started a GitLab board</a> that will track progress on design systems that are needed before the release of Veloren alpha. You can see a more detailed document of the combat design overview here</a>. @Silentium hosted another great design meeting that focused on weapon types. You can see that document here</a> Scrolling combat text </figcaption> </figure> How to Effectively Write a Proposal for the Game Design Team by @Silentium</h2> The first thing to remember when writing a design proposal is that any idea might not make it into the game due to the consensus of the design team. Unfortunately, we can't include all ideas, but with some compromising and some creative thinking, we can usually extract important aspects of the idea. Even ideas that don't get used in their full state can still provide some very important insight into other aspects of the game's design, so do not think that an unused idea is invalid. Every idea is useful, just maybe not necessarily in the way it was intended. The more the better. The second thing to understand is that the proposal needs to keep from being too detailed. The goal is to do the least amount of work possible to effectively communicate the fundamental principles and reasoning of an idea. This is because if the idea isn't well-received, or if it needs some reworking or changes, they can be done without subverting a large portion of the work done to write the proposal. No idea proposed to the game design team is used verbatim. Some berry bushes by @Shimox </figcaption> </figure> The third thing is to be open to changing ideas. As previously stated, no idea is used without some changes being made first. As long as the proposer keeps an open mind about what can be changed, their idea will be very useful to the design of the game. This also helps uphold healthy conversation grounds. Fourth is to read all preceding documentation. Almost everything we are currently doing is built off previous work. We have a very specific order in which we are designing gameplay elements and systems, and some of them need to be addressed before others. Make sure not to presume we haven't designed an element of play, and make sure not to read too deeply into the potential implications of a system we have designed. The proposals are written to be specific, including only that which has been explicitly been decided on. Items out of its scope may still be up in the air. New low health border </figcaption> </figure> The last thing is that everything is changeable, even the stuff we have already written in our official documentation. By this, I do not mean we are open to redesigning the whole thing again. We are very proud of the work we have done and would rather not scrap it. That being said, if anyone thinks there is a problem with a system we have designed or a fundamental fatal design choice we have made, we are open to hearing about the criticism. Not only that, but we fully expect some systems to not prove viable when we start playtesting. As a result of this, we will likely have to rework some of our systems and come up with more iterations. Each time we begin a new topic of design, I will make a post to let the team members put their ideas into one document. We all collaborate on this to get the final proposal finished so keep an eye out for those in #game-design! As long as someone can keep these principles in mind while they write their proposal, they will be very effective in contributing their ideas to the game design team. Please let me know if you have any questions about any of this, or if you need clarification. I love when people take an interest in our work, so please don't hesitate to message me! Cheers ✨👍✨ @Silentium New creatures implemented by @Slipped. See you next week! </figcaption> </figure> This Week In Veloren 48 Mon, 30 Dec 2019 00:00:00 +0000 It's the last blog of 2019! With the year wrapping up, we take a look at some of the progress we've made. We've seen many new contributors join Veloren's development, as well as many milestones reached. @Adam also does a deep dive into character states and concepts surrounding them. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @AngelOnFira, @imbris, @Pfau, @Acrimon, @DylanKile, @LunarEclipse, and @Songtronix! @Tub has been working on a new website layout, which can hopefully be implemented fully in the next few weeks. @Sharp has been continuing work on erosion and has just added debris flow erosion. @LunarEclipse added an Airshipper AUR package for easier installation in Arch. There was also a team meeting, as the release date for 0.5 is coming up! @Sharp's new debris flow erosion system </figcaption> </figure> 2019</h2> With 2019 coming to an end, it's important to look back at what we've accomplished. The images in this edition of TWiV reflect some major milestones we've hit. It's also a great way to see where we started, with just the bare-bones of the new engine. Of course, we should also remember the great contributors that have made this possible! Note: this just counts contributors that committed to the GitLab repo. Many others have given input at meetings, created concept art, music, and stories. Big <3 to all of them as well! (817) Joshua Barretto, (275) timokoesters, (162) imbris, (146) Forest Anderson, (139) jshipsey, (127) Pfau(90), (104) Acrimon, (78) imbris, (70) Pfau, (65) Monty Marz, (55) Marcel, (47) Piotr Korgól, (45) Louis Pearson, (42) Timo Koesters, (40) Joshua Yanovski, (31) Marcel Märtens, (26) Louis Pearson, (24) sxv20_, (23) Songtronix, (21) tommy, (20) Shane Handley, (20) Yeedo, (19) Cody, (17) Songtronix, (16) Vechro, (15) Forest, (15) LunarEclipse, (14) Dominik Broński, (14) Songtronix, (14) telastrus, (13) Songtronix, (13) scott-c, (12) haslersn, (12) robojumper, (11) Imberflur, (9) KyoZM, (9) liids, (9) scorpion(9979), (8) Andrew Pritchard, (8) Justin Shipsey, (7) Adam Fogle, (7) Christoffer Lantz, (6) Joseph Gerardot, (6) S Handley, (5) Cedric Hutchings, (5) Sheldon Knuth, (5) Sheldon Knuth, (5) soruh, (4) Adam Whitehurst, (4) Ahmed Ihsan Tawfeeq, (4) Maciej Ćwięka, (3) Cody, (3) JMS, (3) Tom Watson, (3) Wu Yu Wei, (3) stevedagiraffe, (3) telastrus, (2) Arash Outadi, (2) Demonic, (2) Geno, (2) J. R. Vidal F, (2) Nikita Puzankov, (2) Piotr, (2) Tesseract, (2) Treeco, (2) Vsevolod Timchenko, (2) kacper, (1) Adam Whitehurst, (1) Adam Whitehurst, (1) Algorhythm, (1) Artem, (1) Brian Lewis, (1) Carbonhell, (1) Christian Authmann, (1) Christoffer Lans, (1) Dylan Kile, (1) Erocs, (1) Isaac Freund, (1) Jessie Mancer, (1) Luc Fauvel, (1) Luc Fauvel, (1) MidgeOnGithub, (1) Nero, (1) Nick(12), (1) Nicolas, (1) RustyBamboo, (1) Sebastian Venter, (1) Tanner Donovan, (1) Thomas JULLIEN, (1) appcrashwin(7), (1) heydabop, (1) neronim66@gmail.com, (1) pestilence, (1) yashaslokesh, (1) yeet This year's credits are brought to you by git shortlog -sne --since="1 year ago"</code> </blockquote> Your browser does not support the video tag. </video> One of the oldest videos of the new engine (March 4th) </figcaption> </figure> Character States Overhaul by @Adam</h2> Hello, @Adam here! I'm working on redesigning the Character State System so that it can (hopefully) handle all the awesome ideas that #game-design</code> has in mind. This will include the combat, abilities, and weapons systems of Veloren. I'm going to walk through all the guts of this new system, to illustrate how it works and why I'm so proud of it. :) But first, some background... The CharacterState</code> component is what handles behaviors of "characters": Any player or NPC, human or otherwise. Each CharacterState</code> actually has two concurrent states: an ActionState</code> which is primarily concerned with how a character is interacting with the world (Attacking, Blocking, Wielding), and a MoveState</code> which primarily describes how a player is moving around the world (Standing, Running, Gliding, Climbing). The beginning of networking! (March 18th) </figcaption> </figure> Existing State of Character States</h3> When I began, the existing movement</code>, controller</code>, and combat</code> systems were under-equipped to handle the exciting ideas that #game-design</code> was coming up with. Here are a few reasons why. First, CharacterState</code> update logic was spread across these three separate systems, so to make any changes or fix any bugs, one would first have to understand how all three of these systems worked, just to change one state's behavior. Second, the controller</code> system was the main source for state-transitioning logic, but that logic was occurring across a series of conditional checks, with state behavior logic mixing with that of others. This meant that changing one state's implementation could have unpredictable effects on another's. Original concept of character creation screen (March 18th) </figcaption> </figure> Finally, The state interactions during combat were being defined by the combat system itself. For example, when you tried to attack, the system would check if the enemy was blocking, and handled that blocking logic. So to have new, interesting ways of attacking/blocking/dodging, we would have to layer that on top of the logic of every other attack/block/dodge behavior. What needed to happen instead was that the blocking state needed to be able to define how it would handle blocking an attack i.e: Would the block interrupt the attacker? Would it apply a strength debuff? The state of graphics in Veloren with AO, FXAA, and terrain gradients (May 6th) </figcaption> </figure> To summarize, the issues with the existing systems are: State updating logic was spread across three separate, interlocked systems leading to cognitive overhead.</li> State behavior logic depended on the behavior logic of every other state. Changing one state would affect every other state in unpredictable ways.</li> State handling was too static and would not scale as weapons and abilities were added.</li> </ol> Your browser does not support the video tag. </video> Playing around with NPC characters (May 13th) </figcaption> </figure> Veloren Character State System (VCSS)</h3> With these issues in mind, I'm going to start at the root of this new Veloren Character State System (referred to simply as 'VCSS'). Peek into the implementation file: sys/character_state.rs</code>. Don't worry! This part is actually pretty simple, mostly just boilerplate! The key piece of code is this: // Determine new move state if character can move if let (None, false) = (move_overrides.get(entity), character.move_disabled) { let state_update = character.move_state.handle(&EcsStateData { entity: &entity, uid, character, pos, vel, ori, dt: &dt, inputs, stats, body, physics, updater: &updater, server_bus: &server_bus, local_bus: &local_bus, }); character = state_update.character; pos = state_update.pos; vel = state_update.vel; ori = state_update.ori; } </code></pre> The character's action_state</code> update logic is similar, so we only need to focus on move_state</code>. First, the code must check whether the character's MoveState can update. The character's ActionState may override the MoveState, or there may be some outside override occurring from an OverrideMove</code> component. If it can, the VCSS packages all the components that any state might need to read into an EcsStateData</code> struct, and passes that to move_state.handle()</code>. More on this function later. The new shadow system (June 3rd) </figcaption> </figure> What's so nice about this EcsStateData</code> struct is: In the future, a newly implemented state might need to read a component that doesn't currently exist or isn't needed for current states. That new component can be plugged into the EcsStateData</code> struct, without needing to update the parameters of all the existing states. They will accept (and be able to read) that new component, through EcsStateData</code> automatically. Notice, though, that this function returns something labeled state_update</code>. Well, that's the StateUpdate</code> tuple, which is really just a tuple of new CharacterState</code>, Pos</code>, Vel</code>, and Ori</code> components, that the current state has determined should be the updated state of the components. This illuminates a very critical part of the new VCSS. State update handle()</code> functions are pure. They cannot mutate any components they are passed, they must return new components. The reason for this is twofold: State handle()</code> functions only read data, and return new data, so they can be easily parallelized.</li> ECS data-behavior-constraint is maintained, systems handle behavior, and the VCSS here still handles manipulating the data in storage.</li> </ol> Alright, I bet you thought we'd move onto move_state</code>s handle()</code> function now. Not yet, but I appreciate your enthusiasm ;) First, we must know where this handle()</code> function comes from (and why). Town generation (September 2nd) </figcaption> </figure> Meet StateHandle trait</h3> It's defined in common/src/comp/states/mod.rs</code>: pub trait StateHandle { fn handle(&self, ecs_data: &EcsStateData) -> StateUpdate; } </code></pre> This guy is the glue that connects the VCSS to a state and its update logic. It takes in that EcsStateData</code> struct, and passes back a StateUpdate</code> tuple like I just explained. Knowledgeable observers might be asking: "Wait... but you just said ECS systems need to separate data and behavior, but you're implementing functions on the data to handle how to update that data?" </figure> As a newbie to the Rust language, this was a problem that made me question my entire implementation strategy (and worth as a programmer, but that's for my therapist). In case you are unfamiliar with why ECS systems are so powerful and why this was so troubling: The slowest part of game programs is usually waiting for data to be moved between cache and storage. Data-behavior-separation makes ECS systems so efficient because only relevant data is cached when behaviors are performed. Traditional Object-Oriented data-behavior-encapsulation caches the relevant data, along with all the other data (and behavior functions) that an object has, which is just wasted space in the cache. This leads to more calls to storage, and major performance hits. Rivers and erosion (September 30th) </figcaption> </figure> The key takeaway is that we want to minimize calls to storage by caching only relevant data. Bundling data up with their behavior would take up excess space in the cache! So, I spent a long time looking in the mirror and asking, "Is this what we want? Is this the right approach? What am I missing about ECS?" Of course, after wasting so much time in the bathroom, I did a little research and found that missing piece: trait member functions are syntactic sugar for static functions that accept their implementors as the first argument. And that was a sweet discovery indeed. :) What this means is that calling move_state.handle()</code> is the same as calling MoveState::handle(move_state)</code>. The function implementation is not actually bundled into the state struct, it exists somewhere outside the struct, as a static function, just like the VCSS that called it. It's not put into cache along with the data, and therefore won't waste space! The VCSS can still churn through only relevant data at lightning speed and us dumb humans can move that handle()</code> function somewhere else where it's easier to manage! Win-win. Handling StateHandle</h3> So, states impl StateHandle</code> trait to define how their data gets updated, but then you might notice something else! MoveState</code> isn't actually a state, it's the enum that defines all the possible MoveState</code>s! So why does it impl StateHandle</code>? Well, fictitious reader-in-my-head, you are quite astute. This is another reason why StateHandle</code> is the glue between the VCSS and states. Peek below StateHandle</code>s definition at the impl StateHandle for MoveState</code> and you will see that its just a big ole match statement that passes EcsStateData</code> to the handle()</code> functions of the states themselves. Moon and clouds (November 18th) </figcaption> </figure> This was a design decision that I think is important. While this matching could have been done within the VCSS itself, I chose to put it here because... It keeps the VCSS concise</li> This matching logic is an implementation detail of how states handle their updates and not a detail of the VCSS itself.</li> There are several RFC's and plans for rust to eliminate the need for matching on enum variants just to perform the same trait function that is implemented by all variants of that enum. Thus, it could likely be refactored away in the future.</li> You have to update states/mod.rs</code> when implementing new states anyway, so now we don't need to touch the VCSS file every time we want to add a new state.</li> </ol> Okay, I'm done patting myself on the back. Before I get to the stuff you care about, I should explain this nest of matches inside impl StateHandle for ActionState</code>, because this was a stumbling point for me as a newbie rustacean: /// Passes handle to variant or subvariant handlers fn handle(&self, ecs_data: &EcsStateData) -> StateUpdate { match self { Attack(kind) => match kind { BasicAttack(state) => state.handle(ecs_data), Charge(state) => state.handle(ecs_data), }, Block(kind) => match kind { BasicBlock(state) => state.handle(ecs_data), }, Dodge(kind) => match kind { Roll(state) => state.handle(ecs_data), }, Wield(state) => state.handle(ecs_data), Idle(state) => state.handle(ecs_data), // All states should be explicitly handled // Do not use default match: _ => {}, } } </code></pre> So we're matching on self</code> (an ActionState</code>)... then if its an Attack</code>, we match on kind</code> (an Actionkind</code>), and ActionKind</code> variants have some object inside them called state</code> that has the handle()</code> we want to call. Cool. Why? Let's look at BasicAttack</code>. It holds a BasicAttackState</code> struct that we will see defined in a moment. This struct defines all the data fields that BasicAttack</code> needs, along with the implementation of StateHandle</code> trait, because enum variants aren't allowed to impl</code> traits (yet). BasicAttack is an AttackKind</code> itself. We have different AttackKind</code> variants inside the Attack</code> ActionState</code> variant because this allows us to easily check character states by different levels. Sometimes we only need to check if a character is attacking, sometimes we want to know what attack they are using. Most importantly, if different attacks were added to ActionState</code> enum itself, every additional state would require updating other systems that match on action state but don't care about what kind of attack the character is using. Okay, dear reader, I think it's time ... </figure> Where it All Comes Together</h3> Take a lil' looksee at common/src/comp/states/basic_attack.rs</code>. Inside you'll find nothing surprising. You've got the BasicAttackStruct</code> I already talked about: pub struct BasicAttackState { /// How long the state has until exiting remaining_duration: Duration, } </code></pre> With a field, remaining_duration</code>, so the state knows when it should finish. This is all the data that's in this state that's going into cache. 'impl StateHandle' trait won't go into cache. It's handle</code> function initializes new components: let mut update = StateUpdate { pos: ecs_data.pos, vel: ecs_data.vel, ori: ecs_data.ori, character: ecs_data.character, }; </code></pre> It does some behavior stuff, if the remaining_duration</code> is 0, it goes back to wielding or idle state, otherwise, it ticks down remaining_duration</code>. Either way, it just returns the updated components. :) That's it, that's how a full state is implemented, from start to finish. But let's just take a moment to appreciate what's going on here. All of a single state's implementation, data, and behavior, looks like it's in one place, so it's easy to see all the important information us humans need when writing states, but the program can still separate this into its data and behavior pieces for ECS. What's more, you don't see any of the logic for anything that isn't part of BasicAttackState</code>. You don't need to know how the VCSS calls this state update, you don't need to know what other state behavior looks like, you don't need to rely on a different movement</code> systems to move the character, you don't have to worry if this state will break parallelization in the system, none of that junk! All you have in front of you is the state you care about right now, and that's the way it should be. :) So, with all that ogling and awing, I encourage you to look at other states' implementations and see how they work. Also, check out common/src/util/movement_utils.rs</code> to see what those functions can do for you, you don't have to rewrite logic that is shared across states, do you? And don't be afraid to reach out to me with questions, suggestions, or to volunteer! ;) That's all for this year! Catch you in 2020 :) </figcaption> </figure> This Week In Veloren 47 Mon, 23 Dec 2019 00:00:00 +0000 Super short blog this week, happy holidays! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @Songtronix, and @Shandley! And that's all. See you for a 2019 wrap up next week! </figcaption> </figure> This Week In Veloren 46 Mon, 16 Dec 2019 00:00:00 +0000 This week we take a look at Airshipper's progress and potential future concepts. We also have a new section, the Contributor Spotlight where we learn more about Veloren's contributors. @Silentium gives us a run-down on the state of design, and we hear about some SFX with @Shandley. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @imbris, @xMAC94x, @Pfau, @Songtronix, @Adam, @AngelOnFira, and @Shandley! @Pfaunauge has fixed fire-rate issues with the bow. He also worked on the minimap, adding scalability and zooming. @imbris fixed the minimization overflow and messed around with Iced, a UI library. Discussions are happening about potential networking changes, but it is very much in a concept phase. The RFC can be found here</a>. Contributor Spotlight: AngelOnFira</h2> The contributor spotlight is a new section of TWiV. With so many people working on Veloren from around the world, the contributor spotlight will try to capture some of the personality behind the development. </blockquote> Hey! I'm a student in my 4th (fifth) year at Carleton University in Ottawa, Canada. I'm studying computer science, with honours in game development. On the Veloren project, I'm the meta lead. I do things like write this blog, and work on the CI/CD pipeline. I'm also exploring cross-platform builds for Mac, and compiler/development optimizations. Other than school and Veloren, I work at a startup called Timsle, where I'm a backend/security web developer. I also run a security competition called Hack All The Things, and I love participating in others, like NorthSec and BSides. Game jams are also super cool, check out the Global Game Jam</a> that is coming up at the end of January! At the beginning of 2019, I had a semester off school. I wanted to start a new project in my spare time. I was interested in creating a game similar to Cube World. I wanted to learn procedural generation, lower-level graphics APIs, and Rust. As I was doing my research, I stumbled across Veloren. It was eerily odd how many of their values and goals were the same as mine. I wanted to contribute to Veloren, but I had only used Rust for simple problems, and I hadn't yet read the Rust book. I wanted to contribute in any way I could, so I picked up the blog, which only contained one post. Every week since then I've written a little about the progress of Veloren. </figure> My vision for Veloren is to create a game that can achieve what larger games cannot. Games that are trying to sell copies are produced with limited resources that dictate deadlines. It is difficult to find pure motivation for these projects, as there is always a financial aspect at the end of the tunnel. Veloren is built without these restrictions. Veloren only progresses with motivation from volunteers that want to make something neat. We are free to explore concepts that other games would have to cut due to time constraints and research capacity. We can try and fail and try again. We are the creators, we are the players, and we are the community. And I like being a part of it. If you're interested in having your own contributor spotlight, keep an eye out on the Discord! Also, feedback on this format is always appreciated. </blockquote> Airshipper Updates with @Songtronix</h2> While Airshipper can't be considered stable yet, a lot of progress has been made. A progress bar has been added if the game is being downloaded/extracted and as such you don't have to wonder if it's still doing something. Nice little quality of life improvements in the launcher </figcaption> </figure> However, note that these changes right now aren't available yet due to the code being a mess and the need for elaborate testing. On the topic of availability, Airshipper can be downloaded already but remember that the launcher right now is in an unstable state and many things will change. </figure> One of the biggest changes will be a beautiful looking UI, thanks to this concept from @SrMizuki! As you can see the launcher has a section for the news and a changelog which we seriously need for releases! :D The launcher provides profile support to encourage the use of the latest and greatest version of Veloren while easily being able to switch to a stable version for serious gameplay. This will be similar to Overwatch PTR, or Factorio's beta versions. While not noticeable in the UI concept, this is implemented but not exposed to the user yet. Dreaming big is one part but the other part is making it real! That's why the UI design concept will be realized with Iced</a>, a very promising GUI library, and I'm excited to start working on it. Your browser does not support the video tag. </video> A very impressive tour on what Iced is capable of </figcaption> </figure> Your browser does not support the video tag. SFX with @Shandley</h2> It's been challenging to add sound effects to the game. This is because there are so many areas being developed at once. We’ve added an event-dispatcher based SFX system, which allows us to decouple the SFX implementation from the development of new features. Here is a rundown on how this is achieved: The EventBus is registered during initialization of the specs::World, and holds a VecDeque</code> to which we push and read a Struct containing a sound effect constant (which references the SFX file to be played) as well as a position in the world from where it should be emitted. During gameplay, the event queue is consumed by the audio system, which locates the correct audio file from configuration and emits it at the specified position. An interesting cave </figcaption> </figure> We can then construct small ‘mappers’ which watch specific resources and entities in the world and emit events based on changes in state. For example, a simple inventory SFX ‘mapper’ watches the player entity's inventory, and dispatches a ‘ConsumeItem(Apple)’ event at the player position when the relevant change in the player's inventory state happens. We have access to the player/world state through Veloren's Entity Component System. Without needing to know about the specifics of any particular system, we can watch the state of entities during movement or combat, and "match" that entity's state to sound effects. This is also good news for non-coding sound designers since we configure a catalog of these states as constants in a .RON configuration file, they only need to update the config to attach a sound effect file to a specific state to add it to the game. </figure> So far we’ve implemented movement states such as running. gliding and basic attacks, but we’re also working on other systems in-game: Combat: including blocked/special attacks and support for special weapons with specific sounds.</li> Inventory: adding and consuming items.</li> Modifying SFX based on the player's environment, such as the surface they are standing on, or echoes created when the player is near a cliff.</li> </ul> This SFX system is in its early days, and we still need to create a lot of new sounds as the combat team evolves their systems. However, having SFX already adds a lot of atmosphere to the gameplay. Game Design Update by @Silentium</h2> Over the past six weeks, the game design group has gotten through quite a bit of the high-level combat mechanics. With new people joining the discussion every so often, the team has laid down a solid foundation for the future of Veloren's design. However, now we are getting into a bit more detail with some of our design choices. Topics that were once designed in a single two-hour session at a high level are now requiring multiple meetings to get through on a detailed level. This was expected, but the change in pace is noticeable. Our master document with all the things we have officially designed is in this</a> document, but all of it is subject to re-examination and re-design if need be. There are also a few other documents that serve as "idea dumps" where everyone involved in the design process will place their ideas during the week leading up to the weekly meeting. I have also made a flowchart that represents our current understanding of the order in which design topics can be approached. Each color represents a game system, and the topics are differentiated by that system, so don’t worry if you see two of the same topics in the chart. The current design flowchart </figcaption> </figure> Since our understanding widens with each topic we design, this chart expands and changes to fit the new model, but for now, it does a good job of showing a few of the game systems we plan to address. This chart does not show everything we plan on designing, but a fair chunk of it for sure. For right now combat seems to be our focus, but that will change once we get most of it finished up. I’m not the only one who’s excited to move on to magic and crafting :) Overall we’ve been making steady progress with our efforts, and we already have some dedicated programmers putting our designs into the game! If anyone has any questions about the process or anything we have written up, shoot me a message! That's all for this week. See you next time! </figcaption> </figure> This Week In Veloren 45 Mon, 09 Dec 2019 00:00:00 +0000 This week, we get a glance at some of the ideas behind pathfinding, both at a macro and micro level. We also see optimizations to networking, as well as the current state of the design working group. Also, a new edition of "This Month in Rust GameDev" has come out</a>! - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @Acrimon, @Shandley, @Adam, @Songtronix and @Treeco! @Acrimon is working on the underlying message system for networking. Optimizations to this will improve the connection from the client to the server. @chrischrischris has been working on pathfinding and has significant progress on prototypes. The design working group put the topic of conditions on temporary hold for now, since they should have enough to start designing skill trees for the combat system. You can check out the WIP formal document on conditions and status effects</a>, as well as the preliminary steps</a>. @danach has been working on the definitions for biomes, and you can see that document here</a>. @SrMizuki's work on the map </figcaption> </figure> Pathfinding by @chrischrischris</h2> One of the major goals in Veloren is to create a world that feels alive and dynamic and to provide a sort of simulated world over time. A major component of this world will be cities and civilizations which interact with each other. To provide this experience, an essential component is for entities to be able to travel and explore. Think of trading caravans being able to navigate long roads between cities, guards patrolling castle gates, and villagers walking from their homes to the market. The first step to making this a reality is adding intelligent pathfinding. For Veloren's pathfinding implementation, we wanted to focus on modularity and reusability. There are three major components: 1: A</h3> A generic A* algorithm which knows nothing about the world, but does know how to find the shortest path in an abstract graph. For people not familiar with the algorithm, its goal is to be given a graph and a heuristic and find a short path without having to scan the entire graph. To learn more about it, check out this excellent reference</a> on Red Blob Games. A forest to explore </figcaption> </figure> 2: Translation To World</h3> The block pathfinding component which connects the A algorithm above and blocks in the world. Its job is to use the ReadVol API to transform coordinates in the world to a graph that A can use. 3: Macro Scale</h3> This is a chunk pathfinding component that connects #1 and #2. This exists to make the pathfinding more efficient across long distances. It works by partitioning the world up into chunks and ignoring large amounts of contiguous blocks that are non-traversable. Imagine this scenario: A NPC is trying to find a path from one civilization to another across a large distance, with an ocean in between the two cities. There is a bridge connecting the two cities right in the middle of the ocean. If we only use a block pathfinding algorithm, then we look at every block in the ocean until we find the bridge. However, with this system, we can instead look at chunks of blocks. If there were 500 blocks of ocean and then the bridge, and the chunk size was 100, then we would only have to look at 5 chunks of ocean before finding the bridge instead of 500. This macro-scale pathfinding is still in the works. Your browser does not support the video tag. </video> The pathfinding in action </figcaption> </figure> I am currently working on adding ray casting to detect if the path has become invalid. This can happen when blocks are placed and blocking off the old path, or explosions destroying terrain. My project partner is also working on making it hierarchical, by having NPCs create paths along chunks and then along blocks for more efficient pathfinding. The sun sets on the savannah. See you next week! </figcaption> </figure> This Week In Veloren 44 Mon, 02 Dec 2019 00:00:00 +0000 Small blog this week! Advent of Code</a> has started, and I've become strapped on writing time. Others also have a lot going on, and so there aren't any major writeups. However, I have compiled some of my ramblings into a new TWiV section. - AngelOnFira, TWiV Editor Contributor Work</h2> Thanks to this week's contributors, @AngelOnFira, @xMAC94x, @Pfau, @Adam, and @Treeco! This week, @Pfau got the first animated UI element going! @Zesterer and @imbris helped out with the implementation. @Sharp is continuing to work on sediment transport in the erosion system. @AngelOnFira has worked on more GitHub Actions CI testing and compression of assets. View of the sediment transport </figcaption> </figure> @Silentium also prepared a flow chart to guide the topics covered in design meetings. </figure> Since I don't have much content to curate about this week, it's time to rant about stuff I've been exploring. As meta lead, I deal with a lot of experimentation of stuff that you don't see in the game. From this, I've written some incomplete blog posts. Taking inspiration from His Dark Materials, here is the first edition of the "Lantern Slides" Lantern Slides: Mac Build Predicament</h3> Building for Linux is easy. Veloren developers work across many different flavors of it, so we have a good breadth of installation instructions. Windows is also pretty standard, and its drivers are quite resilient. Mac, on the other hand, is not so friendly. With our deployment setup, we want to be able to build executables from an Ubuntu runner. Although this is Linux, it can build for Windows with a specific Rust target installed. Mac also has a target that can be installed on Linux, however, it also needs a specific compiler. Exploring the wild </figcaption> </figure> The compiler that can be used to build Linux and Windows executables is quite standard. Mac has a special SDK that has to be used to build the compiler. I'm still learning why this is the situation, but it adds to the process required to build a Mac executable. This is much easier done when building from a Mac, however that is not great for us. The intended solution is as follows: Dump the Mac SDK from XCode</li> Package the SDK in a specific format</li> Build the compiler with OSXCross</a></li> </ol> First off, I don't want to install XCode just to get the SDK. Luckily, there is a GitHub repo</a> that has the SDKs prepared. I then made my own repo</a> that packaged them as they weren't already. Next up, I started working with OSXCross. Unfortunately this is where I'm stuck. OSXCross requires a lot of manual tinkering to get it working. The latest example of it working with a Rust project is a few years old. The documentation can only get you so far, and there is a lot of digging that has to be done. Hopefully, this can be ironed out before the 0.5 release, as I've promised Mac builds for quite a while. If I get it working, I would like to build a prototype Docker image that can be used to target Mac from Linux for Rust. This will hopefully be useful for the Rust CI community, as currently, I'm not aware of any other option than building from a Mac device. With GitHub actions just releasing with Mac runners, hopefully, there will also be other solutions parallel to this one. Mountain above the clouds </figcaption> </figure> Lantern Slides: Unfinished Rust CI Blog</h2> Since Rust is a compiled language, it uses many techniques to help lower compile time. Most of these include storing files in the target/ folder of the project. Looking at Veloren as a Case Study</h3> Veloren</a> is an open source game being developed with Rust. One of the key reasons we use GitLab for Veloren is the integrated CI. We have several GitLab runners that are each used for all of the CI tasks that Veloren requires. Each runner can compile, test, lint, verify, and build executables. The Docker image used on the runners</a> contains: All of the dependencies for builds</li> A specific version of Rust that is forced in dev as well</li> Targets for cross-platform builds</li> Rustup components for tools like Rustfmt and Clippy</li> The cloned project for easier checkout during builds</li> A target folder populated from cargo run</code></li> </ul> This means that the Docker image is quite large, around 6gb. This is unfortunate, however, it greatly helps CI times. During CI, some of the benefits from this are: The entire ~150mb project doesn't need to be re-cloned each time</li> The specific Rust version doesn't need to be installed</li> Many of the dependency crates won't need to be rebuilt, let alone redownloaded</li> Many of the source files for Veloren are already compiled. Therefore, since many merges to master don't change all the files, they only have to compile the files they changed.</li> </ul> A view of the current terrain </figcaption> </figure> The runners have a cache that stores the target/ folder after each build. It uses a Docker anonymous volume for this. Here is what the target folder looks like after a week of a runner's work: 11G target/debug 1.3G target/release 2.5G target/x86_64-pc-windows-gnu </code></pre> The size difference makes sense since the initial compile and all tests are run with the Linux target. This stores artifacts in target/debug. The target/release and target/x86_64-pc-windows-gnu only hold the final executables for their respective platforms. However, the size of the folders is quite a problem. Since this runner has only been running for a week, a 15gb target folder is quite large. A runner that is new and contains only a single build of each type takes up the following space: 6.1G target/debug 1.5G target/release 2.4G target/x86_64-pc-windows-gnu </code></pre> Note, the reason that target/release is bigger is most likely that the runner didn't get asked to run that specific stage. </blockquote> So, in the week that the runner was doing jobs, it accumulated around 5gb in just the target/debug</code> folder. In fact, some of our runners have accumulated 100gb+ of target artifacts. This has caused us to sometimes run out of space on the runners, which we've then had to manually restart. Not ideal. Your browser does not support the video tag. </video> The new animated map by @Pfau </figcaption> </figure> Let's examine some other differences between the target folders of these runners. Let's call the runner that has run for a while old runner</code>, and the new one new runner</code>. First, here is</a> some great information about what the target folder contains. Let's take a look at what the target folder of new runner contains: drwxr-xr-x 8 root root 4096 Jul 21 20:29 . drwxr-xr-x 5 root root 4096 Jul 21 19:43 .. drwxr-xr-x 153 root root 12288 Jul 21 20:29 build -rw-r--r-- 1 root root 0 Jul 9 12:05 .cargo-lock drwxr-xr-x 2 root root 131072 Jul 21 20:33 deps drwxr-xr-x 2 root root 4096 Jul 21 20:29 examples drwxr-xr-x 836 root root 45056 Jul 21 20:30 .fingerprint drwxr-xr-x 41 root root 4096 Jul 21 20:33 incremental drwxr-xr-x 2 root root 4096 Jul 9 12:05 native -rwxr-xr-x 2 root root 4487824 Jul 21 20:29 veloren_chat_cli-94fcc09b2c5cad1e -rw-r--r-- 1 root root 2942 Jul 21 20:29 veloren_chat_cli-94fcc09b2c5cad1e.d -rwxr-xr-x 2 root root 4487808 Jul 21 20:29 veloren_client-d0c1376a22680bbe -rw-r--r-- 1 root root 2896 Jul 21 20:29 veloren_client-d0c1376a22680bbe.d -rwxr-xr-x 2 root root 11732848 Jul 21 20:29 veloren_common-0b3ae1d1ad5c1cb1 -rw-r--r-- 1 root root 2812 Jul 21 20:29 veloren_common-0b3ae1d1ad5c1cb1.d -rwxr-xr-x 2 root root 82117288 Jul 21 20:20 veloren-server-cli -rw-r--r-- 1 root root 3758 Jul 21 20:19 veloren-server-cli.d -rwxr-xr-x 2 root root 4487840 Jul 21 20:29 veloren_server_cli-d029ad657c74936b -rw-r--r-- 1 root root 3775 Jul 21 20:29 veloren_server_cli-d029ad657c74936b.d -rwxr-xr-x 2 root root 5311464 Jul 21 20:29 veloren_server-fc3a2f6366701d99 -rw-r--r-- 1 root root 3725 Jul 21 20:29 veloren_server-fc3a2f6366701d99.d -rwxr-xr-x 2 root root 227318048 Jul 21 19:34 veloren-voxygen -rw-r--r-- 1 root root 9061 Jul 21 19:29 veloren-voxygen.d -rwxr-xr-x 2 root root 23485928 Jul 21 20:29 veloren_voxygen-fb154c7c142b5881 -rw-r--r-- 1 root root 9078 Jul 21 20:29 veloren_voxygen-fb154c7c142b5881.d -rwxr-xr-x 2 root root 4563864 Jul 21 20:29 veloren_world-1f1dbc7fde8cc98d -rw-r--r-- 1 root root 3466 Jul 21 20:29 veloren_world-1f1dbc7fde8cc98d.d </code></pre> Here is where I stopped writing. Maybe someday I'll finish these ideas and write a remediation blog alongside this analytical post. </blockquote> The place where the rivers meet. See you next week! </figcaption> </figure> This Week In Veloren 43 Mon, 25 Nov 2019 00:00:00 +0000 This week we get a postmortem from @Sharp about their learnings on erosions to generate rivers and better land features. Also more on the CI improvements, a new article on dtf.ru, and other updates. Contributor Work</h2> Thanks to this week's contributors, @Zesterer and @xMAC94x, @Pfau, @Songtronix, @Slipped, @shandley, @telastrus! This week, @xMAC94 and @AngelOnFira have been working on upgrades to CI. @xMAC94x worked primarily on improving the current CI by building the base image more frequently. @AngelOnFira focused on experiments with new CI setups on GitHub Actions, and some more OSXCross for Mac builds. @Songtronix got the FreeBSD build to compile again. They also worked on improving logging. @RonVal4 and @DoNeo wrote a Veloren article on dtf.ru</a>. It's worth a translated read if your Russian isn't очень хорошо! The game design group met up last Saturday to discuss non-damaging conditions in-game. They will be meeting again this Saturday to finish up this topic. @chrischrischris will be continuing their work on advanced pathfinding for agents. Screenshots coming up in future devblogs! @imbris has been working on a bug where entities aren't properly sent to the client. The bug occurs when entities leave the visible range from the player and come back in. @imbris is close to solving the issue, but there are still some anomalies. @Felixader has another Imgur gallery</a> with some work they've been doing this week. @shandley has been continuing work on SFX. River postmortem by @Sharp</h2> After having done a lot on river, erosion, and world generation, @Sharp takes some time to dive into some ideas. </blockquote> Nobody has ever been able to figure out a way to make river networks that fit the terrain with pure noise. The original authors of ideas like Perlin Noise were explicitly trying to find ways to reproduce geological features without running expensive simulations. These simulations would have been impractical for the time when they were working on these ideas many years ago. They were able to successfully reproduce things that evoked the feelings of a lot of terrain. Shattered hills, some kinds of ridged mountains, and so on. But never river networks, glaciation, or other processes that evolve in a more "global" way. Even though they sometimes produce fractal-like patterns, they don't do so randomly. Mountain above the clouds </figcaption> </figure> People had the idea to just model the physical processes of things like water flow directly a long time ago. I think the first paper on computationally simulating hydraulic erosion came out in 1989. However, most of these early algorithms were "explicit", meaning that each new step relied exclusively on the values of the previous step. This made computing iterations much faster and simpler, and easy to parallelize. This is because each grid can operate in isolation for each round, and then just look at the effects of a previous round. However, the downside is that explicit numerical methods do not converge to the same solution if you make the time step large enough Each of them has a certain range of time steps where they are "stable" and this varies by algorithm. If you're applying lots of different methods like this (as you often do for things like erosion), you are limited by the shortest convergence time scale of any of the methods In practice, this time scale is sometimes measured in years, or even days. While we need to simulate erosion over millions of years to get realistic looking landscapes. </figure> The more recent innovations that have allowed these techniques to scale to large areas and time periods have thus been in finding clever implicit algorithms for solving these problems. In each iteration, an implicit algorithm computes values for all the cells "at once". This is done by solving partial differential equations, either exactly or using numerical methods with guaranteed convergence rates per iteration. The downside is that these equations are much more complex, and often require global information and ordering of the solution that makes them difficult to parallelize. The upside is that a fully implicit method's convergence is not dependent on the time scale. This means that you can set it to any scale you want, so it will never be a bottleneck to your erosion algorithm. Our fluvial erosion algorithm is a mixture of the two. First, we explicitly compute a river drainage network at a discrete-time point, and we only consider a single path from node to node rather than potential water flow from all paths. Second, we implicitly compute the differential equation that predicts the effect of shear stress on the land elevations along that flow. Shear stress is the pushing effect that fluids have normal to their direction of flow. This allows for far larger time steps than we could use otherwise while guaranteeing, if not complete convergence, then at least something very close to it. A river at the bottom of a valley </figcaption> </figure> Fluvial erosion is the process people are familiar with where water weathers the rock it flows over, eventually forcing it down and producing deep gouges. It gets stronger the higher its volume per time, which we approximate with the area flowing into the cell. This is one reason we compute a drainage network explicitly; the other is to figure out a single slope we can use in the equation. We currently combine this with three other algorithms. The first is tectonic uplift. This is relevant over large timescales. On land, at least some parts (not sure if all), there are areas where tectonic processes are causing more material to be released and thus rising the land above them. This allows mountains to develop out of even formerly flat ground and is a large advantage to us over other erosion algorithms that eventually tend to make all land flat. Tectonic uplift map </figcaption> </figure> The second is thermal erosion, which reflects the tendency of rock to "slide" when above a certain angle. This is known as its talus angle, also called its angle of repose. It is dependent on the rock type and relates to the steepness that the rock grains can be heaped at before they start to slide down. This corrects the tendency that stream power has to create extremely steep slopes, by breaking down the rock when it gets too steep, and has a large effect on the final elevation and overall map shape. It also has a nice side effect of limiting overall altitude in the presence of uplift. I think this is distinct from "mountain height" as mentioned in the paper, which I believe refers to how high a particular ridge can get before depositing into a basin; but I'm not sure. The third, just added on my branch, is hillslope diffusion. This reflects the tendency of land to "slump" into each other, even below its angle of repose, and is a catchall for the effects of lots of different processes (e.g. wind). This equation is fully implicit, meaning it converges for every time scale no matter what, so it is pretty easy to add on as a step at the end. It is responsible for effects like making hills convex, beach slopes gentle, filling in small depressions, and creating new lakes (e.g. "oxbow" lakes) by blocking rivers with sediment. We still use noise to influence uplift rates at each point, compose an initial continent shape, and control parameters to the erosion equations (such as rock strength and diffusion rate). We also still use noise heavily in the local generation of features, and for things like deciding on humidity and temperature maps; however, these things are also weighted by other factors (like altitude and flux). Over time, we hope to decrease the role of noise as we simulate more processes. Mountains off in the distance </figcaption> </figure> There are many more things left to simulate, but so far this has given Veloren very distinctive and realistic-feeling worldgen compared to a lot of procedurally generated worlds, especially those which render things at a fine enough scale that you can play in them in 3D. Just having rivers and lakes guaranteed to actually flow downhill and connect up globally makes a huge difference in feel, as does having ridges in mountains and gorged valleys. With hillslope diffusion, we also have features like oxbow lakes and islands built up out of sediment (smoother than regular islands). As we add more processes, we will get more diverse terrain and more biomes, but we could also get that with hardcoded biome types or noise-based approaches. The use of physical processes, however, results in terrain that is much more interesting and diverse by comparison. This is because it allows for the interaction of all these effects. It also means that the interesting terrain will be cohesive with its environment, which is often a stumbling block for biome-based or noise-based generation. Your shattered hills may look great, but where do you put them and why are they there? The new loading screen by @Pfau. See you next week! </figcaption> </figure> This Week In Veloren 42 Mon, 18 Nov 2019 00:00:00 +0000 Welcome to TWiV 42, the only edition that comes with a towel included! This week look at the newly-created game design working group and improvements to CI. We also get some updates about authentication, asset compression, player creation, and a new song by @Aeronic. Contributor Work</h2> Thanks to this week's contributors, @xMAC94x and @Zesterer! @Acrimon has been continuing work on authentication by fixing bugs, as well as working on a Veloren video renderer. @AngelOnFira has been working on cross-compiling to Mac, as well as an RFC and discussions on moving VCS to GitHub. He has also been working on asset compression, which has resulted in a 50% decrease in the asset folder size. @SrMizuki has been working on improving the player creation screen, see the image below. @Felixader created an Imgur gallery with their work, you can check that out here</a>. @Zesterer has just finished his work on clouds, but there will be a larger writeup on that next week. The WIP character creation screen </figcaption> </figure> Verdant Glades by @Aeronic</h3> Your browser does not support the audio element. </audio> An exploration or village theme </figcaption> </figure> CI Improvements by @xMAC94x</h3> The GitLab CI cache currently copies all residual build files into a .zip (2 GB compressed, 8 GB uncompressed) before and after every job. This kills CI performance, as Rust builds leave a lot of small files and many dependencies, which take longer to zip. With the new changes, we precompile Veloren while building our CI Docker image. This cache will be saved under /dockercache/veloren/target</code> and we can make a symlink to that folder in the .gitlab-ci.yml</code> file. That way we can reuse the cache and we don't need to copy stuff. Docker is quite quick to start up the container with this cache. @Zesterer has created Moon </figcaption> </figure> We can have multiple runners going at once, compiling different branches, because Docker handles the storage completely. There is no shared storage between them. However we have a huge disadvantage, the cache doesn't get updated. This means the cache is the same every time it builds. So we don't get any advantages of Rust incremental builds between Docker image builds. When we want to update the cache, we need to create a new Docker image. However, I would expect a weekly run to be viable. This should be an overnight image build, as it takes 40 min on an 8 core Ryzen 1700X. Even if it took 3 hours it wouldn't be a problem. The new system can compile all jobs in a merge-to-master pipeline version in 32 minutes on a single runner compared to over 2 hours on the previous system. New Game Design Working Group</h3> This week, a new working group was created for game design! @Silentium is the team lead and has been working hard the last few weeks to get design frameworks in place. Two weeks ago, a design meeting was held for character stats. The process is to write a Google Doc during the meeting, and then move it to the design repo on GitLab as an RFC. Here is a link</a> to the doc, and here is the description of the topic: The idea for this system is to create a few stats that combat is concerned with. That isn't to say that other systems outside combat shouldn't have anything to do with these stats, and there should definitely be more stats than this in the game, but for combat purposes, these are a few stats that we might want to consider. </blockquote> This past weekend, another meeting was held about damage types. You can check it out here</a>. It's a cloudy night tonight. See you next week! </figcaption> </figure> This Week In Veloren 41 Mon, 11 Nov 2019 00:00:00 +0000 This week, we have lots of contributor work. A new Veloren video, some excerpts from Danari lore, and updates on Airshipper. We also just recently passed 50,000 lines of code on Veloren! The Rust GameDev Working Group also just released their October newsletter. Contributor Work</h2> Thanks to this week's contributors, @Shandley, @Qwertycrackers, @Timo, @Pfau, @Acrimon, @AngelOnFira, @AdamWhitehurst, @xMAC94x, @soruh, and @Slipped! We recently just passed 50,000 lines of code in the main Veloren repository! This is according to Tokei, so some strings may be attached :P Also, This Month in Rust GameDev #3 was just released. Be sure to check it out</a> to see what's going on in the Rust GameDev community! @Songtronix and @Acrimon have been hard at work getting the authentication site working. It's almost ready, and will allow for user authentication in a few weeks! </iframe> </div> A new Veloren video by @DoNeo and @RonVal4! It's geared for the Russian community, but there are English subtitles as well. </figcaption> </figure>First Steps by @Aeronic</h3> Your browser does not support the audio element. </audio> A piece that might play during character creation </figcaption> </figure> Airshipper 0.1.1</h3> Airshipper is now a little bit better! With the launcher, you'll be able to install Veloren's latest nightly. The launcher is still in Alpha, and there is a lot of work to be done on it. Here is the changelog for this version: - Airshipper won't close the window if an error occurred so you have time to read it. - Downloading the Linux version of Veloren will now end with .tar.gz, as suggested by Timo. - The installer will now allow you to create a desktop shortcut and customize where the game data will be stored, as suggested by Pfau. (experimental) - Default location of game data will be %appdata%/veloren - Website (https://www.songtronix.com/) now links to our social media and improved SEO </code></pre> Several new male hairstyles have been added by @Pfau </figcaption> </figure> Writing Update by @Felixader</h3> @Felixader has been continuing work on the lore of races and cultures. He just finished the Danari lore. Here is an excerpt: When the Velvet Black Army came to Veloren, the danari had long been the bureaucratic backbone of The Velvet Black Army. By then their entire culture had served the Velvet Black for so long that their home country was a distant memory. The ideal that bound their people to the Velvet Black Master was the vision that one strong leader could unite all peoples and lead to a final and everlasting peace. </blockquote> The long, drawn-out war against Dwarves and Elves that taxed the Velvet Black Army damaged that vision. Veloren's people held steadfastly and solidly over decades even as they lost battles every day. Unaccustomed to a difficult battle their leader became unbearable, even for them. As their master's impatience grew to cruelty, the danari were the first to see his true nature. </blockquote> It took a while since the vision for universal peace through conquest was so integral to the danari’s view of themselves. But behind the curtains of the Velvet Black Court, the danari decided after many meetings and council sessions to act. </blockquote> WIP palms by @Slipped </figcaption> </figure> You can take a look at the Danari lore and lots of other writing here</a>. The next steps are going to be race/culture relations and motivations as they are at the time when the player enters Veloren. In the short term for 0.5, here are some of the plans: - Around 50 artifacts to find and fill a collection book. This will motivate players in 0.5 to explore the world. Additional to this task: - Making the symbols in form of pixel art for in the inventory - Adding lore text to the artifacts. </code></pre> And for the longer term: - Constructing various quests, with phases that outline possible Quest task. - Relating how some of those quests could play into the faction simulation. - Constructing various quests that are directly related to the faction simulation, with phases that outline possible quest tasks. </code></pre> @Felixader working on a relations chart for factions in Veloren </figcaption> </figure> You now start the game with a little breakfast in your pocket! See you next week :) </figcaption> </figure> This Week In Veloren 40 Mon, 04 Nov 2019 00:00:00 +0000 This week we have a small blog. To account for this, we have a large gallery section that shows off some neat screenshots in-game. We also take a look at the player survey for a second time, analyzing the interest in certain systems. We also hear a bit about the first design meeting. Contributor Work</h2> Thanks to this week's contributors, @Acrimon, @xMAC94x, @Pfau, @Soruh, @Zesterer! This week has been quite slow on updates, lots of the work is behind the scenes. @Timo and @Daddy Demon are working on adding a lot of new weapons to Veloren. Combat met for a design meeting this week, and it was the first time that the new design process was followed. There will be work in the upcoming weeks to refine this process and improve the design RFC system. This is being headed up by @Silentium. You can check out the combat design overview here</a>. New water shader by @Zesterer. Left is the old shader, right is the new. Pic by @Treeco </figcaption> </figure> New login information </figcaption> </figure> New weapons that @Timo and @Daddy Demon are working on </figcaption> </figure> Player survey part 2</h2> A few weeks ago, we had a survey that we send out about Veloren. We already went over some of the results here</a>. We got lots of other information that we didn't cover there, so let's look at some more of it! </figure> </figure> What do you want Veloren developers to focus on? Blue is less interested and increases to purple, which represents high importance to the community. </figcaption> </figure> This question gave a lot of data. Three main categories were quite clear, combat, exploration, and progression. It makes sense that these stand out as they have been pillars of Veloren's development up until now. The rest of the categories are quite similar. There are still some other indicators we can see through. Specifically, what had the least importance. These were survival, building, and story. Now, these are topics that we have big ideas for. But the implication of the survey suggests that it is not what needs to be focused on to get people interested in Veloren. We can compare this to some of the results on what the community is looking most forward to: </figure> As we can see, there are still high results for PvE (combat) and exploration. It's still interesting to see how little of a focus there is on PvP. "Getting around" also has quite a high score. This is a system that the dev team is quite inspired by, so much so that the install tool for Veloren is called "AirShipper" :P </figure> Finally, we take a look at the most important systems to have prepared for a 1.0 release. This insight will help us scope the roadmap a little more. Again, we see combat and progression as important tasks. The item system and animation are following up. These are systems that are being improved at the moment. NPC AI will have to be looked into, as the current system is quite primitive. The results of the survey have allowed the dev team to get a better idea of what will get the community interested in Veloren's gameplay instead of the tech demo it currently is. In the next survey analysis, we'll take a look at some of the individual unique responses. Gallery</h2> Since we don't have a ton of content to read this week, let's check out some cool screenshots! </figure> </figure> </figure> </figure> </figure> That's all for this week, see you soon! </figcaption> </figure> This Week In Veloren 39 Mon, 28 Oct 2019 00:00:00 +0000 This week we discuss the 0.5 intro meeting that occurred last weekend. Some topics include design meetings and the Liberapay plan of action. We also stop in with @imbris, who shows off some new optimizations with caching, as well as a bug that prevented spawned objects from being shown. Contributor Work</h2> Thanks to this week's contributors, @imbris, @Slipped, @Timo, @Acrimon, @Pfau, @Songtronix, @soruh, @pestilence, @xMAC94x, and @LunarEclipse! The first design iteration for Veloren's login website </figcaption> </figure> @Songtronix has been working on testing and fixes for Airshipper, which is slated for release soon. @SrMizuki is working on general user interface improvements to try and find a balance between functionality, design, and user experience. </iframe> </div> A positive message from @Lulu! </figcaption> </figure> @Soruh has been working on upgrading dependencies to get rid of security issues from RUSTSEC. @AngelOnFira has been working on getting a MacOSX target set up. This has proven to be quite difficult, but it will allow CI to automatically build Mac executables. Some variations of axolotl by @Axolotl </figcaption> </figure> Optimizations by @imbris</h2> Time for a mini flame graph story. I hadn't run a flame graph recently and there had been some improvements to meshing speed among other changes to the engine. I was curious about what the current flame graph would look like, so I gave it a go. The result showed that meshing was still a huge chunk of the flame graph, especially now that I could crank the view distance up past 25. Taking another look at it, I discovered there was a portion of the code doing lookups into the volume that didn't use the cached access that I had previously added. It caches the last accessed chunk to prevent a hash map lookup for every block since most will be in the same chunk. The code of interest looked up adjacent blocks to determine which faces were exposed and thus needed to be meshed. </figure> For a moment I considered using the caching here as well. However, the color smoothing was already accessing all the adjacent blocks which I took advantage of essentially removing redundant block accesses. Now the main bottleneck is the lighting flood calculations which is slated to be moved out of meshing entirely. For more information, check out !625</a> Object Spawn Bug by @imbris</h2> Here's what happens when the client sends the /object chair</code> chat command. For context, the server communication with clients was moved into the ECS systems. The relevant server code looks like this: // 3) Handle inputs from clients frontend_events.append(&mut self.handle_new_connections()?); // Handle game events frontend_events.append(&mut self.handle_events()); let before_tick_4 = Instant::now(); // 4) Tick the client's LocalState. self.state.tick(dt, sys::add_server_systems); // Tick the world self.world.tick(dt); // 5) Fetch any generated `TerrainChunk`s and insert them into the terrain. // in sys/terrain.rs let before_tick_6 = Instant::now(); // 6) Synchronise clients with the new state of the world. // TODO: Remove sphynx // Sync 'logical' state using Sphynx. let sync_package = self.state.ecs_mut().next_sync_package(); self.state .notify_registered_clients(ServerMsg::EcsSync(sync_package)); </code></pre> During state.tick()</code> one of the systems, message</code>, receives messages from clients. When it gets this chat command, it pushes it onto the server-side event bus. So our /object chair</code> commend is pushed onto this bus. But where does it get handled? In self.handle_events()</code>, which occurs before state.tick()</code>. This means we wait until the next tick to handle the chat command. This might introduce some latency but logically we are good so far. Now the next tick arrives and a chair entity is assembled and inserted into the world inside of self.handle_events()</code>. Rat </figcaption> </figure> Now we get to state.tick()</code>. At this point, the ECS systems are run including the entity_sync</code> system which is responsible for sending physics updates to the clients. This includes the Pos</code>, Vel</code>, and Ori</code> components. It happily does this, since the chair has no Last<Pos/Vel/Ori></code> components, which are used to track whether an update needs to be sent. The client then receives this information and processes it in a match</code>: ServerMsg::EntityPos { entity, pos } => { if let Some(entity) = self.state.ecs().entity_from_uid(entity) { self.state.write_component(entity, pos); } } ServerMsg::EntityVel { entity, vel } => { if let Some(entity) = self.state.ecs().entity_from_uid(entity) { self.state.write_component(entity, vel); } } ServerMsg::EntityOri { entity, ori } => { if let Some(entity) = self.state.ecs().entity_from_uid(entity) { self.state.write_component(entity, ori); } } </code></pre> The client then promptly converts the UID to its associated entity and uses that to insert the received value e.g. the position... or does it? In reality, the client doesn't know this entity exists and so it just throws out this information since entity_from_uid()</code> returns None</code>. Meanwhile, the server keeps going through the current tick, all the way to: self.state.notify_registered_clients(ServerMsg::EcsSync(sync_package)) </code></pre> Here, sphynx bundles up all the information it manages, like new entities! And that is sent to the client. So our client receives this and a positionless (effectively invisible) chair is created on the client's side. And because that chair never moves the server won't waste network bandwidth sending its position again. The evasive chair, at long last </figcaption> </figure> 0.5 Intro Meeting</h2> Last weekend, we met up to discuss what we were going to achieve in 0.5. Each team lead also gave a rundown on what they had worked on during 0.4, and their goals for 0.5. The meeting attendees list keeps getting longer! </figcaption> </figure> @Silentium and @AngelOnFira are working on working on coming up with a better process to make design decisions. The process focuses on regular design meetings and request for comments (RFC). A design meeting will consist of discussion on a specific topic, with a moderator to keep the conversation in scope. This meeting will produce an RFC document, which will be added to the Veloren RFC repo. Anyone will be able to discuss the RFC in the comment section. Once everyone has been able to voice their opinion, a selected few will sign off on the RFC, and it will be added to the MDBook. The MDBook will be an accessible collection of all finalized design ideas. Since the MDBook only includes finalized ideas, it will be easier for external parties as well as contributors to understand Veloren's design. For more information on the process, take a look at the WIP document</a>. Down by the riverside </figcaption> </figure> Although a formal description for 0.5 has not been written yet, some initial ideas were brainstormed for what the release could include; - More player combat design in the game, multiple skills, more weapons. Individual behaviors, left click is different on sword and axe - Skills with buttons on the keyboard - Some effects from the skills. - Integrating this with levels and XP, so that people have reasons to progress. - Make NPCs drop stuff - Crafting - Fishing action - Initial implementation to prehistory simulation - Initial implementation of real-time simulation - Have NPC AI hook into the realtime simulation - Rework towns and populate them - Have some basic trade/reputation mechanics </code></pre> The release date of 0.5 has been moved forward to sometime in January rather than the beginning of December. Since 0.4 was released partly into October, contributors would have been stressed on time to get new content ready for 0.5. On top of that, since many contributors are in school, progress is made a bit more slowly. The new release date is still being figured out, but it will be at least a week into January. This will hopefully allow for a healthy code freeze period right after the new year. Liberapay was also a big topic during this meeting. The core team is working on setting up a crowdfunding model for Veloren. It is important to note that this model is incredibly experimental. Many tweaks will be made, and the logistic setup of the process is still ongoing. This model would follow three phases: # Phase 1 - Anyone can donate, but not advertised as much - Money only goes to official infrastructure, rest is saved for Phase 2 # Phase 2 - Anyone can donate - Infrastructure costs have the highest priority - The remainder is distributed into each working group by the leads # Phase 3 - Anyone can donate - Infrastructure costs have the highest priority - Process of remainder usage is refined depending on the outcome of Phase 2 </code></pre> For more information about the meeting, you can take a look at the meeting minutes</a>. That's all for this week. See you next time! </figcaption> </figure> This Week In Veloren 38 Mon, 21 Oct 2019 00:00:00 +0000 Small blog this week. With the team still recovering from the 0.4 release, bigger changes are starting to come along. @Sharp talks about some of the future work with rivers and undertow. @DoNeo and @RonVal4 have started a Russian Veloren community. Contributor Work</h2> Thanks to this week's contributors, @Songtronix, @Zesterer, @lawtonfogle, @shandley, @Sharp, and @Pfau! @Felixader has been continuing work on Veloren lore. They finished the undead protectorate lore and based on this, added a better reason why the Orc tribes are split in two. @Songtronix is almost ready to release Airshipper! In the way Airshipper is currently implemented, you will be able to create profiles where you can set a name, a channel (release, nightly) with their own voxygen config. This will be useful when mod support comes up, so that you can easily switch between enabled mods. A panda model made in tribute to @Lulu's positivity on the Discord server </figcaption> </figure> @DoNeo and @RonVal4 have been working on setting up a Russian community for Veloren. You can check it out here</a>. They are working to translate the blog and bridge the language gap for the purely Russian community. They have also been working on creating some models for the game. Rivers update by @Sharp</h2> Lakes, rivers, and erosion were merged! World generation is now dramatically different from before, with much more terrain variety, and consequently more memorable locations. It also has large-scale geographic features, such as plains, lakes, and mountains that extend for many square kilometers, as well as rivers that span more than half the map. Note that this makes worldgen take much longer as it is simulating 12.5 million years of erosion. So if singleplayer seems not to be working after you click the button, just wait for it to finish. It usually takes a minute or two. We will soon be adding a loading screen and the ability to cancel singleplayer early to make this more obvious to players. </figure> I've been working on adding somewhat physically realistic river undertow so river flow properly affects characters and items when submerged. This also requires solving river self-intersections, to give the rivers an impact on gameplay beyond their effect on world generation. On my branch, we are already properly transferring over river velocities and having them push around a player, so the remaining work is mostly little tweaks to make the velocities nicer and apply the drag equations more effectively (I will probably not add lift yet, but we'll see!). Once these are solved, the next step will be modifying the river renderer to also reflect the flow direction at each point (I might also work on this concurrently). The sun sets for this week. See you next time! </figcaption> </figure> This Week In Veloren 37 Mon, 14 Oct 2019 00:00:00 +0000 This week, we released 0.4! We hear back from @Vercidium with another graphics analysis. We also take a look at the server usage from the launch party, as we had over 40 players connected at once. There has also been a lot of work done for asset creation. Contributor Work</h2> Thanks to this week's contributors, @Timo, @KyoZM, @Acrimon, @AngelOnFira, @xMAC94x, @imbris, @Zesterer, @Pfau and @lfauvel! Many artists have been working on weapon models this week. @Jollyfish, @Duko, @Shimox, and @Silentium were some of the many to do this. We've also had many other artists working on other components, such as @gallostrart and @Zornithorinque working on trees, and @Lawtonfogle working on hot loading armor. More weapons by @Jollyfish </figcaption> </figure> @Felixader has been keeping up with expanding lore, this week was about the background of orcs. @Sharp has just completed their river, lake, and erosion work. This is in the process of getting reviewed, and should be merged in the next few days! @Zesterer and @Sharp have been in talks about world simulation, and there will likely be groundwork done on this in the next few days. @Zesterer also worked on lots of improvements and cleaning up the code. @Qutrin is working on implementing stat points to give your character benefits, such as health or weapon damage. Render Analysis #2 by @Vercidium</h2> I've been asked by Yuri to analyse the game's performance again so here we go :) I had 60 FPS while playing the game for a couple minutes and all seemed good, but then it dropped to 30 FPS. I captured a single frame and noticed there were still large gaps in the rendering pipeline where the CPU wasn't sending any work to the GPU (see the red lines on the image). I think this is still caused by GFX though. </figure> The map was taking 13.82ms to render and the water was taking 16.15ms to render, but I hadn't seen any water yet. After restarting the game I was running at 60 FPS again, however there were still gaps in the pipeline: </figure> I'm not sure how the water shader works but it seems like it's not doing any work at all. After finding some water and analyzing the telemetry, I wasn't sure why 519372 water vertices were being rendered. Especially since the shader looked like it was just creating flat triangles. The shader appears to be spending 62.65% of the time doing nothing. I'd recommend aligning water chunks to map chunks and only rendering the water chunk if that map chunk is rendered (frustum culling). </figure> The map is still drawn in a random order with no frustum culling. Frustum culling is a must! There are a lot of chunks completely outside the view that are still being drawn. There were 162 chunks rendered that didn't end up on the screen. On top of that, there were 1175 rendering calls (mostly water) that didn't end up rendering any colour pixels to the screen. This is because there are lots of water rendering calls that are asking the GPU to draw 0 triangles. </figure> Map rendering at 25 view distance spends 19.75% of the time doing nothing on the GPU. I think that's still a GFX issue but damn 6.7 million vertices per frame is a lot. Top limiting factor in the rendering pipeline is Viewport Culling at 33.9%, followed by Vertex Attribute Fetch (loading a bazillion triangles) at 30.2%. Rendering the chunks is quite fast with SM Active is at 62.2, it's just that there's a lot of fluff GFX does (16726 redundant OpenGL calls a frame) before it actually tells the GPU to render the chunk. </figure> That's all from me, I hope it helps! Launch party</h2> This week, we officially released 0.4! Thanks to all of the great contributors to this version, @Zesterer, @Timo, @imbris, @Acrimon, @Sharp, @Destinghim, @Slipped, @AngelOnFira, @Pfau, @Geno, @scott-c, @haslersn, @Qutrin, @Vechro, @xMAC94x, @KyoZM, @Andrewpritchard, @Songtronix, @Shanehandley, @telastrus, @christofferlantz, @stevedagiraffe, @Vercidium, @Demonic, @tommy, @arashout, @nick12, @lfauvel, @wusyong, @cauthmann, @yashaslokesh, @artem, @carbonhell, @appcrashwin7, @LunarEclipse, and @keller! Also thanks to everyone else who added something of their own to Veloren, the community is really what pushes this project forward :) The launch party went great, with over 40 people joining at its peak. With over 3000 people in the Discord server now, we reach a lot more people with @everyone :P You might have noticed that the download link was through Airshipper. Although future versions of Airshipper will have clients that you can install on your computer, you can rely on this link to get you the latest version for now. </figure> </figure> Now let's take a look at some of the server graphs! Above you can see the tick time broken down, as well as the CPU task parallelization. For the launch party, we specifically reserved a powerful server to make sure our load would be handled. Turns out it was more than handled. The server used was an AWS EC2 instance, c5.9xlarge. This instance has 36 vCPUs, which have 141 ECU of compute power. It also has 72 GB of ram, but we were really not limited here. The instance cost ~$1.8 CAD an hour, however the real cost was from bandwidth, more to come on this below. As you can see in the CPU usage graph, we were using around 20% of the server's compute capacity with the 40 players. Projections would show that we should be able to handle at least four times the number of players. Maybe more depending on the standard overhead that the Veloren server has. </figure> </figure> </figure> Above you can see graphs of the players on the server, and the number of chunks loaded, and the memory usage of the server over time. The number of chunks grew over time as players explored further away from spawn. The memory usage also increased quite proportionally to the number of chunks. </figure> The real killer of the launch party was the bandwidth. At it's peak, the server was sending out about 50 MB/s, or 400 megabits per second. That equated to around 1 megabyte per second for each player. This will have to be a domain of heavy work in the next few versions. Over the entire launch party, 110 GB of data was sent out from the server. AWS really charges hard for bandwidth use, and so this incurred a cost of ~$8 CAD alone. In the future, we'll likely host through a different service. @AngelOnFira getting content for the devblog. See you next week! </figcaption> </figure> This Week In Veloren 36 Mon, 07 Oct 2019 00:00:00 +0000 Thanks to this week's contributors, @Timo, @AngelOnFira, @Acrimon, @KyoZM, @Songtronix, @stevedagiraffe, @shanehandley, @Pfau, @Qutrin, @Nick12, @Slipped, @Zesterer, @appcrashwin7, @LunarEclipse, @haslersn, @Wuyuwei, and @keller! This month we're featured front and center of This Month in Rust GameDev</a>! Be sure to check this blog out, there is a lot of other great work being done in the Rust gamedev community :) We're also right on the verge of our 0.4 release, and were working to squash all the bugs we can. Expect a new version this time next week! Here is a new video highlighting different structures in Veloren. </iframe> </div> </figure>Contributor Work</h2> With 0.4 approaching quickly, the core team has been hard at work fixing bugs. One of the primary goals is to fix problems that prevent players from opening the game. @Jollyfish's weapon creations </figcaption> </figure> @Songtronix has been continuing work on Airshipper and also fixing Discord Rich Presence and Torvus. @Qutrin worked on giving enemies levels when they spawn and displaying it on their nametags. @shandley has been working on audio tweaks. @Pfau started working on the UI component of a map. There is still a ton of work to go on this front. Qutrin's new enemy level work </figcaption> </figure> We've seen a ton of new contributors come in this week, and start working on great stuff! @Jollyfish is working on a large assortment of weapons, mostly varieties of polearms. @Felixader is working on bringing writing back, as they expand the background lore of elves and dwarves. @Argoplantus has been having lots of discussions that focused around system proposals. @Shimox has worked on creating variants for log mobs. @Shimox's log mobs </figcaption> </figure> Erosion and Rivers by @Sharp</h3> In games or as a sort of core for research purposes, the usual way people do erosion is as follows. Approximate your surface as a height map consisting of a series of points with associated altitudes. In Veloren, we approximate each map chunk as a "point". For each point, figure out the neighboring point most downhill of it, and call that the point's receiver. Repeat this until you have a directed and acyclic forest of nodes pointing to your "boundary". The boundary is comprised of the nodes at the edge of the map that aren't expected to have a downhill, usually the ocean. This graph models river flow using the core assumption of all of these models: water flows along the shortest path downhill until it hits the ocean. Now, reverse the graph. Starting from points that have no incoming flows, for each point, we compute the approximate average rainfall times of the area of the point. Remember, these points represent a surface, in Veloren's case a chunk. This is your volumetric flux, or some parameter related to it. Volumetric flux is the rate of water coming out of the point per unit time. Three rivers converging </figcaption> </figure> As you traverse the reversed graph, you take the sum of all the flux coming into each point, plus the water the point receives naturally, and call that its "drainage". This represents the total amount of water that ends up flowing into each point. We also can take this opportunity to try to calculate a slope from this point to its receiver, which is the approximate slope that the water will flow downhill on. Now, we take all this information and dump it into an empirical formula called the stream power equation. This is intended to model the shear stress of water flowing over a surface per unit time. It relates drainage, slope, and some magic constants. It tells you the expected change in height per unit time from water flowing over the point. You run this on all your points, and that constitutes an iteration of erosion--water flattening out the slopes it runs over. In general, the higher the flux and the higher the slope, the more pressure is exerted. This is one of the reasons why rivers tend to run down high slope areas and make them flat. That's the basic version of erosion. But you'll note that there's a problem here: when rivers hit a local depression they stop in this model. A local depression is a point with no other downhill points that aren't on our boundary, for example, a lake. This means that this erosion equation can't get rid of depressions, even though it can introduce them. Furthermore, since we're only running erosion in this model and not other geological processes, the more iterations you run, the lower and flatter your land will become. A small river feeding into a lake </figcaption> </figure> So if you run it too many times or at too high a delta t, you will end up with a completely flat and uninteresting landscape. So, the above system is kind of limited. It should be stressed that this model is perfectly fine in some circumstances, and it is used by most games that do erosion, which is already a pretty advanced thing for a game to do. The system also has a lot of trouble generating interesting terrain by itself. It's better at more realistically shaping previously existing interesting terrain. To fix the "rivers stop at lakes" problem, people either make special maps that always flow downhill by construction. For instance, the most popular blog about this, Red Blob Games</a>, has a map where altitude always increases towards the center. So many games that have erosion and copied this article's approach and have a single mountain on an island. Either that or run one of several algorithms that fill in all depressions on a heightmap before running each iteration. You can see an example of that here</a> The "fill in depressions" method sort of works, but it has two disadvantages: It completely removes lakes from your map. This is why you may notice that when people talk about using this method in games and want lakes, they often just have lakes there from the start.</li> It is slow compared to the other steps, the best-known algorithms for drainage filling are O(n^1.5). So this even further limits how many iterations can be run.</li> </ul> Rivers running through the region </figcaption> </figure> So, what do we do? It turns out that we are not exactly the first people to notice these problems. Clever people have been hard at work figuring out how to make this equation scale to large datasets. An algorithm</a> addresses our problems in three ways: It adds tectonic uplift, another important component of the erosion model that is missing from the simplified version of the stream power equation. It turns out that if you simulate for long enough, tectonic uplift and erosion cancel each other out to form a steady state. This means that erosion can be run for as many iterations as you like without flattening out the map.</li> It comes up with a clever algorithm for lake flow connections. This allows us to avoid figuring out how to fill in all the drains to compute a consistent stream tree. The high-level overview is abstract points by the local depression (i.e. lakes) that they are in, and look for the "lowest" path between each pair of neighboring lakes. Then if we start from the boundary and always choose the lowest available path to a lake that we haven't traversed yet, we'll find a consistent path "downhill" between lakes, that will be connected if the lakes are all flooded. This algorithm is O(n + m log m) (sorta) rather than O(n^1.5), which means that even with tons and tons of lakes it finishes pretty rapidly.</li> It does this using an "implicit" algorithm that allows you to choose whatever delta t and erosion level you want without destroying convergence.</li> </ul> This is the algorithm we use. An island in the middle of a river </figcaption> </figure> Player survey</h2> Thanks to all of you that read the blog <3 </figcaption> </figure> Last week we put out a survey, and we've had a ton of responses! We've got a lot of valuable insight on many topics. With the sudden server population increase this week, it's interesting to get opinions from people who just found out about the game, as well as people who have been a part of the server for a while. Different games players have played before </figcaption> </figure> One of the big goals of the survey was to find more about the Veloren player base. And then on an even deeper level, the previous experiences of players in different games. Veloren is trying to encapsulate dynamics and pillars that can be found in many other games. For most people who look at Veloren, they can draw connections to Cube World and Minecraft. It's interesting to see the number of players that have played these games, which is near 90-100%. If we contrast this to the similarities that Veloren has to Dwarf Fortress, we don't hear as much about the overlap. There is a much smaller subset of players who have played this before; around 30%. Also, many of the underlying systems that dictate large scale world simulation haven't been incredibly visible just yet. This might be a motivation to bring out those systems that players aren't familiar with. We'll see. The different types of combat preferred by players </figcaption> </figure> An interesting discovery was the proportion of players that liked player vs environment (PvE) over player vs player (PvP) combat. Because of what people imagine of a game like Veloren, the systems that promote PvE seem more commonplace. These types of systems center around teamwork to kill bosses, or quests to find items. This is also similar to the raid systems of MMO games. On the other hand, PvP combat is quite low, at only around 30%. We can look at many other games that have similar mechanics to Veloren, and see how their PvP systems have progressed. Whether that be Minecraft hunger games, or duals in Borderlands 2, or player combat in World of Warcraft. All of these games are intrinsically PvE games, but have a PvP mask put on them. We can compare that to games that focus on PvP, such as Counter Strike, League of Legends, or Fortnite. These base PvP games would really struggle to introduce elements of PvE into them as core mechanics. This means more than just jungling in LoL, or killing chickens in CS. Veloren's theme opinions </figcaption> </figure> Finally, let's take a look at the theme of magic in Veloren. This came down to quite a close decision between soft and hard magic. Soft magic meaning that it exists in the world, however, it is not well defined. Hard magic means the world is focused around it, and it has tangible limitations. Take a look here</a> for more details. The decision of how magic is included in Veloren will likely evolve with the design and development process. It's hard to settle on this topic when there is so little content in the game. There is already quite a lot that has been written on the lore of Veloren, but how that plays out once mechanics are introduced is yet to be seen. The vote shows that more players prefer soft magic worlds. This is valuable for us to know, as these questions are very much answered with what the player's "idea" of Veloren is. Next week, we will look at some more of the results from this survey. Stay tuned! We've found the motherload! Until next week :) </figcaption> </figure> This Week In Veloren 35 Mon, 30 Sep 2019 00:00:00 +0000 Thanks to this week's contributors, @Zesterer, @Pfau, @imbris, @Xacrimon, @shandley, @Vechro, @Timo, @AngelOnFira, and @Carbonhell! New Piece by @Aeronic</h2> It's been a while since we've seen some audio in TWiV, so here you go, a new piece by @Aeronic! Your browser does not support the audio element. </audio> Grasslands </figcaption> </figure> Veloren Videos</h2> More of an effort is being made on creating video content for Veloren. Here is a video of some alpha gameplay! </iframe> </div> </figure>Contributor Work</h2> A crafting bench designed by @Vechro </figcaption> </figure> This week, @YuriMomo discovered a bug where you could fall through the terrain. The problem with this bug was that although certain users were running into it, there wasn't a standard way of replicating it. First, @YuriMomo used debugging tools to find the conditions that were causing the bug to happen. Then, once it was replicable, they were able to try reproducing it without tools. Turns out by moving forward and spamming both shift and space then moving the camera, you were able to achieve the bug. Now that the bug has been replicated and isolated, it's much easier to resolve. </figure> Above, you can see the new entity highlight system by @Zesterer. When you hover over different objects in the world, you'll be able to see if you can interact with them. You are also able to gather them into your inventory by right-clicking on them. Right now there are a few pickable entities in the game: grass (ingredient), flowers (ingredient), velorite ore (ingredient), mushrooms (consumable), and apples (consumable). Consumables can be eaten to regain lost health and ingredients will be used for crafting later on. Inventory tooltips have also been added, with different icons per item coming soon. </figure> Above is an initial crafting window concept. An idea for crafting has been getting the player able to discover recipes by themselves or by the knowledge from other sources. However, that means a player could look up a recipe in a wiki that will allow them to craft every item they could get the ingredients for. Using the items might be restricted though; they couldn't craft an epic armour set to wear at level one. Once a recipe is discovered, it could be listed on the left side and can be used again. Getting better at crafting could allow players to put more items into the discovery table, as well as other perks. </figure> Initial ideas were also developed for a trading window. The currency will probably be called "Velorite", or "Vel" for short. It is the most valuable material in the Veloren world. In this concept for trading, the idea of allowing the player to barter was proposed. Depending on multiple factors, the trader will accept or decline the offer. </figure> A new contributor, @Carbonhell, introduced a popup at the login screen that lets players cancel the login process when it takes too long. </figure> @Songtronix has been keeping up with Airshipper, Veloren's launcher. The command line interface can start an existing install of Veloren, no matter the platform. Next up is going to be checking for updated versions, and downloading them. River Work by @Sharp</h2> @Sharp has been continuing their hard work on rivers. Although they look great, there are still many optimizations that need to be made to them. They are quite a costly part of the world generation. Enjoy a large selection of screenshots, in which there are winding rivers in many different situations. </figure> </figure> </figure> @Sharp has also worked on a world map viewer to be able to see land and water. This will help with the world generation development, as it gives a high-level view of what the world looks like. </figure> New Character Proportions by @Pfau</h2> This week, @Pfau started to rework character proportions. The reason for this was to more closely follow the standard Veloren character design, but also to give Veloren artists more space for details on armour. The new models are 3 Voxels taller than the old ones. This gives one more row for the chest, the pants, and the shoes. The hands have also been modified to look more humanoid. </figure> </figure> Above, you can see cloth in the style of a Kimono as a possible armour design for casters/healers. The new models look more "heroic" and fit the level of detail of our other objects better than previous iterations. Below, you can see the concept of the Kimono armour. Characters also have necks now that clip into their heads to never have a gap between the head and body when turning the head. The sun sets for the dev blog this week. See you next time! </figcaption> </figure> This Week In Veloren 34 Mon, 23 Sep 2019 00:00:00 +0000 Thanks to this week's contributors, @Xacrimon, @imbris, @Pfaunenauge, and @Zesterer! Contributor work</h2> Many contributors are still getting into the swing of school. But we still have some great progress this week! @Yeedo has continued work on the gliding system. @imbris, @Zesterer, and @Xacrimon put in some great optimization work. @Pfau worked on fixing bugs within the character creation screen. Visuals added for deleting characters </figcaption> </figure> Improvement to Worldgen with @imbris</h2> @imbris has spent lots of time this week working on worldgen improvements. Before the work started, a flame graph was recorded. Flame graphs are used to show where the most time is being spent within different functions. You can see the initial flame graph here: </figure> The goal is to look at the widest items and try to make them thinner. @imbris noticed that a lot of time was being spent in the seed_expan::diffuse</code> function. This one is near the middle of the flame graph image. You can see that each function below it has to be just as large as it is waiting on the diffuse function to move along. This function used some code magic: /// Simple non-cryptographic diffusion function. pub fn diffuse(mut x: u32) -> u32 { x = x.wrapping_add(0x7ed55d16).wrapping_add(x << 12); x = (x ^ 0xc761c23c) ^ (x >> 19); x = x.wrapping_add(0x165667b1).wrapping_add(x << 5); x = x.wrapping_add(0xd3a2646c) ^ (x << 9); x = x.wrapping_add(0xfd7046c5).wrapping_add(x << 3); x = (x ^ 0xb55a4f09) ^ (x >> 16); x = x.wrapping_add((1 << 31) - 13) ^ (x << 13); x } </code></pre> @Xacrimon was able to simplify this function by combining a few of the operations. It gives mostly the same effect, but much more quickly: /// Simple non-cryptographic diffusion function. #[inline(always)] pub fn diffuse(mut a: u32) -> u32 { a ^= a.rotate_right(23); a.wrapping_mul(2654435761) } </code></pre> And with that, we are already able to see improvements in the flame graph! No longer do we have the long wait in the middle of the flame graph: </figure> @imbris took a closer look at some other sections, specifically the Fastnoise</code> function. While they had improved it during diffuse's improvements, it still took almost half of the time spent generating a chunk. </figure> The middle section where it was calling into libm.so was a cosine used for cosine interpolation to smooth the noise. let factor = pos.map(|e| 0.5 - (e.fract() as f32 * f32::consts::PI).cos() * 0.5); </code></pre> This was being used instead of linear interpolation because it gave a much smoother transition (e.g. for colors). You can take a look at a nice visualization of cosine vs linear interpolation here</a>. Thus, @imbris set out to find an interpolation method that was similar to cosine but cheaper. They stumbled upon Smoothstep</a> which is almost indistinguishable from cosine. let factor = pos.map(|e| { let f = e.fract().add(1.0).fract() as f32; f.powf(2.0) * (3.0 - 2.0 * f) // <- smooth step }); </code></pre> Blue is cosine, and red is Smoothstep </figcaption> </figure> As you can see in the figure above, both are nearly identical. Additionally, @imbris noticed that 2/3 of the time spent lerping the noise with the factor calculated above was in clamping the factor when it is known that the factor will always be between 0.0 and 1.0. The clamp function in the flame graph </figcaption> </figure> Thus, @imbris was able to avoid the clamping check and replaced the cosine interpolation with Smoothstep. We now had this flame graph: </figure> Looking good! A lot of fat has been trimmed in those greedy areas. At this point, @Zesterer pointed out that the cache in this section could be improved: </figure> So @imbris, @Zesterer, and @Xacrimon collaborated to create a more efficient, fixed size, small cache that wasn't on the heap. It also used a less expensive custom hash function. @Zesterer also made the bounds-checked generation much more precise, which lead to a very significant reduction in worldgen time. Feel free to check out !504</a> and !507</a> to see the relevant MRs. The final flame graph </figcaption> </figure> There is a lot more work to go in the optimization field, but it will always be an ongoing process. @Zesterer gave some insight into some future work. So at the moment, we go through the whole process of generation for every block. That means that there's a hell of a lot of code being run each time we try to sample a block. I strongly suspect that this is very unfriendly for the instruction cache. So I would propose to move to a system where, in an almost ECS-like manner, we instead apply the generation process in layers with the whole chunk being operated upon every time. This might even allow the compiler to parallelize (via SIMD) a bunch of things too. </blockquote> Exploring the frost lands. See you next week! </figcaption> </figure>

Veloren

These weeks in Veloren 250

Merged work</h3>

Ongoing unmerged work</h3>

Screenshots</h2> </a> The hills have lights — by @Alley_Oop</i></p> </figcaption> </figure>

These weeks in Veloren 249

Merged work</h3>

Ongoing unmerged work</h3>

Community showcase</h2>

Concept art</h3> First-hand accounts of various explorations in voxel space. A mix of things intended for use in-game, and more experimental ideations.</p>

These weeks in Veloren 248

Merged work</h3>

Ongoing unmerged work</h3>

Community showcase</h2>

Screenshots</h2> </a> We've only got the one bridge, so it better be sturdy — by @isse</i></p> </figcaption> </figure>

These weeks in Veloren 247

Merged work</h3>

Ongoing unmerged work</h3>

Doom-loren</h3> @horblegorble drilled down past the lava biomes of their screenshot folders to fire up just the right mood with @souffle's logo design.</p> </a> Is this the future of an unstoppable Gigas?</i></p> </figcaption> </figure>

These weeks in Veloren 246

Merged work</h3>

Concept art</h3>
First-hand accounts of various explorations in voxel space. A mix of things intended for use in-game, and more experimental ideations.</p>