DOCUMENT: Miscellaneous source findings and thoughts

[Martin Gühmann]

Interestingly in the Debug version there is some sort of Sprite tester, maybe an early version of a sprite editor.

-Martin

[Solver]

The code still has many referrences to the Alien victory, such as IsAlienVictoryEnabled variable, and so on. I won't be surprised if the code that worked with the Xenoform lab in CtP1 is still to be found somewhere.

[Locutus]

Originally posted by Martin Gühmann
Interestingly in the Debug version there is some sort of Sprite tester, maybe an early version of a sprite editor.

Yes, it was only alpha builds I worked with as well, but I could never get it to work: when I try to load a different sprite than the Settler, it always seems to crash (never tried too hard though).

[Martin Gühmann]

Originally posted by Solver
The code still has many referrences to the Alien victory, such as IsAlienVictoryEnabled variable, and so on. I won't be surprised if the code that worked with the Xenoform lab in CtP1 is still to be found somewhere.

Probably the Alien Victory is the science victory. But of course you could still find some CTP1 stuff.

-Martin

[Solver]

Yeah, I figure so, Martin, although there are separate classes to be found for the Gaia Controller items.

[MrBaggins]

The Veteran bug

SYMPTOM: Veteran status does not effect combat in any shape, form or way.

CAUSE: [CTP2Combat.cpp] The CombatUnit class does not include a veteran status variable, the CombatField::FillFrom function doesn't modify attack/defence strength & the CTP2Combat::ExecuteAttack doesn't attempt to look up veteran status or anything similar digging through the unit class.

SOLUTION:
Add veteran variable & populate in CombatUnit constructor. I.E. unit->IsVeteran()

Alter attack/def strength in CTP2Combat::ExecuteAttack
I.E. * g_theConstDB->GetVetCoef()

[Solver]

A good find, Mr. Baggins. I have also quickly written some additional code to the classes, but can't check whether it's working or not, so I'm not posting. But the main idea was adding the m_veteran variable to members of CombatUnit class.

[MrBaggins]

The "not working" is a bit of a bummer. Also the fact that we are stuck with 1.0 kinda sucks. We have to reinvent the wheel a bit... but fwiw adding new SLIC functionality isn't rocket science.

[MrBaggins]

Hmmm... time to dig up the patch readme to check what we need to fix again ourselves.

[Locutus]

I already did, it's doesn't offer an awfully lot of detail.

A. Multiplayer Issues
- Resolved several general issues.
- Addressed synchronization issues.
- Issues with nukes in network games have been resolved.
- Huge improvements to stability overall.
- Resolved client border update issue with captured cities.
B. Diplomacy Issues
- Embargo button on Diplomacy Manager remains enabled when confirmation is cancelled.
- Resolved some AI issues regarding diplomacy.
C. Miscellaneous
- Message occurring when a Wonder is nearly complete is now triggered earlier.
- Various general and stability issues with Scenarios have been addressed.
- Several text issues in the non-US versions of Call to Power II have been resolved.

[Maquiladora]

You can find all the seperate altered files in the XPatch zip file in the directory, if you need to know all the specific files that were added/changed.

[Locutus]

That's not very useful, we mainly want to know what changed in the ctp2.exe file, which we obviously need the source for...

[Maquiladora]

Better than nothing

[J Bytheway]

The rush buy bug

This particularly infamous bug seems to arise from the following dirty hack in ui\interface\NationalManagementDialog.cpp, around line 1255:

		g_gevManager->AddEvent(GEV_INSERT_Tail, GEV_BuyFront, GEA_City, city, GEA_End);

Which simply tells the city to rush buy no matter the circumstances, and so it is unsurprising that problems arose. I have replaced it with the following:

		// JJB removed the following:
		// g_gevManager->AddEvent(GEV_INSERT_Tail, GEV_BuyFront, GEA_City, city, GEA_End);
		// and replaced it with the following:
		if (!city.GetCityData()->AlreadyBoughtFront()) {
			city.GetCityData()->AddBuyFront();
		}
		// in the hope of fixing the rush buy bug.

Which calls the routines in the city to do it, which seems like what should have been done anyway.

Because of this on line 479 an additional condition needs to be added:

			// JJB added this inner if so that things add up properly
			if (!city.GetCityData()->AlreadyBoughtFront()) {
				rushBuyTotal += city.GetCityData()->GetOvertimeCost();
			}

so that the total cost displayed for rush buying is correct.

Brief tests suggest that this all works correctly.

[Solver]

I wonder if anyone who gets the compiled game to actually run can test this code, which is supposed to fix the veteran bug.

CombatUnit class declaration changed to be:

class CombatUnit {
private:
	
	double m_offense, m_defense,
		m_strength, m_armor,
		m_ranged, m_hp;
	bool m_veteran;
	UNIT_TYPE m_type;
	sint32 m_preferredCol;
	sint32 m_priority;
	
	bool m_valid;

public:
	
	bool m_alreadyExploded;
	bool m_alreadyAttacked;
#ifdef TEST_APP
	uint32 m_id;
#else
	Unit m_unit;
#endif

	CombatUnit() { m_valid = false; }

#ifdef TEST_APP
	CombatUnit::CombatUnit(double offense, double defense,
			   double strength, double armor,
			   double ranged, double hp, bool veteran, 
			   UNIT_TYPE type); //bool veteran added
#else
	CombatUnit::CombatUnit(double offense, double defense,
			   double strength, double armor,
			   double ranged, double hp, bool veteran,
			   Unit &u); //bool veteran added by solver
#endif

	double GetOffense() { return m_offense; }
	double GetDefense() { return m_defense; }
	double GetStrength() { return m_strength; }
	double GetArmor() { return m_armor; }
	double GetRangedAttack() { return m_ranged; }
	UNIT_TYPE GetCombatType() { return m_type; }
	sint32 GetPreferredCol() { return m_preferredCol; }
	void SetPreferredCol(sint32 col) { m_preferredCol = col; }

	sint32 GetPriority() { return m_priority; }
	void SetPriority(sint32 pri) { m_priority = pri; }
	//following two added by Solver
	void SetAttack (double att) { m_offense = att; } 
	void SetDefense (double def) { m_defense = def; } 

	double GetHP() { return m_hp; }

	bool IsVeteran(){	return m_veteran; }

	void DeductHP(double amt) 
#ifndef TEST_APP
		;
#else
	{ 
		m_hp -= amt; 
		if(m_hp < 0.001) {
			m_hp = 0;
		}
			
	}
#endif

	bool IsValid() { return m_valid; }
	bool IsAlive() { return m_hp > 0.001; }
	bool IsActive() { return IsValid() && IsAlive(); }

	void AddKill();

	void Invalidate() { m_valid = false; }
};

Round line 867 in CtP2Combat.cpp, changed code to:

CombatUnit newUnit(rec->GetAttack(), rec->GetDefense(), rec->GetFirepower(),
						   rec->GetArmor(), rec->GetZBRangeAttack(), u->GetHP(),
						   u->IsVeteran(),   u);

Function CtP2Combat::ExecuteAttack now contains this code in beggining:

void CTP2Combat::ExecuteAttack(CombatField *attacker, sint32 attX, sint32 attY,
							   CombatField *defender, sint32 defX, sint32 defY)
{
	m_noAttacksPossible = false;

	
	CombatUnit *att = &attacker->GetUnit(attX, attY);
	CombatUnit *def = &defender->GetUnit(defX, defY);
	//Solver added the following to add veteran check
	if (att->IsVeteran()) {
		double vetattack; double vetdefense;
		vetattack=att->GetOffense() + att->GetOffense() * g_theConstDB->GetVetCoef();
		att->SetAttack(vetattack);
		vetdefense=att->GetDefense() + att->GetDefense() * g_theConstDB->GetVetCoef();
		att->SetDefense(vetdefense);
	}

Finally, to CtP2Combat.cpp I added

#include "ConstDB.h" //the const db for veteran
extern ConstDB *g_theConstDB;  //to get vetstatus

in the beggining.

I hope this fixes the bug, if I understood the way code works from my quick look at it.