Budda

Developer
  • Content Count

    1673
  • Joined

  • Last visited

  • Days Won

    22

Budda last won the day on April 27

Budda had the most liked content!

Community Reputation

2500 Rare

About Budda

  • Rank
    Mayor

Contact Methods

  • Website URL
    http://buddat.net

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for the feedback, will look into these issues. Warmaster is supposed to drop invul when all the turrets are killed, so there's nothing special that you missed - just sounds broken.
  2. 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.
  3. 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.
  4. 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.
  5. Thanks, that's fine - you're well over 7500km.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. 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?
  12. 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.
  13. That one is fixed in the preview client already.
  14. 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.