• Content Count

  • Joined

  • Last visited

Community Reputation

117 Good

About Batolemaeus

  • Rank

Recent Profile Visitors

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

  1. The environment variable _JAVA_OPTIONS gets picked up by any Java implementation I know of. It looks like this: $ export _JAVA_OPTIONS="${_JAVA_OPTIONS} -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:wurm_gc.log" $ GDK_BACKEND=x11 ./WurmLauncher [...] Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:wurm_gc.log So it should be visible in the client log file as well. So if you set the env variable system-wide, it should get picked up by the launcher no matter where. The GC log file contains nothing particularly identifying, by the way. You can dump it into whatever online analyser you want. gets SEO'd to the top of the search results and is, by all accounts, decent enough. "Pause time" is the important statistic, it indicates the time when no code gets executed. If that goes beyond 16ms, Wurm will drop a frame.
  2. Set an environment variable called _JAVA_OPTIONS to '-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:wurm_gc.log'. It might only work on *NIX, I don't use or know Windows. The log file will appear wherever the current working directory is, so you may want to use a full path to the log file instead. You can probably correlate lines starting with "Full GC" to your freezes. FWIW, Wurm probably churns through too many objects, but a lot of issues also just come from the GC doing full runs and stopping the world.
  3. You could do a lot with the existing assets, it's all in the lighting. For a demonstration, look no further than Valheim, which has comically muddy textures and hilariously low poly models. The vast majority of its look comes from its lighting. That kind of thing is definitely achievable by a single person. It's the area with the highest potential visual impact.
  4.,2428 I'm just suggesting the place because It's pretty central.
  5. We can do it at Zum Steinofen again when the time comes. I have two priests who can summon and it's well-connected to everyone else. I just can't cast the thing.
  6. It just occurred to me that we might be unable to change deed permissions on Oak HIll Ranch. So I'd suggest we meet at Zum Steinofen instead, it's right next door and much easier to find. Just take the highway or boat.,2428
  7. I will offer summons before the date, and I'll shout in freedom for passengers.
  8. I'd caution that you could potentially have created a very low-effort way to care for a lot of animals for free and at a very low maintenance requirement. I'd keep a close eye on new account creation numbers. You know there's always some people.
  9. Sounds good to me. We can meet at or near Oak Hill Ranch, close to HB. Rock and me can summon anyway and it's well-connected to the rest of the server.
  10. Announce a time. Around 20:00 UTC or later usually has the most people online. I wouldn't mind joining.
  11. That is not quite correct, I don't have this issue (to the extend of other people) because I use a GC implementation that manages to be largely concurrent. The problem is that the version of Java Wurm uses is the old Java 8 series, and a lot of the newer GC implementations that try to provide low-latency operation are only available from 11 onwards (or locked behind commercial versions that cost really big bucks). Changing the runtime version is… nontrivial for most people. A further problem is that running a program that can not miss its 16ms (60fps) budget on a garbage collected language is genuinely frustratingly hard. Unity ran into the same problem with C#. Ideally you'd design the application to manually invoke GC and do some tricks to avoid dirtying memory, but that is fiddly and again, genuinely hard to do. Keenan has indicated that a change of the runtime is on the cards, so that would be one hurdle taken. However, low-latency GC implementations come with tradeoffs that may not be worth it for other people.
  12. Well, it's tedious trying to box in the culprit. That's just how the sausage is made. Try these things: a) try disabling the "firewall" component. I have little hope that this helps, but it's low effort b) got an alt? Try logging in as an alt, maybe the server just hates your character. Unlikely, but similarly low effort c) Got another device that can run wurm, or a friend you can steal borrow a laptop from for a few minutes? My experience with Windows AV vendors is that they can never be cleanly uninstalled and are bound to keep hijacking processes and messing with them even when disabled. And if I sound unusually grumpy about AV, it's because I just had to deal with yet another problem caused by an AV vendor (Sophos) going haywire at work…
  13. Okay, that narrows it down then. So it's the runtime Wurm ships that is the culprit for you. I'll try to see if I can resume maintaining the script over Christmas, but I certainly hope the Wurm devs finish their work on an updated runtime.
  14. Avast is purestrain garbage, and impossible to remove without reinstalling the computer. And no, it's hard to figure out. It's something that can listen to the entire communication between you and the server, and either inject a package that tells your client to close the connection, or it's the server, or it's something injecting garbage into your client's process (i.e. Avast). Might even be your router, who knows. Try leeching Internet access from someone else for a test, see if that helps. That at least would rule out your own PC.