View Full Version : Bug fixes

The Great Apple
Apr 30, 2006, 01:48 PM
A few from the bugs forum which are most certainly bugs. Some have quite a bit of evidence behind them... some don't. None of them are that game-destroying, but, in my opinion at least, they are all worthy of being fixed.

Fixed: - loaded units staying on caravels when upped to frigates. Fixed - I think SimCutie has already got this one. ;) Fixed - Minor thing. Button states like "Show Tiles" or "Show Resources" don't seem be be sticking. Fixed - Ships getting stuck in lakes when being shifted to the nearest valid plot. Fixed - production queues being saved between games. This allows the construction of other Civ's UUs. Fixed

- Bug where increasing the number of commerceTypes would cause nasty things to happen. Fixed

The Great Apple
May 18, 2006, 02:59 PM
To be fixed: - At present, if you have more than one promotion being enabled with a tech, only the final promotion shows in the techchoser. Fix is posted on the thread... but I don't have a 1.61 version of the file so I can't do it myself. Confirmed - Rally points not working when auto-promote is on. Weird one - needs a bit more confirmation. Semi-Confirmed - Exploit where you can gift units in your ship to a friend, then use the units on the ship to invade a third Civ who your friend is at war with without him having to fight battles. Sounds plausable. Confirmed When gifting a city to somebody you have a perminent allience with your troops are bumped out of the city. They shouldn't be. Sounds plausable but Not Confirmed

May 18, 2006, 05:01 PM
Bug 1 has just been fixed by me. If you upload a transport unit with cargo to a unit which has no or less cargo space than the old one, the exceeding cargo is put to the next valid plot.


May 18, 2006, 08:37 PM
Couldn't that potentialy be used as an exploit to "throw" an invasion ground force at a land mass??

May 19, 2006, 02:10 AM
']Couldn't that potentialy be used as an exploit to "throw" an invasion ground force at a land mass??

Would be hard to do so, because you need to know what plot the function CvUnit::jumpToNearestPlot() calculates.

There are several factors :
- friendly cities, same area, own country, neutral country.

In any case, the units are never put into an enemies country.


The Great Apple
May 19, 2006, 03:21 AM
Also, when you are upgrading you have to be within your own terriatory - it's probably pretty unlikely you'll be thrown anywhere exploitable.

May 19, 2006, 04:36 PM
Another one: - Ships getting stuck in lakes when being shifted to the nearest valid plot. Should check for a sea plot before checking lake plots (can't discount lakes - won't work on a map with just lakes). Confirmed

fixed as well !

Following procedure :
- if destination plot is a lake and source plot is no lake, the probability that this plot is taken is very very low.
- if source plot is ocean and destination plot is a city, than it is checked if the city has a direct connection to the ocean. If not, the probability that this city is taken as destination plot is very very low.

To do so I added two new methods :

bool CvPlot::isOcean()
bool CvCity::isConnectedToOcean()

Both are exposed to Python, for further use in the API.

May 19, 2006, 05:14 PM - Minor thing. Button states like "Show Tiles" or "Show Resources" don't seem be be sticking. Maybe we can attach them to the saves? Confirmed
If anybody get's bored...
Fixed. Now all mini-map button state including Show Resource, Show Grid, show Tile , Show Score will be saved as User info And restored on next start. Not in game save file.

May 20, 2006, 05:09 PM
To be fixed: - production queues being saved between games. Got to find out where these are handled and wipe them when a new game is launched. Confirmed


The description above is a bit wrong, so let me first explain the problem :
When you save a production queue which contains civ specific special units and load that queue in a new game into a city which belongs to another civ those special units can be build.

This solution was a rather strange one. First I tried to find the loading/saving procedures for the production queues, but they're handled neither in the API nor in the SDK. It seems to be that they're handled by the game core, so that we don't have influence to it. Also the queues are not saved in the savegame but somewhere else in the game config.

Next I tried to find a good point were I can catch it after the loading, so that I can clean up the queue. Then I found out, that its not a problem of the queues or its loading saving functions, its a simple problem of the "canTrain" function. the CvPlayer::canTrain() function does not check for any civilization specific dependencies. The only reason why this does not effect the Main Interface is, that the Main Interface does a loop through all civilization units and not through all units.

So the solution was rather simple : I enhanced CvPlayer::canTrain() so that it also checks for civilization dependencies.

The Great Apple
May 20, 2006, 05:18 PM
Good job!

I've re-organised the first two posts to include all the ones fixed, and all the ones to be fixed. If you find any I've missed feel free to post them!

May 20, 2006, 06:12 PM
In the process of expanded the Commerce types in the game I came across and fixed a "silent" bug. Firaxis was iterating arrays with NUM_YIELD_TYPES rather then NUM_COMMERCE_TYPES in several places, as both of these are 3 in the default game nothing bad ever happened untill I incressed the number of Commerce types. The bug caused all Shrines to have a bonus of garbage data for the extracommerce types per city with its religion.

The Great Apple
Jul 18, 2006, 01:04 PM
Just fixed a bug where negative values of religion happiness would display incorrectly in the civics screen.

Jul 18, 2006, 04:33 PM
Originally found by Mongoose in the mod component forum, there's a bug in calculating first strike chance in CvUnit::getCombatUnit.

Here's the relevant section:

FAssertMsg(getCombatUnit() == NULL, "Combat Unit is not expected to be assigned");
FAssertMsg(!(plot()->isFighting()), "(plot()->isFighting()) did not return false as expected");
m_bCombatFocus = (bAttacking && !(gDLL->getInterfaceIFace()->isFocusedWidget()) && ((getOwnerINLINE() == GC.getGameINLINE().getActivePlayer()) || ((pCombatUnit->getOwnerINLINE() == GC.getGameINLINE().getActivePlayer()) && !(GC.getGameINLINE().isMPOption(MPOPTION_SIMULTANE OUS_TURNS)))));
m_combatUnit = pCombatUnit->getIDInfo();

// First strike fix START
setCombatFirstStrikes((pCombatUnit->immuneToFirstStrikes()) ? 0 : (firstStrikes() + GC.getGameINLINE().getSorenRandNum((chanceFirstStr ikes() + 1), "First Strike")));
// First strike fix END



EDIT: I've had it confirmed it's fixed in Warlords (or first patch of Warlords, not sure).