Damocles

Its quite trivial to write your own 16 importer in Unity for raw arrays like the terrain here. Not sure about its import options for 16 bit greyscale pngs. Java can handle many different png formats. But im sure there is some C# library that can also do that.

Worked fine when I tested it. Its independent of the build-in RWG. I have to check if there are new POIs that can be added to the list, or changed dimensions.

That would work too, as long as you always search towards the nearest next node (town). Not sure if that might end up looking like a snake then, not generating branching/crossing roads, but one long winded road. I have made a galaxy map (like in EvE) once with a similar distribution pattern, balancing out connections and dead ends to keep it interesting, while assuring that every system is connected to the grid.

You need to navigate via console to the nitrogen main directory and start the bat there locally. Java needs to find the resource folder in its working (active) directory. Thats usually the one the jar is started from. The world folder is the created inside the output folder with the maps name. The open command is just a convenience function to find the generated folder, using the explorer command.

Its mostly a visual thing to not have too many roads. The map could end up looking like a huge spiderweb with too many roads. The fact that roads seldomly go up mountains is naturally due to the roads actively avoiding harsh terrain if possible. They will try to find the easiest and flattest terrain to traverse, like going through a valley. I can test how it looks when the roads go up so SOME mountain POIs, to have more of those mountain-passes.

Ok, this 16 bit png format (8TYPE_USHORT_GRAY) seems to be imported by Java without an issue, it just needs to be converted to the float map directly then. I can add an import for that when I have some time.

I have not tried that TGA import, but the problem would still be to match the POIs to the hightmap and flatten the terrain as needed. So a tga import is of limited use for an actual map.

About the biome colors: I could render some "palette" pixels in a corner of the biome map optionally. (Im mostly worried about the GUI of the generator getting too complex with too many options), or just include a reference biomes.png for people to pick the correct colors from. About 16 bit greyscale: I could import those directly to the POI mapper (skipping the terrain gen, and its 8 bit intermediary output). I have to see the precise output what photoshop produces or terrain.party supplies though, maybe you upload and can add a link to the file. Then the user would have full control (and full responsibility) about the precise hightmap, as smoothing should be skipped here. ---- The water should theoretically flood everything evenly, even with a single water-spawner. The edge case you see at shallow shores is actually a problem with the games internal water-spreading calculation. Looks like it regards shallow terrain voxels as fully blocked in some cases. While the generator spawns the spawners in a regular grid (checking if the near area is below water level), it should theoretically still flood everything evenly. Maybe the floodfill is blocking itself with too many water spawners... If you want to test around, erase all water spawners from the xml apart from a single one in the middle of the lake (the lake with the observed problems) and see if it fills everything evenly. In theory a single spawner should fill the complete lake, as it only stops at the edge of the map. (the spawners for large lakes are after the <!-- comment in the xml)

Edit: I can add more colors to the mask, such as traders and playerspawns. The imported maps dont do much with the biomes (apart from putting snow on high elevation, and using an optional border biome). The patches of wasteland and burned forest are part of the terrain gen, the map importer runs parallel to that and does not apply those procedures. You would have to paint the precise color in the biomes.png to mark custom biomes in imported aps.

Hi, it really comes down to how users are able to find a usable workflow. Creating and managing greyscale images is trivial to do in any graphics program. Such that a usable hightmap and placement-mask for gameplay could be drawn within a few minutes. The best solution regarding quality would be to import a 2-byte channel RAW map directly (like from a Unity terrain or Blender). But that is a very specific workflow, I assume not many people can do or use efficiently. From https://terrain.party/ the user also just gets an 8-bit per channel greyscale image. Your suggestion is interesting to separate the range into 3 channels, but it would then still have to be told to the editor that those need to be combined (to match the internal 0 meter to 255 meter value range). The user would have to mostly work with 2 channels in parallel (from 0 to 84 meters - where most of the terrain would be set, and 85 to 168 meters - for medium hills). Overall, there is a natural limit to the resolution given by the nature of the voxels anyhow. POIs can only have blocks placed in 1 meter increments. The terrain needs to match that around the POIs. The terrain is smoothed over during POI placement and before export. So a high dimension of the imported hightmap (possibly as big as the output maps dimension will be) will have a higher impact on quality than the resolution. ------ Water: any area at 33 meters and below will get a water-spawner-node. (33 would be the RGB value here). So the main low-land terrain should be at least 35 Meters high. For imported highmaps from terrain libraries you should adjust the grey-color-range in such a way that oceans/lakes have a grey value of 33 and below, and the land-mass 35 and above. Maybe I can add a water-level to the preview map to visualize that. (Its only an approximation, as the game is ultimately doing the water "flooding") There are two water types: the general water level (33 and below) and small lakes (spawned at different hights, can be disabled).

Lets see, I will add some logic eventually. Currently, you could add the bridge POIs manually by editing the prefabs.xml something like <decoration type="model" name="bridge_asphalt1" position="654,41,-247" rotation="1" /> where the second parameter in position is the hight (wich you probably need to run some tests to find the correct one) those are the bridge POIs currently in vanilla: //bridge_10x10_end_01,BRIDGE,2,-1,10,18,10, //bridge_10x10_tile_01,BRIDGE,2,-1,10,18,10, //bridge_asphalt1,BRIDGE,2,0,39,11,11, //bridge_asphalt_broken,BRIDGE,2,0,39,16,11, //bridge_concrete1,BRIDGE,2,0,39,11,11, //bridge_wood1,BRIDGE,2,0,39,11,9, //bridge_wood2,BRIDGE,2,0,32,10,7,

Just added the option to NitroGen (v0.253) to set city and town spawners to the mask. So you can define the preferred spawn locations (the center) for those settlements. (placing red or green pixels onto the mask image)

NEW VERSION (same download link) v 0.253 Can use city and town spawers for the mask (to define make your own town and city layout) within the mask you can set 3 predefined colors #1 solid Red: RGB 255,0,0 (full alpha 255) -> City Spawner #2 solid Green: RGB 0,255,0 (full alpha 255) -> Town Spawner #3 solid Yellow: RGB 255,255,0 (full alpha 255) -> help color (ignored) wherever you set a city or town color PIXEL, a city or town is preferred to spawn there the generator will (from top-left to bottom right) scan for pixels and spawn a city or town ad long as there are more to spawn, (if you set more pixels than the number of cities, it will just ignore the spawners, in this case set the number of cities to spawn higher) If it can not find a pixel it will spawn a city or town on a random suitable location as before. beware: only use SINGLE PIXELS, as each pixel defines a spawner! To make editing the mask easier you can set a yellow help color around those pixels, to make them easier to find. The help color is regarded as passable area (not blocking POI spawns) There is an example mask in the resource directory showcasing the city and town spawners.

The topic was more about the prefabs details. What I mean with tricky is less how the bridge has a smooth surface-terrain transition, and has more to to with matching roads to bridges (of fixed length) in a random map with random areas to bridge over. Here there needs to be logic to: -detect where a bridge should be placed -have the road connect to both ends of the bridge -create landfill for areas wider than the bridge -have everything work in a straight line, as bridges can only be turned 90 degrees. -place the bridge POI precisely and adjust the terrain as needed (so the ends of the bridge dont hang in the air) Im also not super sure if the game will try to fill the area under the bridge POI automatically with terrain, as this would render bridges pretty useless.

A hint for hosting very large server maps, NitroGen creates several intermediary outputs: -genHM.png -poiHM.png -previewMap.png They could be deleted before hosting the game, so the clients dont download those images (takes more time than necessary)

Ok, edited it in

The default in NitroGen is an 8k map, you might just have to change the size to 8192 x 8192 <property name="WorldGenSize" value="8192"/> You probably also have to change the name of the generated map folder (the one you copy over) to your chosen name, the default folder name is NitroGenMap

Thats why I've build in this version check message (Java can not clearly state what version it is using internal lookups for whatever reason), Often there are several versions installed over time, and NitroGen is probably one of the few instances where that 64bit really matters (heap memory).

Open a command shell (cmd in Windows), and type in java -version this show the version of java that the OS is using as active installation, it might point to a 32bit version. The 64 bit version is needed to reserve more memory for the larger map sizes. Its often the case that several java versions are installed. Can you tell me what java -version prints out?

Small update: v 0.252 - can select to import HM and mask from output directory (you need to manually copy it there) - "unique" marker, to restrict POIs to spawn only once (for custom scenario prefablists), just add it to the zone list like mp_waste_sewer_hole_1,COMMERCIAL,2,-10,33,32,31,houses;unique be careful to have at least one non-unique POI of each zone type, else the generator can run into a deadlock

I think I can do that. The main reason why the import map is loaded from the resource dir was that a novel user can try it out immediately without having to set up a directory. I can also make it load the import map from the target output folder. (you need to make the directory with the correct name then manually)

Added your post to the main post... 20 k is pretty ambitious (lots of RAM needed to generate)

I have not tried out setting up a dedicated server, if you tutorial works, I can add it to the starter post.

There are also water bugs occurring due to the water not spreading correctly (mostly at shallow shorelines). But that more a fault of the 7dtd water-flooding calculations. Water is still very fragile currently in 7DtD... If there are more water bugs, I could make those ramps even wider...

Here a quickly drawn custom map with lots of islands, which forces roads to cross the water: They will then generate a ramp over the main water level. Maybe you try to download the very recent version. I did add those ramps to 0.251 in a second upload quickly after the first upload. (so technically the versioning is not correct here)