[MOD] Colonization: 2071

You have 33 special buildings in python, but you have 35 in XML. It loops though the python array using the index limit from XML, which naturally leads to a problem.

I think I will go back to my idea about moving the special building locations to XML. That way we will not have two lists, which can go out of sync and we will remove some mod specific code from python. Ray correctly pointed out that python changes takes place right away while XML changes will need a game restart. I wonder if I can add gc.reloadSpecialBuildingXML() to main screen init and get those XML changes to appear right away :think:
The problem would be that it should call CvXMLLoadUtility::(something), which mean I will need a pointer to an instance of CvXMLLoadUtility. If I figure out how to get that pointer, then the rest should be trivial. However it looks like the pointer is handled by the exe, but that isn't the same as it can't be done from DLL.
 
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?


There hasn't been any changes to special building grid stuff for a long time, at least from me. One thing to note, when a game of M:C loads the yields flash for a second at the bottom of the screen for some reason, so this tells me that in 2071 the yields are displayed but the part of the code that "hides" them isn't reached. I have made several changes to the maininterface.py here recently. Like with the new Trade Screens especially. I extened some funtions to have extra input values and when you do this each time they are used in python you have to add an extra value there as well. In the dll you can leave extra input values off if you have a default value set up for them but in python they need to be there or they will cause the main screen not to appear.

Are you using the mainscreen.py from M:C or 2071, if you don't have the updated version from M:C and you are using the latest dll from M:C then I bet you have several problems. You will have to merge your 2071 changes into the new M:C maininterface.py I bet.
 
You have 33 special buildings in python, but you have 35 in XML. It loops though the python array using the index limit from XML
Yes, this must be it! :hammer2::crazyeye: I will try recoding the python specialbuildings. I was using the updated M:C python, thinking this would work with the M:C DLL, but hadn't kept track of the fact that python always needs a hardcoded specialbuildings grid for each mod. The 2071 python otherwise doesn't have any differences from standard M:C ATM.

(PS. where is the python specifying the array of specialbuildings located? I don't see this in CvMainInterface.py. )

I think I will go back to my idea about moving the special building locations to XML. That way we will not have two lists, which can go out of sync and we will remove some mod specific code from python. Ray correctly pointed out that python changes takes place right away while XML changes will need a game restart. I wonder if I can add gc.reloadSpecialBuildingXML() to main screen init and get those XML changes to appear right away
That sounds like a good idea if it can be done. This would avoid the need for specialbuilding grid setup to be recoded for each mod (the python-hardcoded grids of specialbuilding coordinates probably aren't set up very optimally anyway and are a pain to reconfigure for mods with large number of buildings).
 
(PS. where is the python specifying the array of specialbuildings located? I don't see this in CvMainInterface.py. )
CvMainInterface.py line 182. Do note that it needs the same number of "" in the declaration as it has special buildings. This mean there are two lines in python, which can go out of sync and the XML is the 3rd place, which also has to match precisely :crazyeye:
 
Yeeeoww, the python interface is fixed!
:woohoo::band::cool: :dance: :beer:

I know, I basically just broke the mod branch then fixed it lol. But it's like losing your wallet; when you find it again you're so relieved it was almost worth losing it in the first place :lol:

Big props to platy, Nightingale and Kailric for helping trace down the solution :science: In 2071 that kind of breakthrough requires 200 units of Isotopes. :scan:
 
I noticed a new script has been added to this branch. I added a perl module in master to make it easier if we keep the scripts there as all mods will be able to use them.

Code:
use XMLaccess;
my @lines = (openFile('Units/CIV4UnitInfos.xml'));
foreach (@lines)
{
# write new file version to @new_lines
}
writefile(@new_lines);
openFile will open the file relative to assets/xml. Writefile will write the argument (an array of lines) to the last file being called with openFile().
The clever part here is that it will read YOURMOD from Makefile.settings meaning the very same script can work on multiple mods without modifications. You should consider this option whenever you write a new script.
 
Ok thanks Night :king:
I'm not sure whether anyone else will want to use XMLgen.pl though; if they do they will likely want to edit/customize it heavily for their mod.

BTW on adding city and miscellaneous techlines I found the following nonfatal asserts, I don't think they're likely a big deal but thought I'd mention them.
File: CvCityAI.cpp
Line: 2129
Expression: iMaxStored != 0
Message: Native

CvTechnologyAdvisor
line 139 interfaceScreen
line 164 drawIdeasExperience
ZeroDivisionError: float division
The first one may have something to do with vanilla hardcoding of Native civ behaviors surrounding specific yields. I think the second one relates to techscreen display of the Prolific Inventor experience point counter, maybe this just means that unitclass needs to always stay unlocked.
 
I think you may need to double check your tag lines, something is definitely off.
 
I tried updating col2071 to the new system where building positions in the city screen are set in XML. However I can't manage to get it to display any buildings
Ok, that should be fixed with the latest commit, enabling techlines for city yields where you can start with a Tier 1 building. (I think the buildings could appear, you just didn't start with any automatically).

BTW do you know why it's always declaring a Conquest Victory after Turn 1? This happens even when there are other Human and Alien civs alive on the map including Alien cities.

edit: it looks like this was changed in M:C victoryinfos. The Revolution victory was renamed Conquest Victory (has <bRevolution>1), but for some reason it's still triggering all the time.

I think you may need to double check your tag lines, something is definitely off
something is always off :crazyeye::lol: were you talking about the above issue or did you mean something else?
 
Ok, now I can have buildings (or at least one) in city screen. I committed the update.
log said:
Moved building placement in city screen to XML

It is now possible to set BuildingUpdateInterval in GlobalDefineALT
Setting it to N will make the city screen reload special building XML and update city screen every Nth screen update. There are 4 updates every second.
This is useful for moving buildings around at runtime and see the result right away. However the updates can interrupt gameplay (dragging cancelled etc) and is only recommended to enable when actually changing building setup.
This should make it easier to use the same python for multiple mods. It is also proof of concept where XML can be reloaded at runtime. I wonder if I can do the same for placement of techs in the tech screen.

Master branch has a script called indentXML.pl. Execute this and it will go though all XML files in YOURMOD path where it sets the indents correctly. I haven't done so because it would likely not be nice to your local changes, but I figure it would be nice if you would run it once in a while, like every time you are ready to commit and you edited an XML file. That way the layout will be more readable.

I will look into victory conditions. Conquest is when you own more than 60% of land, but I suspect the total is counted to 0, in which case the threshold is 0 and the check becomes if (0 >=0). The debugger will likely be the only way to figure out why the threshold is completely off.
 
git log said:
Added relative placement in tech screen

New tags: iX_Relative_Location and iY_Relative_Location
When this is set to something different from (0,0) and RequiredInvention is not NONE, then location will be
location of RequiredInvention + (iX_Relative_Location, iY_Relative_Location)
The normal location is ignored in this case.

Relative location (0,0) is assumed unless specified otherwise.
Running xmlTagAdd.pl in master will add the needed schema updates as well as add the new tags. That script is intended to make it easy to keep all schema files up to date with the newest DLL source changes.
 
Ok, I've used your script to add the new tags; it didn't update schemas but I added them manually and it works. The Conquest Victory being declared was actually a Revolution Victory, the M:C XML had renamed Revolution to Conquest. I'm still not sure why that's triggering; I did add parent King civs in civilizationinfos.xml using <DerivativeCiv>, and I can see them show up on the Foreign Relations screen.
 
Maybe the "king" lacks military units and you win because he has none left.
hmm that sounds like it could be it.. I knew u were smarter than Eilmer of Malmesbury! :p:science:

Ok, I've added sets of REF Naval and Land units for the King civs, but it's still declaring Revolution victory. Is there some DLL hardcoding checking specifically for vanilla content like UNITCLASS_MAN_OF_WAR etc?

I don't get why it didn't copy the schema file(s)
how does detecting the "yourmod" directory work? I had to copy it into my 2071/scripts folder to get it to run, but then it can't find the master branch files. (I generally edit everything in a mod branch folder in the github directory then copy it to my /Mods folder to test out before committing.)
 
Ok, I've added sets of REF Naval and Land units for the King civs, but it's still declaring Revolution victory. Is there some DLL hardcoding checking specifically for vanilla content like UNITCLASS_MAN_OF_WAR etc?
Doesn't look like it. However if conquest victory is enabled and all other teams have no cities, then you automatically win. This mean you win unless at least one AI has at least one city.

how does detecting the "yourmod" directory work? I had to copy it into my 2071/scripts folder to get it to run, but then it can't find the master branch files. (I generally edit everything in a mod branch folder in the github directory then copy it to my /Mods folder to test out before committing.)
The system is designed with an intended setup like this:
You have two clones. One is in MODS and is using col2071 branch.
The other can be whereever you want except in MODS. This one is using master branch.

In master clone, you edit Makefile.settings and add
Code:
CUSTOM_CFLAGS = -DCOLONIZATION_2071
YOURMOD = path to MODS\Colonization_2071
Order of lines doesn't matter.

To check if this is set up correctly, remove the DLL from MODS and then compile. If a new DLL appears in MODS\Colonization_2071, then YOURMOD is set up correctly. You will no longer have to move the newly compiled DLL manually. In addition to this, scripts in master knows where the files are relative to the scripts in master. It will know where the target is (in this case Colonization_2071) and can figure out how to update that one, but only if you do not move the script.

There is a sideeffect of this. You will have to update two clones. As they are from the same server, you can technically add one of them as an additional server for the other if you want to reduce bandwidth. The setup will be more complex though and it will likely be easier to just pull twice if you have the bandwidth.
 
Ok, I've added sets of REF Naval and Land units for the King civs, but it's still declaring Revolution victory. Is there some DLL hardcoding checking specifically for vanilla content like UNITCLASS_MAN_OF_WAR etc?

I remember having this issue once myself, but I don't quite remember what was causing it. Are you able to debug? You can perhaps add a break point inCvGame::testVictory(VictoryTypes eVictory, TeamTypes eTeam, bool* pbEndScore) as this is were the victory is determined.
 
I've never been able to get a debug DLL to compile and run successfully in the past, is there a guide about how to do that? I made separate clones for each branch in the Github directory, I was able to run the script from the master branch one which I think worked appropriately, but I also updated the XMLgen script to add the new tags in case they need to be used, and added FatherInfos.xml generation with the latest commit.

After the specialbuildings change the maininterface display issue cropped up again, but relating to a different call related to specialbuilding attribute getSizePos:
CvMainInterface line 3651 setBuildingGrid
CvSpecialBuildingInfo object has no attribute getSizePos

Looking in SpecialBuildings XML, each of the specialbuildings does have size and pos values which seem to be ok.
 
Yes, it works after rebuild from the master branch. :cool: It turns out git has an old DLL still in the 2071 branch, but it won't let me remove it. You & Kailric have been updating DLL faster than I can compile, it looks like the Civics update will be quite a major one when finished up & merged to master :bowdown:

The former Tech Advisor screen assert has also gone away :cool::goodjob: and it looks like the techs are all showing up, but in a very large multiply-branching arrangement, maybe because of the new relativeposition system. I think the xmlgen script should be placing X & Y coordinates ok, should I just set RelativePosition to 0 to let X & Y coordinates control placement?

I've been thinking that the amount of techs in 2071 (and especially World History) is getting too big to view reasonably on one screen. If techs could be assigned to different Categories like in the original Inventor modcomp, this could be used to let the screen have a tab for each Category like the Founding Fathers one currently does, making it a lot easier to display groups of related techs in an easy to navigate way.
 
Back
Top Bottom