Tool KingGen - A Random World Generator for 7 Days to Die

[Cpt Krunch]

9 hours ago, bdubyah said:

Speaking of radiation, would it be possible to say, tag a POI in the list so that when it gets placed, it adds to the radiation.png automatically? I have some POIs in my mod that I want to be radiated no matter what and this would be nice for that. I'm currently just using entities, but this would be cleaner.

Would that just add the radiation to the coordinates of the prefab? I guess maybe radiation could be written to the processed dtm or splat

[KingSlayerGM]

4 hours ago, Maharin said:

Linux Mint 19.3 here with Python 3.6 installed (the default, everything still fully supported).  While I could upgrade my Python to 3.8 is there any real reason to require the later version be installed?  Will it not work on older versions?

It is not required at all. KG is a self contained executable. Anything it needs should be inside the file already.

[Maharin]

44 minutes ago, KingSlayerGM said:

It is not required at all. KG is a self contained executable. Anything it needs should be inside the file already.

 

I get this error when I run the program (from the console, not working through my GUI):

 

[28155] Error loading Python lib '/tmp/_MEIDc1As9/libpython3.8.so.1.0': dlopen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/_MEIDc1As9/libpython3.8.so.1.0)

 

So maybe it is a glibc issue instead?

[KingSlayerGM]

Some system libraries are expected and not included in the executable.

 

Yes, it looks like you need glibc. Hopefully installing it should fix the issue.

[Maharin]

Glib 2.27 is installed but your program is requiring 2.29.  The problems I keep getting into with this are about required versions (Python 3.8 versus 3.6 was the first one) and not whether a particular lib or program is installed. 

 

I downloaded the Windows version and tried running it with Wine.  It runs but crashes every time with this exception:

 

Unhandled exception: unimplemented function vcomp140.dll._vcomp_for_static_simple_init_i8 called in 64-bit code (0x000000007b44da67).

 

Gonna give up for now, but let me know if you want me to test anything else or give you more information.

[meganoth]

20 hours ago, KingSlayerGM said:

@gpcstargate and others interested:

I tried setting a strict rule of no poi repetition inside the same city, but the result is large empty lots with no pois, which is very ugly. For now the system will remain as it is. If you really want to avoid repetition I suggest small cities, small towns, small vllages, large grid size, and long poi list. These settings will reduce the chances of repetition.

 

 

Any expert programmer that has an idea for an algorithm, please share. Keep in mind that when picking a poi for a specific lot there are 5 requirements:
1) it must fit in the lot,

2) it must be a city poi if building a city, or a town poi if building a town,

3) it must be compatible with the zone(downtown,iindustrial...) of the city,

4) it must be compatible with the biome

5) it should avoid repetition

 

Got a suitable idea:

 

1) For a specific city create a list-of-poi-lists. At first the list-of-po-lists contains just one list with all pois available in it.
  listofpois= [pois]
2) For each plot:
  *) Cycle through the list-of-poi-lists until you have found a fitting POI:
     for listnum in listofpois:
     a) Find a suitable building for that place with the normal algorithm you use at the moment 
        (that algorithm must be able to report back if it can't find a suitable building)
        poi= findsuitablepoi(listofpois[listnum])
     c) if none is found, go to the next entry in the list of poi lists, otherwise remove the poi from the list it is in and move it to the next poi list in the list-of-poi-lists
        if (poi != False):
           if listnum = len(listofpois):
             listofpois.append([])
           listofpois[listnum+1].append(listofpois[listnum][poi])
           del(listofpois[listnum][poi])
		   break

 

Practically it makes a priority list so that always the least-often placed poi suitable for a lot will be used. And it simply calls the algorithm used now, so it should be easy to plug in.

 

Changing the current algorithm (for example if counts for specific cities were added) would probably save on execution time and memory usage, but to know how to change that algorithm you first would need to know how it works currently

 

4 hours ago, Maharin said:

 

I get this error when I run the program (from the console, not working through my GUI):

 

[28155] Error loading Python lib '/tmp/_MEIDc1As9/libpython3.8.so.1.0': dlopen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/_MEIDc1As9/libpython3.8.so.1.0)

 

So maybe it is a glibc issue instead?

 

There is a very small chance that you could replace /tmp/_M.../libpython3.8 with a logical link to your libpython3.6 library in /usr/lib/x86_64-linux-gnu and it just works. (When you replace, just move libpython3.8 away so you can reinstate it again it it doesn't work)
 

Other solutions I can see are

1) installing a newer python3.8 from backporting repositories and reoving libpython3.8 in tmp as well

2) installing a newer glibc from backporting repos

3) updating Mint

 

 

 

[KingSlayerGM]

1 hour ago, meganoth said:

Got a suitable idea:

1) For a specific city create a list-of-poi-lists. At first the list-of-po-lists contains just one list with all pois available in it.
  listofpois= [pois]
2) For each plot:
  *) Cycle through the list-of-poi-lists until you have found a fitting POI:
     for listnum in listofpois:
     a) Find a suitable building for that place with the normal algorithm you use at the moment 
        (that algorithm must be able to report back if it can't find a suitable building)
        poi= findsuitablepoi(listofpois[listnum])
     c) if none is found, go to the next entry in the list of poi lists, otherwise remove the poi from the list it is in and move it to the next poi list in the list-of-poi-lists
        if (poi != False):
           if listnum = len(listofpois):
             listofpois.append([])
           listofpois[listnum+1].append(listofpois[listnum][poi])
           del(listofpois[listnum][poi])
		   break

 

Practically it makes a priority list so that always the least-often placed poi suitable for a lot will be used. And it simply calls the algorithm used now, so it should be easy to plug in.

 

Changing the current algorithm (for example if counts for specific cities were added) would probably save on execution time and memory usage, but to know how to change that algorithm you first would need to know how it works currently

The idea of lists as "levels" and when you have finished a level you move on to the next one, is pretty cool. Just a couple of thoughts:
1) it could grow forever because small pois keep getting selected to fill small lots, so they keep getting pushed to another list. Whereas large pois remain in the first list.
2) why the need for a list of lists? Why do you actually need to separate the pois in "levels"? You could just have a single queue and when you extract a poi, it gets pushed back to the bottom of the queue. Thus ensuring that you always get the least recently used poi.

 

 

Point 2 is basically what KG does right now. However cities are large, requirements for pois are strict, so very few are actually a good match for a specific lot, and what happens is that KG is forced to go back to pois already used somewhere else.

 

 

 

I've just had this idea. For each city, for each poi, keep a counter of how many times that poi has been used in that city. Sort the list of pois based on the value of that counter. Anytime you need to select a poi, scan the list from less used to most used and stop as soon as you find a suitable one. Update the counter.

Edited May 27, 2021 by KingSlayerGM (see edit history)

[meganoth]

1 hour ago, KingSlayerGM said:

The idea of lists as "levels" and when you have finished a level you move on to the next one, is pretty cool. Just a couple of thoughts:
1) it could grow forever because small pois keep getting selected to fill small lots, so they keep getting pushed to another list. Whereas large pois remain in the first list.

 

Not forever. The position in list-of-poi-lists is just the number of times this poi was already placed in that town.

 

That can't be worse than it is now: If with the old algorithm you would have found 10 of the same poi in a specific city (and this was the maximum) then with this algorithm 10 would be the maximum size of list-of-poi-lists and that poi would be in that last list only if no better distribution among fitting pois were possible. But less if there were more than one POI fitting into that lot.

 

Example: Say there were 20 very small lots and only 4 pois available to fill that slot. And the old algorithm would set 10 to have poi1, 7 to have poi2, 3 to have poi3 and 0 to have poi4. The new algorithm would distribute them 5,5,5,5 and the list size of list-of-poi-lists would be 6, with all four of them in that last list.

 

Quote

2) why the need for a list of lists? Why do you actually need to separate the pois in "levels"? You could just have a single queue and when you extract a poi, it gets pushed back to the bottom of the queue. Thus ensuring that you always get the least recently used poi.

 

As I said I don't know the orignal algorithm. If that algo for example picks pois through randomly starting somewhere in the list and taking the first poi it finds, it won't work with pushing back. Or if it creates a tree of pois from the list first.

I have been using the original algo as a black box. If you know how the original algo works, you can probably change it to work similar with much less CPU cycles, no question about that.

 

Quote

 

 

Point 2 is basically what KG does right now. However cities are large, requirements for pois are strict, so very few are actually a good match for a specific lot, and what happens is that KG is forced to go back to pois already used somewhere else.

 

If it already places an optimal distribution of suitable pois then you can't change the problem with a new poi-picking algorithm you asked for.

 

You either need to increase the number of acceptable pois for a specific lot footprint or decrease the number of those (small) lots to be filled. That would need knowledge about the current way city layout is generated in KingGen and the rules governing that.

 

Quote

 

 

 

I've just had this idea. For each city, for each poi, keep a counter of how many times that poi has been used in that city. Sort the list of pois based on the value of that counter. Anytime you need to select a poi, scan the list from less used to most used and stop as soon as you find a suitable one. Update the counter.

 

 

Edited May 27, 2021 by meganoth (see edit history)

[KingSlayerGM]

8 minutes ago, meganoth said:

Not forever. The position in list-of-poi-lists is just the number of times this poi was already placed in that town.

 

That can't be worse than it is now: If with the old algorithm you would have found 10 of the same poi in a specific city (and this was the maximum) then with this algorithm 10 would be the maximum size of list-of-poi-lists and that poi would be in that last list only if no better distribution among fitting pois were possible. But less if there were more than one POI fitting into that lot.

 

Example: Say there were 20 very small lots and only 4 pois available to fill that slot. And the old algorithm would set 10 to have poi1, 7 to have poi2, 3 to have poi3 and 0 to have poi4. The new algorithm would distribute them 5,5,5,5 and the list size of list-of-poi-lists would be 6, with all four of them in that last list.

 You are right, it wouldn't grow that much.

 

8 minutes ago, meganoth said:

As I said I don't know the orignal algorithm. If that algo for example picks pois through randomly starting somewhere in the list and taking the first poi it finds, it won't work with pushing back. Or if it creates a tree of pois from the list first.

I have been using the original algo as a black box. If you know how the original algo works, you can probably change it to work similar with much less CPU cycles, no question about that.

 

If it already places an optimal distribution of suitable pois you can't change the problem with a new poi-picking algorithm you asked for. You either need to increase the number of acceptable pois for a specific lot footprint or decrease the number of those (small) lots to be filled. That would need knowledge about the current way city layout is generated in KingGen and the rules governing that.

 

 

The current algorithm divides pois into groups based on their properties. For example all pois that are "city","downtown" and "desert" are in a list. A poi can be in more than one list. Lists are shuffled. When KG needs a poi for "village","oldresidential","forest", it will go to that list and use it as a queue. Talking the last recently used poi.

Edited May 27, 2021 by KingSlayerGM (see edit history)

[meganoth]

If we assume that the city generator just generates rectangular city blocks of same or a specific number of sizes and then automatically fill these blocks with pois, then I would suggest to add lot

17 minutes ago, KingSlayerGM said:

 You are right, it wouldn't grow that much.

 

 

 

The current algorithm divides pois into groups based on their properties. For example all pois that are "city","downtown" and "desert" are in a list. A poi can be in more than one list. Lists are shuffled. Then when KG needs a poi for "village","oldresidential","forest", it will go to that list and use it as a queue. Talking the last recently used one.

 

Ok, then you really need to attack the algorithm which parcels city blocks into lots. I would guess this is just done randomly by placing pois until space runs out?

 

One idea could be to provide a lot of handcrafted parcelled blocks for the poi placer to use. Or automatically create a few random parcellations and drop the ones with too many small plots or other deficiencies.

 

Edited May 27, 2021 by meganoth (see edit history)

[SEDATIVE]

Umm, i just generated a few Vanilla maps, and there is NO Red Mesa in it 🤨 How is that possible?  🤯

Edited May 28, 2021 by SEDATIVE (see edit history)

[KingSlayerGM]

Version 0.8.0 released!

Here is what's new:

• Added very wide biomes option
• Added label to identify game version (for compatibility)
• Added key bindings: "enter" to start generation, "escape" to stop generation, "escape" when not generating to close the editor, "tab" to switch to advanged settings and back
• Added option to customize world border
• Added option to choose output folder
• Optimizations for smoothing world around pois
• Added support for raw heightmap import
• Added tools for map makers:
  • png to raw
  • raw to 16 bit png
  • raw to 8 bit png
  • biomes file fix
  • splat file fix
  • preview generator for any world
• Optimized caching of native functions
• Improved mountains. Sharper edges, rougher terrain.
• Added dynamic elevation for cities. Now cities spawn at whatever height the terrain underneath is
• Added cities map import: you can now draw cities on a file and KG will generate cities accordingly
• Added zoning map import: you can mask zones on a png file and KG will use that to generate pois

Edited May 28, 2021 by KingSlayerGM (see edit history)

[KingSlayerGM]

This is a new very cool feature of KingGen. You can paint cities!

[gavin11489]

Great work so far with this! I've used Nitrogen for a while and only just come across KingGen - initial impressions are great! I love the 'city painting' feature.

 

A couple of questions / suggestions; 
1) Can we have an option to change water start height and also city spawn height range please? I like to use real location heightmaps and being able to adjust these values allows for more 'realistic' placement of certain locations.

2) As mentioned the 'city painting' map is great - Can we also do the same for roads?

 

My goal is to re-create real world locations with somewhat accurate layouts of roads/pois/etc. 

 

Cheers! 

[Cpt Krunch]

2 hours ago, gavin11489 said:

; 

1) Can we have an option to change water start height and also city spawn height range please? I like to use real location heightmaps and being able to adjust these values allows for more 'realistic' placement of certain locations.

Ive been doing these maps for a few years, and Ive always found 1-to-1 mapping to real locations close to impossible. IMHO you wont ever get it to scale just right, your best option is try and recreate specific scenes tied approximately to their real world locations.

The other thing you want to strongly consider is prepping your height maps separate from tools like KG or Nitro, that editing step is really where you are going to come to realize how close you can get a place to original size and then scale the best you are able to.

 

 

[Dark_Shadow_231]

One thing I've not seen in any random generator, (be interested to know if any of the features here would allow it with some tinkering), is the ability to create random maps, where traders are outside of towns/cities?

[KingSlayerGM]

8 hours ago, Dark_Shadow_231 said:

One thing I've not seen in any random generator, (be interested to know if any of the features here would allow it with some tinkering), is the ability to create random maps, where traders are outside of towns/cities?

I think this feature is in nitrogen, isn't it?

Anyway it's not hard to do.

[Dark_Shadow_231]

2 hours ago, KingSlayerGM said:

I think this feature is in nitrogen, isn't it?

Anyway it's not hard to do.

I'll have a look into that. I thought Nitro had been abandoned.

Is it something that KingGen currently cannot do?

[KingSlayerGM]

1 hour ago, Dark_Shadow_231 said:

I'll have a look into that. I thought Nitro had been abandoned.

Is it something that KingGen currently cannot do?

KG doesn't do that. But i can easily add it for next release.

[Dark_Shadow_231]

5 minutes ago, KingSlayerGM said:

KG doesn't do that. But i can easily add it for next release.

Yes would definitely love that. I always like the traders outside cities

1. as that's the trade off. Lots of places to loot, or near a trader, but not both.

2. cities are supposed to be dangerous so traders would set up away from those.

[Cpt Krunch]

 

3 hours ago, Dark_Shadow_231 said:

I'll have a look into that. I thought Nitro had been abandoned.

Is it something that KingGen currently cannot do?

Nitro isnt abandoned quite yet, but at the rate King is updating, its quickly being surpassed.

[Dark_Shadow_231]

6 hours ago, Dark_Shadow_231 said:

Yes would definitely love that. I always like the traders outside cities

1. as that's the trade off. Lots of places to loot, or near a trader, but not both.

2. cities are supposed to be dangerous so traders would set up away from those.

Would it also be possible to allow a minimum distance between those traders? I don't like them to near each other.

[gavin11489]

20 hours ago, Cpt Krunch said:

 

 

That's all your opinion mate. I didn't say 1 to 1, I said 'realistic'. There are plenty of real world 16KM places that work fine for game maps, or it's a simple case of scaling to your needs.

Oh and of course I "prep" heightmaps in software other than KG/Nitro. I'm aware of the limitations. 

 

No offense intended, but your reply was not helpful and came across a bit elitist. I'm just asking for features to software we all enjoy...

 

 

[Cpt Krunch]

1 hour ago, gavin11489 said:

 

Oh and of course I "prep" heightmaps in software other than KG/Nitro. I'm aware of the limitations. 

 

 

 

Of course I prep my map! Well excuuuuse me mate. You've got 20 posts. Almost no one knows to do prep. What in anything that you said would lead me to have any idea what you know or dont know? If you already knew to do any of that, I would imagine you would have been doing it with Nitrogen like the rest of us for the last 3 years.

Good luck with your map.
 

Edited May 29, 2021 by Cpt Krunch (see edit history)

[gpcstargate]

12 hours ago, Cpt Krunch said:

 

Nitro isnt abandoned quite yet, but at the rate King is updating, its quickly being surpassed.

 

Good Day . KingSlayerGM

 

Would love to see this feature in KingGen ... I personally do like 1 traders per city and town (as long as they next to each other) 

Thank you for the update, just downloaded it now ... the Old Gamer .. 😌

Edited May 29, 2021 by gpcstargate (see edit history)