[MOD] Colonization: 2071

[drjest2000]

@Newfloridian - It is hard to place a precise number on the loyalist population in the colonial era. Pennsylvania and New York, for instance, were particularly strong in loyalist sentiment, yet we see that New York City and Philadelphia were both the new nation's capital before the founding of Washington, DC. From all that I have ever read from the period, the rebels represented a vociferous minority, but a minority that had considerable money and therefore the power to achieve their ambition. The whole of Vermont, for instance, was willing to go any direction that granted then colonial status/statehood.

Certainly there were less fortunate sorts that leaned in the direction of independence. But in some locations, I would put the figure as high as 90% against Independence, but it has to be said that almost everyone thought that the taxation without representation issue had to end.

On the street level, the notion of "free land" taken from the natives had very high popular appeal to the up-and-coming sort, but the more well-to-do sort who were established in the cities generally perceived an exodus of people from the cities as their financial ruin, so they were most certainly not in favour of letting anyone go stake a claim to Indian land. The British government had made treaties with the Indians and had every intention of keeping them for very sound financial reasons: Fighting a war with the Indians on the other side of the world cost rather a large sum of money. That was one of the major reasons for all the taxes that had been encumbered on the American colonies. They just could not keep their fingers out of the Indian pie. Seven or eight Indian wars later, the government in London had said something like "okay, guys, you keep causing wars that are bankrupting the motherland, so if you want protection, you're going to have to pay for it yourself and you're going to have to house and feed them too."

I won't say that the colonists acted like spoiled brats, but there was less than zealous welcome to this news that they were going to have to foot the bill for the wars they kept causing.

Meanwhile, Joe Tinker in Philadelphia or New York who was making a fortune selling food and clothing to all the teeming masses huddled in Philadelphia or New York (huddling out of fear that the Indians might kill them if they didn't huddle), saw this as a curse and a blessing. Just how he leaned on the point of independence probably ran in the same direction as his wallet.

Places like Philadelphia and New York City were dangerous for the rebels, people had a tendency to hurt them. And the Sons of Liberty in New York and Philadelphia were rather notorious for running some grave bodily harm the other direction. By most accounts, even among the rebels, the Sons of Liberty were a dangerous lot of violent men who used the "cause" as an excuse to get drunk and hurt people. No matter how you turn it, it was far from the squeaky clean version that appears in American History text books you find in American schools, which generally reads something like "and one day, they all agreed that they were tired of being mistreated, so they said no more" - followed by the King going all Evil Genius on them, so they did their best Chuck Norris to him, because Americans never do anything wrong, ever, promise.

I would like to say, that I am an American, I like being an American, I think being an American is just dandy... but, I have no illusions about the people who started this nation of mine. Those guys, well, they got the job done, but they were no saints. And that stuff in the history books... well... mostly lies. But the victor writes history the way he sees fit.

 

[Newfloridian]

As a matter of interest would it be possible to build something like this into Civ4Col / 2071 to reflect differing levels of 'bell' support in individual settlements at the time of Independence? Maybe a settlement with 0% bell rate would be more sympathetic to allowing Expeditionary Forces in without a fight.

Also, when exploring the submenus I came across 'Transcendence' listed amongst the Victory Conditions. Is this a hangover from a different mod? or how do I activate the research?

Alan

 

[orlanth]

IIRC I think that actually already is the case (ie each of your colonies gets varying levels of defence bonus depending on their Rebel Sentiment locally, so it's a good strategic factor to think about prior to revolution). Several of the Founding Fathers (Directors in 2071) give bonuses that depend on Rebel Sentiment, though I think it's nation-wide in that case.
The Transcendence victory was meant to reuse the Industrialization victory of the original Tech Modcomp, however I don't see a way to unlock it via a tech in XML

 

[drjest2000]

Like Orlanth says, the varying levels of rebel sentiment affect defense of individual settlements. And, like, Orlanth, I'm pretty sure the FF bonuses are a nation-wide effect. I looked at the code in the DLL and, plainly stated, I don't know if the bonuses can be made to work per city. It appears that all FF bonuses is applied "directly to the player" rather than to the settlements or units. I suppose that there could be a work around crafted that applied the defense bonus to units as a promotion, like the armor in M:C. Perhaps a FF could "unlock" an otherwise un-researchable technology rather than grant a blanket bonus. I don't have enough experience with the technology mod to even rightly guess how that could be made to work.

 

[Nightinggale]

That could be interesting. I tried it again (first time after making RaRE) and I learned two things.

1: it freezes on 32 bit CPUs (or at least my setup). Didn't freeze on the 64 bit setup through.
2: it's SLOW

Maybe I have high expectations, but it feels a lot slower than RaR or M:C. The number of yields and stuff like that is relatively low, which mean the code must be inefficient somehow.

I haven't checked the code, but I have a hunch you like Kailric just wrote the code without considering speed and didn't realize that getDefineINT() is dead slow. Looks like Firaxis didn't bother/notice this either as they use getDefineINT() in lots of places.

M:C caches all of them with a significant speed boost as a result. It looks like a fairly big change, but as I recall I scripted most of the code generation.
https://github.com/Nightinggale/Medieval_Tech/commit/64fcafe819948bdeeb8b12d25789f6a58e818979

The other major speed kill is CvPlayer::getYieldEquipmentAmount(). While it's not dead slow it's called really often. Remember that the execution speed of the AI's turn in RaR increased 21% by caching this.
https://github.com/Nightinggale/Medieval_Tech/commit/0dd61a85c6281fb9f046ddc7e78c88a47b01547e
I didn't script any of this. However the important parts are written generic enough to allow copy paste of the code. Code like

if (GET_PLAYER(getOwnerINLINE()).hasContentsYieldEquipmentAmount(getProfession())) // cache CvPlayer::getYieldEquipmentAmount - Nightinggale

contributed to 2/7 of the speed boost. It's a really fast check to see if the profession use any yields at all. It is set up around loops, which are pointless when all are 0, such as changing a profession. It will not need to loop though the entire array of 0 and then add 0 to the colony and after that take 0 from the colony for the new profession. This calculation is done many times by the AI without changing anything as the AI use it to figure out if the professions should be changed, hence the speed benefits of avoiding the loops.

The main reason why I write about this is I stopped playing because I got tired of waiting. It feels really slow after trying RaR and M:C after they use proper caches.

I had all sorts of other issues, but they turned out to be player error. The new concepts are a bit tricky to get into if you skip reading about anything before you try
I could have used a better guide to get started, but I don't know how it should be made.

I think it's a shame with the speed issue as I suspect I really would dig into this if I ddin't grow that tired of waiting all the time. The ideas behind this mod appears to be great. I really like the concept of needing different resources to do research. However it has two issues:
1: feeder service would work golden for distributing resources to handle this
2: I still haven't figured out how to get Progenitor Artifacts

Ok, I admit I haven't got that far into the game yet. I haven't even made a trade network. I lack resources to build land transport. I haven't figured out how to get those yet either. Maybe the start is a bit tricky, specially if you haven't tried it before.

 

[orlanth]

Cool thanks for trying it out Nightingale!

You're right about the performance of this old DLL.. it's based on a very old initial version of Kailric's Inventor modcomp, which has probably undergone lots of improvements along the road to M2C. There's an occasional bug where sometimes you start with no access to Research Labs, which neither me nor Kailric were able to track down at the time. Also, if you play long enough you'll notice the Civ4 Judaism religion symbol randomly get displayed with some cities on the map I was totally unable to track that one down lol, must be some issue with my modified gamefonts for the new yields.

I had not done extensive changes to the DLL myself since with fairly limited knowledge I was afraid of making things worse. But I did attempt to make a few targeted DLL modifications regarding the AI behavior of "natives"/Aliens, by searching for isNative checks in the code and disabling some of the vanilla behaviors like prioritizing only Horses/Food/Muskets etc. The aim is to let them function as much like "regular" colonial civs as possible; I monitored the AI awhile and they can succeed at traveling to Earth in their Saucers to trade and abduct hapless Earthlings, just like I'd hoped

Anyway I think the bottom line is that old DLL should be abandoned, and the mod rebuilt around a much better "modern" one like M:C or RaRE. One other feature I'd wanted to include is Androrc's Space Domain modcomp which he kindly uploaded a few pages back in this thread.

Maybe the start is a bit tricky, specially if you haven't tried it before.

Yes, it can be quite tricky at first to get a strong colony running, and is very different from vanilla. In keeping with the dystopian setting, you start out with access to only a few of the Yield types, Professions and Buildings that eventually become available; so you'll need to prioritize research early on to unlock these and begin to attract better colonist types than Convicts/Proletarians. The fastest way is to buy techs from the Aliens that helps exploit your colony's local terrains. You can also trade with them for goods like Xenospores/Uranium/Artifacts which you can then analyze in your Research Lab. Some other good early techs to prioritize are the agricultural ones which boost Food production (research also uses Food rather than rarer yields) and Civil Rights to start getting Free Colonists as emigrants.

 

[Newfloridian]

I have continued to play along with the existing version (ie not tried modding the 'lack of city center' capability in captured settlements we talked about some posts back). The reason for this is that I want to see what a War of Independence looks like in the vanilla 2071! I am now at turn 500.

My colony was based on 6 of my own settlements and 6 captured from other colonists. My own settlements provide bells - the captured ones dont. I have desparately been trying to reach the 50% level - having churned out artful politicians and building (when possible) those structures which increase percentage bell levels. I have even created two more settlements (Seattle and San Francisco). However, despite all this, my total bell level has only crawled up to 39%

For many turns I have committed my colony to produce forces which have now reached:

Me: 23 soldiers; 23 mechs; 91 artillery; 19 warships (515 vehicles, 1257 arms in store)
Ex Force: 23 stormtroopers; 10 heavy mechs; 9 devastators; 8 warships)

I'm assuming that my army is now more than a match for any invasion.

It may be possible that the mod you suggested earlier on to allow the building of city center structures in captured settlements may help to solve this problem. But in the meantime, would it not be possible to be able to turn off building production in individual settlements to produce bells or money (like civ4 does). I have already completed the research tree and it seems that all directors have been allocated so the option for 'trade', 'politics' etc has also disappeared.

btw: When can you arm alien hybrids? Is this only after independence declaration?

Cheers Alan

 

[Nightinggale]

Anyway I think the bottom line is that old DLL should be abandoned, and the mod rebuilt around a much better "modern" one like M:C or RaRE.

That made me think. It appears to be a big issue because you also said

I had not done extensive changes to the DLL myself since with fairly limited knowledge I was afraid of making things worse.

This is no good. That will be an issue as you will need to change some stuff in the DLL and once you are done the core of what you worked on will already be outdated.

I came up with a different solution. To some extend the DLL is a library of functions controlled by XML and python. We should investigate the possibility of having just one DLL. Luckily Kailric left debug code around, which made me code this makefile feature.
Now we we exploit that to write -DCOLONIZATION2071 we can write code like

Spoiler :

enum DllExport YieldTypes
{

NO_YIELD = -1,​

#ifdef COLONIZATION2071

YIELD_FOOD,
///TKs Invention Core Mod v 1.0
YIELD_COAL,
///TKe
YIELD_LUMBER,
YIELD_SILVER,
YIELD_COTTON,
YIELD_FUR,
YIELD_SUGAR,
YIELD_TOBACCO,
YIELD_ORE,
YIELD_CLOTH,
YIELD_COATS,
YIELD_RUM,
YIELD_CIGARS,
YIELD_TOOLS,
YIELD_MUSKETS,
YIELD_HORSES,
YIELD_TRADE_GOODS,
YIELD_HAMMERS,
YIELD_BELLS,
YIELD_CROSSES,
YIELD_EDUCATION,
///TKs Invention Core Mod v 1.0
YIELD_IDEAS,​

#else // Medieval Tech

YIELD_FOOD,///0
///TKs ME
YIELD_GRAIN,///1NEW*
YIELD_CATTLE,///2/NEW*
YIELD_SHEEP,///3/NEW*
YIELD_WOOL,///4NEW*
//YIELD_SALT,///5NEW*
YIELD_LUMBER,///6
YIELD_STONE,///7NEW*
// YIELD_LEATHER,///20NEW*
YIELD_SILVER,///8
//YIELD_GOLD,///9/NEW*
// YIELD_IVORY,//9/NEW*
YIELD_SALT,///5NEW*
YIELD_SPICES,///10NEW*
YIELD_FUR,///11
YIELD_COTTON,///12
YIELD_BARLEY,///13YIELD_SUGAR,
YIELD_GRAPES,///14YIELD_TOBACCO,
YIELD_ORE,///15
YIELD_CLOTH,///16
YIELD_COATS,///17
YIELD_ALE,///18YIELD_RUM,
YIELD_WINE,///19YIELD_CIGARS,
YIELD_TOOLS,///20
YIELD_WEAPONS,///21YIELD_MUSKETS,
YIELD_HORSES,///22
YIELD_LEATHER_ARMOR,///23NEW*
YIELD_SCALE_ARMOR,///24NEW*
YIELD_MAIL_ARMOR,///25NEW*
YIELD_PLATE_ARMOR,///26NEW*
YIELD_TRADE_GOODS,///27
// YIELD_SILK,///29NEW*
// YIELD_PORCELAIN,///30NEW*
YIELD_HAMMERS,///28
YIELD_BELLS,///29
YIELD_CROSSES,///30
YIELD_EDUCATION,///31
///TKs Invention Core Mod v 1.0
YIELD_IDEAS,///32
YIELD_CULTURE,///33
YIELD_GOLD,///34/NEW*

///TKe​

#endif

#ifdef _USRDLL

NUM_YIELD_TYPES​

#endif
};

That way we can have one DLL source, which an pick either M:C or col2071 when it compiles. If somebody makes a cool feature for one of them, it will be in the other right away. This is the best solution I can think of as the total C++ coding time is the lowest possible of everything I came up with when you consider you get a mod "for free" when you code for one mod. Granted compiling for one of the mods might break at times, but I assume that will always be fixable. We just need to test once in a while to locate those issues. We will also likely end up with a DLL with some features for one mod and some for the other meaning none of the mods will use all the available features.

I suspect most stuff will just work out of the box when doing this. The only real issue is the yields as they are hardcoded into the DLL (has something to do with calls from python). I think yield types needs to check for COLONIZATION2071 in 3 locations. We will know this for sure soon enough and we can add comments just before enum YieldTypes about where else to change when adding yields to make it easier to add more yields later. It will also make it easier to rename yields, something both mods could benefit from.

Now two things remain: figure out if this is possible (we may make a git branch to test on) and ask Kailric if he is ok with this idea.

Oh and for the record Makefile.settings can also overwrite YOURMOD meaning Makefile.settings should look like

CUSTOM_CFLAGS = -DCOLONIZATION2071
YOURMOD=C:\PATH\MODS\Colonization 2071

That way the mod file will be moved to the right location even though the DLL source is in the M:C source.

EDIT: just read about git merging. While I have done it before, it's not something I do daily and have to look up commands each time
The basic idea is this

The revision tree branches into two (hence the name branch) and then the master (M:C) continues unaffected. The other branch is then a playground for this experimental feature. Once it works it can be merged into the master (C6) and we continue with shared source.
There is the safety valve that if this approach turns out to be a failure, we can skip the merge and M:C will never see any of the col2071 commits.

Git was designed with branching in mind and the goal is to make merges a whole lot easier. New versions of svn stole some of the ideas, but this is still git territory.

 

[Kailric]

Now two things remain: figure out if this is possible (we may make a git branch to test on) and ask Kailric if he is ok with this idea.

No, I am not "ok" with this idea, I am "all for it" Sounds like a challenge. I always wanted to help out more on this mod and that may make it easier.

 

[Nightinggale]

Sounds like a challenge.

The challenge is getting M:C code to work with col2071. Adding the ability to still compile M:C appears to be a minor task in comparison if this is done correctly. All it takes is a few #if #else line in the example I posted. It's not like it's horribly difficult compared to just replacing the code.

I have no idea how hard it will be to get the DLL to work with col2071, but that task is unavoidable if col2071 is to get a new DLL. Taking the one from RaR is likely even harder.

I always wanted to help out more on this mod and that may make it easier.

It actually goes both ways. If col2071 needs a DLL addition, then M:C will get it for free. This will likely provide some interesting possibilities. Most likely none of us imagine what the outcome of that option will be. I think worst case would be that M:C ignores such additions, which isn't that bad after all.

 

[orlanth]

Wow that sounds great, thanks a lot Nightingale and Kailric I've always wanted to "upgrade" to a much better DLL but skeptical about my ability to achieve it on my own.. I certainly couldn't come anywhere close to all the advances made by mods like M:C, TAC and RaRE!

Anyway, I doubt there's too much worth saving in the old DLL. So it could be possible to start fresh from M:C and gradually make a few incremental edits/additions hoping not to break anything too badly . Hopefully that will leave lots of old 2071 bugs behind for good. As you notice, cause of all the DLL hardcoding I'd built the mod using all the standard yield names in XML.. it worked but can eventually get pretty frustrating (wait, YIELD_CIGARS is Fusion Cores and YIELD_FUR is Progenitor Artifacts?? )

With the many great features in M:C, I'm sure I could think of ways for them to be used in 2071 as well. Like the Animals/Bandits, some Beasts and Progenitor units could roam the planets, it would be cool if defeating them gave some rare yield types like Tissue Samples which could be used for researching special techs Likewise all the new promotions options would be awesome for kitting out ships and units differently.

For Trade Points unlocking Silk Road etc, could instead accumulate Progenitor Secrets, which unlock a special series of techs and eventually access new trade screens through the wormhole, such as the Progenitor Homeworld

Luxury Food, I don't know if I can think of a really good way to use it but let me know if you guys have any ideas. But maybe some sort of Cybernetics yield and techs could enable you to access "upgraded" Colonist types

Newfloridian

I have continued to play along with the existing version (ie not tried modding the 'lack of city center' capability in captured settlements we talked about some posts back). The reason for this is that I want to see what a War of Independence looks like in the vanilla 2071! I am now at turn 500.

Wow you should revolt, you can easily take them. Don't wait too long or Earth tyrants will win a Stagnation Victory.. I think Alien Hybrids should be able to take Soldier or Mecha Pilot professions. The City Center really needs to be made buildable in captured cities so go ahead with the XML edit, that was an oversight on my part. Anyway if upgrading to M:C DLL that issue will go away; IIRC the need to have a new buildingclass for City Center was cause of the old modcomp version using buildingtypes instead of buildingclasses which is thankfully no longer the case.

Anyway here's an Excel document I'd made awhile ago with design ideas for a new version; maybe it would be best to start out much more limited though with less yield types etc. I'd be really interested to hear any ideas/input from people who've played it

 

[Nightinggale]

I made a branch cleverly named colonization2071.

I learned that it will be way easier if col2071 has it's own targets. I made two (assert-2071 and assert-fast-2071). I wonder if it should be 2071-assert as they are sorted alphabetically, but that's a minor detail.

Makefile.settings should then contain

!IF "$(MODULE)" == "colonization2071"
CUSTOM_CFLAGS = -DCOLONIZATION2071
!ENDIF

Theoretically that should be in the Makefile itself, but I want to keep that one mod independent, at least for now.

I then changed the enum as I wrote in the example a few posts back. That didn't go very well. It turns out that the yields are more hardcoded into the source than I first realized. The code is full of lines like

if (eEquipment == YIELD_LEATHER_ARMOR || eEquipment == YIELD_SCALE_ARMOR || eEquipment == YIELD_MAIL_ARMOR || eEquipment == YIELD_PLATE_ARMOR)

I think this is bad in more ways than one. Having decentralized the checks like this makes it prone to bugs due to copy paste errors. What if I want to add YIELD_MITHRIL_ARMOR?
On top of that it also makes it really bad for col2071.

What do you say about adding info to CIV4YieldInfos.xml instead? Say we add armor_level and such a check would then be if armor_level > 0. The checks where leather armor isn't present would then be > 1 checks. Food and luxury food would then be food level 1 and 2, possibly just food and then the DLL will assign index for them. With a bit of thinking I think we can make yield classes in the DLL rather than specific hardcoded C++ code.

What do you guys say? Can we figure out a yield classification system, where most stuff is handled in XML instead?

 

[raystuttgart]

What do you guys say? Can we figure out a yield classification system, where most stuff is handled in XML instead?

Be careful with approaches that.
There is a reason for hardcoding yields. It is simply performant.
The amount of checks related to yields is enormous.

By the way:

I can understand why you are thinking about having one dll for several mods.
But do you really think it is a good idea to mix code for a science fiction and a medieval mod into one common dll ?

Isn't it easier to take a dll and adjust it for specific needs and features ?
Where is the problem sharing features the old way from one mod to another and then do the mod specific adapting / changing?

Do you really think that every feature that 2 mods use, will work exactly the same in the other one ?
Modding is simply a lot of personal taste (or team taste) as well.

I would really suggest that you try to keep things clean and separated.
Most likely you will get much better quality out of this.

But of course, orlanth could take the DLL of M:C as a starting point.
And of course, you could share features around. (Like it is done anyways between modders.)

Sharing and cooperation are great, don't get me wrong.
It is something totally different though, to intertwine 2 projects / mods on a technical level like you are currently discussing.

 

[Nightinggale]

Be careful with approaches that.
There is a reason for hardcoding yields. It is simply performant.
The amount of checks related to yields is enormous.

Yeah I abandoned that idea and came up with something which can be done in the precompiler, just like the hardcoded enum. In fact it is a hardcoded enum.

Spoiler :

enum DllExport YieldTypes
{

NO_YIELD = -1,​

#ifdef COLONIZATION2071

YIELD_FOOD,
YIELD_LUMBER,
YIELD_SILVER,
YIELD_COTTON,
YIELD_FUR,
YIELD_BARLEY,
YIELD_GRAPES,
YIELD_ORE,
YIELD_CLOTH,
YIELD_COATS,
YIELD_ALE,
YIELD_WINE,
YIELD_TOOLS,
YIELD_WEAPONS,
YIELD_HORSES,
YIELD_TRADE_GOODS,
YIELD_HAMMERS,
YIELD_BELLS,
YIELD_CROSSES,
YIELD_EDUCATION,
YIELD_IDEAS,

NUM_YIELD_TYPES,

YIELD_GRAIN,
YIELD_CATTLE,
YIELD_SHEEP,
YIELD_WOOL,
YIELD_STONE,
YIELD_SALT,
YIELD_SPICES,
YIELD_LEATHER_ARMOR,
YIELD_SCALE_ARMOR,
YIELD_MAIL_ARMOR,
YIELD_PLATE_ARMOR,
YIELD_CULTURE,
YIELD_GOLD,​

#else // Medieval tech
the current M:C code

This is precisely the same names as M:C uses and the compiler will not have any issues compiling this. The names doesn't matter at all as the compiler will change them into numbers. We could rename YIELD_HAMMERS into MyBubabubaYield and it would still work. I would hate to read that code though
We can exploit the fact that the compiler doesn't care about the names and reuse names like the current col2071 does. This should work as long as we keep in mind which yields which have a special meaning in the DLL, such as luxury food (cleverly hidden under the name YIELD_GRAIN).

The order is important here because the order here is the same as the order of yields in XML. My theory is that anything after NUM_YIELD_TYPES will be out of range for the code and as such it will never be reached. We need to test this well to make sure it works that way.

This mean we will need a list of what enum name goes with what ingame name. The source provides this as well. Inside CyEnumsInterface.cpp

Spoiler :

python::enum_<YieldTypes>("YieldTypes")

.value("NO_YIELD", NO_YIELD)​

#ifdef COLONIZATION2071

.value("YIELD_FOOD", YIELD_FOOD)
.value("YIELD_LUMBER", YIELD_LUMBER)
.value("YIELD_SILVER", YIELD_SILVER)
.value("YIELD_COTTON", YIELD_COTTON)
.value("YIELD_FUR", YIELD_FUR)
.value("YIELD_SUGAR", YIELD_BARLEY)
.value("YIELD_TOBACCO", YIELD_GRAPES)
.value("YIELD_ORE", YIELD_ORE)
.value("YIELD_CLOTH", YIELD_CLOTH)
.value("YIELD_COATS", YIELD_COATS)
.value("YIELD_RUM", YIELD_ALE)
.value("YIELD_CIGARS", YIELD_WINE)
.value("YIELD_TOOLS", YIELD_TOOLS)
.value("YIELD_MUSKETS", YIELD_WEAPONS)
.value("YIELD_HORSES", YIELD_HORSES)
.value("YIELD_TRADE_GOODS", YIELD_TRADE_GOODS)
.value("YIELD_HAMMERS", YIELD_HAMMERS)
.value("YIELD_BELLS", YIELD_BELLS)
.value("YIELD_CROSSES", YIELD_CROSSES)
.value("YIELD_EDUCATION", YIELD_EDUCATION)
.value("YIELD_IDEAS", YIELD_IDEAS)
.value("NUM_YIELD_TYPES", NUM_YIELD_TYPES)​

#else // Medieval Tech

I didn't test this, but if I understand this right it mean when the python code requests whatever is in "", it will answer with the number to the right. If I understand your old post correctly, it would make sense to write

.value("YIELD_PROGENITOR_ARTIFACTS", YIELD_FUR)

This way the python code works on human readable names and the internal code still use YIELD_FUR to keep the code compatible with M:C.

I can understand why you are thinking about having one dll for several mods.
But do you really think it is a good idea to mix code for a science fiction and a medieval mod into one common dll ?

Isn't it easier to take a dll and adjust it for specific needs and features ?
Where is the problem sharing features the old way from one mod to another and then do the mod specific adapting / changing?

Do you really think that every feature that 2 mods use, will work exactly the same in the other one ?
Modding is simply a lot of personal taste (or team taste) as well.

Normally I would agree. However realistically speaking we know more or less nothing happens to the DLL in Colonization 2071. Making it live in an M:C DLL world appears to be a better choice than to leave it in the near vanilla world it is in right now.

Also this work is in an experimental branch. We have no idea if it will end up being merged at some point at all. While I came up with this idea and thought it though before telling anybody, I do have to say that I'm still not 100% sure we will end up with something where merging is in our common interest or if we even get col2071 to accept the M:C DLL. I think the chance is good enough to do the attempt.

 

[Nightinggale]

It crashes each time I try to start.

bool CvPlayerOptionInfo::getDefault() const
{
	return m_bDefault;
}

The problem is that m_bDefault isn't set. In fact it looks like *this is uninitialized. Now the big question is: what did Kailric change to game options, which breaks this?

This is unrelated to yields.

 

[orlanth]

There are new M:C game options for No Wild Land Animals and No Wild Sea Animals, maybe it's relating to those. I wonder if it could be addressed by pasting some of the unitinfos.xml Animals from M:C as placeholders (or tweaking DLL to work with or without Animals/Bandits).

I think most of the new XML tags added by M:C were made optional which is great for mod flexibility. But there must be at least some XML changes that'd be required to get it to load with M:C DLL. Pretty much any XML checks hardcoded in DLL would need to be dealt with. Kailric, based on your coding recollections do you have any ideas of the important XML issues to address for M:C compatibility?

One particular thing I can think of is, in gameinfo/CIV4CivicInfos.xml the old modcomp uses <AllowsBuildingTypes> for techs, whereas the new M:C uses that same tag name but with buildingclasses instead, eg <BuildingType>BUILDINGCLASS_INVENTORS_HOUSE</BuildingType>
(that was a good modding decision believe you me.) I'm thinking 2071 xml could be brought up to date for it by doing a find/replace BUILDING_ to BUILDINGCLASS_ in that file.

 

[Kailric]

It crashes each time I try to start.

bool CvPlayerOptionInfo::getDefault() const
{
	return m_bDefault;
}

The problem is that m_bDefault isn't set. In fact it looks like *this is uninitialized. Now the big question is: what did Kailric change to game options, which breaks this?

This is unrelated to yields.

There is no telling what I changed. I've made so many changes. I am not sure exactly what your trying to do. Are you trying to start the new branch? Anyway, yeah we can add XML tags so we can group equipment and remove a bunch of those yield checks. We would probably need to do a search of each yield and analyze the code and see if there needs to be any changes or new XML tags made through out the whole project.

 

[Nightinggale]

I am not sure exactly what your trying to do. Are you trying to start the new branch?

It's actually fairly simple what I did. I moved the M:C DLL into col2071 and tried to start the game. This crash appears to be before anything yield related.

I added an assert in that function, which tells me the number of PlayerOptionInfos. It turns out to be 21. I then counted the number of asserts and it crashes the 22nd time the assert appears. For some reason the game tries to read from GC.getPlayerOptionInfo() and just continues to read without checking if it reached the end of the vector. The big question is why would it do that

 

[Nightinggale]

Found the problem. CIV4PlayerOptionInfos.xml needed 3 more options as the number is hardcoded into the DLL. Adding those made interesting results. A lot of XML errors appears, a few asserts and then it crashes when it reach main menu.

For the record the missing options are named PLAYEROPTION_MODDER_4, 5 and 6. I would like to propose names, which is human readable. Those options are wild animals and stuff. However I don't know which is which. However what they are called aren't important at the moment. The important part is that the amount of options is correct.

EFFECT_CITY_FIRE is used for multiple purposes in XML. This isn't allowed as Kailric learned the hard way
This is a minor issue compared to not being able to even reach the main menu.

I pushed the new branch to github https://github.com/Nightinggale/Medieval_Tech/tree/colonization2071

@orlanth:
Do you think you can pull this source and compile it? Also would you look into the XML errors?

Maybe it would be a good idea to put the colonization2071 text files on git. Otherwise it will be a pain to keep track of changes and to share problems between people.

 

[orlanth]

rrr, trying to compile
ok, I installed the SDK going by the modiki , while using Visual C++ Express 2010 instead like you'd mentioned. I then downloaded the branch as a zip from your github page, extracted the DLL_Sources folder to a working directory, copied your makefile into it, and included the bin folder inside it with fastdep and jom. I copied a project file to the directory using the one in the makefile link in your sig, opened it in Express 2010, and added the DLL files to the project; but when I try to Build it can't find boost or python and has a fatal error. (Where would I get these? they're not in the DLL_Sources folder & the modiki page doesn't mention where to find them, just that they're there..) sorry it's been years since I managed to compile a DLL and think I was using 2008 at the time!

The XML files in the github branch are the standard M:C ones, do you think the 2071 XML should go there?