Arindor

Yes, working for me now too. Thanks so much Darklords!

-lowmem does not work. I suspect this only works for folk who already had the lowmem client downloaded.

+1 If you want me to stop playing just tell me the old UI has been removed, and I'll stop my subscriptions. Otherwise, please provide get this fixed or provide an "undecorated" UI without all the cruft. Most similar games for at least a decade now allow modding of the UI to meet the user's desires. If wurm does not, then wurm must provide reasonable options. Trying to force everyone into a "one size fits all" cluttered UI is not the way to retain your base.

On Linux I use: WurmLauncher -client "Live - Old UI"

Did I miss something? According to the post, horses are grazers... the only change to grazers is to allow them to eat mixed grass. Where does the apple come in?

[19:46:58] You try to bandage the wound with a cloth glove but fail. I was healing a series of light wounds with my cotton stack, and clicking on different wound areas in the paperdoll. I always quick bind a key to "Firstaid", and then mouseover the wound and press the hotkey - to reduce all the menu clicks. Somewhere in the process, my computer laggggged for a moment and my hand/glove became activated. I immediately realized this and switched back to the cotton stack, but apparently the quickbind was already in flight and my glove went *POOF*. Unfortunately I did not notice the missing glove until a few hours later. This was particularly painful since I just went to Lunalong this year for the sole purpose of getting a decent tint on my cloth armor. I traveled far, and waited a whole day for the tint. I did not even bother with getting any of my items imped - I just wanted the color (I was going for "that look"). So to have such a hard won glove just go *POOF* so easily is just wrong. A deep black tint is hard to get, but I can imagine the situation would be just as bad if the glove was enchanted (?). The fix should be: do not allow an equipped armor slot item to be used as a bandage. If you try to do this, you should receive a message similar to "You must first unequip the glove to try to use it as a bandage". Alternatively, add a confirmation window for equipped armor slot items: "Are you really sure you want to use the glove as a bandage?". Also: Thanks Shydow for helping out in my deep despair! Shydow was able to make a closely matching glove to replace the glove that went *POOF*. Thanks so much - I probably would not have been able to get a matching black glove until next Lunalong.

Running: WurmLauncher -client "Live - Old UI" worked for me on Linux (where "Live - Old UI" is the menu option with caps and spacing exactly as shown in the menu). This is not documented anywhere, and I think they are intentionally not sharing this information trying to get users to use the new UI. I hate it, Wife hates it, and we are sticking with the old UI until/if they make some improvements (already documented) to the new UI. For Windows, you can probably run something like you show above: D:\Wurm Online\WurmLauncher64.exe -client "Live - Old UI" I hope it works for you! Best of luck.

Not a fan of the new GUI. At all. I hate 😠 the huge fonts, and all the fancy window decorations. Even down to 90% scaling, way too big. Yeah, I get it... steam launch - you think you have to make the GUI look sexy... but this is *NOT* more immersive - it's anti-immersive adding lots of large fonts and window decorations that get between me and the scene. I think it's perfectly fine to offer this as a CHOICE to players, and even make it the default. But I think serious players get tired of all the "fluff" and want just the "stuff". I am in favor of a more transparent GUI, absent of unnecessary window decorations, and the option to use small fonts. A GUI that doesn't get between you and the scene, and/or add "artificial" elements to the scene gives more immersion, in my opinion. Darkfall had this - you could make the GUI (window decorations) almost completely transparent. Give me that option. Please 🙂 I do like the filtering and search on windows. But I will rarely use that. Maybe on some full BSBs. But I like the option. Again with the "lightweight" GUI concept, maybe make that a button (or key bind) that pulls up the option for a window - maybe a magnifying glass icon up by the "X" to close the window. It really does not need to be there all the time. I didn't think I'd like the health bars in the scene (on mouseover). But I actually found that more immersive and engaging. I am not sure why I like it, but I do. It makes me want to go fight that mob and not just look at it. ;) But I hate 😠showing the key presses in the scene ("press F for ..."). That should be a "tutorial mode" or such toggle. After a short look, back to classic GUI and small fonts for me. Please don't remove them!

I have already documented the (Linux) launcher does not work for me. I too use the JNLP launcher. The JNLP launcher is still shown as a valid method of running the game when you click "Play" on the website: "Generic Java installer if your platform is unavailable." Please fix this ASAP. Edit: I am fine now. For anybody else having similar issues, I was able to get the native launcher working by: Download the Linux tar.gz launcher. Extract the launcher tarball: tar xvfpz wurmlauncher.tar.gz Change directory to the extracted launcher directory: cd wurm-launcher Copy libstdc++.so.6 from another system into that directory. Set LD_LIBRARY_PATH to "." (which command depends on what shell you run): export LD_LIBRARY_PATH="." LD_LIBRARY_PATH="." ; export LD_LIBRARY_PATH setenv LD_LIBRARY_PATH "." Run the launcher: ./WurmLauncher I again respectfully suggest that the Wurm devs statically compile this library (libstdc++) into the binary (or bundle the library) to avoid this issue.

2011-2012 Started on Indy and then Exodus when it first opened. That would be when it broke. I was not playing then to report it then. Sorry. * sigh * I guess I've not clearly stated enough times that I know it's not working now, and that I know this is the error message you get *now*. Yeah. Somebody else can do this. I thought I was reporting a bug to the developers (there is no other mechanism). Didn't expect to deal with entrenched players chiming in to say "it doesn't work that way" (now) - which I thought was obvious and I've made clear I know. I don't think there is anything more that I can add, so I'm done.

Right. This can work, but when you have two high-quality veins at V that you do not want to destroy, and want to remove the tile at "1" so you can build a house or tunnel, this suggestion is not useful. This is my situation. I understand this is your (and other's) assertion. But you are, simply, wrong. There is nothing inherently "broken" in the Wurm engine such that diagonal "voids" cannot exist. They do all the time, and the Wurm engine handles this well, and always has to my knowledge. Again, mining like this was allowed, and USED TO HAPPEN. You can go looking around old mines and see examples of this, like I just did. Also, nothing prevents you from building a house diagonal from a vein (Note: You can only build adjacent to cave wall *on deed*). And finally, you could use Shaker Orb or Strongwall diagonal from an existing vein or cave wall, if you like. All of these things can happen, do happen, and do not cause any problem whatsoever for the Wurm engine. This is also wrong. The dangerous side-shaft message is *intended* to warn about vastly different heights between tunnels. There is nothing dangerous about two cave tiles (voids) meeting diagonally at the same height, which is why the message is inappropriate and this is a bug. If you free your thought from the incorrect assertion that diagonal "voids" can't exist in Wurm, then you realize that not allowing mining, such as the examples I have given, is a bug. And sorry to provide the "history lesson", but this is something that *used to* work in Wurm. In Wurm many years ago, you used to be able to mine into any adjacent tunnel at any height, in addition to mining diagonal to an existing void. The Wurm engine also handled these situations well, but mining into adjacent tunnels at vastly different heights caused many issues and resulted in many /support complants from users. They were "dangerous" because you could fall down one and become injured. My assertion is the ability to mine diagonally at similar heights was "broken" many years ago by the mining changes that were implemented to prevent these "side shafts" of vastly different heights. The warning message is correct and applicable if the heights of the tunnel are vastly different. My report is that the warning message is incorrect and not applicable where the tunnel heights are similar - such as the two real-world examples I tried to provide above. Fixing this bug should be a simple change: a simple height comparison - just make sure the "diagonal" tunnel heights are vastly different when reporting this message and preventing mining; otherwise allow the mining to proceed. Sorry to report this bug after *years* of people assuming this is the way mining is intended to work. I played many years ago, and returned about two years ago and so I am just reporting this bug now that it has sufficiently annoyed me.

To simplify, in my first example, you're just saying mine 1 first, then mine 3, and then mine 2. I get it, and thanks for the workaround for that scenario. Unfortunately, this does not help in a blocked tunnel though, unless you have miners on both sides. Also, doesn't help in my second example at all. But again, thanks for the workaround for that scenario. Might be useful for some.

My report is not about whether or not I matched up or understood a warning message properly. My report is about what should work (and used to work) in Wurm. The only time "a dangerous side-shaft" occurs (or occurred) was when the height was vastly different. Both examples I showed *should work* in Wurm, but do not. My point about height is that developers can "match" the height of the mining operations to see if it should work, or generate the message instead. My belief is that developers blanket removed the ability for diagonal tunnels to meet, and the code should instead use a height check that allows the operation to work as long as the height "matches". Even if you don't understand or agree with my first example, how can anybody look at the second example and say you should not be able to mine that tile? This is a bug.

Consider the following - a downhill tunnel created with the standard "Mine Down" command, and all slopes adjusted (from random) to exactly 20 slope: X X X X X X X X X X where X is a wall tile, and blank is our tunnel. Now a cave collapse occurs at V. But V is a metal vein that will take forever to mine through: X X X X XVX X X X X so instead of mining through the vein, we would like to mine around the vein (tiles 1, 2, and 3), as follows: X X X 1X XV2X X 3X X X as long as we keep the slope of 1, 2, and 3 the same, everything should work out right? It doesn't. Some years ago, this used to work, but no longer does. Tile 1, is a bit tricky. You can either mine up from the tunnel and then mine the floor to make sure you have exactly a 20 slope that matches the tunnel tile alongside it. Or you could mine forward from the tunnel and then just lower the one corner to make sure the lower edge of the tile matches the tunnel alongside it. In that case, the far edge will only end up being a 10 slope though. Either way, the tunnel is now correctly positioned to mine tile 2. The problem is that when you try to mine down into tile 2, and as the tile is about to collapse, you get the message: "The cave walls sound hollow. A dangerous side shaft could emerge.". This message is in error and should not happen when tunnels meet at the proper height. I know the workaround - mine an extra tile over and mine an extra tile back. I think this workaround works, but this should not be required. And if you have a vein there, or reinforced wall, you're out of luck. Here is another, simple example: X X X V X X 1V X X X X X Everything in the above is perfectly flat. If you try to mine away tile 1, (I believe) you get the same message (will confirm). If a mining operation causes two "tunnels" to meet, at the correct height (within some tolerance for the random up/down which sometimes occur from the selected direction), then we should not be getting a "dangerous side shaft" message. I know that this was added some time ago to prevent from mining into a tunnel way above/below an existing tunnel, to prevent a dropshaft from happening. But getting this mesage at the correct height is a bug and needs to be fixed.

I am so sick of this. This same rant has been going on for years (since 2012 at least). My priest was able to dom a drakespirit when they first came out, and they made a great pet. Sure I died lots of times trying to keep it, but it was a blast! But the ######-storm that caused from all the folk screaming "but mah drops!", was extremely disheartening. Greed pervades even video games, and the pressure from this group of folk caused Rolf to program three separate patches to nerf containment each time I figured out how to contain my pet, when he should have been fixing critical bugs in the game. How about this: You can't dominate creatures that folk are going to scream "but mah drops!" about. I think Rolf already fixed all the issues with trying to contain them. Make a server-wide announcement when the unique spawns, so everybody has a chance to participate, just like for the rift. And for that matter put a freakin' beacon on it just like the rift. STFU about this once and for all. And maybe, just maybe, if you want to be nice to another mindset of players, make a couple of really cool, nearly unique creatures that don't drop a damn thing that priests can have as pets, for a time.