PROJECT: CivOnly and CultureOnly

[Ekmek]

for cultureOnly...

//----------------------------------------------------------------------------
//
// Name       : Player::CanBuildUnit
//
// Description: Checks whether the city can build the unit specified by type.
//
// Parameters : type: The unit type for that is checked whether the player can 
//              build it.
//
// Globals    : g_player:           The list of players
//              g_theUnitDB:        The unit database
//              g_theWonderTracker: The wonder tracker
//              g_exclusions:       The exclusions data
//
// Returns    : Whether the city can build the unit specified by type.
//
// Remark(s)  : CultureOnly flag added by E. It allows only civilizations with 
//		the same CityStyle as CultureOnly's style to build that unit
//
//----------------------------------------------------------------------------
BOOL Player::CanBuildUnit(const sint32 type) const
{
	const UnitRecord *rec = g_theUnitDB->Get(type);

    if (!HasAdvance(rec->GetEnableAdvanceIndex()))
        return FALSE;

	sint32 o;
	for(o = rec->GetNumObsoleteAdvance() - 1; o >= 0; o--) {
		if(HasAdvance(rec->GetObsoleteAdvanceIndex(o)))
			return FALSE;
	}

	if(g_exclusions->IsUnitExcluded(type))
		return FALSE;

	if(rec->GetCantBuild()) {
		
		return FALSE;
	}

	if(rec->GetNumGovernmentType() > 0) {
		sint32 i;
		bool found = false;
		for(i = 0; i < rec->GetNumGovernmentType(); i++) {
			if(rec->GetGovernmentTypeIndex(i) == m_government_type) {
				found = true;
				break;
			}
		}
		if(!found)
			return FALSE;
	}


	if(rec->GetNuclearAttack() &&
	   wonderutil_GetNukesEliminated(g_theWonderTracker->GetBuiltWonders())) {
		return FALSE;
	}

	if(rec->GetSlaveRaids() || rec->GetSettlerSlaveRaids() ||
	   rec->GetSlaveUprising()) {
		if(wonderutil_GetFreeSlaves(g_theWonderTracker->GetBuiltWonders())) {
			return FALSE;
		}
	}

	if(rec->GetSlaveRaids() || rec->GetSettlerSlaveRaids()) {
		sint32 i, n = m_all_units->Num();
		for(i = 0; i < n; i++) {
			if(m_all_units->Access(i).GetDBRec()->GetNoSlaves())
				return FALSE;
		}
	}

	if(rec->GetNoSlaves()) {
		
		sint32 i, n = m_all_cities->Num();
		for(i = 0; i < n; i++) {
			if(m_all_cities->Access(i).CountSlaves() > 0)
				return FALSE;
		}

		n = g_player[m_owner]->m_all_units->Num();
		for(i = 0; i < n; i++) {
			if(m_all_units->Access(i).GetDBRec()->GetSlaveRaids())
				return FALSE;
		}
	}


	if(rec->GetCreateParks() && 
	   !wonderutil_GetParkRangersEnabled(g_theWonderTracker->GetBuiltWonders())) {
		return FALSE;
	}[b]
#if !defined(ACTIVISION_ORIGINAL)
	if(rec->GetNumCultureOnly() > 0) {
		sint32 s;
		for(s = 0; s < rec->GetNumCultureOnly(); s++) {
			if(rec->GetCultureOnlyIndex(s) == GetCivilisation()->GetCityStyle()) {
				return TRUE;
			}
		}
			return FALSE;
	}
#endif	[/b]
	return TRUE;
}

[Martin Gühmann]

Both functions seem to be compilable. To things about tabs. In the description block you used tabs to indent the line under Remark(s). And I can tell you that this probably looks different on another edotor. So better use spaces there.

The other tab is in your code in front of the return FALSE; The return FALSE is on the same level like the preceeding for loop and should have therefore the same indention.

As said otherwise it is fine. So you have now to present the code in the unit.cdb file.

-Martin

[Ekmek]

ok, I added the code in unit.cdb as such...

	Record Advance             EnableAdvance
	Record Advance[0..5]        ObsoleteAdvance
	Record Government[] GovernmentsModified
	Record Terrain[] CanSettleOn //added by E
	Record CityStyle[] CultureOnly //added by E -- can only build units if civ has certain citystyle
	Record CityStyle[] CityStyleOnly //added by E--can only build units at cities with certain citystyle

I think I got it right. I say citystyle in the citystyle.cdb and since my code mirrors government type I copied the same in and renamed it (obviously)

If this is okay I'm going to added it to buildings, terrain improvements, wonders, governments, and advances. Of course they won't use the citystyle one just cultureonly, but I'm thinking advances might be difficult because they may be captured.

Also, once I do this I'm thinking I'll add the government type code to them as well and when I add my code fragment to the other CanBuild stuff I'll put the government Type in there, I don't think it should cause any problems...

[Martin Gühmann]

Probably it doesn't casue amy problems, but just to be sure post them as well.

-Martin

[Ekmek]

Martin,
I added the CityStyleOnly and CultureOnly to other Cdbs (of course CityStyleOnly applies only to wonders, buildings, and units as far as think the game can handle)

I added the GovernmentType as well although I think it may have play problems, not necessaruily crashing, but weird if you can build something in one govt but still have it if you change (but may Baggins' govt modified could do something for it).

Also I went a little crazy on Future Use flags you might want to look at. If for some reason the cdbs can't handle I'll repost only cdbs with CultureOnly and CityStyleOnly.

I'll start adding the code into the player.cpp and citydata.cpp soon.

[Martin Gühmann]

The cdb's seem to compile and seem not to cause serious effect, like the sudden requirment for an additional flag. But I have to thinks you should reconsider.

Bit IsIrrigation //futureUse -- can only build on rivers or adjacent to other IsIrrigation imps

For me an irrigation type doesn't really require water supply, for instance you could access the gound water, or you have enough rain, so better call it NeedsWaterSupply. Maybe this might be also dependent on the terrain type. The only little problem here will be the AI terrain improvement routines.

And as we are talking about adding missing features from Civ2, you forgot BrigdeConstruction on your list. It should be an advance flag like EnablingAdvance.

Record Resource[0..4] PlantGood //added by E for future imp that places a good instead

Are you really sure that you want to allow to plant four different goods at the same when a tile improvement is built?

[Ekmek]

Originally posted by Martin Gühmann

Bit IsIrrigation //futureUse -- can only build on rivers or adjacent to other IsIrrigation imps

For me an irrigation type doesn't really require water supply, for instance you could access the gound water, or you have enough rain, so better call it NeedsWaterSupply. Maybe this might be also dependent on the terrain type. The only little problem here will be the AI terrain improvement routines.

No prob on the name change and yeah I think the AI may have a prob but this is long term, something that makes rivers more strategic and required for city building (although the food bonus does that too, it'll be nice to cut off water supplies)

And as we are talking about adding missing features from Civ2, you forgot BrigdeConstruction on your list. It should be an advance flag like EnablingAdvance.

Record Resource[0..4] PlantGood //added by E for future imp that places a good instead

Are you really sure that you want to allow to plant four different goods at the same when a tile improvement is built?

I'll add the bridge thing. PlantGood i wasn't sure about. I want to make it a unique feature where players can plant tradeable goods (ie cotton and also a unit PillageGood ability) I guess I should make it a number for each one? I just copied it from terrain. So it should be four lines?

Record Resource[0] PlantGood
...
Record Resource[4] PlantGood

thanks

[Martin Gühmann]

Originally posted by E
I'll add the bridge thing. PlantGood i wasn't sure about. I want to make it a unique feature where players can plant tradeable goods (ie cotton and also a unit PillageGood ability) I guess I should make it a number for each one? I just copied it from terrain. So it should be four lines?

Record Resource[0] PlantGood
...
Record Resource[4] PlantGood

Not quite, and actual it depends on what you want to do. If you want to do it like so that it plants a one of the four goods that can be found on that terrain you should rather use an integer value.

Or it should work like this that the terrain improvement must plant an specific good that can be found in the ressource databse.

Actual the later concept is ugly, as you decide to plant a good on a terrain that actual never can have the specified good.

-Martin

[Ekmek]

If we use the CantBuildOn in conjuction with integer you could have spice farms or cotton plantations then I guess. I opt to make it only one resource on one type of terrain. It controls what can be built and when. So I'll go with the integer I guess...

[Ekmek]

Martin, I've added most of the code snipits to the citydata, player, wonder_util, but I'm little unsure where to put it in terrain improvements:

bool terrainutil_CanPlayerBuild(const TerrainImprovementRecord *rec, sint32 pl, bool checkMaterials)
{
	Assert(rec != NULL);
	if(rec == NULL)
		return false;

	Assert(pl >= 0);
	Assert(pl < k_MAX_PLAYERS);
	if(pl < 0 || pl >= k_MAX_PLAYERS)
		return false;

	Assert(g_player[pl]);
	if(!g_player[pl])
		return false;


	if(terrainutil_PlayerHasAdvancesFor(rec, pl)) {
		

		if(!checkMaterials)
			return true;

		
		
		sint32 i;
		for(i = 0; i < g_theTerrainDB->NumRecords(); i++) {
			if(terrainutil_PlayerHasAdvancesForTerrain(rec, pl, i)) {

[b][i]HERE? since it access the DB but would that affect terraforming?[/i][/b][i][/i]


				if(rec->GetClassTerraform()) {
					sint32 toterrain;
					if(!rec->GetTerraformTerrainIndex(toterrain))
						return false;
					
					const TerrainRecord::TransformData *tfrom = terrainutil_GetTransformData(toterrain, true);
					const TerrainRecord::TransformData *tto = terrainutil_GetTransformData(toterrain, false);

[b][i] OR HERE BEFORE IT CHECKS MATERIALS?[/i][/b][i][/i]

					if(g_player[pl]->m_materialPool->GetMaterials() >= tfrom->GetMaterials() + tto->GetMaterials()) {
						return true;
					}
				} else {
					const TerrainImprovementRecord::Effect *eff;
					eff = terrainutil_GetTerrainEffect(rec, i);
					if(eff) {
						if(g_player[pl]->m_materialPool->GetMaterials() >= eff->GetProductionCost()) {
							return true;
						}
					}
				}
			}
		}
	}

	return false;
}

[Ekmek]

I think its before checking materials (the second part)? If I'm right I'll post everything, this is the only thing holding me up.

[Martin Gühmann]

Neither nor. The second position would forbide terraforming and the first position is inefficient. It isn't bound to the terrain only to the player. So it belongs before the Advance checking.

-Martin

[Ekmek]

Martin,
I'm adding stuff back into this thread since it has more to do with the code than Good specific improvements

For CivOnly I think this may use the stringDB, and the code will go where my other code is. However I don't think I can get a numeric value but here it is:

#if !defined(ACTIVISION_ORIGINAL)

	if(irec->GetNumCivOnly() > 0) {
		sint32 s;
		bool found = false;
		for(s = 0; s < irec->GetNumCivOnly(); s++) {
			if(irec->GetCivOnlyIndex(s) == g_theStringDB->GetNameStr(g_theCivilisationDB->GetCountryName(m_civ)) {
				found = true;
				break;
			}
		}
		if(!found)
			return FALSE;
	}
#endif

OR with out the Number reference (so it matches text?)

#if !defined(ACTIVISION_ORIGINAL)

	if(irec->GetCivOnly() > 0) {
		sint32 s;
		bool found = false;
		for(s = 0; s < irec->GetCivOnly(); s++) {
			if(irec->GetCivOnlyIndex(s) == g_theStringDB->GetNameStr(g_theCivilisationDB->GetCountryName(m_civ)) {
				found = true;
				break;
			}
		}
		if(!found)
			return FALSE;
	}
#endif