Posted October 9, 2015 (edited) If someone uses this API to make a tool, I myself and I am sure others would be willing to pay for it or at least buy you lunch with a donation if it is done right (hint hint). I mean afterall I am looking at spending maybe 200$ per month on a server (only reason I do not have the server already is lack of information on what is needed). Edited October 9, 2015 by Xyp Share this post Link to post Share on other sites
Posted October 9, 2015 (edited) My first map, still needs some adjusting but getting better. This is a 2048x2048 map. I am not satisfied with the rock calculation, how are you guys doing it? calculating slope then adjusting if rock or grass? Edited October 9, 2015 by Sklo:D Share this post Link to post Share on other sites
Posted October 9, 2015 (edited) Slope checks are the way to go but the wiki does not say what the serious climbing stamina drain curves is beyond the 23 dirt slope you cannot walk. http://www.wurmpedia.com/index.php/Cliffhttp://www.wurmpedia.com/index.php/Rock_tile Fill material in the real world can sustain a 30-45 degree slope (23-40 dirt slope). On systems that can blend textures sloped based interpolations would look much better but Wurm cannot do that. I was thinking to try sloped thresholds of 20 grass, 30 dirt/sand, 40 rock and 60 cliff for simple gameplay reasons it indicates how hard it would be to climb and dig. Would be nice to know how Wurm defines steeper for switching from rock to cliff though. Keep in mind maps need to have to have two terrain layers so you have rock underneath the grass/dirt. So maybe do a rock/cliff map layer which you expose or fill using erosion algorithms on the other layer Edited October 9, 2015 by yarnevk Share this post Link to post Share on other sites
Posted October 9, 2015 Awesome! Looking forward to play with this. Can someone recommend an open source IDE for Windows that can get this up and running quickly? I have started working on a map generator in World Machine, but it still needs a lot of refinement: http://i.imgur.com/AyQXjuB.jpg http://i.imgur.com/xl9vVgG.jpg Eclipse : https://eclipse.org/downloads/ Is what I use, quite easy to get working! Share this post Link to post Share on other sites
Posted October 9, 2015 Slope checks are the way to go but the wiki does not say what the serious climbing stamina drain curves is beyond the 23 dirt slope you cannot walk. http://www.wurmpedia.com/index.php/Cliff http://www.wurmpedia.com/index.php/Rock_tile Fill material in the real world can sustain a 30-45 degree slope (23-40 dirt slope). On systems that can blend textures sloped based interpolations would look much better but Wurm cannot do that. I was thinking to try sloped thresholds of 20 grass, 30 dirt/sand, 40 rock and 60 cliff for simple gameplay reasons it indicates how hard it would be to climb and dig. Would be nice to know how Wurm defines steeper for switching from rock to cliff though. Keep in mind maps need to have to have two terrain layers so you have rock underneath the grass/dirt. So maybe do a rock/cliff map layer which you expose or fill using erosion algorithms on the other layer API is ignoring cliff tiles at all, all exposed tiles are rock tiles. Personally I think that generating only rock layer first and then "eroding" it to create dirt layer based on it would be the best approach. Share this post Link to post Share on other sites
Posted October 9, 2015 (edited) I never understood the purpose of a cliff tile - the texture is nearly the same as a rock tile maybe just blander texture so it looked better at a distance without repeating dark patterns on the rock texture? If it was intended for steep slopes then it should have had a texture that looks better after the vertical stretch. However the wiki does show a difference - a cliff has no travel speed indicated - so was there special code they could not be climbed? horsebacked? It also says a cliff covered in dirt cannot be dug back up if covered in dirt, not sure what use that had since I thought you could not drop dirt on a cliff. So that means you do not define a surface on rock layer at all, it is by definition always rock. Edited October 9, 2015 by yarnevk Share this post Link to post Share on other sites
Posted October 10, 2015 Just small update - I pushed change which allows you to set number of mining actions needed to deplete vein, so you can play around with resources distribution now. 2 Share this post Link to post Share on other sites
Posted October 10, 2015 Ok I need to play around with that a bit more. Just one question, if I have a mountain where rock is at the surface, do I set the rocklayer height equal to the surface layer height and the surface tile as rock tile too, or how can I achieve that? Share this post Link to post Share on other sites
Posted October 10, 2015 (edited) *?* Edited October 10, 2015 by Darkmalice Share this post Link to post Share on other sites
Posted October 10, 2015 (edited) *?* Edited October 10, 2015 by Darkmalice Share this post Link to post Share on other sites
Posted October 10, 2015 Okay I don't know what happened there, sorry.If the rocklayer is greater at a point than the surfaceheight, just set the surfaceheight to equal the rocklayer at that point (if you want the rock exposed). Share this post Link to post Share on other sites
Posted October 10, 2015 Yeah seems legit, already found some ways to tweak my rock detection a bit. Will post a new update soon, already got some really promising maps. Thanks 1 Share this post Link to post Share on other sites
Posted October 10, 2015 (edited) Just small update - I pushed change which allows you to set number of mining actions needed to deplete vein, so you can play around with resources distribution now. What do you think of minecraft style distributions, drastically reduce depletion count but distribute them into more veins? Would that completely break the prospecting system? I like the idea of randomly hitting gold then getting on a hot streak with a huge vein,. With accelerated timers ores will not be complete blockages and you will be able to create mines much quicker. There is nothing more annoying then planning out a nice underground tunnel only to ruin it with zig-zag around the heavy nodes or stalling your progress mining it out. Edited October 10, 2015 by yarnevk Share this post Link to post Share on other sites
Posted October 10, 2015 Okay I don't know what happened there, sorry.If the rocklayer is greater at a point than the surfaceheight, just set the surfaceheight to equal the rocklayer at that point (if you want the rock exposed). Are you saying it will break if the surface is less than the rock layer? I understood it was whichever layer is higher is the one shown. Won't that cause flicker if they are the same with distant LOD not being able to exactly resolve which is higher so that you would want a underground surface well underneath the rock layer to expose the rock? Share this post Link to post Share on other sites
Posted October 10, 2015 Not a clue mate. Surfaceheight has to always be the surface layer, no? So if the rockheight is equal to or higher, then the surfaceheight tile is set to rock and the height of the rocklayer at that point also becomes the surfaceheight. So, if that is the case, won't the LOD just use the surfaceheight's rock-type? Share this post Link to post Share on other sites
Posted October 11, 2015 I glanced through the code a bit and noticed a few things. First, there's a pretty obvious bug at line 360 in MapData.java. Specfically, it's getting tiles from surfaceMesh instead of caveMesh, resulting in the getCaveTile method returning surface tiles instead of cave tiles. Second, while it's not an issue with the current square maps, several of the methods will require changes to work properly with non-square maps if people want to use non-square maps. Third, it's interesting to see how the map dumps are generated, particularly how the northwest and southeast corner heights of tiles are used to determine how to adjust the base tile color. I was a little surprised to see the way floating point values are used in calculating final colors and for the base color of water, though that does explain some of the rounding issues which led to me adding tolerances in my map dump scanner. While it's understandable you probably wouldn't want to output the whole map for extremely large maps (due to memory usage and file sizes), it's a bit odd the way a random subsection of such large maps is chosen to output. Also, is it allowed to decompile the contents of common.jar? I can tell from some of the posts that some people have already done so, but thought it would still be a good idea to check before doing so. In addition to making tools for generating/editing maps, some of the information from this could be useful for analysis of map dumps. While it's true you can't get enough information to reproduce a map from one, some useful information (to players) can still be extracted from them. I should be able to improve my map dump scanner's accuracy (in terms of determining tile types) with the information from this, though it would likely require a significant rewrite of the color analysis portion of its code (almost a total rewrite of that section of its code). Share this post Link to post Share on other sites
Posted October 11, 2015 Thanks for noticing this MapData bug, fixed and pushed. You can decompile common.jar, but discuss about it only in WU section. In addition, I don't think there is anything very useful inside (this is just simple class library shared between WU client and server). Share this post Link to post Share on other sites
Posted October 11, 2015 (edited) Lets talk some more about eroded rock, AKA dirt. Wurmified my rock erosion code to make rock and dirt greyscale maps. No pics because...it is just dirt. The issue I had is not even the wiki has settled on what the dirt layer is on the various islands, just a bunch of people arguing that sampling theory cannot determine an average (actually it can - people need to read up on confidence intervals - sampling is done all the time in manufacturing) So what I decided to do was to generate 1000 random maps as a sufficient sample to determine with three sigma outliers what the maximum dirt is likely to be out of the infinity of possible maps. I tweaked my erosion constants accordingly so that maximum depth was <=300 simply because that is the maximum digging slope for maxed diggers. Of course you can dig deeper by going wider open pit mining but that is more work. This is a case where gameplay trumps reality. An accurate erosion simulator would use flow and sediment science to create dirt fill. What I did was simply split my digs into dirt river/lake beds with air taking the place of elevated rivers/lakes (maybe someday we get real water features). The idea is that if anyone that thinks a dried lake bed with dried river channel for easy access road was a good place to make a deed and expect to make a simple mine hole even with max digging deserves to not reach the bottom. If you are paying attention to the terrain you will realize that dry creek washes and mountain tops are where the rock layer is closer to dirt layer. This also fits with regional resourcing that I want my maps to have. Now because I hate surface mining - my under dirt rock layer will not be fractally noisy nor have detailed erosion and will be smooth. Thus I changed my stats that such a critical fail should exist and changed to 95% of the dirt is less than 300, but there will be dirt pits deeper than that, this also gives me an out in case my random sampling falls short or codes change and I forget to resample. Actually one of my best experiences in WO was when the local got together to help just such a deeder who had located in a hollow. Once we had ruined his deed with an open pit mine and still did not reach bottom he decided it would look better if he just stuck with the cliff entrances rather than sink hole. And since Wurm does not enforce the dirt slope fall dropping rule for digging slopes, that open pit dirt mine that was never a rock mine was still there when I went back recently for nostalgia. The dirt bsb that he never did sell had long ago rotted/looted though. Edited October 11, 2015 by yarnevk Share this post Link to post Share on other sites
Posted October 11, 2015 (edited) I kept my rock layer generation simple, it's just based on the max slope of each border of the surface for that tile. int delta = (int) (Math.max(0, 60 - slope) * 1.5); rock.setTile(x, y, new RockLayerTile(height - delta));Then for setting the surface to rock/cliff I check if all 4 corners of the tile the surface height is equal to rock layer height. If it is then I check the max slope of each border; if it's less than 125 I set it to a rock tile, otherwise a cliff tile. Edited October 11, 2015 by Jonneh Share this post Link to post Share on other sites
Posted October 11, 2015 I am doing it almost in the same way. But the problem is that a slopes greater than 100-150 look really weird ingame I think. Is it worth it cutting the map so there is no slope bigger than 100? I don't think that there are many slopes in WO which are greater than 100...?? Share this post Link to post Share on other sites
Posted October 11, 2015 (edited) Short update on my map... Edited October 11, 2015 by Sklo:D 1 Share this post Link to post Share on other sites
Posted October 11, 2015 (edited) I am doing it almost in the same way. But the problem is that a slopes greater than 100-150 look really weird ingame I think. Is it worth it cutting the map so there is no slope bigger than 100? I don't think that there are many slopes in WO which are greater than 100...?? Some of the mountains and cliffs are pretty extreme but I guess not that steep, dunno what the WO slope break between rock and cliff tiles is, or even why there is a distinction (WurmAPI converts cliff to rock per Warlander). But plenty of terraformed slopes that high because dirt flow is not done for digs like it is for drops. I would love it if a mod did enforce that unless the slope was paved over time you risk it collapsing. Edited October 11, 2015 by yarnevk Share this post Link to post Share on other sites
Posted October 11, 2015 Have updated my repo (and changed name): https://github.com/BuddaT/WGenerator It's currently spitting out maps like the following: 2 Share this post Link to post Share on other sites
Posted October 12, 2015 (edited) Have updated my repo (and changed name): https://github.com/BuddaT/WGenerator The biomes look a lot better than this morning. I've been playing with your generator trying to add Clay into the paintBiome functionality. My strategy was to have a fairly high seed count (MAP_SIZE/2) but in the growGrass function I had it check if the tile type is clay and if the height is > 0.24, if so skip it. That tended to keep clay deposits next to water. Is there a setting I can mess with to lower the water level. I'd like to try to generate more continent style maps, fewer islands. Edited October 12, 2015 by vardoj Share this post Link to post Share on other sites