Changes in this version:


Version 1.30 changes:

- CvPlayerAI::AI_bestTech - Fixed potential rare crash bug in mods where units with no transport capacity can upgrade to units with transport capacity (thanks Afforess)
- CvGameTextMgr::getOtherRelationsString - Fixed potential issue revealing names of civs you haven't met yet (thanks Emperor Fool)
- CvCity::popOrder - Fixed issue introduced by prior attempt to fix handling of buildings with player limits. Building classes which set iMaxPlayerInstances should now work correctly regardless of what iExtraPlayerInstances is set to. (thanks ztjal)
- CvPlayerAI::AI_civicValue - Fixed crash bug in multi-player simultaneous turns games created by necessary re-timing of AI_doSplit (thanks to TheOnlyDJCat for debugging help)
- CvPlayer::canDoCivics - Same as above
- CvUnit::maxCombatStr - Handled very rare case where pointer might not be properly set when loading simultaneous turns game in hotseat
- CvPlayer::canFound - Fixed several issues for mods using the python callback to allow founding cities on water tiles (thanks Emperor Fool)
- CvPlayerAI::AI_getHealthWeight - Fixed bug for mods where civics with negative iExtraHealth were evaluated incorrectly (thanks phungus420)
- CvPlayerAI::AI_getHappinessWeight - Fixed bug for mods where civics with negative happiness effects from troops, largest cities, or war weariness were evaluated incorrectly
- CvPlayerAI::AI_civicValue - Changes so that civics valuation works properly with above changes
- CvCity::setBuildingHealthChange - Fixed several copy/paste and logic bugs affecting bonus building health from events, especially after city conquest (thanks Emperor Fool)
- CvCity::setBuildingHappyChange - Fixed several logic bugs affecting bonus building health from events, especially after city conquest
- CvPlot::doFeature - Plot feature (Forest/jungle) appearance now scales by game speed
- CvPlot::doImprovement - Bonus appearance in mines now scales by game speed
- CvAdvisorUtils.py - Blocked city liberation popup if you haven't met liberation player (reported by r_rolo1)
- CvPlayer::canTradeItem - You can now ask AI members of your own team to change religion or civics (thanks denev)
- CIV4EventTriggerInfos.xml - EVENTTRIGGER_SPY_DISCOVERED now requires you have a spy, fixes issue where event would fire with no espionage enabled and your only choice was war
- CvCity::init - Building a city on floodplains no longer removes floodplains, they'll still be there if city is destroyed (from Mongoose SDK)
- CvUnit::convert - Fixed potential issue in mods where units with transport capacity might upgrade to units without (from Mongoose SDK)
- CvUnit::canLoadUnit - Block units which are on another transport from taking on cargo of their own (from Mongoose SDK)
- CvUnit::shouldLoadOnMove - Fixed issue with all terrain land units moving onto water tiles with transports in them (from Mongoose SDK)
- CvUnit::canAirDefend - Land units which are on transports can no longer defend against air attacks (from Mongoose SDK)

Great Work Jdog! Looks great!

I'm curious about this one:


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())
{
return false;
}
/************************************************** **********************************************/
/* UNOFFICIAL_PATCH END */
/************************************************** **********************************************/

if (getCargo() > 0)
{
return false;
}


Is it always going to be the case that transports cannot be put on transports? Suppose I wanted to ... I don't know... load some APCs loaded with infantry on a water-based transport. Wouldn't this logic prevent that? Am I missing something?

This is from the Mongoose SDK mod, described as follows:

"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)."

Oh of course. I remember seeing that description.

Anyway, I suppose any modder who wants to change transports would be clever enough to alter that code so it's not a big deal.

As a consequence of the change to canLoadUnit, you can no longer make chains of transports because you cannot transfer units between transports. Some mightn't appreciate that, but I think it's a good change.

I wonder if there's any other consequences...

Great work, much appreciated. Many thanks. :worship:

I personally don't mind the changes to loadunit either, and think its the right call.

28) CvCity::setCultureLevel - Removed behavior where a city building culture would cancel order when reaching next level. Completely unnecessary for AI, human player is unlikely to be expecting this. Also appears to cause a bug with extra overflow production.


Extra overflow production bug is still available.
There is my sample code to fix it.

I do not have certainty this is best way, but I hope it may make some help.

So if I had the previous one installed and I want to update, do I simply overwrite whatever my pc asks me to or do I install the entire game all ovr again?

So if I had the previous one installed and I want to update, do I simply overwrite whatever my pc asks me to or do I install the entire game all ovr again?

Overwriting the previous installation should be fine.

I am assuming you had it installed as a mod. If you overwrote your original game files that would be a :nono: but the same advice would still apply - you'd still just need to overwrite.

As a consequence of the change to canLoadUnit, you can no longer make chains of transports because you cannot transfer units between transports. Some mightn't appreciate that, but I think it's a good change.

I wonder if there's any other consequences...

No reallocation of guided missiles and tac nukes amongst my fleet. Either to free a ship to go pick up more, or to distribute them to ships that aren't defending or attacking. Big change.

I guess moving troops off partially-loaded transports (making them defend sooner, or able to leave to pick up more units) is affected as well.

This seems like a huge naval gameplay change. While I like the idea, I don't think it belongs in the UP.

No reallocation of guided missiles and tac nukes amongst my fleet. Either to free a ship to go pick up more, or to distribute them to ships that aren't defending or attacking. Big change.

I guess moving troops off partially-loaded transports (making them defend sooner, or able to leave to pick up more units) is affected as well.

This seems like a huge naval gameplay change. While I like the idea, I don't think it belongs in the UP.
If I understand well the code , I have to agree with Elkad. The code you inserted does not make what it was intended for it to do ( block the load button for units that are in a loaded transport inside of another transport ), it simply forbids a unit that is in a transport to be loaded into another transport in the same tile. From what you said, I guess this was not what you meant to do ...

Yep, gameplay change, and should not be in the UP. I also hope it doesn't go in RevDCM (which allows gameplay changes), as this is a change I don't agree with.

Well, fortunately the sdk change you have to avoid is a very simple one, as outlined in my post above. Whether it IMO belongs in the UP or not I won't say, but it it's pretty trivial to change regardless.

I must say, that while I think many of LunarMongoose's ideas are fantastic, :mischief: the implementation is also fantastic. :p

Alright, I'll roll that one back. It sounded good, but it is not just fixing what was intended.

This is from CvCity::init


/************************************************** **********************************************/
/* UNOFFICIAL_PATCH 10/30/09 Mongoose & jdog5000 */
/* */
/* Bugfix */
/************************************************** **********************************************/
/* original bts code
if (pPlot->getFeatureType() != NO_FEATURE)
*/
// From Mongoose SDK
// Don't remove floodplains from tiles when founding city
if ((pPlot->getFeatureType() != NO_FEATURE) && (pPlot->getFeatureType() != (FeatureTypes)GC.getInfoTypeForString("FEATURE_FLOOD_PLAINS")))
/************************************************** **********************************************/
/* UNOFFICIAL_PATCH END */
/************************************************** **********************************************/


you sure you want to use GC.getInfoTypeForString and not a GC.getDefineINT for the floodplains feature?

My bad on the canLoadUnit() unintended consequences guys, and good job spotting that. I'll see if there's a better way to fix the Load button cuz it really bothers me heh. And... no need to be so harsh PieceOfMind, geez. ;)

...while I think many of LunarMongoose's ideas are fantastic the implementation of some one of them is not great. fixed. ;)

A better load button would be awesome by the way. :goodjob:

I wonder if there's any other consequences...
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?
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() && (pPlot->isCity(true) || getTransportUnit() == pUnit))
{
return false;
}
/************************************************** **********************************************/
/* UNOFFICIAL_PATCH END */
/************************************************** **********************************************/

I'm not sure I understand the logic there.

To me, it looks like you're saying if a unit is cargo and it is either on a city plot (including forts) or it is a transport then it cannot be loaded.

If I had a unit as cargo in a ship sitting in a city, it should be loadable onto another transport on the same plot.

Am I misunderstanding?

To me, it looks like you're saying if a unit is cargo and it is either on a city plot (including forts) or it is a transport then it cannot be loaded.

Exactly, I just said so.


If I had a unit as cargo in a ship sitting in a city, it should be loadable onto another transport on the same plot.

Yes, you can do it after unload the unit you want reloading to another vassal.
I intend to make exclusive between "Load button" and "Unload button", because I always confound them.
A pair of "Load" and "Unload" commands confuse me that whether the unit is already loaded onto vassal or not yet.

Ah, I see. That looks like it would work perfectly.

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.

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.

Oh boy. ... Why am I not surprised.