Budda

Alright, here’s what’s happening over the next few months. As said in the last dev blog, we’ve switched to a different update cycle with monthly smaller updates and interspersed larger marketable updates, aiming for a few large updates a year on a predictable schedule. This month’s small update includes the client rendering distance changes that have been worked on for the past while, as well as some new creature AI additions, and the usual slew of bug fixes. These AI changes are intended to finish off the work started a long time ago on the Valrei creatures with the initial Uttacha changes, making them more interesting encounters in combat than the usual ‘target and wait’ that a large portion of PvE combat is currently. These Valrei creature changes will ideally make any fights involving the remaining creatures more interesting and varied than normal, and will lead into some content for the planned large update later on. The June and July updates are currently planned to include a few new UI changes for the preview client, as well as overall UI QoL features and general combat & combat UI improvements with some focus on giving more information to the player about what is happening in combat, as well as the usual bug fixes and possibly another new feature that I’m not ready to share yet. The first planned large update in this new cycle will be a large expansion to an existing set of content in Wurm Online which will see players exploring new lands and working together against a common enemy - hereafter codenamed Frontier. It will combine a lot of existing features and recent changes in Wurm into a big chunk of new content available to all players - old and new. The Valrei creature changes going live this month are a precursor to some of the work that will be involved with this update, and the reason they are going out early is to help us gather feedback over the next short while to lead into some of the planned changes for Frontier. As I’ve said in the past I don’t want to share too many details before they are finalised or well underway, so the most I will give out right now is that it will be a large update with new repeatable content that should entice players with a wide range of interests, and touch most parts of Wurm as a whole. Later in the year after Frontier is complete we’ll be moving onto extending the building options available to everyone, and later on after that we will begin working on plans for introducing another new skill to the game. Frontier will also be a precursor for big changes that will come to Epic in the future, and feedback from how everything goes later in the year will inform us on how we implement the current plans that we have. These changes to Epic won’t be anytime in the next few months, but when they do come they will involve a large overhaul to the cluster in an attempt to bring it closer to the original design for Epic years ago. We will be addressing the larger complaints of the Epic community in that update - but some smaller changes will be heading to live in the coming months as well. For those changes see the recent feedback thread posted here. More info about the exact plans we have for later on will be shared after Frontier is live. As always, more information about everything we’re working on will be shared closer to the dates that they’ll be coming in. Frontier will be accompanied by a marketing push to help make the most out of the new update cycle, and is where everyone will get a lot more info about what exactly is coming into the game.

As stated in the OP part of the reason for these changes is to better have time before a release to give out information and testing periods for appropriate changes. There are a fair amount of things currently in the works, and there is a longer list that we're planning on for the near future, and an even longer list for what to do after that. Giving out all of those plans and ideas at such an early stage does nothing good in my opinion, we have years and years of instances we can reference back on where an idea or plan was shared well before it had been started in any meaningful way, and many of those instances lead to that project being delayed or outright dropped as other things popped up/took precedence - and that always leads to a ton of threads and questions about when X or Y is due because we announced it a year ago. Plans change a lot and our team is _very_ small. A project may be started and not touched again for 6 months due to the person working on it not having sufficient time for it, or abandoned outright until years later when someone else feels they can do it justice. I would much rather announce what is coming when I can for sure say that it is coming in a reasonable timeframe instead of more promises of Soon™. This isn't a matter of "no information until two weeks beforehand", but more of "I don't want to promise this new thing when I haven't even started on it yet." Echoing Retro, everything already goes through the test server. We have the immeasurably awesome Alectrys on there most days testing what is coming and confirming they work as intended, but as with anything sometimes things can slip through the gaps. We'll still be going forward with the public testing scenarios that we have in the past for larger changes and mechanic additions as that tends to do a lot for the stability of such large changes, but for 95% of the changes and updates we add Alectrys' testing is sufficient enough to the point where a couple of people who see a new set of upcoming notes and decide to test the one thing they're interested in isn't really going to add anything that we don't already have. That being said, I'm sure Alectrys would love the help of any dedicated people that are interested in helping out on the regular.

Over the last few years the update cycle for Wurm Online and Wurm Unlimited has been a bit sporadic to say the least. The goal in that time has been to stick to a fortnightly schedule with the odd larger update for big changes or new mechanics, but there have been many times where that hasn’t been effective or possible. There are various reasons for this, ranging from needing to push out bug fixes soon after a larger update to not having enough changes ready to go live in that two week timespan. With such a small team working on Wurm it can be difficult to get enough ready to go in that two week timespan to have something meaningful to show or have enough time to get sufficient testing completed. Starting with this week’s update and going forward into the future, our development cycle will be changing a bit, meaning that the update cycle will change to match. The new goal will be moving from fortnightly-ish updates to a more predictable schedule of the last Thursday of each month - plus any necessary hotfixes in the week afterwards. This should allow us more time between updates to better plan what new things are coming, flesh them out a bit more, and have sufficient time for internal (and public where appropriate) testing periods to nail everything down. It’ll also better allow for us to schedule and share information about upcoming updates and share tidbits of new things coming on the planned devstreams. This new planned schedule may not translate 1:1 to Wurm Unlimited in most cases, but we will be aiming for those to be a bit more consistent compared to the latest 1.9 update to WU. Included in this change to the update cycle we’ll be changing our planning and development cycle to shift towards a more predictable pattern of larger content updates, currently planned for a few times a year. Because of this the primary monthly updates might be overall smaller going forward, but will still include things like bugfixes, tweaks/changes, and smaller content additions as appropriate. The larger updates will be planned around a theme and should include additions or changes to a variety of things in the game, as well as introducing new mechanics and things to do. We hope this change going forward will put our development cycle back into a more predictable pattern, giving us a bit more time to get things right, and give everybody playing Wurm some clear knowledge on when new and exciting things are due into the game.

Thanks, that's fine - you're well over 7500km.

I'll look into something, but I won't be able to make it exactly correct due to the ~4 months of overlapping achievements. No promises.

Looks like the trigger for that one isn't working as intended, will fix that thanks. The fragment one will also be fixed, that one isn't updating properly. As said above, some achievements were never tracked in the past so can't be counted towards the new journal entries. such as complete a colossus, mine out a vein, dye items. The slay creature one works off the newer journal achievement of slaying any creature that was added with the first tiers, which won't be counting any older achievements that track individual creature type kills. The mission related one was a new achievement added with the journal due to Epic Helper and Epic Finalizer not really covering the requirement (helper can trigger multiple times per mission, finalizer only triggers for the person who completes the mission) - which is why your progress for that might be below the older achievement counts. Same deal with slaying a legendary creature, there was no achievement that properly covered all uniques, only tracking the individual types - so that one was added with the journal as well. I did what I could to create the journal with existing records and achievements in mind so older players wouldn't have to redo a bunch of things that were completed in the past, but some new tracking achievements had to be added to make things work as needed.

Just to confirm you already did have that distance traveled, can you check your achievements window and tell me how many "Nomad" achievements you have? Looks like that one isn't triggering correctly, will fix that, thanks. This one only started tracking properly as of the original Journal release - there are older tracking achievements for specific creatures, but there was none for creatures overall before that first set of tiers.

Oh right, my mistake. I presume on your screen you were looking at where hes standing in his video (meaning the positions of you two are fine, just both looking the wrong way?). Looks like something weird going on with the rotations there, I'll have a look into it. Thanks.

The only thing I can see at 32:30 is a single arrow being fired. Both people are facing each other, when the arrow is fired the target turns to the side to try block it. Is your part a different time in the video?

The one at 9min just seems like good old lag to me, not movement desync. If the server is lagging slightly and a bit behind in processing the movements sent from the client (same thing as the cause of the "please move slower" message) then it can seem like your client is a bit away from where others see you at that exact moment. The rest of your movements were likely still processing when the final hit on you happened. I'll have a look and see what I can do about those processing times, but can't promise anything in the short term. I can't really see what you're pointing out at the 32:30 part of the video, is it something further on that just starts there?

That shouldn't be possible anymore. Can you post a bug report in the server bugs section with some more info if you come across it again? Screenshots from both perspectives, what you were doing, where you were doing it etc. The only thing I can think of is some mismatching range bug where you were just on the edge of local range of your alt where he wasn't removed from your local, but you also weren't receiving movement updates due to being out of local, then you came back in range and he didn't move at all after that. Currently if there is some weird edge case like this, then any sort of slight movement from the alt (including moving the camera view at all) would force its proper position to be sent to anyone in range, moving him back to where he actually is for anyone in range and ending any possible desync.

That one is fixed in the preview client already.

In this week's patch notes there was a small line that a lot of people would have glossed over, that being “Fixed a number of movement issues.” There’s a long story behind this one, with a few weeks total of working on it and something completely insane that I had to fix, so I wanted to write a bit about it - if you’ll forgive my rambling. Note: Before we start this I should point out that in the context of this post, "desync" is referring to a creature or player appearing at one location from your view, but from their view they're in a different spot. This isn't related to the "Your position on the server is not updated." message that you can sometimes get when the server itself is lagging. Hopefully by now some people have noticed a bit smoother movement in general (ignoring today's horses being a bit jittery on bridges), and a lot less (ideally none) movement desync that the game has had troubles with for a long time. These desync issues were magnified with the Fishing update and became a lot more apparent over the last few months. You might have encountered this on your boat by disembarking after a long trip and being a tile or two away from where you thought you were, or by leading a creature a long distance and it slowly getting farther and farther away from you. The cause of the desync becoming more apparent was a change I did months ago for fish. Each fish in the game is technically a creature the same as any other and the server controls it as such. When you cast your line it decides when your fish will spawn, then tells it to move towards your line where it stops for a bit. Early on we ran into issues where the fish wouldn’t always stop right on your line, but sometimes off to one side or the other. To get into the reason for this issue and how I fixed it we have to dive a bit into how the movement updates in Wurm work. Movement is calculated on the client based on your input which then sends your new position to the server. Server then checks that data against what you’re allowed and expected to actually do with that movement then if everything is okay it saves that as your new position and updates everything that needs to know where you are. This includes any other players that can see you, all the creatures within range of you, anything you’re riding or dragging or leading and a few other things. When doing these updates they’ve historically been done using position differences. The difference is passed along and calculations are done based on that instead of the exact new position. This is where the problem starts. For reasons of keeping data packets to all clients as low as possible, all movement difference values got packaged into byte values (which is a quarter of the data that sending the full position value would be), meaning a number in the range of -127 to +127. This means that when you’re moving from [1587.33, 903.19] to [1587.39, 903.81] the X and Y differences have to be converted into that -127 to 127 range, whole numbers only. To accomplish this the differences were multiplied by 10, which had the downside of ignoring any movement difference below 10cm (0.1) since that would get rounded down to 0cm when converted into a whole number byte. Here’s where we get back to the fish problem. Because the final movement of the fish to get to the hook was sometimes less than 10cm the update packet sent to the client was rounded down to 0cm and ignored. After some testing to figure out the actual movement values being sent to the client was never getting beyond the -7 to +7 range, I changed that x10 multiplier into a x100 multiplier. This gave us an extra degree of precision in movement, while keeping the movement difference values inside that -127 to +127 range. Although this fixed the fishy issue that we were having at the time, it brought to light some new desync issues and made some existing ones worse. At that time the biggest issue was stamina drain problems because of this change - I had thought it was because I missed some x10 -> x100 change at some point, but after going through the related stamina drain code it didn’t make sense. I gave up some point after and tweaked the draining code to be as close to live as it was before the change and chalked it up to something weird that I might find later on. The last few weeks was that ‘later on’ where I found out that my initial thought of “this doesn’t make sense” was correct. You may have noticed that I glossed over what happened in the old code when those difference values were rounded down to 0cm if they didn’t hit that 10cm (or 1cm after the x100 change) threshold. This is the source of the desync that the game has had in varying degrees since day one. When these values were rounded down to 0cm (or remainders from a whole number were rounded down), the movement would still be applied but the “update everything else” code would see it as no movement and not run. This means there could be some movement ticks where nothing was sent to players that were in range, or stamina would not drain at all if it was a player’s movement. But then how has everything still mostly worked all of this time if these movement differences weren’t updating properly? Now we get to the meat of the issue. The code that transformed the new position values into a difference value was prone to a rounding error that every now and then would cause a movement difference that is usually under 1cm to get rounded up to 10cm and trigger the chain of updates to everything and stamina drain. When the difference code was working on 10cm intervals, the rounding error just happened to occur about as often as the “lost movement” from rounding down would have added up to 10cm, so it kind of balanced itself out. Changing it to 1cm intervals meant less data was lost to rounding down, but also meant when the rounding-up error did occur it was only triggering enough movement for 1cm, meaning it lost the ‘happy accident of balance’ that it previously had which lead to desync problems being slightly more pronounced over the last couple of months. During my trek over the last few weeks into figuring out the desync issues Samool and I came across that piece code and recognised that it could cause some precision errors, so I changed it to something that wouldn’t. This lead me to a couple days of pulling my hair out over stamina no longer draining as expected before realising the rounding error was the reason it ever worked properly in the first place, and that the code down the chain relied on it to work 99% of the time for smaller movements. Without having this rounding error, slow movement will very rarely be above that 1cm threshold, meaning none of the drain code or update code was ever called, since the movement was rounded down to 0. Fixing this new issue involved changing the entire chain of code to not use the byte value differences, and instead use the actual position data and calculating exact difference values when needed, eliminating any need for rounding down (or random errors causing rounding up). This also lead to a couple days of rebalancing stamina drain from movement to be as close to live as possible considering the old system relied on a random rounding error to work at all. I’m truly surprised that it worked as well as it did being based on an error for smaller movements like that. The upside of all of this is that movement updates sent to players now use the exact position instead of difference values, meaning desync should be a thing of the past. The place that you see other creatures and players is the exact same position that the server sees that creature of player - and stamina draining should be a lot more precise for smaller movements instead of relying on a rounding error. I hope I never have to touch movement code again.

My job title covers both WO and WU, so yes while the Journal system was created for WO I also kept WU in mind when designing it to make things possible on both. The short answer to this is as Retro has already said. If we see any sort of evidence of a single person or group taking every global cast despite others attempting it then I'll be looking at a change to limit global casts per character. Currently we haven't seen that since the update for the priest journal. There have only been casts on Indy and Xan and each by different people at this point, there are another 5-10 (depending on how you count it) servers with favor pools, each with pools for 4 gods. There should be plenty of casts to go around (and the journal task even easier to complete with only requiring being linked).

So after the update this is how it should have gone, please tell me if this is not what happened to you. Non-lib on Freedom, Lib on chaos. -> If you were on chaos at that time, you stay as Lib when you move off chaos. -> If you were on freedom at that time and transferred to chaos, you were set to Lib and kept your faith - you're then free to /transfer to whatever you want as long as it aligns with your kingdom. Using /transfer after the update -> If you're on Chaos it would only let you change to a god that aligns with your kingdom. -> On Freedom it allows you to switch to whatever you want (as your kingdom isn't known). Transferring back to Chaos at this point would then set your deity to nothing if your god does not align with your Chaos kingdom. I'm guessing that last point is what happened to you, after you transferred to Chaos once already (where it would have automatically set you to Lib to align with your kingdom there) then came back to Freedom and transferred to Mag. I did put in warnings to all of the converting windows pre-update that has this line: "Warning: Converting to Libila while on a Freedom server then transferring to Chaos while already in a WL based kingdom will remove your faith and any bonuses gained. Transferring to Chaos into a BL based kingdom will keep your Libila faith and bonuses." Though I can see that wording doesn't quite cover your situation, as I was focused on the Lib and WL kingdom interaction (didn't really expect people to go a WL god and expect to stay in a BL kingdom sorry). I'll fix up the wording of all the warnings to make it clear that you'll lose faith if your kingdom and god don't align.

But which deity gets Kikoho? Seems discussion is leaning a little bit towards making casting a bit more interruptible as a counter instead of having outright chances to block spells cast at you which makes sense. Needing to equip a statuette in order to cast an offensive spells seems an okay idea at first glance, though I'm curious what the current equipment of offensive priests are? Would 1-handed equipping be enough of a drop in parry rates to make interruption more viable, or would a still equipped shield basically negate that in practice?

If only we put up threads months beforehand with open invites for everyone to come test and give feedback hmmm.

This is why I posted asking for more input, I'm not just throwing in changes for the hell of it.

So after the discussion here and the other thread, is there an actual issue with dodging spell nukes or is it just lack of time getting used to the new stuff (or is it split based on kingdom)? I'm not against adding another form of defense against spell damage beyond the current jewelry enchants, but I think it makes sense that getting extra bonuses against that should come with some sort of downside to avoid it becoming a "this is 100% the best setup" type deal. Not a fan of the idea of having shields just outright block all spell damage or anything like that, since that would just throw priests back into irrelevance in fights. One thought I had is allowing the defensive elemental enchants to be cast on wooden shields that then give you a ~20% chance to block spell damage of that type (instead of outright reducing that damage by a % like the current jewelry enchants do). Downside in this case is obviously having to use a wooden shield, and even then only getting the chance to block one type of elemental spell damage.

A few points. Damaging spells can also be interrupted by tangleweave, as well as breaking line of sight. If you've come up against a 20v1 situation and immediately died to spells (after the last update with balance changes to spell damage and resists), I'd be interested in those logs. The idea behind resists is that it gives a severe diminishing returns for stacking multiple priests against a single target. If you have 20 people doing a coordinated attack against a single target, should that person really survive?

Just bouncing off the Immortals Hunt idea, I have something similar I've had on my WU server for a few years now that might fit the sort of thing you're bringing up. Basic idea is at some interval, an event spawns at a random spot on the map and gives an approximate location in quadrants of the map. Players then go out to hunt for that event, defeat the creatures spawned there, then claim the reward (via something like a capture timer). So instead of 4+ points that kingdoms capture, and rotate around to recapture etc, it is a single point that presumably everyone would be fighting over. On paper this sounds like it might cause people to be roaming out in those quadrants looking for the event (and then possibly larger battles to control that area and kill the creatures), but would that actually happen? Or with it being a single point would other kingdoms just not bother once they learned that it had been found? Back on the current camp idea and the cap of 10, keep in mind that with the once a day spawning of the camps this is a longer term game than the current HotA. Two large kingdoms might capture 3 each waiting for the 4th to spawn, but then they have to each defend all of those points randomly across the map for 3+ days. I think having the option there for smaller kingdoms to hold points or back cap them as larger kingdoms make a push for one well out of their territory might make for some more interesting scenarios. That said, if its put in place and the first couple of wins are clearly just two kingdoms ignoring each other and capping their own, we can drop it down to a max of 6 or 7 to push more forcing capping of defended ones.

As per today's patch notes: Resist changes: Fireheart, shard of ice and rotting gut all changed to 150 seconds for 100% resist with 1.5 seconds resist added per power. Tweaked spell damages: Worm brains from 140 damage down to 120 damage per power Inferno from 30k to 25k base damage Hypothermia from 300 to 250 damage per power Fireheart from 10k to 9k base damage, 100 to 80 damage per power Shard of ice from 150 to 120 damage per power Rotting gut from 8k to 7k base damage, 120 to 100 damage per power Was also a bug with the resist numbers on the 3 nuke spells that I fixed up to work with their intended values, so you might notice some changes with the resists there. Should hopefully keep the stacking of multiple priests on one target a bit more in line, shouldn't be able to immediately outright kill a 50 characteristic character stacking each cast now. If inferno still proves to be the far and away best heavy nuke spell I'll look at balancing the damage output to rely on power of the cast a little bit more, instead of having such high static base damage. As always, keep feedback of how it works in-game coming and we'll keep tweaking.

If the character you're caring for it with is a never-prem alt, then its still cared for and protected but only for 2 weeks after last login. Even after that point, that status and protection only clear if the creature is examined. There aren't any cases where it is cared for and not protected from old age. Do keep in mind that cared status only protects from old age, nothing else (hence kinda needing the death reason from the corpse for us to track down why they might be dying).

Oh you're right actually, this is for never prem chars only it looks like. Nevermind me.