Version 1.5 discussion thread

[jdog5000]

CFC download
Sourceforge repository

In 1.4 there were only 5 fixes and we thought maybe we'd fixed most everything. Well, in 1.5 there are 24 fixes! A big thanks to all of you who contributed and reported bugs and other issues, the UP is truly a community effort

Changes in v 1.5:

- CvCityAI::AI_buildingValueThreshold - Fixed bug causing AI cities to over value buildings which unlock specialists in many circumstances when picking what to build
- CyInfoInterface2 - Fixed issue with "getHappiness" for improvements (thanks NotSoGood)
- CvPlayer::canFound - Changed handling of founding on water tiles so that Python callback has final say if it is turned on
- CvPlayer::removeBuildingClass - Fixed issue with removing buildings when building class was maxed out for some mods (thanks EF)
- CvPlot::doImprovement - Minor efficiency improvement for existing game speed scaling fix
- CvPlot::doImprovment & CvPlot::doFeature - Now scale accoding to getVictoryDelayPercent, which is more appropriate
- CvUnitAI::AI_specialSeaTransportMissionary - Fixed minor bug in valuation for executives
- CvPlayerAI::AI_targetGold - Fixed bug causing AI to not bother with budgeting for expenses for first 40 turns of scenarios and advanced start games
- CvCity::init - Reverted to standard BTS code where floodplains are removed when a city is founded
- CvCity::kill - Replace floodplain after city is destroyed
- CvTeam::doTurn - Added barbarian passive tech fix from Mongoose SDK
- CvPlayerAI::AI_changePeacetimeTradeValue and CvPlayerAI::AI_changePeacetimeGrantValue - AIs you haven't met yet will no longer get angry at you for trading with their worst enemy (thanks Sephi)
- CvPlayerAI::AI_getStrategyHash - Fixed several bugs where player ID was used where team ID was intended
- CvPlayerAI::AI_targetCityValue - Fixed issues with valuation of cities with inactive world wonders, multi-holy-cities
- CvCity - Added function getNumActiveWorldWonders()
- CvPlayerAI::AI_commerceWeight - Improved valuation of generating culture in human player cities when culture bar is > 50% (ie, player probably going for cultural victory)
- CyInfoInterface1 - Added missing CvUnitInfo::isOnlyDefensive (thanks Afforess)
- CvCityAI::AI_calculateCulturePressure and CvCityAI::AI_playerCloseness - Fixed incorrect usage of getID() (thanks denev)
- CvPlayerAI::AI_foundValue - Added missing division for iClaimThrehsold (thanks denev)
- CvTeam::shareCounters - Fixed bug causing inappropriate overflow research and effectively free techs when forming a Permanent Alliance
- CIV4GameText_Events_BTS.xml - Fixed Italian translation for TXT_KEY_EVENTTRIGGER_MOTOR_OIL and usage of Amun-Re (thanks jsbrigo)
- Popup.py - Fixed X versus iX in addPythonButtonXY(), and (maybe) fixed reference to non-existent variable in addTitleData() (thanks EF)
- CvCity::getProductionModifier (three versions of this function) - Changed to allow mods to create negative production modifiers (thanks NotSoGood)
- CvUnit::rangeStrike - Fixed bug with determining if can range strike, and potential OOS from range strikes (thanks God-Emperor)
- CvUnit::canRangeStrikeAt - Added check for whether target plot is visible (thanks God-Emperor)

 

[Roland Johansen]

I love it that you keep bug fixing this game. There don't seem to be a lot of serious bugs left by now. These seem to be the kind of bugs which are noticed only when someone is digging through the code and can't make sense of some part of it. Your BetterAI mod is more and more becoming a logical extension of the Unofficial Patch.

 

[MadmanAtW]

- CvPlayerAI::AI_changePeacetimeTradeValue and CvPlayerAI::AI_changePeacetimeGrantValue - AIs you haven't met yet will no longer get angry at you for trading with their worst enemy (thanks Sephi)

Wow, that's huge. If that means what I think it does, I'll bet TMIT is happy. (But it's quite the gameplay change... though one I am happy to see.)

 

[LunarMongoose]

Cross-quoting from the 1.3 thread:

I intend to "Fixes an annoying but harmless vanilla bug where the Load button still appears for a unit already being carried by a transport (though hitting it does nothing)."
I believe this doesn't change game rules and good for Unofficial Patch.

Already be carried unit can access to the Load button only when other loadable vassal exists in the same tile (except for in the city because you can unload units in the city.)
How do you think, everyone?

Spoiler :

bool CvUnit::canLoadUnit(const CvUnit* pUnit, const CvPlot* pPlot) const
{
	FAssert(pUnit != NULL);
	FAssert(pPlot != NULL);

	if (pUnit == this)
	{
		return false;
	}

	if (pUnit->getTeam() != getTeam())
	{
		return false;
	}

/************************************************************************************************/
/* UNOFFICIAL_PATCH                       10/30/09                     Mongoose & jdog5000      */
/*                                                                                              */
/* Bugfix                                                                                       */
/************************************************************************************************/
	// From Mongoose SDK
	if (isCargo()[COLOR="Blue"] && (pPlot->isCity(true) || getTransportUnit() == pUnit)[/COLOR])
	{
		return false;
	}
/************************************************************************************************/
/* UNOFFICIAL_PATCH                        END                                                  */
/************************************************************************************************/

Having finally had time to actually look at this problem... I know, it was three months ago sigh... What I wound up doing on my own just now is pretty much exactly what Denev did, except without the isCity condition because it's completely unnecessary; if you can move a carried unit from one transport directly into another out in the ocean, why can't you do it in a city? Sure the city allows you to unload it first and then reload it, but just because you can doesn't mean you should be forced to do that.

So my final solution is:

if (isCargo() && (getTransportUnit() == pUnit))
{
return false;
}

This does prevent the load button from appearing due to the presence of the transport that is carrying the carried unit, as intended, but does not block any other transports that are present from triggering the button, which was the problem before. So, feel free to reinstate this fix if you want to, JDog.

 

[LunarMongoose]

Also cross-quoted from the 1.3 thread:

By the way, I just noticed something odd with a quick test in-game. A unit on board a transport can pillage a fort without unloading, and the transport gets bumped onto the water along with the unit onboard! Not that I can see it realistically being abused or anything, but it gives a ship a free move.

The problem is actually slightly worse than this. Currently any carried land unit can pillage a fort from inside a transport, yes, but additionally, any carried unit with the CanMoveAllTerrain ability can pillage anything from inside a ship. I just ran a test game to be sure, and sure enough, a Helicopter as cargo inside a Transport can pillage Fishing Nets in water tiles without the Transport having to do anything. I have added the very simple fix:

if (isCargo())
{
return false;
}

near the top of "CvUnit::canPillage()", and unlike with the load button issue, I can't see how this same code could possibly cause any unintended consequences this time lol.

 

[jdog5000]

Thanks LM, those both look good.