This is the Bug List - current as of Jan 1, 2005 (v40)
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)
X172 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)
-173 (Alms) I don't see it in the list so, could we fix the bug where specials don't get drawn after they get buried by fog of war? This is really apparent in dawn, with the wheat and horses disappearing after you move away from those tiles.
Mark: I see the wheat just fine through the fog. Anyone else not see it?
-174 (Alms 16) Can we add some extra black space at the bottom and right hand sides of the display map? The scroll bar cuts off the bottom half of the bottom row of tiles which makes them difficult to select, and for some reason the last column of tiles on the right is difficult to select. I often end up clicking the mouse 3 or more times to get a unit's move path set there. I assume it's a display problem. Anyone else have this? (Mark doesn’t have this problem)
-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