[MODCOMP] Obsolete Buildings

[xienwolf]

Quick question while I am compiling this (trying to help Ploe out by importing it to FfH myself), what happens with Building Requirements?

As I was skimming your code in the DLL, it seemed that it removes the obsolete buildings from the city. So if I have a unit that requires Archery Range, and I make the Bowyer cause Archery Range to go Obsolete... will I be able to build that unit still? Seems to me like the answer will be no.

Can you think of an elegant and easy way to solve this if that is the case? I suppose I could add a loop to check for buildings which make the requirement obsolete when the CanTrain/Upgrade function looks for a valid building.

First inclination was just to set it up so you could have multiple buildings required for a unit, but I'm kinda loathe to write that one myself, and the closest MODCOMP I can find right now is TheLopez's mod from back in Warlords

EDIT: For now I have commented out all your changes in Game Text Manager, as they are causing an issue. But I am not sure if the mechanics are working. An obsolete Building should no longer display as being in the city, correct? If so, then none of it is working just yet for me (have both Archery Range and Bowyers showing in my city with the new DLL)

EDIT 2: Realized I can answer my own questions by just loading your example It should make the building quit showing, so that means I have some work to do on making it actually work at all. I'll have to peek at how much Kael has shifted Building Requirements around, I suspect it is in there. Also realized that it wouldn't work to have the building recurse all the buildings which it made obsolete and allow the same units, as blocking off units is one of the main reasons behind making buildings go obsolete!

 

[Jean Elcard]

Quick question while I am compiling this (trying to help Ploe out by importing it to FfH myself), what happens with Building Requirements?

As I was skimming your code in the DLL, it seemed that it removes the obsolete buildings from the city. So if I have a unit that requires Archery Range, and I make the Bowyer cause Archery Range to go Obsolete... will I be able to build that unit still? Seems to me like the answer will be no.

You are absolutely right, the Archery Range would be replaced by its successor. Means: No Archery Range in Town anymore if you finish building the Bowyer. If you want to keep the bonuses provided by a building going obsolete you will have to add theses bonuses to it's successor too - manually in XML. In your case to the Bowyer. I've implemented it this way to prevent a successor from getting all the bonuses of all its possible predecessors. This is working fine for walls and stuff, but I see that this going to be a problem in this special case.

Can you think of an elegant and easy way to solve this if that is the case? I suppose I could add a loop to check for buildings which make the requirement obsolete when the CanTrain/Upgrade function looks for a valid building.

You are right here too. You could possibly add a special loop to check for predecessor buildings allowing to build Archers, but this wouldn't be very elegant way of doing it. Too specific for my taste, but possible. Furthermore you would have to change the CvGameTextMgr files too, so all the abilities show up correctly in all the tool tips and the Civilopedia.

First inclination was just to set it up so you could have multiple buildings required for a unit, but I'm kinda loathe to write that one myself, and the closest MODCOMP I can find right now is TheLopez's mod from back in Warlords

The solution you came up with first, seems the way to go for me. Can't think of a better way right now. The changes necessary to allow more than one building as a building requirement for units shouldn't be too difficult to implement after all. Could be useful as a general game mechanics too.

 

[xienwolf]

ARGH! Most annoying thing ever! I just loaded your module into my FfH test folder, and ran the exact same game which wouldn't work with the Archery Range and Bowyers. Your module worked fine! But the Bowyer continues to NOT remove the Archery Range....

I feel some fun coming up with thsi debugging session

 

[Jean Elcard]

Yes, it seems there is a conflict (or more than one, if you are especially lucky) between my code and FfH. I hope you are able to solve it. I would really like to help you out, but I'm a bit short of time at the moment and don't have a clue, what is causing all this trouble Ploeperbengel and you are stumbling over without trying to compile the code myself. Don't even have a compiler installed these days.

Good night and good luck.

 

[xienwolf]

Found my first problem: I am trying to make the field optional. That's what causes my Civilopedia to be blanked out. If I place a Null field in each entry then that part works fine.

And no worries about not knowing what the issue is. I'm just posting to keep Ploe up to date and help future merges mostly.

EDIT: Well, done playing with it for today I think. I moved all your sample buildings from Module to main mod, and they still worked. Then I placed all the Obsolete tags on Building B onto Bowyers, and suddenly Bowyers worked like Building B + Archery Range. Worked properly and everything. Went back to doing nothing when I returned to just obsoleting the Archery Range.

Oh, and during all this I found that while it failed to load things (blank Civilopedia for Buildings/Wonders) most of the time, on every 2nd or 3rd load it would actually bring up everything properly. Overall... NFC for today. Hopefully some inspiration on the drive home tonight.

 

[xienwolf]

Turns out that the reason Bowyer wasn't working on the Archery Range was the same as the complication I had with another MODCOMP. I placed a comment in the XML.

Anyway, it all works nicely now, except that 2 out of every 3 times you load the game there is a glitch with the Civilopedia causing it to blank the buildings (which will crash you as soon as you settle your first city).

Hopefully have that isolated sometime soonish.

 

[Ploeperpengel]

That's great news, xienwolf! wished I could help but that just exceeds my pitiful skills by far.

 

[xienwolf]

Problem solved. Now I just have to discover precisely how to fix it.

The problem is solved by Commenting out:

/*************************************************************************************************/
/**	Obsolete Buildings				05/08/07			Written: Elgor		Imported: Xienwolf	**/
/**																								**/
/**			Finds all Buildings which cause Obsolescence and Displays Information				**/
/*************************************************************************************************
	for (iI = 0; iI < GC.getNumBuildingClassInfos(); iI++)
	{
		fillObsoleteWithBuildingArray(pabObsoleteWith, iI, eBuilding);
	}

	for (iI = 0; iI < GC.getNumBuildingInfos(); iI++)
	{
		if (pabObsoleteWith[iI])
		{
			szBuffer.append(NEWLINE);
			szBuffer.append(gDLL->getText("TXT_KEY_BUILDING_OBSOLETE_WITH", GC.getBuildingInfo((BuildingTypes)iI).getTextKeyWide()));
		}
	}
/*************************************************************************************************/
/**	Obsolete Buildings							END												**/
/*************************************************************************************************/

and

void CvGameTextMgr::fillObsoleteWithBuildingArray(bool* pabBuilding, int iItem, BuildingTypes eBuilding)
{
	int iI;
	BuildingTypes eLoopBuilding;

	if (GC.getGameINLINE().getActivePlayer() != NO_PLAYER)
	{
		eLoopBuilding = (BuildingTypes)GC.getCivilizationInfo(GC.getGameINLINE().getActiveCivilizationType()).getCivilizationBuildings(iItem);
	}
	else
	{
		eLoopBuilding = (BuildingTypes)GC.getBuildingClassInfo((BuildingClassTypes)iItem).getDefaultBuildingIndex();
	}

	if (GC.getBuildingInfo(eLoopBuilding).isObsoletesBuildingClass(GC.getBuildingInfo(eBuilding).getBuildingClassType()))
	{
		if (!pabBuilding[eLoopBuilding])
		{
			pabBuilding[eLoopBuilding] = true;
/**
			for (iI = 0; iI < GC.getNumBuildingClassInfos(); iI++)
			{
				fillObsoleteWithBuildingArray(pabBuilding, iI, eLoopBuilding);
			}
**/		}
	}
}

Remove those comment tags and 2 in 3 loads of the game result in a blank Building Page in the Civilopedia, and a crash when you build the first City. But that third time when the Civilopedia DOES load, the displays and everything else work perfectly.



With this portion commented out, everything is flawless, you just don't have a display on each building stating what precisely makes it become obsolete.

 

[Jean Elcard]

Good to see, you could figure out most of the glitches. The one reamining is only a minor problem. A nice to have functionality, but not really necessary for the game mechanics to work.

Especially strange is the fact, that it only happens 2 out of 3 times. Can't remember anything like this happening with the BtS version of this mod component. Maybe it depends on the civilization you are playing? Did you check if the Civilopedia is blanked out sometimes too, when you are still in the main menue screen or only if you already started a game and civ4 knows which civ you are playing?

EDIT: If the case is the latter the solution might be as easy as to add a check for "eLoopBuilding != NO_BUILDING": in the "fillObsoleteWithBuildingArray" function like this:

[B]if (eLoopBuilding != NO_BUILDING)
{[/B]
	if (GC.getBuildingInfo(eLoopBuilding).isObsoletesBuildingClass(...))
	{			
		...
	}	
[B]}[/B]

In BtS all civs can at least build the default building of each building class, but in FfH that's not always the case. Hence this check is probably necessary to make it work.

 

[xienwolf]

I was only checking the Civilopedia from the main screen, without starting up an actual game, specifically to avoid the "which Leader are you?" issues. Had the same thought about maybe the != NO_PLAYER causing issues.

Since it occasionally DOES work, I figured the issue might be an array somewhere not getting deleted or initialized. Thus the times it works are when it happens to grab a clean chunk of memory to work with. Haven't found anything yet on those lines.

EDIT: Wrong reason, but good solution. So far I have had it load successfully 4 times out of 4 using the NO_BUILDING check. I love when easy answers are the right ones.

 

[Jean Elcard]

Everything alright then. I should probably add this check to the current main modcomp version as well, to prevent other people from running into the same issue. It's always better to do one check more than necessary.

 

[Jean Elcard]

New Version 0.1.1 for Beyond the Sword 3.17 released.

changelog for version 0.1.1

• compatibility update to BtS version 3.17
• fixed a bug, which could cause the pedia to blank out and would crash the game after founding a city if used in conjunction with certain mods
• no need for activating modular loading manually anymore

 

[MagisterCultuum]

Transitivity: If Building B obsoletes A and C obsoletes B, then C also obsoletes A automatically.

What is the point of this?

Imho, it would be far better to do away with the automatic obsolescence, since you can easily handle it manually in the xml. Allowing Circular obsolescence paths would make this modcomp far more useful. I understand that it could cause problems if the AI keeps replacing one building with another, but that can be overcome manually or with different prereqs, like State Religion Requirements.

 

[Jean Elcard]

The point was, that I had a problem with this scenario concerning three buildings: "B should obsolete C and A should obsoelte B and C". If A wouldn't have been told to obsolete C explicitly in XML, besides the fact that it obsoletes B, than after you build A you would be able to build C again because B became obsolete by building A. In many cases you wouldn't want this to happen. Imagine a wall becoming better over time for example: Palisade, Stone Wall, High Stone Wall. Why sould you be able to build a Palisade again after updating you Wall to an High Wall?

I know you could have just told A to obsolete both (B and C) in XML. Doing it automatically just saves you time. You don't need to declare everything explicitly. In complex scenarios with more than three buildings this becomes a very tedious task and is more prone to produce unintended behaviour because you missed an entrance or stuff like this.

Nevertheless, I have to admit, it would be nice to have something like mutual exclusiveness (circles). I will think about, how to make this possible, but without removing the currently implemented automatically generated obsoleteness.

 

[Jennar]

Based upon your last entry I am safe to assume that your mod will not allow us to make 'Doctrines" (like those form Company of Heroes)?

I was really looking forward to that type of functionality.

-J