Telurius

If you'd be interested, I'd be interested in trading the final charge of my green tome for a charge of your black tome. My name in-game is the same as my forum name. Trading by mail would probably be easiest. If you're on Independence, meeting in person to trade could also be an option, but my schedule's been kind of weird lately, which could make it difficult to arrange.

If you're still interested, I'd be interested in trading a charge of my green tome for a charge of your red tome. My name in-game is the same as on the forum. Tomes are mailable. If you're on Independence, meeting to trade in person could also be an option, but my schedule's kind of weird right now, so it could be difficult to arrange an in person trade.

I just thought I'd mention a few things: First, if you want you can disable the overhead limit check that's actually triggering these crashes by including including "-J-XX:-UseGCOverheadLimit" (without quotes) in a command to start the client, but be aware that doing that without making other adjustments to solve the underlying problem will likely lead to either freezing/stuttering (due to excessive garbage collection) and/or a different type of OutOfMemoryError crash. Second, the default maximum heap size being used by the client is currently 1024 MB. It's been increased since my old post about this type of OutOfMemoryError crash years ago. It's worth mentioning since this type of crash is usually caused by having a heap size that's just a little too small for your settings, and you may want to factor in the current maximum heap size (either the default or whatever custom setting you're using) when considering what to try raising it to. Third, if you just started getting these crashes after a Java update, it's possible a change to garbage collection could have started triggering it, in which case adjusting your garbage collection settings may help. If you haven't already done so, I'd highly recommend switching to either the concurrent mark sweep (CMS) collector or the garbage first (G1) collector. They're currently the most suitable garbage collectors for most situations where low garbage collection pause times are desired (like when playing real-time games). You can use the CMS collector by including "-J-XX:+UseConcMarkSweepGC" (without the quotes) in the command to start the client, or you can use the G1 collector by including "-J-XX:+UseG1GC" (again, without the quotes) in the command. There are also a variety of other options that can be specified to the Java Virtual Machine (JVM) to adjust garbage collection (and other things), many of which can be found at the following pages: Windows: http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html Linux / Mac OS X / Solaris / Unix: http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html Fourth, in Odynn's case (based on the supplied console log) I noticed the crash originated in a model loader thread. While I noticed the settings for most things were set low, I noticed you're using 3 model loading threads with high thread priority. While this will speed model loading, it could cause other problems. In particular, higher numbers of threads can increase memory usage and could be contributing to the problem, and the higher thread priority could cause it to spend more time loading models if there are several to load (which if close to your maximum heap size could lead to more frequent garbage collection, possibly contributing to the problem). You may want to consider reducing the number of model loading threads and/or the model loader thread priority and see if that helps any. Be aware setting them too low may cause delayed model loading and resulting pop-in, but as low as your rendering distances are you'll likely be seeing pop-in if you travel anyway. Both options can be found under the "Advanced graphics" tab of settings in the game launcher. Anyway, here's a command to launch the client you may want to consider trying: That command will start the stable client with a slightly higher maximum heap size (1280 MB instead of the current 1024 MB default) using the concurrent mark sweep garbage collector with some experimental optimizations enabled. If you're already using a higher maximum heap size than that (A console log won't indicate what maximum heap size you're using, so I can only guess without more information.), you may want to try setting the maximum heap size even higher.

I've finally gotten around to making a site to host my tools and updated the first post in this thread with links to where they can be found there. I've also made a few changes to my map dump scanner. It now uses the real base colors specified in Wurm API for scanning, which should improve accuracy slightly, but I still haven't gotten around to rewriting the code to maximize accuracy. It also now supports using an isometric dump for gathering depth information for the map key and another map dump for the actual map area (Terrain dumps are recommended, but you can use others.) now. I've also added support for some more tile types and adjusted the output color scheme a bit as well as making a few other changes. I've commented out (disabled) the food perishability presets from my decay calculator for now due to some changes I've noticed around the 1.3 cooking update. I'm not sure if/when I'll get around to testing, updating, and reenabling them. I've also generated new resource maps based on the most recent set of map dumps. They now use the isometric dumps for depth information, but the terrain dumps for the actual maps.

Internal containers can still be separated by loading them onto a catapult, and firing a catapult loaded with them can even destroy at least some of them. Tested using a still, which had its condenser destroyed (After this, it can no longer distill. It still heats the liquid in the boiler, but nothing happens to it.).

With recipes that require both solids and liquids, you can eat a bit of the solids to also reduce the amount of liquids needed. Eating consumes 0.03 kg of food at a time, so you just need to start eating a solid food item and cancel when/before its weight gets below that weight to reduce it. This can reduce your nutrition, though.

While it's down, you can view a backup/cached copy of the site from one of various sources, such as the Internet Archive's WayBack Machine or Google's cached copies of pages. I currently recommend using the most recent copy stored by the Internet Archive here: http://web.archive.org/web/20160326184001/http://wurmpedia.com/index.php/Main_Page

While I haven't used them myself yet, I suspect underwater fences could allow secure private ports where it's actually possible to sail in and out of without having to use cave canals to get in and out. Prior to this, having a secure private port would have meant needing to either use a secured cave canal to sail in and out or move the boats in and out via alternative means (dragging, pushing, pulling, or loading them onto ship transporters). Fences can supposedly be placed at up to 15 dirts below water level now. That's definitely deep enough for knarrs, rowing boats, and small sailing boats to sail in, though I'm not sure if that's deep enough for some of the big ships to pass. Tall fences (for example, tall stone walls and palisades) could be placed in the water to secure a port (If placed within a deed on a non-PvP server, deed permissions could also protect against players bashing the underwater fences.), with a tall gate (such as a palisade gate) as an entryway. This could allow you to control who could get into the port. I'm not sure if low fences (for example, low stone walls or wooden fences) would be effective at keeping unwanted boats and swimmers out or not, though.

I have a few additions and corrections to make to the information on this issue. It's specifically the northwest corner of the tile lava is erupted/spawned at that is raised. As a result, players can potentially raise the northeast, southeast, and southwest corners of a mine entrance using the erupt ability this way. It's worth noting the corners of a mine entrance can be raised this way regardless of whether or not it has a mine door. If it has a mine door, this can be used to raise the slopes above 90 (You can't normally place mine doors at entrances with slopes above 90, but it's possible to use lava to raise them above 90 after they're placed.). This can also be used to raise corners of the bottom of a mine entrance (the tile border connecting to the floor) higher than corners of the top of a mine entrance (the tile border connecting to the ceiling). The statement about server restarts fixing the visible gaps between the surface and cave floor is only partially correct. If there's no mine door at the entrance, server restarts do fix the visible gaps. However, if there's a mine door at the entrance they don't, allowing the visible gaps to be maintained long-term (until the mine door is gone). This makes it easy to create large gaps at entrances with mine doors by repeatedly erupting and freezing tiles, and these gaps can then be used to observe the surrounding area, seeing through terrain and into other nearby caves, where you can also highlight and select things. It's worth noting that the level 7 Path of Power ability erupt is only known to work within Magranon influence or no deity's influence. Additionally, certain objects can block the erupt ability from being used near them. In particular, lamps, signs, altars, and vehicles are known to block using the erupt ability near them. These factors can be used to help protect mine entrances that aren't on deed from being altered with the erupt ability.

Some of the images were saved along with old copies of the page cached by the Internet Archive, but oddly it only saved a portion of the images. You can see what I mean here: https://web.archive.org/web/20150217083128/http://www.wurmpedia.com/index.php/Digging_-_Simplified Still, at least you can retrieve a few of the images from there.

I built a small house with a few timber framed walls of varying types off-deed not in perimeter and observed their decay a bit to make sure they were decaying properly. They appear to be following the expected decay pattern, taking normal QL-based decay with a perishability of 10, as this sample from my data shows: Listed QL = 13.797505 Post-Fix Timber Framed House Wall Data Decay Calculator Predictions Initial Damage = 0.0 Damage = 0.0 After Decay Tick 1 Damage = 0.72476876 Damage = 0.72476876, Effective QL = 13.697505 After Decay Tick 2 ? (missed this tick) Damage = 1.4548287, Effective QL = 13.596776 After Decay Tick 3 Damage = 2.1902971 Damage = 2.1902971, Effective QL = 13.495299 After Decay Tick 4 Damage = 2.9312959 Damage = 2.9312959, Effective QL = 13.393059 After Decay Tick 5 Damage = 3.6779513 Damage = 3.6779513, Effective QL = 13.29004 After Decay Tick 6 Damage = 4.4303946 Damage = 4.4303946, Effective QL = 13.186221 I also noticed that with the new permissions system it's now possible to give a house to someone without them having to accept or even being online. This might make it quicker/easier to gather data on decay for abandoned houses, but that will require more looking into. No, I don't have a repair calculator. Repairing actions that don't use materials are far more complicated than decay, especially with both the repair and skill ticks occurring throughout the action. I'm not even sure if it would be possible to make an accurate repair calculator. In particular, if the skills at the start of the action are used for all repair ticks throughout the action and there is no randomness to the QL/damage changes per repair tick, it should be possible to make an accurate calculator. If each repair tick uses skills at the time of that repair tick or there's any randomness to the QL/damage changes per repair tick, it will be impossible to make a completely accurate calculator, though it still might be possible to calculate upper and lower bounds on what the listed QL could be reduced to. However, it would require a huge amount of data, more than is likely to be gathered in any reasonable period of time without examining the code. I do not have Wurm Unlimited myself, but perhaps someone with it will make such a tool, though it will need to be tested with Wurm Online data for accuracy, as repairing could have differences between the two. Players other than the owner entering houses hasn't affected their abandoned status in the past as far as I know (Some of the abandoned houses I've observed in the past were open to the public and personally entered by me.), though that's no guarantee it won't in the future. To my knowledge, it goes by how long it's been since the owner logged into the server the house is on, with houses on servers where the owner has been away for longer than 1.5 real months being flagged as abandoned. I'm not aware of any obvious indicator as to when they're flagged as abandoned, other than the change in the formula used for damage per decay tick (If you're paying close attention to the damage they're taking, the difference is usually pretty obvious when they get flagged as abandoned.). If the player is active on the server, but somewhere far away from the house, it won't get flagged as abandoned, even if nobody is using it.

Without knowing the exact maps you're talking about, it's impossible to be sure. However, many Wurm Unlimited maps are probably map dumps generated using tools that make use of Wurm API. For map dumps, Wurm Online (and Wurm API) associates a base color with each tile type and brightens/darkens that color based on the northwest and southeast corner heights (adjusts for altitude and slopes). If the tile is underwater, it takes 20% of the resulting color components and adds them to the color components for the base color for water (though water is a bit odd due to the way it's coded, having non-integer base color components, while every tile type has integer base color components). You can find the base colors for tile types defined in Wurm API in the Tile enum of Tiles..java (The class files from it are contained within common.jar.). Here are the base colors defined for surface tile types: Tile Type Raw Color Code Color TILE_GRASS TILE_LAWN TILE_KELP TILE_REED TILE_TREE (superseded) TILE_BUSH (superseded) TILE_TREE_BIRCH TILE_TREE_PINE TILE_TREE_OAK TILE_TREE_CEDAR TILE_TREE_WILLOW TILE_TREE_MAPLE TILE_TREE_APPLE TILE_TREE_LEMON TILE_TREE_OLIVE TILE_TREE_CHERRY TILE_TREE_CHESTNUT TILE_TREE_WALNUT TILE_TREE_FIR TILE_TREE_LINDEN TILE_BUSH_LAVENDER TILE_BUSH_ROSE TILE_BUSH_THORN TILE_BUSH_GRAPE TILE_BUSH_CAMELLIA TILE_BUSH_OLEANDER TILE_MINE_DOOR_WOOD TILE_MYCELIUM TILE_MYCELIUM_LAWN TILE_MYCELIUM_TREE (superseded) TILE_MYCELIUM_BUSH (superseded) TILE_MYCELIUM_TREE_BIRCH TILE_MYCELIUM_TREE_PINE TILE_MYCELIUM_TREE_OAK TILE_MYCELIUM_TREE_CEDAR TILE_MYCELIUM_TREE_WILLOW TILE_MYCELIUM_TREE_MAPLE TILE_MYCELIUM_TREE_APPLE TILE_MYCELIUM_TREE_LEMON TILE_MYCELIUM_TREE_OLIVE TILE_MYCELIUM_TREE_CHERRY TILE_MYCELIUM_TREE_CHESTNUT TILE_MYCELIUM_TREE_WALNUT TILE_MYCELIUM_TREE_FIR TILE_MYCELIUM_TREE_LINDEN TILE_MYCELIUM_BUSH_LAVENDER TILE_MYCELIUM_BUSH_ROSE TILE_MYCELIUM_BUSH_THORN TILE_MYCELIUM_BUSH_GRAPE TILE_MYCELIUM_BUSH_CAMELLIA TILE_MYCELIUM_BUSH_OLEANDER TILE_ENCHANTED_GRASS TILE_ENCHANTED_TREE (superseded) TILE_ENCHANTED_BUSH (superseded) TILE_ENCHANTED_TREE_BIRCH TILE_ENCHANTED_TREE_PINE TILE_ENCHANTED_TREE_OAK TILE_ENCHANTED_TREE_CEDAR TILE_ENCHANTED_TREE_WILLOW TILE_ENCHANTED_TREE_MAPLE TILE_ENCHANTED_TREE_APPLE TILE_ENCHANTED_TREE_LEMON TILE_ENCHANTED_TREE_OLIVE TILE_ENCHANTED_TREE_CHERRY TILE_ENCHANTED_TREE_CHESTNUT TILE_ENCHANTED_TREE_WALNUT TILE_ENCHANTED_TREE_FIR TILE_ENCHANTED_TREE_LINDEN TILE_ENCHANTED_BUSH_LAVENDER TILE_ENCHANTED_BUSH_ROSE TILE_ENCHANTED_BUSH_THORN TILE_ENCHANTED_BUSH_GRAPE TILE_ENCHANTED_BUSH_CAMELLIA TILE_ENCHANTED_BUSH_OLEANDER TILE_MINE_DOOR_GOLD TILE_DIRT TILE_DIRT_PACKED TILE_COBBLESTONE TILE_COBBLESTONE_ROUGH TILE_COBBLESTONE_ROUND TILE_COBBLESTONE_NW TILE_COBBLESTONE_NE TILE_COBBLESTONE_SE TILE_COBBLESTONE_SW TILE_STONE_SLABS TILE_SLATE_SLABS TILE_MARBLE_SLABS TILE_PLANKS TILE_PLANKS_TARRED TILE_GRAVEL TILE_ROCK TILE_MINE_DOOR_STONE TILE_CLIFF TILE_LAVA TILE_CLAY TILE_FIELD TILE_SAND TILE_PEAT TILE_MINE_DOOR_SILVER TILE_TUNDRA TILE_MOSS TILE_STEPPE TILE_MARSH TILE_MINE_DOOR_STEEL TILE_TAR TILE_HOLE TILE_SNOW #366503 #366503 #366503 #366503 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #293A02 #470233 #470233 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #DD0229 #2d5d2b #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #1a3418 #4B3F2F #4B3F2F #5C5349 #5C5349 #5C5349 #5C5349 #5C5349 #5C5349 #5C5349 #636363 #636363 #636363 #726650 #726650 #4f4a40 #726E6B #726E6B #9b9794 #d7331e #717C76 #473C2F #A0936D #362720 #362720 #76876d #6a8e38 #727543 #2b6548 #2b6548 #121528 #000000 #FFFFFF R: 54 G: 101 B: 3 R: 54 G: 101 B: 3 R: 54 G: 101 B: 3 R: 54 G: 101 B: 3 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 41 G: 58 B: 2 R: 71 G: 2 B: 51 R: 71 G: 2 B: 51 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 221 G: 2 B: 41 R: 45 G: 93 B: 43 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 26 G: 52 B: 24 R: 75 G: 63 B: 47 R: 75 G: 63 B: 47 R: 92 G: 83 B: 73 R: 92 G: 83 B: 73 R: 92 G: 83 B: 73 R: 92 G: 83 B: 73 R: 92 G: 83 B: 73 R: 92 G: 83 B: 73 R: 92 G: 83 B: 73 R: 99 G: 99 B: 99 R: 99 G: 99 B: 99 R: 99 G: 99 B: 99 R: 114 G: 102 B: 80 R: 114 G: 102 B: 80 R: 79 G: 74 B: 64 R: 114 G: 110 B: 107 R: 114 G: 110 B: 107 R: 155 G: 151 B: 148 R: 215 G: 51 B: 30 R: 113 G: 124 B: 118 R: 71 G: 60 B: 47 R: 160 G: 147 B: 109 R: 54 G: 39 B: 32 R: 54 G: 39 B: 32 R: 118 G: 135 B: 109 R: 106 G: 142 B: 56 R: 114 G: 117 B: 67 R: 43 G: 101 B: 72 R: 43 G: 101 B: 72 R: 18 G: 21 B: 40 R: 0 G: 0 B: 0 R: 255 G: 255 B: 255 The base color for water isn't explicitly defined, but is a result of how underwater tile colors are calculated in MapData.java. It also varies slightly depending on the type of map dump. The base color for water winds up being R: 40.96 G: 51.2 B: 102.4 for terrain/topographic map dumps and R: 40.8 G: 51 B: 102 for regular map dumps. Tile types with the same base colors are indistinguishable on map dumps. Due to the way tiles are brightened/darkened, it's the approximate color component ratios that really matter for distinguishing between tile types, rather than the base colors, though it's also impossible to tell tile types for pure white or pure black (or the underwater equivalents) sections of a map dump as a result. Tile types with similar but different color component ratios can be difficult to tell apart on map dumps, though it is possible in at least some cases to tell them apart. You can find the thread for Wurm API, including a link to where you can obtain it here: http://forum.wurmonline.com/index.php?/topic/131691-wurmapi-create-your-own-wurm-world/ You may also be interested in my map dump scanner. It was designed to help pick out useful information from Wurm Online map dumps and predates Wurm API and Wurm Unlimited, but it will probably work with most Wurm Unlimited map dumps made using tools based on Wurm API. However, be aware that it is only designed for use with map dumps stored in a lossless image format without significant editing. If they've been heavily edited (especially if a smoothing filter or color shifting filter has been applied) or have been stored in a lossy image format (like JPEG), which can distort/destroy needed information, it may produce bad results. If the only available images are in a lossy format, converting those images to a lossless format won't help. Once a lossy format has distorted/destroyed data, it can not be reliably retrieved unless you have it in a prior (from before the conversion to a lossy format) lossless format or regenerate the data in a new lossless image. My map dump scanner groups many tile types that share base colors, but also groups together some related tile types with different base colors to simplify output images, so it's technically possible to distinguish more tile types than you'll be able to tell apart from looking at its output. My map dump scanner's accuracy could be improved a little with information from Wurm API, but I haven't gotten around to doing so yet. You can find a link to the current version of my map dump scanner, links to some resource maps generated from Wurm Online official map dumps using it, and also links to some of my other tools here: http://forum.wurmonline.com/index.php?/topic/112192-telurian-tools/

Decay rates for off-deed house walls that aren't abandoned and not in perimeter seem to be back to normal, using normal QL-based decay. Specifically, they take ( perishability / EffectiveQL ) damage per decay tick, where perishability is 10 for wooden house walls and 3 for stone house walls. Timber framed house walls used to have a perishability of 10, but it's been a while since I tested them. All floor/roof types I have data for seemed to have a perishability of 10 also, but I do not have data for some floor/roof types and it's been a while since I last tested it for floors/roofs. Here is some data for wooden and stone house walls since the fix, as well as what my decay calculator predicts for their decay patterns: Listed QL = 18.935068 Post-Fix Wooden House Wall Data Decay Calculator Predictions Initial Damage = 0.0 Damage = 0.0 After Decay Tick 1 Damage = 0.52812064 Damage = 0.52812064, Effective QL = 18.835068 After Decay Tick 2 Damage = 1.0590452 Damage = 1.0590452, Effective QL = 18.734537 Listed QL = 35.237965 Post-Fix Stone House Wall Data Decay Calculator Predictions Initial Damage = 0.0 Damage = 0.0 After Decay Tick 1 Damage = 0.08513545 Damage = 0.08513545, Effective QL = 35.207962 After Decay Tick 2 Damage = 0.17034346 Damage = 0.17034346, Effective QL = 35.17794 After Decay Tick 3 Damage = 0.25562418 Damage = 0.25562418, Effective QL = 35.14789 As I've said previously numerous times in-game, it appeared that the problem was all houses off-deed were being treated as abandoned. While I don't have an exact formula for abandoned decay, I do have some limited data on it, dating as far back as 2011. Here is some data from my 2011 observations on abandoned decay of stone house walls, as well as some data on off-deed stone house wall decay (from a house that shouldn't have been flagged as abandoned) during the problem: Listed QL = 31.510109 2011 Abandoned Stone House Wall Data Initial Damage = 2.700985 After Decay Tick 1 Damage = 5.8019485 After Decay Tick 2 Damage = 8.906345 After Decay Tick 3 Damage = 12.0144205 After Decay Tick 4 Damage = 15.126449 After Decay Tick 5 Damage = 18.242735 Listed QL = 35.243835 Recent Pre-Fix (Bugged) Stone House Wall Data Initial Damage = 0.0 After Decay Tick 1 Damage = 3.0877538 After Decay Tick 2 Damage = 6.178393 After Decay Tick 3 Damage = 9.272116 After Decay Tick 4 Damage = 12.369144 I don't have any data on decay of houses that are abandoned or in perimeter since the fix, so I can't comment on whether they're decaying properly or not. Whether non-abandoned house decay rates outside perimeter are what they should be or not is debatable (and has been debated for years), but I can confirm that for wooden house walls they're back to the decay rate they've been using since at least 2010 and for stone house walls they're back to the decay rate they've been using since at least 2011. I don't have any timber framed walls at the moment, as I personally don't consider them worth the effort/materials to make and only make a few periodically for testing purposes, though I'll probably get around to making and testing some in the next week or so. For those who are curious about my decay calculator, you can find a link to the current version of it (as well as some of my other tools and resource maps) in the following thread: http://forum.wurmonline.com/index.php?/topic/112192-telurian-tools/

I played around with source liquid, some small barrels, a mail box, flasks, and a reed pen for a bit. As far as I can tell, it seems like the mailing fees for source liquid change at certain break points. Here are the mailing fees I observed: Empty Small Barrel 1c Small Barrel with up to 0.05 kg of Source Liquid 2c Small Barrel with 0.05 kg - 0.10 kg of Source Liquid 6c Small Barrel with 0.10 kg - 1.00 kg of Source Liquid 11c Small Barrel with 1.00 kg - 8.28 kg (as much as I had to test with) of Source Liquid 1s1c

If that's accurate, it implies that accelerated decay hasn't simply been disabled. Even for a non-abandoned stone house wall, that's abnormally low damage from decay ticks (Those damage differences are showing less than 1/30 the expected damage per tick for a non-abandoned stone house wall.). Looking at the values, they also don't seem to fit the formula for normal QL-based decay. Normal QL-based decay is normally used for non-abandoned house walls, but not for accelerated decay due to abandonment/perimeter. It's possible the formula used for accelerated decay was just altered to do drastically less damage for now, but so low that it's actually much lower than regular non-abandoned decay normally is.