[MOD] Colonization: 2071

[orlanth]

It was actually working fine for me yesterday but now is not when I reinstall from the github branch. It's strange but I wonder if there had been something remaining in my local folder or game cache that isn't on github.

Also odd is that the error would relate to memory allocation for HillsYieldChanges for IMPROVEMENT_FARM when the commit had nothing to do with that. I had also been unsuccessfully trying to get the M:C techtree screen interface working, I wonder if the techtree screen interface may have resulted in a memory leak which contributed. Anyway I will have to roll back to the earlier commit and try applying the non-tech screen XML changes only.

edit: ok, it's working for me now, does it work well for you? I'm still not totally sure what the problem was.

 

[Nightinggale]

New assert when opening inventions in the pedia opened from main menu (can be ignored). It appears to work anyway, but it might be the cause of some pink on the screen (missing graphics). It's not a high priority issue.

The dll reappeared in last commit and I had to delete my own before git would let me pull the new version. I wonder if I can tell git to not allow .dll files.

I will look into the empty inventions screen. I suspect it to be a coding issue rather than an XML setup issue.

 

[Nightinggale]

I will look into the empty inventions screen. I suspect it to be a coding issue rather than an XML setup issue.

I was both right and wrong. I solved the problem, found a new one and solved that one as well.

<iX_Location>0</iX_Location>
<iY_Location>0</iY_Location>
<RequiredInvention/>
<RequiredInvention2/>
<RequiredInventionOr/>
<RequiredUnitType/>
<RequiredYields/>
<iCostToResearch>100</iCostToResearch>

The x,y location does precisely what you think it will do. It tells the x,y location on the invention screen where the invention is drawn. The issue here is that all are currently set to 0,0. The code will skip any invention where either x or y is below 1.

I added iCostToResearch (it is present in M:C). It tells research cost and is needed by any invention drawn on the invention screen. The reason is that it tells remaining turns and this is done by yields produced each turn divided with total costs for this invention. The default value of iCostToResearch is 0 meaning it will divide by 0, which in turn crash the python script and we get a python error and once again a blank screen. Setting iCostToResearch to any positive number will fix this problem.

 

[orlanth]

yes that gets them to display correctly the hardcoded M:C techs I will leave at 0,0 since they're the Censures rather than techs. The background image shows up as the wrong sizes depending on screen resolution, I'm not sure how to make it adapt to that though I know Schmiddie & Ray got screens to adapt for various resolutions for RaR.

I added Build commands for all units for clearing/harvesting all the terrain Features. In the old 2071, you can unlock access to Mining Vessels and Science Vessels which have special build commands to harvest valuable Features in Deep Space (eg Asteroid Belt for Mining Vessel and Dark Matter / Anomaly for Science Vessel). This had worked fairly well without requiring coding of a separate Whaling Boat system like RaR, but the one drawback is that the AI players didn't yet know to use it even when using the UnitAI for Pioneers. Is there some way to tell a certain UnitAI type to clear features that are nearby?

 

[Nightinggale]

yes that gets them to display correctly the hardcoded M:C techs I will leave at 0,0 since they're the Censures rather than techs.

TEST is missing iCostToResearch and as such the tech advisor screen is broken. I tried to make an assert based on this, but it asserts on working code in M:C. There is more to this than just iCostToResearch and x,y location.

I spotted that the first 5 civics aren't civics at all. They are Civic types like NATIVE_TECH and MEDIEVAL_TRADE_TECH. I think it would be better to move those into a xml file of their own. It is also somewhat unclear what the effect of each is as there is no comments about it and some aren't mentioned in C++ at all. I suspect that the game will not care if InventionCategory is NATIVE_TECH or MEDIEVAL_TECH.

The background image shows up as the wrong sizes depending on screen resolution, I'm not sure how to make it adapt to that though I know Schmiddie & Ray got screens to adapt for various resolutions for RaR.

If you know somebody, who made something work and you can't get it to work, then the obvious solution is to ask that somebody how to do it

I added Build commands for all units for clearing/harvesting all the terrain Features. In the old 2071, you can unlock access to Mining Vessels and Science Vessels which have special build commands to harvest valuable Features in Deep Space (eg Asteroid Belt for Mining Vessel and Dark Matter / Anomaly for Science Vessel). This had worked fairly well without requiring coding of a separate Whaling Boat system like RaR, but the one drawback is that the AI players didn't yet know to use it even when using the UnitAI for Pioneers. Is there some way to tell a certain UnitAI type to clear features that are nearby?

Just make it work for the human player. Once the game is mature enough for the player to do this, then I can look into the AI code. This order allows me to test if modifications actually improve AI behavior.

 

[orlanth]

I spotted that the first 5 civics aren't civics at all. They are Civic types like NATIVE_TECH and MEDIEVAL_TRADE_TECH. I think it would be better to move those into a xml file of their own. It is also somewhat unclear what the effect of each is as there is no comments about it and some aren't mentioned in C++ at all. I suspect that the game will not care if InventionCategory is NATIVE_TECH or MEDIEVAL_TECH.

That's right; these initial entries are just the "Tech Categories" - the existing inventions system of M:C is set up such that each of the actual techs belongs to a category such as MEDIEVAL_TRADE_TECH, and each of these categories is declared by an entry in civicinfos.xml where all the other tags are basically empty. Then all of the actual inventions that are from that category declare that in their <InventionCategory> tag. In 2071 I've planned to eventually try to use this to place Techs into categories like Genetics or Nanotechnology, where a leader trait could give a slight boost to that type of research. Currently in M:C, techs from MEDIEVAL_TRADE_TECH show up in the "Trade Perks" screen rather than inventions screen; there is some hardcoding for techs from MEDIEVAL_CENSURE that I'm not sure about the details of. I'm also not clear on the effects of NATIVE_TECH but the game asserts if it's not in there; everything in the current commit of 2071 civicinfos is mostly just the content expected by M:C to avoid asserts. IIRC I think NATIVE_TECH techs may be given as free starting tech to all Natives.

I agree the current system winds up being a bit cumbersome / confusing; though it's not impossible to work around that in XML & so is not a major problem if this system is hard to change. One possibly more natural way might be to instead declare the categories in civicoptioninfos.xml, and have tags there like <bIsInvention> <bIsCivic> <isCensure> allow Inventions or Civics to appear appropriately, which would also be good if there are plans to let this system handle actual Civics in addition to Techs, Censures, and endgame Constitution. Currently everything handled as invention-categories has <Type>CIVICOPTION_INVENTIONS</Type> .

 

[Nightinggale]

That's right;

Useless comment. I wrote it. Naturally it's right

In 2071 I've planned to eventually try to use this to place Techs into categories like Genetics or Nanotechnology, where a leader trait could give a slight boost to that type of research.

In which case the categories will need to be defined in an xml file, which is read before CvCivilizationInfo. I can't remember the load order, but I know where it is written in the DLL and we can change it as well. In fact it is really easy to modify the load order. It's also fairly strait forward to add new files here.

I agree the current system winds up being a bit cumbersome / confusing; though it's not impossible to work around that in XML & so is not a major problem if this system is hard to change. One possibly more natural way might be to instead declare the categories in civicoptioninfos.xml, and have tags there like <bIsInvention> <bIsCivic> <isCensure> allow Inventions or Civics to appear appropriately, which would also be good if there are plans to let this system handle actual Civics in addition to Techs, Censures, and endgame Constitution. Currently everything handled as invention-categories has <Type>CIVICOPTION_INVENTIONS</Type> .

Civicoptioninfos.xml appears to be an ok place to add the groups/types. Technically it would be the most correct thing to add a brand new file, but using this one is easier and I can't really see any issues unless somebody starts to use the ID as index to an array.

MEDIEVAL_TRADE_TECH isn't mentioned in the DLL except that it is added as a key to be used by getDefineINT(). I would like to keep it that way. If I add all CivicOptionInfos to getDefineINT(), then modders can add new types to xml and access them in python without modifying the DLL. I think it would be correct to remove advisor code from the DLL as it is a task for python only.

I know I have spoken badly about performance and getDefineINT(), but I think it's ok to use it in python. If we use it 2-3 times when we open an advisor screen (like tech advisor), then we will not be able to tell the difference. If we make a call, which is called (num of AI units in game) * num of professions, then we will wait noteworthy longer when we hit end turn.

<bIsInvention> <bIsCivic> <isCensure>.
Adding bools mean the types are defined in the DLL/xml. Using InventionCategory mean the types are defined in xml alone, which makes future expansions easier. The python code should be commented about which defines/category names it triggers on, making it well defined how it behaves. Most of the xml setup problems are due to poor/missing documentation about what each keyword activates in the DLL. The amount of half finished code, which adds options with no real functions yet doesn't help either.

 

[orlanth]

ok youre right it should work fine to have all the categories in Civicoptioninfos without needing bools, as long as its clear which few categories have a special DLL behavior (ie Censures) and the rest are standard tech categories.

I'm surprised those tech category tags aren't more present in the DLL since it complains if they're missing. I guess the interface-related references to them may all be in python which makes sense.

 

[orlanth]

Blast off into the unknown with this new 2071 Buttons Pack! Anyone's welcome to use them, let's hope this helps stimulate some futuristic total conversion modding in Civ4 and Civ4Col!

 

[Commander Bello]

Thanks for providing all these buttons!

(Although I'm not in the SciFi-area )

 

[orlanth]

I've been trying to make a start on rewriting the Planets mapscript, though I don't know too much about fractals and python. Basically, CvMapGeneratorUtil.py uses some kind of fractal system to generate Terrain types, then the PublicMaps/Planets.py mapscript chooses circular areas to preserve as Planets and fills the rest with Space terrain.

One issue with the old 2071 Planets mapscript was that it kept using latitude to compute terrain types, so planets near the "north" or "south" of the map ended up nearly all Tundra, etc. I can't quite figure out all the python details for sure but I think I've now got it working to generate all of the basic terrain types using fractals rather than latitudes, so that terrain types should all be created across the map in a balanced way.

In the new version, the aim will be to enable terrain variation on a per-planet basis rather than a latitude value across the entire map. The basic terrain types (Grass, Plains, Desert, Marsh, Tundra, Coast, Ocean) have variants depending on the planet's climate type (e.g. for a Volcanic Planet, there will be a chance of replacing standard Plains with its analagous equivalent of Batholith).

I'm thinking the best way to do this might be to add a conditional under if fDistance < iRadius: in Planets.py that changes basic terrains to a variant version depending on the type of the planet being generated.

I've also been carefully working out a system for painstakingly balancing the terrains, planet types, and yields produced. The basic template by which it works is on the google docs page; it may be a bit too convoluted to explain fully, but suffice it to say I've taken a lot of effort to ensure that each of the terrains and Planet types have relatively subtle variations in yields provided, the overall amounts of which are precisely balanced against all the others. Each Terrain can contain 3 production Yields in addition to Nutrients, and one of these always the basic tier of its yield group which all players start with tech access to. So you'll never get stuck in a situation where you don't have something to produce or research; but there still will be possibilities for research to take advantage of the terrains found in your colony.

Time will tell if it's a stroke of game design genius or more along the lines of something from David Icke's "Turquoise Period"..

 

[Nightinggale]

Time will tell if it's a stroke of game design genius

I predict a whole lot of tweaking, which mean it isn't brilliant enough... yet.

I tried the old 2071 on a Caribbean map and it turned out somewhat interesting. It was like colonizing astroids and it gave the game some more in the sense that the planets are rather predictable. Figuring out how to make proper random maps, which aren't too predictable, are somewhat balanced yet with great diversity is actually rather hard.

Thinking about terrain gave me a related idea. I mentioned underwater tunnels at some point. I just had the idea to make a tunnel unit, which can be produced in cities. Transports (possibly a special one) can then carry it to it's intended location and sacrificing the tunnel unit can add a tunnel improvement to the plot in question, possibly with a build delay like workers have. We can do the same for some land improvements meaning you will have to supply possibly rare yields to produce the land improvements. Alternatively we could make a profession, which needs a certain amount of yields to assign and that profession is the only one to build a specific improvement. Building this improvement will change the profession back to a default one and the yields are lost. It could get rather interesting if improvements becomes more complex than just workers+money. Imagine an improvement you ship in from Europe, which you can't build yourself until you invent something, or you will have to trade local plants with the aliens to really start growing them.

 

[orlanth]

I've tried it on the Caribbean map too and it is interesting. It could be cool to make a variant mapscript for Asteroid Belt, where space-harvesting colonist professions and resource collection by Mining Vessels and Science Vessels play relatively larger roles. I'd like to add options to the Planets mapscript for planet size and number, and maybe relative abundance of climate types, so it would be easy to try out maps with many smaller planetoids or different variations. Professioninfos <bWater> would eventually need to be changed to apply to Space domain tiles; I think harvesting Ocean and Coast terrains could use the standard terrestrial professions to keep things simpler, with a smaller number of space-specific professions for Low Orbit and Deep Space.

I'd definitely like to do something along the lines of the special Improvements you're suggesting to make Lunar Colonies a more important feature; they'd require a generous upfront investment in tech and resources to outfit a Colony Ship, but eventually develop into a highly productive Lunar Settlement after enough turns of being worked. Also it would be cool to have a rare and expensive Construction Vessel be able to found one or two Starbases per player which would be actual cities in Deep Space terrain, using the citytype feature of M:C. A third citytype could be Domed Cities foundable in aquatic terrains only by civs who have the appropriate tech. I'm not sure if the AI could appropriately handle many requirements to build Routes or Improvements or found cities, do you think it could?

 

[Nightinggale]

Professioninfos <bWater> would eventually need to be changed to apply to Space domain tiles;

No. We add a new one instead to allow a new domain and then we have both in the game.

I think harvesting Ocean and Coast terrains could use the standard terrestrial professions to keep things simpler, with a smaller number of space-specific professions for Low Orbit and Deep Space.

It could provide some interesting options. How about allowing a space elevator in low orbit, which acts like a road? If two "islands" are separated by one or two plots, then you can with the right tech build a "bridge" at a high cost.

. I'm not sure if the AI could appropriately handle many requirements to build Routes or Improvements or found cities, do you think it could?

Good point. To make the AI understand this, we should most likely scrap the idea about having improvement units boarding other units. They can however build units, which can move on their own to their destination and then disband to add an improvement and htey can handle professions to do the same, which in turn reverts to the default profession when used. Likewise they can build colony ships to make cities in space. I think it's fairly close to be just XML settings to allow the AI to do this right now. The tricky part is likely to encourage the AI to build those new options without building 200 of them.

I think the current AI will handle the profession part without any AI code modifications. It would be calling pioneer AI code, which looks at allowed improvements for the unit when it needs orders. It will then look for suitable plots for allowed improvements. At least I think that is how it works. Units, which disbands to become improvements would then have to have pioneer as default profession to gain the same AI ability.

 

[orlanth]

Yes I think most of that is possible using XML, possibly with slight tweaking of UNITAI scripts. IIRC in the old 2071, the AI was able to construct Lunar Outpost improvements using Colony Ships (the ships don't actually need to have a profession, but do have UNITAI_WORKER and are the only units with a Build ability for that improvement, which consumes the unit using <bKill>1. It could be possible to use a similar constructor unit to build an expensive Route in orbit if you want. However I'm not sure if the AI really percieves the need to build/buy a special unit when it has a tile to be improved using that unit. I can also make it take longer to colonize Moons with certain Atmosphere types using <FeatureStruct> in buildinfos. Science Vessels are able to terraform lunar Atmosphere types which worked well for players, but AI controlled ships didn't yet know to remove Features even when given UNITAI_WORKER. This may simply be an issue with the AI script being domain-specific, since I think land units with UNITAI_WORKER can clear Features, and Civ4Bts used a separate UNITAI_WORKER_SEA. (Other UNITAI scripts also seem to be domain-specific).

 

[orlanth]

I've tried importing & editing Androrc's Aquatic Planets mapscript for use in the next version; and edited it to use the fractal system instead of latitude system when generating each terrain, to avoid planets at the "north" of the map being all Tundra, etc. (I also had to temporarily replace Space with Ocean since there's not yet Space Domain in the 2071 DLL). It looks like it is successfully generating circular shaped planets with interior Ocean tiles allowed, but it's currently generating all land terrain as TERRAIN_GRASS; I am not too familiar with object oriented python & must have made some error in trying to generate them using fractals. Androrc or anyone else familiar with mapscripts, are you able to tell how to solve this?

 

[Nightinggale]

I never looked at map scripts before, but I look a brief look anyway. I think the issue isn't what you wrote, but what you DIDN'T write. TERRAIN_GRASS is the first TerrainInfo and presumably the default one. This would point in the direction that you somehow skipped setting terrain.

Looking at FaireWeather.py in RaR it looks like this is handled by createTerrainMap(), which is around line 2000. Understanding that one would likely solve the problem.

 

[orlanth]

The default terrain actually does already get set as Grass (in terrainVal = self.terrainGrass), and the terrain type should then get set as one of the others using the conditionals below.

Spoiler :

def generateTerrainAtPlot(self,iX,iY):
lat = self.getLatitudeAtPlot(iX,iY)
plot = self.map.plot(iX, iY)
if (plot.isWater()):
return self.map.plot(iX, iY).getTerrainType()

#uncomment for Space Domain; Androrc Space
# if (plot.isSpace()):
# return self.map.plot(iX, iY).getTerrainType()
#Androrc End

terrainVal = self.terrainGrass
# orlanth no latitude
# if lat >= self.fSnowLatitude:
# terrainVal = self.terrainIce
# elif lat >= self.fTundraLatitude:
# terrainVal = self.terrainTundra
# elif lat < self.fGrassLatitude:
# terrainVal = self.terrainGrass
# else:
tundraVal = self.tundra.getHeight(iX, iY)
# // orlanth no latitude
desertVal = self.deserts.getHeight(iX, iY)
plainsVal = self.plains.getHeight(iX, iY)
marshVal = self.marsh.getHeight(iX, iY)
if ((desertVal >= self.iDesertBottom) and (desertVal <= self.iDesertTop)):
terrainVal = self.terrainDesert
elif ((marshVal >= self.iMarshBottom) and (marshVal <= self.iMarshTop)):
terrainVal = self.terrainMarsh
elif ((plainsVal >= self.iPlainsBottom) and (plainsVal <= self.iPlainsTop)):
terrainVal = self.terrainPlains
# orlanth tundra fractal
elif ((tundraVal >= self.iTundraBottom) and (tundraVal <= self.iTundraTop)):
terrainVal = self.terrainTundra
# // orlanth tundra fractal
if (terrainVal == TerrainTypes.NO_TERRAIN):
return self.map.plot(iX, iY).getTerrainType()
return terrainVal

The previous version I currently have up on github actually does generate all terrain types successfully using fractals; but it didn't include the ability to have Water terrains on Planets themselves which is why I had to update to Androrc's Aquatic Planets. Looking at the two of them I'm not sure why the attached version from this thread only makes Terrain_Grass.

 

[Nightinggale]

The bug is in generateTerrainAtPlot(). You commented out the code regarding latitude, but without the latitude to decide the terrain, it stays at the default value. I say let it stay as it is and go back to tweaking the map generation once the game is playable as this isn't something which can be solved easily.

The same goes for ocean generation. We shouldn't have oceans on planets until the DLL can tell ocean and space apart. Also it needs serious tweaking as the continents on the planets becomes too small.

 

[lampuiho]

what is the victory condition when playing this mod?

Do you fight off alien invasion of your colonized world or what?

Please put the answer in this description section in the first page. I couldn't seem to find it.

Please correct me if I'm wrong.