ErikN

I would also like to say my thanks to everyone, you have all made working on Wurm a really fun experience. I will miss the times I have spent on IRC with the team bouncing ideas or plotting evil things (most evil things never made it into production ). And special thanks to Cerber for all the hours you spent on the test servers with me testing new features before release, I still remember when I somehow hitched you to a wagon.

Well it was fixed with the codes original intent for values > 0.0001, I am guessing here that who ever wrote that code originally figured that it would be less readable if it showed all the decimals for larger values. As for changing it to 8, the rest of the always option only show 6. A value of 8 would result in the skill log printing things like: 1E-7. If you rather have all values with 6 that can easily be arranged, not so much of adding code as removing it, and quite frankly just make the code more readable, so I'm in favor of it

Have you by any chance turned off displaying equip/unequip options in your player profile for that character?

Ahh I know what this is, I actually fixed another bug in there recently. And that allowed this one to show it's ugly face. It should only affect those of you using the always option, and only when the skill tick is > 0.0001 Previously it would throw a silent error when it happened, I fixed that in a quick drive by (was working on other things when I spotted it). A few quick snippets to show how small error it was The original error: if (delta > 1E-4) { change = String.format("%.3g", Float.valueOf(delta)); skillprec = change.length() - 3; } The quick drive by fix: if (delta > 1E-4) { change = String.format("%.3f", Float.valueOf(delta)); skillprec = change.length() - 3; } And what I hope will be the final one (worked after testing): if (delta > 1E-4) { change = String.format("%.4f", Float.valueOf(delta)); skillprec = 4; } Such small things, hard to spot when you are not actively looking for them. Next client update should include the fix.

I have done both actually while testing. Right now just launching through the exe will make it possible to launch 2 or more instances, last time I did it, before WU release that did not work. When launching through Steam the AppID is set in the process by Steam, so not something that is done in our code, it was actually a problem for the dedicated server since it set the tool id, and not the game ID, resulting in Steam not thinking of the server as the WU server but something else, so we had to reset it, which is done in the exe before any Java code is launched. I don't think there is any big risk of Steam seeing you change the AppID unless you change to an incorrect one, it's common to see pirated games using Steams own example ID, I even saw a Wurm server running using it earlier (it might not have been a pirated one, but it was not using our ID).

What an interesting side effect. Last time I started the game like that it would not let me start more then one client, perhaps there have been some changes since then. The ability to add the app id in a txt file is provided by Valve so that devs can start/test their games before launch. Normally the app id is set by steam when the game is launched, it looks however like the default behavior is to look for the txt file first when initializing the api. A quick search indicates that there is several developers that dislike this behavior so there is a possibility for it to change in the future. You should be careful however, since this is a feature designed for devs that is commonly misused by cracked games, there is a risk that if Steam has a way to detect it that you might get caught in a purge and be banned. We have no reason to dislike it however, it's not like it's all that difficult for a modder to remove all steam checks in our java code as it is, mostly we use the steam api to get access to their master servers. It is fairly common for other games to have the game delete any app id files to avoid it being used like this, or stop the game from launching at all.

I personally prefer updating on either Wednesdays or Thursdays, and weekly, due to the time it takes to gather up info for patch notes, there are a lot of things to sift through in terms of changes, not all of which will go live. We have also been going through a migration of version control systems, from SVN to git, so things have been slightly more cumbersome to do recently then they had to be. That migration is now complete, so now the work has begun to improve the patching and hotfixing workflow, it might have to go through a few iterations before we find the flow that works the best for us and our needs. Just as I think we need to find the best updating schedule for WU, perhaps weekly is too often, twice a month might be enough and give modders and server admins the time they need to adapt to changes. When it all comes down to it we need to find a way that is good for both us and you the players, just having a schedule that is "painless" for me don't work, I don't exactly enjoy seeing the stream of posts about not being able to connect like it is now. I think for the next update we will have to update both beta and live with the same version, including the version stuff in both and add a branch to the previous live version. Perhaps even hotfix the current live with the version stuff, albeit a slightly modified version that allows connections to servers not running it so that you may still try and connect to servers that are not updated. It wont remove all the version clashes this time around, I can't really think of any way to completely avoid it this time, having both beta and live running the same version should in theory allow us to reduce the version fragmentation before the next update. Perhaps a weekly updating schedule works better if it's not for both live and beta at the same time but rather opt for just updating one of them each week, resulting in live updating twice a month and beta twice a month.

I'm thinking about adding a previous version branch for the client, would help a little. We are also looking into adding some more version data sent from steam to the client so that it can verify before connection and either filter out or just gray out servers that are not the same version as the client. I'm guessing it would be preferable to see a server as unavailable due to version mismatch then connect to instant crash. Generally it is only a problem when we change the message protocols, been lots of those recently so I understand the frustration.

Allowing the system messages to be optional sort of defeats their purpose, I will take a look at the mail message, that could be moved to be a different type (info perhaps). The shutdown message have been split up into two parts now, time and reason. Only the time part will be on screen when that goes live, to make it shorter, easier to read and less intrusive.

The font size is connected to the Header Font Size option currently, if that messes other things up too much we might just split it up and add another slider. The only message type that you can't disable is the system type (shutdown, warnings, bans). The point of the messages is partially to drag some focus away from the event tab, and partially to inform you of something when your eyes are not there. I know when I don't have event visible I can try and queue up multiple actions over and over without noticing failures, like the tile I'm standing on being full so I can't mine and so on.

If you own the game you can download the Linux packages, but the store front should not be officially announcing Linux support yet.

General game updates do make their way to WU, they might lag behind for some reason at times depending on various factors, such as if we need to update databases locally and so on. A large chunk of the changes we do are pure code, so they trickle over just fine. Other things like changes/fixes related to WO anti-cheat and things that is not in WU don't.

They don't go out to Unlimited automatically, but most changes done in WO will eventually end up in WU as well. I compile patch notes and post them on steam whenever I do a fully fledged patch for WU, I have not done those for the beta branches available for WU since those may at times change in an irregular fashion.

Ok so Linux packages are sort of public now. It can be downloaded in full if you swap to the beta branch on Linux. The beta branches are named: beta_branch for the Wurm Unlimited Client and beta for the dedicated server. I have not however flagged the game as available on Linux, so the store should not say that it is. I have tested it with a regular account so that I know it's possible to download it all without beta keys or dev access. If you don't swap to the beta branch you wont be able to start it, only the files shared with the windows release will be downloaded. They also contains parts of the next patch for WU, so not 100 % sure of exactly what is in it right now. If you run in to any problems with it let me know, and hopefully I will be able to get things sorted.

Well I just added the Linux stuff to our beta packages (should only be accessible to those who got keys from us before WU release so not public yet). Had the Linux stuff in our dev packages before that, so fewer people who could test it. But it was enough to run into a couple issues when it was not started on my dev machine, unable to find our libs and so on. I have personally only tested with Ubuntu 14.04 so far (both 32 and 64 bit). Will see if I can get it up and running on another distro as well, and hopefully some other team members get around to testing it as well. I don't like friday releases, if something goes horribly wrong I have to work weekend, so I generally avoid them.