[MOD] Colonization: 2071

All I get is this:
File: CvPlayerAI.cpp
Line: 6163
Expression: pBestYieldCity != NULL
I do pick NAFTA specifically.

When I pick green I get
File: CvPlayer.cpp
Line: 2478
Expression: checkPopulation()
However it will not crash on that one either.

I'm thinking it may have to do with some hardcoded content about the trade system that's in M:C XML but not in 2071.
That is possible. However it did go away with the latest update when I edited CIV4EuropeInfo.xml. Doesn't sound right if it is still crashing for you. Try to play as different civs and see if they all crash.
 
On my machine, trying it with either of the colonial civs (NAFTA or the EU) results in the asserts & crash mentioned at turn end.
Trying it with Empire of the Greens gives multiples of the following assert during advanced start setup:
File: CvPlayerAI.cpp
Line: 9137
Expression: iMaxStored != 0
Message:
It can then load to the map, but on end turn gives the same assert multiple times then crashes. I'm not sure why it's working for you but not for me with the 2071 branch :confused: maybe I should reinstall my copy of Civ4Col?

edit: I think the difference has something to do with the mapscripts we're using. I just tried A_New_World mapscript and on ending turns get the assert below with no crash:

Assert Failed
File: CvPlayerAI.cpp
Line: 6163
Expression: pBestYieldCity != NULL
Message:

edit: the above is the case with Carribean mapscript as well. Before, my local copy was loading the FaireWeather mapscript by default; that must lead to something about traderoute placement that caused the turn 1 ctd.
 
It can then load to the map, but on end turn gives the same assert multiple times then crashes. I tried replacing Civ4EuropeInfo.xml with the version from the master branch but this didn't change things.
Now you broke it. You should use this version: https://github.com/Nightinggale/Med...c36d12/Assets/XML/GameInfo/CIV4EuropeInfo.xml

I'm not sure why it's working for you but not for me with the 2071 branch :confused: maybe I should reinstall my copy of Civ4Col?
Yeah it sounds odd. However I don't think reinstalling anything will help.
 
The CTD is resolved by changing to non-M:C mapscripts as above - maybe the Faireweather scripts placed trade screen tiles which caused the crash.

I've got most of the basic interface set up - it's probably discouraged to put too much graphics on github so I'll likely keep everything else with vanilla placeholder graphics till the end, but it should be reasonable to at least get much of the interface in place.

There is now no CTD on ending turns :goodjob::king: One remaining thing that's puzzling me is why colonists are currently unable to found cities in the 2071 branch. I made sure the script set <bFound>1 for the citizen unit types; is it looking for something specific referring to M:C CityTypes such as Monastery etc? It does let me start with a city via Advanced Start when selecting Grey or Green civs, so the cities themselves are working. (It gives multiple iMaxStored != 0 asserts as listed above but does not crash, and I'm able to access the city screen :D) The nonfatal pBestYieldCity != NULL asserts when ending turns still occur even when there is a city though.
 
I've got most of the basic interface set up - it's probably discouraged to put too much graphics on github so I'll likely keep everything else with vanilla placeholder graphics till the end, but it should be reasonable to at least get much of the interface in place.
We have one GB and are currently using 77.9 MB for both branches combined. However that would quickly change if we start adding leader heads, music etc. Besides there are file size limitations and the more data the longer it takes to pull/push changes. It does sound like placeholders for as long as possible isn't a bad strategy. On the other hand some graphics can be added if needed. As we aren't extremely low on disk space. Git stores a copy of each file even after they are deleted in case you go back in history. However Github has a guide to completely delete a file even from history to free server disk space.

One remaining thing that's puzzling me is why colonists are currently unable to found cities in the 2071 branch. I made sure the script set <bFound>1 for the citizen unit types; is it looking for something specific referring to M:C CityTypes such as Monastery etc?
I'm puzzled about that one as well. I think maybe it could be related to terrain setup. The colonist is able to walk on ocean meaning maybe it view all terrain as something which can be walked on, but can't build cities on.

I added the "iMaxStored != 0" assert. It multiplies with a constant modifier and divides with iMaxStored. As it crashed when it's 0 I made applying the modifier conditional to iMaxStored > 0 and added the assert in order not to forget about it. I think the game should be fully playable even if this isn't fixed.

I haven't found the cause for "pBestYieldCity != NULL" yet. As it isn't fatal I decided not to look into it for now. It might be affected strongly by setting up yields, terrain and features.
 
after a while of searching I finally tracked down and fixed the issue with city founding - there needed to be <bcanFound> set in professioninfos for the map professions as well as the <bFound> in unitinfos for the units.
Cities are now buildable from turn 1 - but on building a city it gives the following series of asserts and a CTD.

Spoiler :
Assert Failed

File: CvCity.cpp
Line: 409
Expression: eFreeNatureBuilding != NO_BUILDING
Message: Should get a Free Building

Assert Failed

File: CvCity.cpp
Line: 4620
Expression: eIndex >= 0
Message: eIndex expected to be >= 0

Assert Failed

File: CvArea.cpp
Line: 526
Expression: eIndex2 >= 0
Message: eIndex2 is expected to be >= 0

Assert Failed

File: CvPlayer.cpp
Line: 7490
Expression: eIndex >= 0
Message: eIndex is expected to be non-negative (invalid Index)
Assert Failed

File: CvPlayer.cpp
Line: 7497
Expression: eIndex >= 0
Message: eIndex is expected to be non-negative (invalid Index)

Assert Failed

File: CvPlayer.cpp
Line: 8329
Expression: eYield > -1
Message:

Assert Failed

File: CvCityAI.cpp
Line: 3846
Expression: eYield > NO_YIELD && eYield < NUM_YIELD_TYPES
Message:
Assert Failed

File: CvGlobals.cpp
Line: 1490
Expression: eYieldNum > -1
Message:
edit: for the topmost assert, I've tried editing my local civilizationinfos for NAFTA to give the first-tier Liberty building for free
<FreeBuildingClasses>
<FreeBuildingClass>
<BuildingClassType>BUILDINGCLASS_LIBERTY1</BuildingClassType>
<bFreeBuildingClass>1</bFreeBuildingClass>
</FreeBuildingClass>
</FreeBuildingClasses>
but oddly it still gives the same assert
File: CvCity.cpp
Line: 409
Expression: eFreeNatureBuilding != NO_BUILDING
Message: Should get a Free Building
along with the others and ctd.
 
Now I can build cities. Game stability appears to be unchanged, which mean the game doesn't crash for me. I see a new main menu (or old... it looks familiar). I'm not too happy with the scrolling as I do have an issue with vertigo :(
I'm not 100% sure what to do about it though, just that it shouldn't stay as it is right now. We could investigate the option of selecting main menu in the options. Civ4 has this as some of the mods for civ4 has it, yet it looks like this feature is unused for colonization, yet the option is present in the options window.
Another issue with it is that it looks crappy on widescreen.

Explanation for a few asserts: (possibly all of them)
Spoiler :
File: CvCity.cpp
Line: 409
Expression: eFreeNatureBuilding != NO_BUILDING
Message: Should get a Free Building
This searches for the best suited building for the city. It appears not to be listed as free in XML. However it searches the city plot and all the plots around it to find the yield with the highest value and find a building to use that yield as input. For instance if the best yield is barley, then the best building is the lowest level brewery. The assert mean the game fails to find any such building. However the only result from it is that it will not give a building and shouldn't affect game stability.

File: CvCity.cpp
Line: 4620
Expression: eIndex >= 0
Message: eIndex expected to be >= 0
PROFESSION_COLONIST isn't producing a yield, yet for some reason it is trying to get the production modifier for the produced yield anyway.

I think the key is this check:
Code:
kLoopProfession.getSpecialBuilding() == kBuildingInfo.getSpecialBuildingType()
kLoopProfession is PROFESSION_COLONIST and kBuildingInfo is BUILDING_SHRINE. Both values in that comparison are NO_BUILDING (or -1 as it is defined).

File: CvArea.cpp
Line: 526
Expression: eIndex2 >= 0
Message: eIndex2 is expected to be >= 0
Same cause as previous assert.

File: CvPlayer.cpp
Line: 7490
Expression: eIndex >= 0
Message: eIndex is expected to be non-negative (invalid Index)
Same cause.

I stopped looking though the rest. Just the assert messages indicates they can be caused by the same issue.


EDIT:
Committed a proper assert message for most of the asserts, which tells what really went wrong instead of those generic messages. I also investigated pBestYieldCity != NULL and the problem is due to not being able to figure out good trade routes as the city lacks buildings to consume yields.

Also the main menu change appears to be urgent. It is making me dizzy :crazyeye:
 
Now I can build cities. Game stability appears to be unchanged, which mean the game doesn't crash for me. I see a new main menu (or old... it looks familiar). I'm not too happy with the scrolling as I do have an issue with vertigo
Phew, I've got it running crash-fee for me again by rolling back to the earlier commit :king: However when I build a new 2071 DLL from the main branch sources, and copy the main branch's python folder to 2071, it's still giving me a ctd on building cities.
It's the same mainmenu screen as the old mod - I kind of liked the fade effects to orbiting planets, but I'd never thought of it causing issues for people who have vertigo! in the meantime you can replace the civ4artdefinesinterface.xml path to <Type>MAINMENU_SCENE</Type> with anything else. (it just seems to show a black screen if I give it a path to a dds though :confused:)
 
Try to remove the entire 2071 MOD and make a new clone from github. Add Arts, Sounds and Medieval2.FPK and see if that helps. I suspect you might have messed up something by trying to fix it. After all my game doesn't crash and I don't use local modifications as I committed every change I made.

It's the same mainmenu screen as the old mod - I kind of liked the fade effects to orbiting planets, but I'd never thought of it causing issues for people who have vertigo!
Usually people don't consider such issues if they don't suffer from them personally. I noticed that the feeder service use red and green text to tell if imports are active. However this can give colorblind people issues and I didn't really think about that when I wrote it like that. Changing it is kind of tricky which mean it stays that way now as it isn't critical.

It's actually fairly simple to figure out which screens causes issues for people with vertigo. The body has 3 senses to place itself in the environment around it.
1: inner ear sense of acceleration.
2: eyes to get head movement compared to surroundings.
3: muscle movement to get a feeling of shape of body.

Vertigo means #1 is unreliable (which is more common than most people think). If we make a scrolling screen we render #2 unreliable too and the body ends up with 3 senses, each contradicting the others and the brain take a wrong guess at body placement and starts false compensation to movement, which cause nausea, vomiting etc. While carsick is different, it too is about mismatch of the senses and incorrect body response to those.

I like the effects too and I wouldn't mind keeping the fading images. However the scrolling stars is a no-go. I kind of view those like the 18th century cloth colors. Chemists invented new ways to make brighter colors for cloth as well as brand new colors not used in cloth before. However those were banned already in the 18th century because they were so toxic that rich women started dying. A good intension, but then something unexpected happen and it turned really bad.
 
Yeah there's no reason for the star field to pan anyway and it would probably be better without. There may be some way to adjust it in nifskope but I'll have to look further into the details of how nif node movements are generated.

The current 2071 branch alone is working for me (using the built CvGameCoreDLL contained in the 2071 branch); but the crash on city-building seems to be introduced whenever I build an updated 2071 DLL from the DLL_Sources currently in the master branch (at least that was the case as of this morning; I see you're working on some DLL updates). I don't think I did anything wrong in building, it says it was successful :confused: Are you able to run stably on your machine after adding new built DLL and python from the master branch? If so feel free to commit those to 2071 branch as well and I'll try using that commit directly. (The python should be the same for both branches, but explicitly adding the most current python to the 2071 branch may help ensure it's compatible and prevent me forgetting to add it from the master when doing updates). For the same reasons it's also reasonable to keep the most current build of 2071 CvGameCoreDLL in the 2071 branch on github as well (although there's no need for a duplicate DLL Sources folder in that branch).

edit: ok, I've successfully managed to halt the animated starfield panning in the mainmenu nif :king:. The moons still orbit the planet, but since the background itself is stationary I hope it'll now be more stabilized for people who have vertigo.
 
The stars are staying still, yet it didn't help much. I think the spinning globe is bad too. I wonder if it would be good enough to just slow it down. It spins quite fast. Maybe slow moving stars could be ok too.

I already moved the python changes to 2071 branch I can play the game without any local modifications. Yes I can run stable. I did manage to get some python error after I started adding buildings with the world editor, but before I did that I managed to produce new colonists by producing enough nutrients (it was a quick game. Waiting for 200 nutrients could take a while).

I see the DLL is back on github. It was supposed to be compiled from source from M:C instead. The DLL is outdated several times a day (at best). As we will have to compile it over and over it's a waste to keep it on the server.

I noticed one thing, which could help quite a lot. Add a duralloy facility as a free building. Not only would it make the game a bit playable when you can build buildings, it would also be a likely candidate to remove asserts as the current city is unable to consume yields.
 
phew, I've finally gotten it running again with no CTDs on my machine :king: I restarted & rebuilt the 2071 DLL several times and it finally isn't crashing; though I still have no clear idea why it was doing that :confused: I wonder if I was doing something wrong in building the DLL, or if it could be some path issue to do with my Steam copy of the game. I did set up the Makefile to address that.

Anyway, I've synced a commit with several fixes to professions xml, and adding basic free yields for cities and the first Industry building as a free building. It doesn't appear to have resolved all of the asserts yet but makes sense anyway to get things more playable. [edit: actually, the number of asserts does seem to be less].

I also added the Planets mapscript (thanks again to some invaluable early help from TC01):scan:. I've set things up to use the standard terrains and features for now, which all are already present and working in XML, to try to get things working stably before introducing many new ones. I can now start a new game with the Planets mapscript and it generates a planet appropriately on Tiny mapsize with no asserts or crashes on game start, but it does CTD without an assert on turn end (this time only with Planets mapscript, remaining stable with A_New_World). Can you try it out with Planets.py and confirm whether it's working for you? I'm still a little leery that there may be something different between my installation and yours. :confused:

Lastly I was able to find how to access the rotation speeds in nifskope and set the planetary rotation, moon orbits, and space background to be much slower. :king: Did that help with the earlier vertiginous effect? I haven't yet deciphered the details of the "slideshow" controllers, but I still want to rework the slideshow aspect so it's also less abrupt, ie show one of the title backgrounds for 4-5 seconds, then fade in to the planetary view for 4-5 seconds, then back to a title, and so on. There must be some way to try to optimize it for different screen sizes but I'm not sure how to achieve this as yet.
 
Made a commit, which kills the free building assert. I added consumed yield to two professions. After all the game looks for the best building, which consumes something the city can produce. As I didn't fill it out all professions it has a very limited selection of buildings to select from and it appears that it assumes Amino Acids to be the best yield each time.

Most if not all of the yield/index related asserts are due to BUILDING_SHRINE lacking a special building. Set one and the game will start to be more or less assert free.

The planet map crashes due to traderoute access, or lack hereof. Just use one of the other maps for now and we will figure it out later.

Adding the dll to git really annoys me. I have a local modification (I compiled a debug one) and it conflicts will whatever I pull from git if git has a new dll. Why is the DLL even present on git again?

EDIT: forgot to mention that the new main screen appears to be fine, or at least a whole lot better :)
 
Good I'm glad the space induced vertigo is resolving :) Once all the units are in the finished mod, it might be cool to add a massive Dreadnought or something that occasionally cruises ominously past the planets :scan: Ok you can remove the CvGameCoreDLL if its problematic, but since it took so long to successfully recompile locally from the sources for some reason, it could help speed things up to automatically place the current version there during each commit of changed DLL, like it is in the M:C branch.

I've worked on xmlgen.pl script changes which create specialbuildings for Shrine and Trading_Post (they're the two hardcoded buildings from M:C which have only one upgrade level, so may not technically need specialbuildings, but something in the code is apparently looking for them.) This does remove the specialbuilding asserts, but to my surprise it brings back the interface issues which were present before your python fix (with persistent yield icons along the bottom of the map) and causes all kinds of strangeness in the cityscreen itself. I think you mentioned earlier you had to revise the python regarding specialbuildings to fix this, so I wonder if adding the new specialbuildings caused a similar problem with python. Anyway I won't add the script to git since it makes things worse but will attach it here if you want to try it. (as I'm sure you already figgered out, you can run xmlgen.pl and then place.pl from the Scripts folder to generate all the xml.):borg:

There's some strange behavior going on with the M:C-hardcoded buildings. All the 2071 yield-processing buildings seem to be displayed and functioning normally; but Shrine and TradingPost had earlier displayed +3 of all yields without any yields added in XML, and they currently don't show up in the Pedia at all, even though all the XML is present for them.
 
Ok you can remove the CvGameCoreDLL if its problematic, but since it took so long to successfully recompile locally from the sources for some reason, it could help speed things up to automatically place the current version there during each commit of changed DLL, like it is in the M:C branch.
The M:C dll is committed in the master branch together with the source. If we commit to the master branch it will not update any files in any other branch and as such it makes little sense to add it to any non-master branch. The only reason it is added to M:C is because it allows people to play the newest version even if they don't know how to use a compiler.

Besides this isn't that slow to compile. I do it in 1-2 minutes (full recompile). I once worked on a source where my computer spent 20 minutes on a full recompile (back when you measured CPU speed in MHz, not GHz). This is nothing.

This does remove the specialbuilding asserts, but to my surprise it brings back the interface issues which were present before your python fix (with persistent yield icons along the bottom of the map) and causes all kinds of strangeness in the cityscreen itself.
I was expecting that. In fact I would be surprised if it just worked. The reason is really clear in the changelog: https://github.com/Nightinggale/Medieval_Tech/commit/afaeab1c78fd5e7061de1d4cfed9bcce4634ba53

Looking at CvMainInterface.py there are two interesting parts. Line 178 needs a "" for each special building. You also need to add the buildings after line 216.

There's some strange behavior going on with the M:C-hardcoded buildings. All the yield-processing buildings seem to be displayed and functioning normally; but Shrine and TradingPost had earlier displayed +3 of all yields without any yields added in XML, and they currently don't show up in the Pedia at all, even though all the XML is present for them.
I don't like the really hardcoded buildings at all. However I haven't looked at them yet and I'm not going to do so now. I'm trying to finish the gear type code, but I have been distracted quite a number of times with other tasks. Now I really want to focus and finish it so I can move on.
 
ahh ok. thanks 4 letting me know about those python details.

Just committed consumed yields for all manufacturing professions, plus the remaining specialbuildings and python update.

looks like it's getting remarkably assert-free! :cool::woohoo::cool:
 
Europe/immigration doesn't work. However it looks to me like it is because Europe is hardcoded to read data from parent (King of X). Maybe it will work if we add a "king" to NAFTA.

You can't make outdoor professions like explorers as the game crashes due to lack of art. I assume XML updates will fix this.

Apart from that it appears it is getting into a playable and stable state where it is "just" a matter of filling out XML with all the missing data.

I have been thinking. Maybe we can drag-n-drop Art and Sounds from Colonization 2071 1.42 into the git version. This way we can avoid using all those placeholders without filling up github. Getting rid of the placeholders will make it feel a whole lot closer to the goal as we will get a visual result as well.

I also noticed all the missing text all over the place. I wonder if I can script moving all TXT_KEY_from the source into their own xml file. That way we have a organized text xml layout where we can clearly see which text is used from XML and which is hardcoded in the DLL.
 
I added civilizationinfos xml for Humans along with corresponding "King" civs. (the Kings don't display as civs in pedia but are in the game.) Also added placeholder artdefs for the map professions to make them usable. You'll now win a Conquest Victory if using single-player but can choose to continue playing :p

I can now access the Immigration screen; I'm thinking for 2071 in most cases it'll make more sense to use the vanilla mechanism of picking up emigrants from Europe/Earth rather than having them show up after wandering through the wormhole on their own :lol:

It could be possible to start adding non-placeholder graphics fairly soon, but it's likely better to wait till closer to release, when we can be totally sure content won't need to be added or changed, then do it all in one go. (xmlgen.pl has been automatically generating artdef paths for the content which will help in doing this; currently this is substituted by place.pl with placeholders, since the whole game can crash if even a single art path is unfilled). So as you can imagine it would be hard to fill in a few at a time but achievable to drag-n-drop art to content paths once all the content is definitely set in stone.

Likewise, as long as we hold off on the step of beginning to manually tweak XML files individually, it remains easy to achieve fairly powerful & synchronized large-scale balancing changes by adjusting the script. eg we could decide things like, "I think all the second-tier production buildings should cost 50 more Machine Tools, have 1 fewer worker slot and give 10% more production bonus" and this could be done in a few clicks and be ready for playtesting. :king: But once we finally enter the phase of manually adjusting content items by editing XML directly (which will of course be necessary); individual changes would be overwritten when running the script again making this a major and potentially irreversible milestone to cross.

I also noticed all the missing text all over the place. I wonder if I can script moving all TXT_KEY_from the source into their own xml file. That way we have a organized text xml layout where we can clearly see which text is used from XML and which is hardcoded in the DLL.
I bet you could, but there are probably lots of other more important coding issues to work on. Anyway, it should be possible to piece together the text tags the game is expecting from the files in the M:C text xml folder, so I made a start of that. but we should keep an eye out for anything still missing & maybe add it to a list on github.
 
I added civilizationinfos xml for Humans along with corresponding "King" civs. (the Kings don't display as civs in pedia but are in the game.) Also added placeholder artdefs for the map professions to make them usable. You'll now win a Conquest Victory if using single-player but can choose to continue playing :p.
I think you can win Time victory too and that you have been able to do so all the time. To do this all you need to do is to be the player with the highest score at the end of turn 300. I haven't been patient enough to test this though :p

I can now access the Immigration screen; I'm thinking for 2071 in most cases it'll make more sense to use the vanilla mechanism of picking up emigrants from Europe/Earth rather than having them show up after wandering through the wormhole on their own :lol:
The game will use vanilla immigration with the dock if land start isn't set in XML. Give the civ a spaceship to start with and remove land start to get what you want. Aliens have land start and can get units locally. This could be interesting to exploit later.

I bet you could, but there are probably lots of other more important coding issues to work on. Anyway, it should be possible to piece together the text tags the game is expecting from the files in the M:C text xml folder, so I made a start of that. but we should keep an eye out for anything still missing & maybe add it to a list on github.
I was thinking like extract all TXT_KEY from the source and then write those to a new XML file using the values from M:C. The other M:C files can then get those lines removed. In the end we have one file to move to 2071. I don't think we should do anything else to text. Maybe write a script to read all TXT_KEY from xml and then check if they exist in Text xml.

However as you said text isn't high priority right now.
 
The game will use vanilla immigration with the dock if land start isn't set in XML. Give the civ a spaceship to start with and remove land start to get what you want. Aliens have land start and can get units locally. This could be interesting to exploit later.
Ok, I've given the Human civs water start and a starting Corvette to hold their Colonists, and modified the generated default ship units XML to match basic ship stats from M:C and vanilla. However it's still starting the Corvette and its passengers on land :crazyeye: After trying it a few times, I think this may be because it's placing them on the M:C-derived "trade route" map tiles which are currently all on land.
 
Top Bottom