[MOD] Colonization: 2071

[Nightinggale]

1> _precompile.cpp
1>c1xx : fatal error C1083: Cannot open source file: '_precompile.cpp': No such file or directory
1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual C++ Toolkit 2003\bin\cl.exe"' : return code '0x2'

First check that you actually have _precompile.cpp. It is on github, but it's still the first thing to check. The makefile assumes it is in the same directory as the makefile itself.

cl.exe isn't missing. It reports an error code, which is a result of the previous error code C1083 (which is file not found).

If everything looks ok, then try to compile again (no kidding. My laptop gives errors right away around 5% of the time and works the next time for unknown reasons). If it keeps failing, then make a new clone and try to compile that one.

 

[orlanth]

Ok, I rebooted and did a clean pull from Git and built the DLL. With the DLL added to the 2071 folder it loads but gives the following assert:

Assert Failed
File: CvGlobals.cpp
Line: 3305
Expression: getInfoTypeForString("CIVICOPTION_INVENTIONS") == CIVICOPTION_INVENTIONS
Message: Must have index 0

Then on starting the game these asserts and a CTD:

Assert Failed
File: CvPlayer.cpp
Line: 1322
Expression: std::accumulate(aiWeights.begin(), aiWeights.end(), 0) > 0
Message:

Assert Failed
File: CvGame.cpp
Line: 774
Expression: bDone
Message: Player has no starting plot
----------------------------------------------------------

 

[Nightinggale]

I added the assert with a DLL change and pushed an XML fix to col2071 branch. Pull and it will go away.

The crash is due to not being able to find a suitable starting location for one or more players. It would appear that the AI values the new planets too low to accept them as starting plots.

 

[orlanth]

The crash appears to be independent of the updated Planets script or the 2071 terrains; it's also happening whenever I use the new DLL with the current 2071 version on github and also happens with the vanilla mapscript as well. Contrastingly, both the old and updated Planets scripts are working fine with the previous DLL. As you predicted, your recent XML update resolves the civicoptions assert on loading but wasn't related to the issues on starting a game.

I've also tested it in a Custom Game with only colonial players and no natives, in which case it shouldn't need to check anything about starting land plots or yields; it still gives the assert about aiweight / starting plots (then triggers a conquest victory, and repeatedly gives the message about the King raising taxes, possibly because it failed to place your ship in a starting plot and the King then keeps trying to replace it). I'm thinking these issues may be related to the recent DLL changes to Europe plots / trade screens which included changes to how starting plots for civs with various different starting criteria (water start, land start, native, with/without Europe screen, etc) are set up. Can you check to see if the existing 2071 branch on github is working for you with the new DLL?

 

[Nightinggale]

After debugging quite a bit I found a very simple solution. Copy CIV4EuropeInfo.xml and CIV4GameInfoSchema.xml from M:C and you will have the new tags for EuropeInfo set up correctly to make the game playable. If the setup is what you want is another matter, but it will start without problems.

 

[orlanth]

Ok, thanks. It's not crashing now, though with the new DLL the tech screen is no longer displaying for some reason. I'm not sure how civ starting criteria and trade screens are supposed to be set up but will have a look through the XML & Kailric's posts. The immigration screen is still present separately, is it possible for civs to use the option of the standard system ie picking up emigrants from Europe/Earth?

I've updated the Planets mapscript to generate all five different climate types appropriately. The yields are very carefully balanced across terrain types according to the system in the design document, so that players will always have access to a variety of yields from the starting tier and gradually access additional ones with further research.

Currently the terrains for every tile in a planet are entirely dependent on Area ID using iType = iArea % 5 in generateTerrain. It might be nice to add a little variation to this, ie an Aquatic planet would have mainly Aquatic terrains but could also have a few small local patches of terrains from the Arctic or Volcanic tilesets. I was thinking that one way to do this might be to initiate another fractal for this variation, and then have it adjust iType if this fractal is above a threshold; I will look into how to accomplish this further.

 

[Androrc the Orc]

The planets with the different climate types look great!

 

[Nightinggale]

The planets with the different climate types look great!

I totally agree.

I wouldn't worry too much about how the terrain spreads across the planets at the moment. What is in the screenshot is clearly playable and it should likely do for now. Getting the rest of the game up and running to make it playable seems like a better idea as the map doesn't matter in an otherwise unplayable mod

Now that the map generator is working, I might come up with something, which allows the map setup to be controlled from XML where you can set stuff like "group this" or "spread this" or "can't be next to type X" etc.

 

[Nightinggale]

I just pushed a perl module to the master branch, which handles XML file access. You can now write scripts like

use XMLaccess;
my @lines = (openFile('Units/CIV4UnitInfos.xml'));
# code to copy @lines into @new_lines where some lines are modified
writeFile(@new_lines);

First line is like an include in C++. This the the name of the module.
Second line reads the content of a file into an array.
Last line writes the modified file array back into the file. writeFile() is aware of which file you read last and will automatically write to the same file.

One really nice thing about this is that you just write the relative path to the XML files like you are standing in the XML directory. The module will take care of finding the directory for you. In fact it goes into the C++ source to read Makefile.settings to find YOURMOD and use that path to find the XML files. This mean colo 2071 can use scripts from the master branch, which mean it would make sense to place all scripts in master.

When YOURMOD is set, openFile() will automatically copy the schema file in the directory it works in. The schema in master is written to apply to the changes in the DLL and spreading those changes automatically seems like a good idea. xmlTagAdd.pl is written for precisely this purpose as it copies the schema files and adds the missing tags to XML files (with default values).

 

[platyping]

Ok, thanks. It's not crashing now, though with the new DLL the tech screen is no longer displaying for some reason. I'm not sure how civ starting criteria and trade screens are supposed to be set up but will have a look through the XML & Kailric's posts. The immigration screen is still present separately, is it possible for civs to use the option of the standard system ie picking up emigrants from Europe/Earth?

I've updated the Planets mapscript to generate all five different climate types appropriately. The yields are very carefully balanced across terrain types according to the system in the design document, so that players will always have access to a variety of yields from the starting tier and gradually access additional ones with further research.

Currently the terrains for every tile in a planet are entirely dependent on Area ID using iType = iArea % 5 in generateTerrain. It might be nice to add a little variation to this, ie an Aquatic planet would have mainly Aquatic terrains but could also have a few small local patches of terrains from the Arctic or Volcanic tilesets. I was thinking that one way to do this might be to initiate another fractal for this variation, and then have it adjust iType if this fractal is above a threshold; I will look into how to accomplish this further.

Just roll a random number after itype is calculated from the area id.
If the random number is above x, change itype to something else.

 

[orlanth]

I pushed a commit creating a full set of map tile Features; also I applied the Tech Screen fixes suggested by Kailric resetting types to 0, which worked For the issue of a using a normal Earth/Europe transport screen vs separate immigration screen, I changed <TravelCommandType> to 0 for all the leaderheads, but this doesn't seem to have any effect as far as I can tell, with immigration screen still there.

Just roll a random number after itype is calculated from the area id.
If the random number is above x, change itype to something else.

Yeah randoms should work fine for single tiles, but I also like these fractals methods the scripts use, which appear to be generating much more interesting and natural-appearing "strips" and "patches" of terrains (likely through some mysterious Mandelbrot set mechanism ).

During SmartGit pushes its started asking for a "master password" in a popup box, I didn't know it but this doesn't seem to affect the commits so far.

 

[Nightinggale]

During SmartGit pushes its started asking for a "master password" in a popup box, I didn't know it but this doesn't seem to affect the commits so far.

Master password is the one you set in smartGIT. It allows smartGIT to access your stored github password. I'm not sure why it is asking for it now and not earlier.

 

[orlanth]

I've been trying to merge in the latest M:C version to the 2071 branch (to stay compatible & use the updated trade screen and Viking civ settings), but on starting a game it keeps giving the following python callbacks, it does build the map and start the game but it's back to having the all city screen yields appear at the bottom of the main screen, with none of the main screen interface buttons appearing.

CvAppInterface line 66 in preGameStart
CvScreensInterface line 63 in showMainInterface
CvMainInterface line 1230 in interfaceScreen
Index error: list index out of range

I've looked through the python files, and in EntryPoints/CvScreensInterface.py, line 63 is
def showMainInterface():
mainInterface.interfaceScreen()

CvAppInterface.py isn't changed in M:C or 2071, and vanilla EntryPoints/CvAppInterface.py line 66 looks like its calling the above:
CvScreensInterface.showMainInterface()

Line 1230 in Screens/CvMainInterface.py is:
BuildingY = BUILDING_GRID[iSpecial][1] + STACK_BAR_HEIGHT

This is right after an M:C comment tag (#TKs Med) so it's M:C specific. I'm thinking the error is related to this, but I'm not sure why it would be trying to setup a city Building Grid during the main map screen.

Nightingale, IIRC you had earlier done a 2071-specific trade screen change as a workaround to let units embark in the hardcoded Spice Route trade screen that was then existing in M:C. Do you think the M:C trade screen update could be related to becoming incompatible with this?

 

[Nightinggale]

II'm not sure why it would be trying to setup a city Building Grid during the main map screen.

That is because of the (to me) silly design of placing the city screen in main interface instead of its own python class. This mean it sets up the building grid when it starts the main screen. Hopefully we will solve this issue eventually.

Nightingale, IIRC you had earlier done a 2071-specific trade screen change as a workaround to let units embark in the hardcoded Spice Route trade screen that was then existing in M:C. Do you think the M:C trade screen update could be related to becoming incompatible with this?

I did something at one point, but it was DLL only. It shouldn't trigger python errors. It might trigger other errors eventually though and the fix/workaround should likely be reviewed once the trade screen branch is merged back into main.

I'm currently clueless to the cause of this. Either Kailric did something I'm not aware of or something broke due to being copied incorrectly into col2071.

As for updating python: is it even needed to update? Are there changes, which will require special python in 2071? Last time I checked it would be ok to just copy all files and we would likely benefit from keeping it that way.

 

[orlanth]

Argh I can't seem to get 2071 branch to work with M:C anymore. I pulled and compiled the latest M:C DLL but it still has the interface problem plus gives the following assert on loading:

Assert Failed
File: CvXMLLoadUtilitySet.cpp
Line: 2163
Expression: !bLoadOnce && !bFirstLoadRound
Message:

I did copy all Python files from M:C master branch directly; I had not made any modifications to these except minor techscreen changes to allow longer-named techs to display correctly, but I reverted these and used M:C Python only and this didn't affect any of the interface issues.

In trying further to fix things it's just making things worse; I think I need to go back to the last fully working version before the M:C tradescreen changes (I think the version before the current github commit) and see if its somehow possible to make that compatible with current M:C. How can I revert to that using SmartGit? I'm worried that I no longer have a compiled DLL from the old working version though, just one built from current M:C branch DLL sources.

 

[Nightinggale]

!bLoadOnce && !bFirstLoadRound

I added this assert check recently when I made the XML reader immune to read order issues. You shouldn't be able to trigger this and since you are triggering it, I better take a look. I didn't manage to trigger this assert myself and then my thought regarding a message was "why bother if it can't be triggered anyway?".

 

[Nightinggale]

I updated master with a better assert message. Now it tells which type it fails on and which file. The problem is that 4 terrain art types are used multiple times.

 

[orlanth]

Ok thanks. I edited 2071 to remove duplicated terrain artdefs, and copied the updated CIV4EuropeInfo.xml and CIV4GameInfoSchema.xml from current M:C master branch; it can now load without asserts and start the game, but is still having the issue with all city screen yields at the bottom of the main screen with none of the main screen interface content appearing.

 

[orlanth]

Still not making much progress with fixing the interface.. I think the interface error python callback ("Index error: list index out of range ") probably results from trying to look up an interface object in an array but using an improper array index. But the callback mentions lines that call mainInterface.interfaceScreen(), why would that result in an index out of range? Do you think this could somehow be related to the indexes [iSpecial][1] in the line below?
BuildingY = BUILDING_GRID[iSpecial][1] + STACK_BAR_HEIGHT

Now that I think of it, this problem with no mainscreen interface and all city screen yields at the bottom is the same problem we had encountered at the very beginning when the 2071 branch was first made. I think you (nightingale) had solved that quickly but don't know how you'd done it. Does this seem like it could be the same error re-emerging and if so could it be solved by the method used before?

 

[platyping]

It meant what it meant.
When you read the python errors, you read it bottom up.
Because that line is screwed in main interface, this will screw screen interface and pregamestart.

Index out of list means that index does not exist for that list.
If a list is
cow = [2,30,4]
And you are asking what is cow[5], you are screwed.
Thus either the first or second index is wrong.