U=Unpassable t=tundra P=Peak w=water (ocean)
UUUUUUttPtUUUUUU
wwwwwttttttwwww
wwwwwttppwwwww
wwwwwttwwwwwwNo, but it is typically impassable Ice. I adjusted the terrain generation script to always force that top and bottom row as water myself, mainly for asthetic reasons.
You can actually do a bit without breaking the XML rules. The problem comes from non-standard resources, if you write custom resource placement any mod that adds custom resources won't be able to use your script. Of course you've already 'broken' custom features so it really shouldn't matter
Famous last words
Forgive me since I'm not looking at the code right now, but is it easy to track the flowmap (like knowing which adjacent plot to check/modify). I remember bits of it vaguely, like the L and O parts, isn't the rest N,S,E,W? If so is it a matter of saying, "ok, this plot is a W so if I go one plot E I'm tracking the flow 'upstream'."
Didn't you drop the code to clean up lakes, or is it just hidden now? The makeHarbor function is working very well right now, the problem is that I seem to have a bit of luck in getting seas surrounded by land that is two tiles thick, perhaps a quick change to the horbor code is all I need. Is that executed before or after the area lists are generated? If it's after it should be a simple matter to identify inland seas but if it's before I can work directly with the heightmap... Gah!
Yeah, I tried some basic 'evaporation' code, but I wasn't happy with the results since it affected all of the rivers. Although I suppose I could run a check after the terrain is generated but before the rivers are to only apply evaporation in desert squares (I was using temperature & rainfall data before). The again, maybe my evaporation code was just flawed
Yes, the riverMap works that way also. Keep in mind that when you go backwards, each plot might branch off to tributaries, so you'll have to put them on some kind of stack for deletion later. For each plot you think, "ok, who of my four neighbors is flowing into me?" If the answer is nobody, then you are done with that branch of river. Drastic stuff! Maybe theres a better way. Remember that the latest version allows you to control floodplain generation, so maybe you can render those rivers and lakes impotent.
I fill lakes right at the beginning during heightmap generation, with the idea that they will be recreated via the river system. The Areamap class that you speak of is general purpose, if you learn how to use it you can do something on your own concerning areas. I use it for several different things.Didn't you drop the code to clean up lakes, or is it just hidden now? The makeHarbor function is working very well right now, the problem is that I seem to have a bit of luck in getting seas surrounded by land that is two tiles thick, perhaps a quick change to the horbor code is all I need. Is that executed before or after the area lists are generated? If it's after it should be a simple matter to identify inland seas but if it's before I can work directly with the heightmap... Gah!
I have an idea. Find the following code:Yeah, I tried some basic 'evaporation' code, but I wasn't happy with the results since it affected all of the rivers. Although I suppose I could run a check after the terrain is generated but before the rivers are to only apply evaporation in desert squares (I was using temperature & rainfall data before). The again, maybe my evaporation code was just flawed
#Create average rainfall map so that each intersection is an average
#of the rainfall from rm.rainMap
for y in range(hm.mapHeight):
for x in range(hm.mapWidth):
i = hm.GetIndex(x,y)
avg = 0.0;
for yy in range(y,y-2,-1):
for xx in range(x,x+2):
ii = hm.GetIndex(xx,yy)
avg += rm.rainMap[ii]
avg = avg/4.0
self.averageRainfallMap[i] = avgChange
self.averageRainfallMap[i] = avg
to
self.averageRainfallMap[i] = avg * avgThat actually works very well, except I had to reduce the RiverThreshold, not increase it. At 2.0 and above I would have maybe a single river on the entire map, at 1.0 there were more but they were all 1-2 tiles at most, at 0.2 it's very good (for my taste) with plenty of rivers around the map and only a few scarce rivers in the desert. At any rate, that's certainly a more effecient method rather than cycling through the entire map another three of four times to trace rivers
#self.areaList.sort(key=operator.attrgetter('size'),reverse=True)
tpList = [ [ item.size , item ] for item in self.areaList ]
tpList.sort()
tpList.reverse()
self.areaList = [ item[1] for item in tpList ]
#continentList.sort(key=operator.attrgetter('size'),reverse=True)
tpList = [ [ item.size , item ] for item in continentList ]
tpList.sort()
tpList.reverse()
continentList = [ item[1] for item in tpList ]
#continentList.sort(key=operator.attrgetter('ID'),reverse=True)
tpList = [ [ item.ID , item ] for item in continentList ]
tpList.sort()
tpList.reverse()
continentList = [ item[1] for item in tpList ]
#lakeNeighbors.sort(key=operator.attrgetter('altitude'),reverse=False)
tpList = [ [ item.altitude , item ] for item in lakeNeighbors ]
tpList.sort()
lakeNeighbors = [ item[1] for item in tpList ]if (sys.platform == 'darwin'): MacOS = TrueSeven05 said:
No idea here... I double checked and every check for a random value that I use is using your PWRand.random() or PWRand.randint(). Anyway, setting it to use the map rand vs. the python rand does the trick in MP games- no more OOS issues when using your base script.
