This is the Bug List - current as of Dec 19, 2004 (v38)
I have assigned priorities to all bug and small feature requsts they are noted in square brackets at the end of each item. Feel free to question my priorities. If there is enough clamor that something I rate low is of high importance, I'll change it...
Most outstanding bugs are minor and will be addressed within the next few releases. I have eliminated many old bug reports that I personally haven’t seen in a long time. If someone sees a previous bug that I’ve gotten rid of, please let me know. All bugs have a ‘-‘ prefix to distinguish them from the small feature requests, which have a ‘f’ prefix.
An 'X' in front of an item means it has been fixed/addressed. Usually the X items are left for a while in case the same issue comes up (the implementation may not have worked completely).
I have put the newer bugs at the top of the file, and relegated the older ones to the bottom. Note that there is also now a web-based bug reporting system. I will try and transcribed the bugs reported there to here also, so that we can have one-stop shopping. The web site is at http://www.vovan.net/bugzilla/. I will usually omit stack traces and such for the errors already reported at bugzilla
Numerous bugs have been found by alms and others, and many of them have already been fixed by Laurent. If you see a bug reported in one of the demo eight or scenario threads that is not here and seems important, please report it to me, ideally in the format below.
[D8 Medium priority]
-170 (bugzilla bug 4) - mini map
In playing around with the testbed today, trying to find the map size that would fill the entire minimap screen, I discovered that generating a map larger than:
causes a problem with the minimap as seen in the attatched image. I didn't go further to test whether it was the width or the height because, as you may have noticed, I was trying to keep the map square.
-171 Econ bug - social
at java.util.AbstractList$Itr.checkForComodification( AbstractList.java:444)
at java.util.AbstractList$Itr.next(AbstractList.java: 417)
at game.economics.Economics.allEconomicsTurns(Economi cs.java:98)
-172 In the process of looking through the code, I discovered another problem In SquareClass summarized below:
* @todo this method assumes kapital level per population is 1 and hat
* population in the new square will equal average for the civ. Both of
* these assumptions can produce very inaccurate results. (Mark)
public float getPotentialEconomicValue(Civilization civ)
X172 Delenda EncounterManager bug – during active combat and units moving through each other.
at game.military.EncounterManager.meet(EncounterManag er.java:152)
at game.ai.FightSimulation.simulate(FightSimulation.j ava:88)
at game.movement.orders.MovementOrder$SingleMovement. checkImmediateDestination(MovementOrder.java:434)
at game.movement.orders.MovementOrder$SingleMovement. carryOut(MovementOrder.java:268)
at game.movement.CollisionManager.execute(CollisionMa nager.java:209)
at game.movement.CollisionManager.mediate(CollisionMa nager.java:128)
Laurent: I don't really understand how this can happen, apparently I'm passed an empty list of units somewhere but that seems checked. I made a quick fix to return before because if there is no opponent civ, then the attacker should be victor.
So this shouldn't happen again, but it is a bit strange.
X174 (Mark) I haven't been able to get the victory message for either the Delenda or Attila scenarios. Something must be wrong in either the XML or code on extermination victories.
X175 (Mark) there appears to be a bug when a province changes hands due to the capital being conquered. In the new conquered province, the capital ends up being moved to some little square off to the side somewhere, rather than the former capital city. I had a case in the social scenario where the Persians conquered some little side square in Asia minor and flipped the whole province because it had become the capital unbeknownst to me. It was also a bit odd because I had troops in the former capital, and I thought the whole province wouldn't flipped if there were still defending units.
First square conquered in an existing province becomes the new capital. Unless conqueror switches it back to the original capital, it will remain in the first square conquered.
X176 ACME bug (Mark) 20+ turns in, a lot was happening, no idea what special happened that turn.
at game.economics.SquareEconomy.calculateProductionIn AllSectors(SquareEconomy.java:265)
at game.economics.SquareEconomy.economicsTurn(SquareE conomy.java:213)
at game.geography.SquareClass.economicsTurn(SquareCla ss.java:255)
at game.population.Migration.colonize(Migration.java: 286)
at game.population.Migration.carryOut(Migration.java: 251)
at game.population.PopulationTurn.migration(Populatio nTurn.java:78)
It was caused by a SquareEconomy without a PrivateSector. Maybe due to initial population of 0, which results in no creation of PrivateSector. Seemed from the code that this shouldn’t happen though. I put in a patch and diagnostic message to try and figure out why this happened.
-177 (Mark) Attila scenario -- the Huns can't build military units (even as player). They can't build anything, even warriors. Huns can build other stuff like roads, so it is something in the isBuildable chain of stuff for military units at a guess.
-55. When there are too many enemy TFs on a square, right-click does not produce a pop-up window with the details. I noticed this when I let the AI grow huge armies (by turn 80). By that time also the power circle of those mega-concentrations vanishes, cause it's too large and it gets buried under tiles further away which are probably refreshed after that. [don’t know if this is still a problem, low priority, D8]
-116 When econ orders frame comes up first the many little text areas appear with no frame around them then the rest appears. Not critical, but any ideas how to fix this? It didn’t happen in D5. [low priority, that interface will hopefully be completely replaced for D8]
X159 (MacHatter on a Mac)Buttons in population transfer dialog are too narrow (text on the "transfer xxxx" button is truncated) [D8]
-160 (MacHatter on a Mac) Path finding problems-units don't use roads, even if it would be quicker
TF at 11,12 goal is 5,8
Road from 7,14-5,11-5,9
Default path (5 turn)
better path(4 turn)
TF at 3,12, goal is 7,14
Road from 4,12-5,12-5,11-7,14 (arrives 2 (first))
Default path (arrives 2 (2 turn 2 markers))
Better path (2 turn, (1 turn 2 marker))
(Mark says) not sure if this one is really a movement bug. There is a bug, but it may be in the little red circles that show turn numbers. I duplicated the results posted by Andy, and verified by pgrignon, but they Don't Match actual movement times, which are 5 turns in either case. [med D8]
-163 (Mark) Triremes not on build list in Delenda, neither is the cavalry unit Hannibal has [med D7.3]
X164 (Mark) When population of a square is taken away so that square pop is now 0, square doesn’t change possession when conquered. At least it appears to take special circumstances for it to be conquered, although it can happen eventually. It appears the code to change square possession is ignored if pop = 0, suggest the test become if the square has an administration it can change hands. I looked for the code, but couldn’t find it after about 15 min of looking around, so I quit. [Med D7.3]
Workaround: never remove all population from a square, just leave a few and its ok.
-166 (Heffalump/Mark) It looks like a bug has crept into the unloading menu code. Below is the way it usually works.
1. put the ship on a coastal square
2. left-click on either a ship in the carrying TF or the carried TF and select the unload option.
It looks like the bug is making those unload options not appear at first. This results in a very short set of options. A work-around is to select the transporting TF with a mouse click. This makes at least the unload option for the ship appear. Selecting the carried TF seems to make the unload option appear for those.
X167 (Heffalump) - In the Rome/Carthage scenario I retreated to Rome, made a stand and defeated Hannibal, then counterattacked north. I recaptured my northern city and pushed on. Then Carthage had it's greatest victory. I divided my 8 or 9 unit army up into multiple units, then tried to re-form it into 2 separate armys .... and it just disappeared. Gone. Oh well, that put a serious crimp in my invasion plans! (The bug seems related to one of those assign unit to TF commands).
I've played around with it a few times and as best I can tell, here's what I think happened:
In the Carthage/Rome scenario
1. Pick Carthage
2. Goto the big stack at 2,4
3. Split the big TF into seperate TFs using the respective command
4. Right click on Hannibal (which is probably the default selected unit) and click Assign Unit to New TF
We're now in a situation where none of the Units are "selected" but the commands to do things like Add Unit to Selected TF are still visible. Use that command on a unit (without "selecting" any units) and you'll see it disappear into space.
Similarly, right click on a unit and do "Merge units into selected TF" and they will all disappear.
Command line switches (Must be in command line mode (FE batch file) to use):
-ef = error logging to a file
-noAI = no AI movement
-seed = random numbers use constant seed for reproducible behavior
-800x600 = start in 800 x 600 res mode to simulate 800x600 screen
-allecon = allows access to economic orders/info for non-player civs
-nopatrol switches off patrolling in addition to militia. “Patrolling” lets militia be formed for defenders even if a square is empty of friendy units, and militia will help in the order: Those who discriminate less against them, those whose preferred ethnicity they are, the defenders.
Full information on command line switch usage is in the testbed readme file
[edit, some new bugs and bug fixes]