Friya

Possible issues (some of the TODOs I wanted to fix before throwing this out there) On some clients you will have a bit of jerkiness at some movement speeds (tweak and see what works for you) When focusing on objects nearby you can get some rather fast camera moves if you traverse over the same point you are focusing on (avoid this by focusing in same direction but at a bit larger distance). If I recall correctly I tested some hacks here just before I paused development -- they may or may not be working Following a moving object needs to be smarter (right now it's just a simple combination of two linear interpolations if I recall) Before I paused development I had a TODO saying this: "Huh. It seems the renderer crashes after we've run a scene a dozen times or so... Is this reproducible?". This is unconfirmed. Following objects underground will not work Due to a limitation in Wurm, "moving/animating time" slowly will never look great with the shadows. Never seen it mid-scene myself, but changing time on the client may be overridden by server at any point (you can probably use the timelock mod to prevent this) Traversing too large distances will get you kicked off server -- should limit creator from sillinesses like this (but for now, I advice restraint) Probably a lot of debug messages in log and the Cinematics tab A conceptually large server component is not completed (not needed to run or use this) Need player/creature name in object notes (my VM crashed, cannot check the Wurm source ... for now) (no idea what I meant with this one) When you first enter the game, automatic activation of Cinematics tab does not visually indicate that it's currently the selected tab. A few of the examples are incomplete and/or missing - ...and a whole heap of features that are mostly extending on already implemented functionality

This is a client mod that will help you create awesome looking videos in Wurm. This is an Alpha release. Real life dealt some bad cards this way and this code's been sitting on my harddisk 99% done for a few months now. I have not halted development of this, merely paused it for a bit. That said, as you may or may not know, I tend to keep my code updated to the best of my ability -- so please post feedback (positive feedback is nice too). I cannot promise I will be able to reply quickly, but I will eventually. All I really ask from you is please share your videos, tips, tricks (at least here) and encourage others to create awesome looking Wurm videos so we can get more people hooked on Wurm. My intention at some point was to create a real cinematic story that would showcase a lot of the features, did not happen, sorry. I'll instead just give you a very, very simple example that sat on the disk. This took about a minute and five mouse clicks in-game to create... (there may be more videos at https://vimeo.com/user61749266 but these were recorded to document progress rather than being a show case) Brace yourself, I have written quite a bit of documentation to get you going. More information and download: http://www.filterbubbles.com/wurm-unlimited/cinematics/ Get started: http://www.filterbubbles.com/wurm-unlimited/cinematics/getting-started.shtml (scroll down) How to create scenes (etc): http://www.filterbubbles.com/wurm-unlimited/cinematics/documentation.shtml (scroll down) How to install: http://www.filterbubbles.com/wurm-unlimited/cinematics/getting-started.shtml#installing I'd write more here, alas, there's no time. Please browse the site above.

Fixed to work with 1.8.* (use link in original post). I realize I may have some unanswered questions and such in this thread, unfortunately real life is rather difficult at the moment so I have just fixed critical issues. In general, it's best to simply check http://filterbubbles.com for updates as I am more likely to just upload a new release there than post here at the moment. (any other code of mine seem to work without updates)

Fixed to work with 1.8.* (use link in original post). I realize I may have some unanswered questions and such in this thread, unfortunately real life is rather difficult at the moment so I have just fixed critical issues. In general, it's best to simply check http://filterbubbles.com for updates as I am more likely to just upload a new release there than post here at the moment.

Intermittent crashes or freezes are horrible, using a "game hoster" or not. Servers have died and been shut down for less. This will at at the very least help pinning down possible problems that may be introduced by a mod, a combination of mods or just plain old server bugs. I wrote this software to assist me in tracking down problems on a server that was getting intermittent freezes -- and it was rare enough that you want to be able to nail it when it first happens -- alas, I was not clairvoyant enough -- so here we have this mod -- a tad bigger than I thought it would become. I share it because I know I will rely on it in the future. It's a bit of a mish-mash of things (*), but I left it all in there as configurable options. It grew out of me eliminating causes of a problem. It was a server where I did not have any access, issue was not reproducible on a test server, and had an absolute crap-ton of mods. Read: I like a challenge (har har). Later on it it also grew into a tool to help me optimize the server code (or at least my behaviour around it). I have to say it's quite pleasant to be able to pinpoint and measure execution cost without modifying actual source code; I may actually start using a similar approach in non-hobby projects. Dumps If you have full control over your environment and have the technical abilities you may want to hook up some external tools to solve a lot of your problems. That said, this program can also output a stack and/or thread dump if it detects slow calls in a monitored area. It may even be easier to use this than other tools. Note that in many cases this will only point you in the direction of the problem. It could still mean you have a lot of work to do from there (i.e. chasing calls down the chain with more monitoring). The server is half-decent at tracking laggy calls itself (albeit a lot less granularity than what is possible using this), aaand provided the call actually finishes! The original usage of the monitor.* properties outlined in the config file below was to distinguish it from a complete freeze or something else (the problem was rare enough that I threw things on the wall to see what stuck). That said, you can monitor execution cost of any method on the server (to pinpoint strange hot areas) -- and attach possible interesting objects from that context ... to really nail it. To do this, use the monitor.* setting below. You can add as many of those as you may need. It's a pretty powerful tool and if I wasn't chasing a bug I'd start looking at a few spots I have taken notes of where I can optimize the actual WU server (optimizing -is- fun). Hard to reproduce exceptions Funnily enough, it turns out this is a great way to pin down intermittent exceptions. If you add a monitor to a call that takes place in a stack trace -- and wait (without much pain), if that call never finishes (i.e. it threw an exception), a warning will be printed in the log (options to include traces as well). To get the detail of which object is the offending one (say a specific creature), add an argument to the monitor (e.g. $0 for this). For a few special cases (like Zone), instead of just grabbing toString() of the object I output e.g. zone X/Y. I intend to add more humanly readable strings of object as I need them, but yeah, it's primarily toString() at the moment. Combine arguments to a monitor with a full thread dump on a slow call and any freezing or hanging problem should become evident rather quickly. Albeit rather spammy if you let it hang too long. A few warnings Monitoring methods will likely not play well with recursive methods, monitor those from the "outside" (never tried it) Monitoring methods that might be called by several threads simultaneously will get dodgy, no doubt (never tried it). Performance impact This mod is written with performance in mind, even if you choose to monitor tight loops it should not affect performance *too* much. The idea is that you can have this running on a live server and just wait for the problem to happen. That said, be aware that it does add a bit of overhead. And might be noticeable in hot tight loops. The cost of having something nice... Searching in spammy logs In order to find warnings in very spammy logs, search for "Hey Friya" (I kept it in there because I could) -- any offender will be tagged with those words. If you find too many "Hey Friya"'s, it probably means your slow call thresholds are too low -- set them higher. (*) the mish-mash: Dump methods calls in a method (in a format for easy copy/pasting for monitoring.* Log a brief version of data stream coming to and/or going from the server Logging of all actions created (read: new Action()), whether by NPC's or Players Slow mod detection; monitoring default mod hooks Monitor if main loop is still ticking Dump all classes modified by Javassist (I do not decompile them for you ) Dump thread info on slow running calls Monitor itself (! okay, this is a lie, but it will output a message every now and then to indicate this) A few more pointless monitoring options (they all sit in the same thread -- hence pointless) Storage of monitored methods executed since entering a hooked method (this helps determine the code path taken through a method) Various options to specify frequency at which things can happen Dump stack-trace on completion of a slow call Dump stack-trace of a monitored call that is still running ... and a few more things. Well, outta here. Cya on the flip side. Example of a properties file: Download latest version (install like any other server mod)

It's funny that you mention it, was just sitting here talking to someone saying that it would only be at a certain speed. So it might only be happening in combination with mods. But yes, definitely -- mods affecting movement speed all over the place. The creature I have seen causing this is not in a 1x1, but I have been betting on it being in a corner of the enclosure. Thanks for taking a look, it does confirm that I'm not barking up the wrong tree.

I've been chasing a bug in Wurm for a little while now. To a client it reveals itself like this when you try to log in: "Waiting for Steam authentication...", and it will hang there. There are probably situations where you see that message and it actually is true, but in the case of this bug it's just an unfortunate side-effect. The server is most likely hanging in a deadlock or an infinite loop. It will not accept any new connections and all connected clients will eventually disconnect due to timeouts. What you will see in the server log are some threads chugging along doing some work (outputting statistics and such), making it seem like it's kind of working. In the case I was asked to help track down, it was not, the mainthread is frozen (deadlocked/infinite loop). You have to restart your server in order to get things going again. So, off I went to find out where... and it SEEMS I have found it, but I'd like a few more eyeballs on it before I call it a day and pat myself on the back. It lies in the movement code of creatures and it's called from a bunch of different places. This code was introduced somewhere between 1.4 and 1.6 (I was out of the loop so don't have source for all version). It probably all came with the introduction of the "Creature Movement Changes" feature. In Creature.takeSimpleStep() we have: ... a little code ... for (int x = 0; x < mvs; ++x) { ... lots of code ... if ((lDiffTileX != 0 || lDiffTileY != 0) && !this.isGhost()) { ... even more code ... if (Features.Feature.CREATURE_MOVEMENT_CHANGES.isEnabled()) { this.turnTowardsTile((short)this.getTileX(), (short)this.getTileY()); this.rotateRandom(this.status.getRotation(), 45); x = 0; this.getStatus().setMoving(false); continue; } ... some code ... } ... even more code ... } ... even more code ... Setting x to 0 in the iteration here ... is potentially lethal. I am curious if anyone with access to the original source code (or author of the code) can shed some light on the intended behaviour and/or state that this can never cause an infinite loop due to the conditions set by: this.turnTowardsTile((short)this.getTileX(), (short)this.getTileY()); this.rotateRandom(this.status.getRotation(), 45); this.getStatus().setMoving(false); I have a hard time wrapping my head around the scenarios and the intentions (hence request for more eyeballs). That said even if it is guaranteed that we will not reset x every iteration, I have to say that this is also terribly nasty programming. ? If this is indeed causing spurious errors on your server a work-around for now: Disable the server feature "Creature Movement Changes" and it should fix the problem until a real patch can be released (since I don't know the intentions of this, I will not release a patch myself). But first and foremost, would like to hear some feedback on this as I have simply run out of patience waiting for the bug to manifest itself on a live server (it's rare enough). TLDR: for (int x = 0; x < mvs; ++x) { if(condition) { x = 0; continue; } } // we might never get here.

Was mucking about in the garden, went inside for a few minutes, come back out to find this...

Hey MystLeissa, There were indeed some things that's moved around in Wurm. I did not spend much time testing things, but I did try bury and devour, both things should now work. Let me know if I'm a dirty stinking liar! The download is the same as in the original post. Edit: PS. I am sorry to hear about the all the vampires dying from soul feed. But hey, we all know they are the evil ones and the slayers are the good ones, right? Right?

Like you suspected, there is a faith requirement (50), deity requirement (BL / WL)... but also a skill requirement of 25 in soul strength or soul depth (depending on Deity). You also cannot have been a champion in the last six months.

Try binding it to all your interfaces, mod here somewhere:

Thanks for getting back with an explanation. This exception really got me curious. Glad it worked out :) oh and let me also give huge praise to Brash for always lurking and having good advice in this corner of the forum :)

Well, okay then. Let's give it one more shot -- with reasoning then. The reason I am suggesting a forced repair of Wurm Unlimited is because a number of things could have gone wrong with your installation. This could be access permissions, diskspace, memory, corruption of a file, anything. So, try breaking your install and let Steam go over your installation -- it's probably the fastest way -- at least faster than trying everything what possibly could have gone wrong. The line in question that is throwing an exception in the modloader has no magic, it just wants to open client.jar. It failing suggests something out of the ordinary is wrong, and frankly it smells like an IO error to me (but no, I have not looked into the newFileSystem() method). Oh, and while running patcher.bat, make sure nothing has a file-lock on client.jar. If you are certain that you know that you've done everything right (and I do think you are doing everything right -- or at least have had no reason to think otherwise). But obviously something has changed on your system, if it worked yesterday.

Well, if nothing is wrong, then I can obviously not help you. The fact that your mods are not working is because your modloader cannot patch your client; this is not a mod problem. The modloader is failing when attempting to access client.jar -- this is not normal, which is why I am asking about modloader, the client folder and your system. But if everything is okay in your Wurmlauncher folder...

This was an interesting one... 1. Are you using the latest client modloader? If not, install that. 2. Do you have free diskspace on the disk where your client is installed? 3. Are you extremely memory constrained on your computer? (as in, little free memory left) 4. Have you tried rebooting your computer, and before doing anything else, run patcher.bat? If the answers to the above are all 'yes', try repairing your WU install in Steam. If Steam says everything is just hunky dory, break the installation by deleting say client.jar (also delete client-patched.jar for good measure)in your WurmLauncher folder, then ask Steam to repair it again. Umm, further questions if the above was not successful: - Can you give a screenshot of your Wurmlauncher folder?