Notes on progress in the program code

To do list for Gary

D7.1 is complete except for the immediate bugs

Known immediate bugs, all urgent

Power circles and power bars have become tiny.

Main scheduled targets

Design and implement a better economics gui. There should be a one step way of getting to ordering units, roads, etc. The various bits should be voluntary and modal, particularly the "info" panel.
Refactor economics with Mark. This is gettting to be a very high priority, and perhaps should precede D7.1. One of the problems is that the economics acts as though it is the central driving mechanism for the whole program, rather than just another service like the social model. This impacts seriously on just about everything that happens in the rest of the code.
Attila is far too slow in operation, must track that down and fix. Placed here in case it is dependent on the economics refactoring.
Save and restore games. Becoming more important now that games are stretching to 100 moves. Will make debugging a whole lot easier since the game can be saved just before the bug occurs.
Move toward internationalization. This is important to me for very good reasons.
Finish social model code
Design and build technology GUI
Start on AI code

Miscellaneous improvements to be fitted in

The present way of determining a square to build a naval unit on is quite shaky (my fault, I did a bit of a quick and dirty - provided a prespecified main port). What is needed in this area is
  • A means of setting a different port square.
  • A means of getting another port if the port is captured. There are issues here (which also apply to capitals) about whether the port should revert if the previous port is recaptured.
  • A means of creating a port when a province spontaneously expands to reach the coast.
I do not think that units should be build in the most populated square if there is no capital (or port). If there is no capital (or port) the unit should not be buildable. This is how the code works now.
There is a really bizarre series of isCoastal() method calls in economics. They are quite badly misplaced and the code is weird. They cause crashes in Attila. The economics package appears to feel that is its responsibility to differentiate between different kinds of buildable objects, and so has a number of essentially illegal classes called GovtEconOrdersInfoForArmyUnit, GovtEconOrdersInfoForMilitary, GovtEconOrdersInfoForNavyUnit. These need to be removed. There is absolutely no need for the accountants to know that an ordered unit is a ship (or for that matter an army or a statue to the King). It seems to me that this is partly due to the InfrastructureInfo class is being tortured far beyond its actual function. A trireme is a boat, not an Infrastructure.
The present system actually builds everything at the square level (why I do not know). The square then stomps all over the province to build everything at province level (only). The build distincion between civilization and province shown in the menu is apparently ignored by the code. This needs to be straightened out.
I am not very happy about the confusing way I have implemented parameters in the technology model. There are several aspects which seem to have become confused. I now envisage a better system in which:
  • The adjustment parameters (startLevel, add, multiply) will be held in an adjustment class (they are currently held in an inner class and the value calculated in the outer class in the same file - put the calculation into the adjustment class).
  • The ElementArchetype will refer only to the adjustment class - it will know nothing about the parameter class.
  • The UnitArchetype will assemble the ElementArchetypes, as it does now, but will have no knowledge of Parameters or technologies.
  • As a civilization becomes able to build a UnitArchetype it will assemble a BuildableUnit object which has a pointer to the UnitArchetype, but adds a Civilization pointer and the required parameter set. The technology dependent parameters will be held in this object. Each civilization will hold a list of these. As they become obsolete they will be so marked, and removed when there are no Unit objects referring to them. The actual parameter link will be done in this class, as will all costings. Each identical Unit will have a pointer to its corresponding BuildableUnit (there will be only one BuildableUnit instance for each unit type and civilization combination), from which it will obtain the required actual values of its parameters.
  • In deciding which units can be built, the build gui will obtain the required information from the BuildableUnitList in the Civilization, not from a global registration system, which will be removed.
  • All units will then be buidable by specific civilizations - there will be no global buildables.
The effect of all this will be a much cleaner system. The complexity of the Parameter system will be confined to a single class, the BuildableUnit class.

Since this impacts seriously on the build structure in economics, it will be done in coordination with the economics refactoring.

Refactor the social model so that there is a structure called something like Society parallel to the administrative structure, in the same fashion as Economy. This will get the social model material out of the Government class which it clutters up abominably. Try to design a good, robust, and general system for this type of structure. Use the basic premise that there is a different, but extending, interface for each level. I have in mind something like a general Hierarchy system, in which the fact that the Society and Economy classes are branches off an Administration structure is completely hidden, and the Economy and Society structures behave as though they were free-standing hierarchies.
Hot keys and keyboard only operation.
Create icons for the task bar. Not so important now I have shortened the task bar.
Put in proper diagnostics for reading in xml files, so any syntactic errors are immediately identifiable.
Put movement numbers in road-building tracks (based on current road expenditure) and check for duplicate builds.
Check to see why map is drawn twice. Checked it - it seems to be a windows thing beyond our control.
Push for universal roads, rather than directed roads.
Rivers.
Weather patterns, particularly as they relate to random maps.

Discussion points

I would like a more direct connection between manpower and health in military elements, so residual manpower is calculable, and the required reinforcements to bring the element up to strength are also easily calculated. Is there a mechanism in place at present to bring damaged units up to strength?
As something of a corollary to this, each element should have a load factor (of 1 or more) representing the extra baggage that that type of element requires, the obvious example being cavalry. That extra baggage could then affect the capacity required to carry the element, as well as, perhaps, supplies needed to support the element.
Discuss the way in which training should be implemented. My personal feeling is that training takes place after unit creation, and hence should not be part of the construction process. I rather feel that training establishments are part of the infrastructure.
Add city names to map.

History of changes

2002/07/06
  • Completed refactoring of game.military.lists and game.movement. Task forces starting in the same square will now stay together. Fixed various related minor bugs.
2002/07/07
  • Changed the image positioning so it is now calculated correctly
  • Changed all the tiles to 80x40, so image scaling on input is no longer needed. Removed tile and military tags from the images file
  • Made the town images the same size as a tile image and moved the towns to the centre of the tile
  • Moved the military image code from Units and Picture to CivilizationData
  • Fixed the bug in Delenda that caused a crash
  • Commented out the part of economics that meddled with technology (causing a crash)
  • Removed old, unused files: Mover, UnitsByCiv
2002/07/08
  • Moved map down so units in top row can be seen
  • Found cause of phantom unit in Delenda (caused by the pre-start economics turn)
  • Removed two unused constructors in Unit
  • Got wheat and horses back (forgot to change them to 80x40)
  • IsVisibleEvent, IsFoggedEvent and CivilizationSize incorporated into Dawn1, tested and working
  • EventJoin, EventUnion, EventNegativeJoin and EventNegativeUnion written
  • Fixed the Corel-produced error in the roadNW.gif file.
2002/07/09
  • Got many of the early events in dawn1 working.
2002/07/10
  • Made queue.draw synchronized to stop comodification exception.
  • Changed the way in which events are saved to avoid comodification exception.
  • Modified the population dialog to be safer and easier to understand.
  • Fixed bug in disband into individual task forces.
  • Fixed many problems with the events used in Dawn 1.
  • Debugged input problems with Victory conditions.
  • Fixed many of the bugs Laurent found (except one for Mark and the ones Laurent fixed). In particular some comodification problems and fixed up the population dialog used for colonization.
2002/07/11
  • Substantially all the event processing for Dawn 1 completed and tested.
  • First version of a random map scenario added.
  • Fixed event display so text is within the frame.
2002/07/12
  • Substantial improvements in the random map system.
  • Put back the removal of features, which had somehow disappeared.
2002/07/13
  • Various debugging of events relating to Dawn 1.
2002/07/14
  • Major refactoring - game.interfaces introduced to provide a central point of information for all packages. My ultimate aim is that no package should import anything except java/javax packages, game.libraries packages, sub packages of itself, and game.interfaces. Necessary as a step toward proper notification of technology changes. In particular:
    • Moved AI from ai to interfaces.
    • Moved Buildable from economics.infrastructure to interfaces.
    • Moved Technologies from technology to interfaces.
    • Moved Command from military.command to interfaces.
    • Moved Administration from government.administration to interfaces.
    • Moved Coordinator from management to interfaces.
    • Moved GameParameters from management to interfaces.
    • Created Cost class and put in interfaces.
    and then did a horrendous job updating all the relevant import statements.
  • Added parts to the technology system to report integer changes in level and technology activation. Made the AI respond to these.
  • Commented out the tech reporting part of Economy.
  • Moved Units.issueOrders() from Economy to TurnManager.
2002/07/15
  • Refactored movement in preparation for sea movement.
  • Changed the tech level reporting to be multiples of 0.1
2002/07/16
  • Got sea movement going.
  • Add rename units and task forces option.
2002/07/17
  • Fixed bug displaying military attitude.
  • Fixed bug from false move drawing.
  • Fixed bug that stopped some orders from being executed (so now Hannibal moves).
  • Fixed bug showing wagon in TF box.
  • Refactored orders system so the only orders executed are TF level orders. Unit orders will be ignored, and higher level orders are not yet implemented. Made order creation and execution driven through the command structure rather than by geography (that is, by square).
  • Refactored Units so square data is built from task forces (rather than individual units). This will probably make the unit list redundant, but does seem to slow the game down a lot. On the other hand, the unit movement is now animated!
  • Shortened the Civilization in the detail box to just the name (no description).
2002/07/18
  • Fixed bug in merging task forces.
  • Fixed bug in destroying task forces.
  • Shortened civilization name in status bar.
  • Matched the event turn number to the displayed turn number.
  • Technology events display properly. I can't do anything about the very tiny increments provided by the economics model, however, combat works.
2002/07/19
  • Removed a lot of no longer used code from Units, UnitsBySquare, SquareData, and CivilizationData. Pushed some loops further down to make foreign iterators unnecessary.
  • Made sure that naval units, coastal units and land units cannot be put into the same task force. Also made sure that ships are on the same side of an isthmus.
  • Added a toolbar button which lists (rather crudely) the technologies, their levels (for the Player), and their active/inactive status.
2002/07/20
  • Removed some more obsolete code from Command and its implementations.
  • Modified Unit and MovementData to accommodate the boarding gui.
  • In dawn1, made horses helped by Farming, and made Domestication activity contribute to Farming as well. Put a comment in the bulletins mentioning the Technologies button. Gave a <giveresearch> for wheat and horses.
  • Added a <negative> tag to all events, if set this reverses the condition test. Edited dataformat.html to reflect this. Used it to tidy part of the dawn1.xml file.
  • Made the last part of dawn1 event driven (by adding TechnologyEvent). Edited dataformat.html to reflect this.
  • Tidied up MapInputMode right mouse click. Made a right mouse click in road building mode cancel all planned roads. Made a comment to this effect in dawn1.
  • Added a game setting to suppress showing of all bulletins. They still appear on the bulletin list. For testing purposes, setting fog of war, hidden map and show bulletins to off helps.
2002/07/21
  • Fixed bug in bulletins so the list of bulletins works even if they are set to not show.
  • Tidied up combat output and added orders and collisions to it.
  • Changed dawn1.xml as follows:
    • Added civilization tag to wheat event, so give research will work.
    • Removed enable technology tag.
    • Put big barbarians horde back to 4 units (I had changed it 6).
  • Added return button to scenario list.
  • Added <supplyamount> to BuildingOrders.
  • Changed AI move orders so that if the order cannot be carried out (because of no citiesfor example) it is replaced by MoveToNearestSquare.
2002/07/22
  • A complete refactoring of the military command structure (which has been offending me for some time). This involved the following:
    • Reduced the command classes to TaskForceCommand, ArmyCommand and HighCommandClass. This meant eliminating CommandLevel1 completely, replacing CommandLevel2 by TaskForceCommand, replacing CommandLevel3, 4 and 5 by ArmyCommand, and moving HighCommand down a level to replace CommandLevel6. Although there is nothing in the future to prevent in introduction of more intermediate ArmyCommand levels (such as ArmyGroup or Front) this is not implemented, since there is no corresponding gui available.
    • Matched each with a game.interfaces interface (TaskForce, Army and HighCommand) and removed "import game.military.command.*" from 54 classes, after changing the calls to use the interfaces.
    • Removed several methods that are no longer used, and sorted the rest between the various levels (rather than forcing all to have every method, however inappropriate).
    • Automatic names are now:
      • For units, the name of the archetype.
      • For task forces, "1st TF", "2nd TF" and so forth.
      • For armies, "1st Army", "2nd Army", and so forth.
      • For high commands, "High Command".
    • Removed <nameindex> from all the scenario files.
    • Made a task force forced to be in a single square.
    • Made the task force level the only command level to hold orders. Although not currently implemented, the intention is that any orders issued at the army or high command levels will be duplicated for each task force, and held separately, since they will be carried out separately.
    • Made the movement orders only accept a task force as their command.
    • Made the path system only apply to task forces.
    • Removed the location (that is, square and lastSquare) data from game.military.MovementData, and put it in TaskForceCommand, changing "lastSquare" to "previousSquare" because of the the ambiguity of the Englist word "last". Also moved "ticks" and its accessors to MovementOrder, since that is what controls it. Took the square parameter out of the constructor for units. Setting the square is not entirely elegant at present. I will think of ways to tidy it up. The idea of all this is to have the location in just one place, not duplicated in every unit in a task force (which leads to possible prolems if they get out of synch). I strongly believe that data should be stored in one place only. It also simplifies the code.
    • Got rid of the army class in game.scenario.
    • Made the sequence of setters for xml input consistent and complete.
    • Changed all the xml scenario files to have a <unit> within <taskforce> within <army> within <highcommand> within <civilization>.
    • Tested all this.
  • Made unselectable civilizations not appear in the civilization list.
2002/07/23
  • Made a few structural changes to tidy up the creation of units:
    • Added a population cost to the Cost class.
    • Changed MapSquareEconomy to reduce the population (rather than UnitArchetype). Removed the population manipulation code from UnitArchetype.
    • Changed MapSquareEconomy so that if there isn't enough population, the build fails.
    • Changed AI so it is notified if a build fails because of population limits.
    • Removed the addToSuperior method from PopulationData.
    • Added a boolean removePopulation(float population) method to Administration, and implemented in MapSquareAdministration and AreaAdministration, with various safeguards.
    • Added two createUnit methods to Coordinator which use the buildable interface in UnitArchetype, rather than using the constructor in Unit to create new units. Changed all new Unit() calls to use this (except the confusing ones in the various test classes). If it weren't for the test ones I would have made the Unit constructor package private. Both of the Coordinator.createUnit methods have archetypeName as a parameter. One has civilization and square as the other parameters, and the other has an existing task force as its other parameter.
    • Removed the second Unit constructor which was used by the xml input routines and is now replaced by the Coordinator calls.
    The effect of all this is that the messy way in which unit commands and their squares were created has been completely cleaned up. This should reduce some mysterious bugs in the future. It should also completely fix the problem of the phantom Carthaginian and Roman units fighting in the sea.
  • Refactored the next TF code to be cleaner (and work properly). Moved the code to Player, and removed first(), next() and next(command) from the command interface. Added taskForceIterator() which will be used for many things in future refactoring.
  • Tidied the military AI movement to be based on task forces, not units. This should make it much faster.
  • Changed the map visibility scan to be based on task forces rather than units.
  • Got rid of all the unnecessary unitIterators (now generally replaced by taskForceIterator).
  • Make the map image be, correctly, the map task force image with the greatest cumulative attack strength, rather than the commonest.
2002/07/24
  • Fixed non disbanding bug.
  • Fixed bug in sorting out encounters.
  • Fixed collision bug whereby units that got to the square boundary did not get their orders cancelled. Checked collisions generally, and they work correctly. The problem is in the retreat system in combat.
  • Dawn 1 moved to top position on scenario list.
2002/07/25
  • Fixed the bug preventing splitting one unit to a new TF.
  • Changed the Dawn file to have victory conditions. Added "destroy the northern barbarians" to the victory conditions, otherwise the game will usually end before the big barbarian group appears. Made the population requirement 100,000 (rather than 30,000). Made the time limit 200 turns.
  • Added a startup bulletin giving the victory conditions for dawn 1.
  • Completely refactored the victory conditions, simplified them to allow only a single condition to determine victory or defeat. Removed the elaborate victory condition structure completely.
  • Added the necessary victory specifications to dawn 1 and tested them.
  • Simplified the Condition class (deleted condition set and condition group).
  • Changed combat retreat so that a unit can only retreat once.
2002/07/26
  • Confusion between Unit and Command over who kills a task force fixed up.
  • When an element died, its health was not set to zero, so it kept dying over and over. Now fixed.
  • Combat log file output tidied up, and collision and movement and unit and command destruction information added.
  • When a task force does not have a name, the name of the civilization is used.
  • Technology dialog made model, and the numbers in it truncated.
  • Fixed deadlock bug when troops are trying to exchange.
  • Incorporated Laurent's fixes into main code.
  • Fixed an exception that occurred when a non-number or blank is enetered into the settlers transfer field.
2002/07/27
  • Made the selected task force persistent after settlers have been dropped or loaded.
  • Removed the information frame (which has been sitting there, invisible, all along).
  • Commented out the addNotify methods in the economics gui. This stopped the frames growing in size all the time.
  • If a square, part of the civilization, is depopulated by accidentally loading all the population onto a unit, the economics crashes. Fixed this by putting in a try catch block around the string to float conversion. This will go anyway when the economics are refactored.
  • Changed "no funds allocated" to "no funds available"
  • Fixed scroll bars in TF box.
  • Laurent has fixed the automatic naming bug.
  • Fixed the sizing of the TF box, so more than two single unit TFs appear in a row.
2002/07/28
  • Changed the road building cost so desert roads are expensive and the A* algorithm doesn't build desert roads for preference.
  • Slightly modified movement costs so that a diagonal road movement is quicker than an orthogonal flat terrain movement.
  • Fixed ship movement bug.
  • Made desert uncolonizable (by setting food to zero).
  • Made colonization preference depend on distance (giving a slight advantage to orthogonal squares) and road connection (a 20% advantage).
  • Disabled right click on map producing the task force popup. It had led to me doing too many silly things with settlers. I will produce a proper map popup after D7.
  • Put "Display events" into the options menu and changed "All views" to "Views". Moved "Ruler" over with the others (thus saving one separator). Changed "Economics" to "Econ." and "Technologies" to "Tech.". Much as I hate abbreviations, these will do until we have icons there. Added a separator before "Views" (thus unsaving the separator). All this shortens the toolbar quite a bit.
  • Removed the "by far the largest force" comment from Dawn 1. Every time I play, that statement is incorrect because the Northern Barbarians first lot arrives first.
  • Expanded the victory message in Dawn 1.
  • Fixed event panels so they show up from the views menu and also from the Next and Previous buttons.
  • Made the spread of population consistent, so -seed ensures the same squares each time (always starts with the northeast one, unless some random number is called before that happens, like in a fight with the Nomads).
  • Began a saverestore.html file as a design start toward the save/restore system.
  • Removed the dunes square from Delenda. It added nothing to the game.
  • Changed SquareData and MapSquareAdministration so that empty squares cannot be owned, and squares that become depopulated are detached from their civilization. As a consequence, changed Administration so the superior is always AreaAdministration (which it always is anyway).
2002/07/29
  • Fixed the details and task force scroll bars (thank heavens!). Also learned exactly what was wrong, so next time I know what to do. It needs a setPreferredSize in the constructor of the inner panel.
  • Cleaned up the details panel.
  • Fixed the non-appearing capitals in Delenda. Removed the bandaid from MapSquareEconomy.
  • Removed farms and resources from coastal squares.
2002/07/31
  • The economics model arbitrarily manipulates a square at 5, 5, for completely unknown and undocumented reasons. Commented out line 129 of MapSquareEconomy to prevent the resultant crash.
  • Refactored the military gui, to allow darkening of carried task forces. This was a very big job.
  • Added code to load and unload task forces. There is no size check at this point. As a result a single trireme could carry the entire Cathaginian army.
  • Changed TaskForcePopup so that only permitted operations appear in the menu.
2002/08/01
  • Finished all load/unload code. Loaded units are now only moved by their transport and do not carry out orders. Did small test.
  • Changed the encounter list to exclude seagoing and carried units.
  • Investigated roads for scenarios, shelved as too hard, for the moment.
2002/08/02
  • Added <destroyarmies> and <controllocation> events. Required for proper victory conditions for Delenda. Documented this in dataformat. Did not modify the victory conditions in Delenda. Someone else can do that.
  • Added a roads specification to the scenario file. Documented this in dataformat. Put some roads in Delenda.
  • Added carrying capacity limitation on transport. This is currently based on one carrying unit able to carry one carried unit.
  • Added the ability to rename provinces.
2002/08/03
  • Removed all the old, unused, populationTurn methods.
  • Added a recruitment level to civilizations. Changed population cost in Cost to recruits. Implemented removeRecruits throughout. Set default recruits to 0.08 (1/12 approximately). This will require the scenarios to be tuned. However, a <recruitment> tag in the <civilization> tag allows this to be reset. Documented this in dataformat.
  • Made a carried task force appear immediately after the carrying task force in the task force box.
  • Made task forces appear in alphabetic order of name (except for carried units) in the task force box.
  • Significant improvement in the details dialog, allowing details for each unit. The file game.gui.DataDialog.java is no longer used and should be deleted.
2002/08/04
  • Fixed the bug which allowed land and sea units to be combined in a task force.
  • Fixed the bug which confused land and sea units in the encounter (and hence caused a null pointer exception if one side had only sea units).
  • Distinguished between land and sea battle encounters. Changed encounter manager to take land only. Units.getSeaEncounter() is now avaialble for sea combat.
  • Improved the layout of the detail screen to reduce the need for superfluous scroll bars.
2002/08/06
  • Removed a bunch of unnecessary population methods from MapSquare.
  • Refactored the migrations, corrected a number of bugs in it:
    • Did all population turns before any migration turns.
    • Did migrations in random order, and skipped collisions. This eliminated a southwest drift.
    and moved some economics stuff to the economics package.
  • Added social model and population model log files.
  • Removed the TurnManger class and replaced it with a Turn class which calls NewTurn then successively calls AITurn, SocialTurn, MovementTurn, EconomicsTurn, PopulationTurn, TechnologyTurn and PlayerTurn, then NextTurn. Completed the refactoring required for this.
  • Created a player package and put Player in it.
  • Added a disband unit option in task force menu, implemented this. Added a disband() method to Unit to do it.
  • Added a dispersion parameter to civilization. This is the proportion of a disbanded unit that wanders away and does not join the local population. If there is no population in the square, the whole unit disperses - you cannot colonize squares by disbanding units there. Added a <dispersion> tag to the <civilization> tag to allow dispersion to be reset. Documented this in dataformat.
2002/08/07
  • Made Civilization into an interface (along the lines of MapSquare).
  • Fixed bug in UnitArchetype allowing the building of naval units that could never put to sea.
  • Removed over 1000 unnecessary import statements.
  • Split random scenarios off from normal scenarios (as separate buttons in the first menu) and added a couple of new random scenarios, not very different from the old one, yet...
  • Added scenario name to Clash window title.
2002/08/08
  • Got sick of typing MapSquare all the time, so changed them all to Square (so MapSquare, MapSquareClass, MapSquareAdmininstration and MapSquareEconomy are now, respectively, Square, SquareClass, SquareAdministrtaion and SquareEconomy). Had a bit of trouble with CombatReports which had an inner class called Square (created by me). Fixed that.
  • Moved combat reports analysis to AI. This will allow the computer civilizations AI to study them.
  • Added a small popup menu for a map right click.
  • If, on the map, a square is right clicked, and the right button held down, the task force and details frames switch to the clicked square until the button is released, when they revert to the normal selected square. This is quite useful.
  • Fixed bug that stopped road cursor showing.
  • Made move orders cumulative - you can keep clicking for a TF.
  • Made a right click change the selected square while in movement or road building mode.
2002/08/09
  • Made Unit into an interface. All references to the Element class are now confined to the military model.
2002/08/10
  • Extended the administration interface to include Government, ProvinceAdministration, AreaAdministration and SquareAdministration as interfaces.
  • Fixed small sizing bug in event display.
  • Hid CombatData from everything outside the military package by adding a getAttackStrength() method to Command - this is the only thing used elsewhere (for power circle, and deciding on encounters).
  • Cleaned up combat reports. Put a single CombatReport interface into the interfaces so various things do not need to knoaw about the military package.
2002/08/12
  • Substantially modified the end of game tests so the game will end correctly in "Computer only" mode, or at least would if the AI allowed it.
  • Changed the road modifer in migration so that a diagonal square with a road is preferred to an orthogonal square without. Ribbon development rules OK!
  • Finally allowed my frustration to get the better of me and changed every reference to getCiv() to getCivilization() throughout the system.
  • Attempted to fix the bug: "Exception in settlement part of economics in Delenda. Doesn't happen in Dawn which doesn't have any null squares." but it is deep in the economics package and relates to a null resources sector. Put a System.out message to show it happening and left it at that.
  • Cannot reproduce this one: "Exception in getting map image in some as yet unidentified circumstances in Dawn 1." so I have removed it from the list at the top of this document, hoping that it has been accidentally fixed.
  • "When a unit moves through a target square, without stopping there at the end of its move orders, the visit does not trigger the event. This has implications that make it non-trivial." Decided to convert this from a bug to a feature.
  • Consolidated the MapFrame, OverviewMapFrame, TaskForceFrame and DetailFrame view displays under the control of GUIManager, all accessed through the Coordinator, and each set up by a separate thread.
  • Minor tidy up of some aspects of Migration.
2002/08/13
  • Corrected dataformat documentation for province.
  • Added main port (works pretty much like capital) to the province input. Documented this in dataformat.
  • Changed the buildable interface to remove isBuildable and replace it with buildSquare(Administration administration) which will return a null square if the unit is not buildable in that province.
  • Fixed bug in PopulationData that did not remove migrated population.
  • Improved detail display:
    • Added personnel figure to task force details.
    • Truncated the personnel figures to integers in the details display.
  • Added ports to delenda.xml.
  • Refactored parts of the element/unit code to make costs work with manpower at the unit level. In doing this, made ElementCost extend Cost, and added add() and multiply() methods to Cost.
2002/08/14
  • Removed the player economic and merchant reports from Economics and placed them in PalyerAI. Added a small number of accessors to CivEconomy to avoid having horrible method names in PlayerAI.
  • Removed references to Player from Units, UnitsBySquare and SquareData. Moved them to TaskForcePopup.
  • Other small tidyups have now removed Player.getCivilization() from all the places it should not be.
  • Changed MapPopup to show the administration popup directly.
  • "Fix bug in economics which makes all scenarios currently crash." Put in hack at line 140, Economy.java to stop this.
2002/08/18
  • Changed city names in Delenda.