Changes Made to Wargamer

Back to Wargamer Home Page

Versions

Version in CVS

Back to top

Date Author Summary Description
November 2002 Steven Green Code tidying Code now compiles and runs with Dev Studio .NET edition. It should also still work with Visual C++ version 6.0
November 2002 Tim Carne (quartermaster) Battle Editor

Essentially changes in Battle editor

When you add a new CP at division level the CP is available to add SP to.

(Technical note- InitUnitTypeFlags calls a routine SetFled which in turn sets active to false for any divisional CP with no SP. This has been circumvented by a function InitEditUnitTypeFlags which is just a rework of initUnitTypeFlags with the call to setFled removed).

Editing Reinforcements. When you clear reinforcements by clearing the check box for the reinforcement CP the CP properly returns to the OB tree and can be edited. When the file is saved all reinforcements (checked by the reinforcement box) are again set as inactive (active = false).

Technical note. Reinforcements are set as active=false when the OB is loaded into a game or editor by virtue of the CP having an entry on the reinforcement list. When the reinforcement check box is cleared the unit is set active=true so it can be edited. It remains true until the file is saved when the reinforcement list is again checked and any reinforcements are properly set active = false. Ideally reinforcements should have the value of active set and reset as the check box is cleared or set – this will have to wait till a later release.

Deleting CP and SP. No changes made yet but there is obviously something wrong – you get a failure in the edit in an inconsistent fashion when a CP is deleted. You are advised to delete the SP first and then the empty CP as a workaround.

25Nov2001 Steven Green Battle Editor:OOB load The battle hexmap is updated after loading the OOB, so newly loaded units are displayed
25Nov2001 Steven Green Battle AI messages Battle AI's message queues was leaving dangling references to leaders
25Nov2001 Steven Green Battle OB cleanup Due to a fault in earlier versions of the battle editor, many of the battle files have got orphaned units in them, which are now causing reference count errors because of mutual pointers. Wrote function to detect such units and delete them.
25Nov2001 Steven Green PathFind compiler warnings Converted char[] into an enumeration type to remove compiler warnings and make the code a bit neater.
25Nov2001 Steven Green Battle OB Loading The Generic part of the OB was not being loaded and saved when doing load/save OOB in the editor
25Nov2001 Steven Green Battle Editor File dialogs Code was using raw Windows functions to do open/save of OOB and map. Changed it to use the classes that load/save game use which avoid problem of current directory changing and are wrapped into easy to use C++ class
25Nov2001 Steven Green Battle Map units reference counted Changed HexMap to use reference counted units. Avoids problem of deleted units trying to be redrawn when using the battle editor. Unfortunately this had now caused a major problem with the editor when trying to remove BattleSPs.
25Nov2001 Steven Green Battle Order of Battle loading Changed BattleCPList to hold Reference pointed units instead of copying them. This fixes a bug with loading OBs into the editor and also unpredictable values when loading some of the battles.
24Nov2001 Steven Green Battle Movement - changing formation Bug in code that worked out which direction to face, which could have caused a crash... or unpredictable movement
24Nov2001 Steven Green Battle AI message queue bug Message queue's pop() was using an invalid iterator causing an exception. Also removed faulty obsolete thread-locking of message
24Nov2001 Steven Green Battle Game Sound bugs The Battle Game sound system did not initialize itself correctly leaving many variables undefined leading to unpredictable behaviour. I also took the opportunity to change the member variables to suit the project's normal programming style. Also some over-enthusiastic error checking was preventing sounds from being played most of the time!
24Nov2001 Steven Green Working out current directory Code to set the current directory to where the game was installed was updated to use GetCommandLine instead of looking for "wargamer.exe"

Version 1.2.0

Back to top

Date Author Summary Description
11Aug2001 Steven Green Release First open-source version, 1.2.0
28Jul2001 Steven Green Battlegame: Unit Info window crashed StringID was being passed to wsprintf instead of a char* I don't see how this could have ever worked!!!
28Jul2001 Steven Green BattleMessageQueue not threadsafe Added thread locking
29Jul2001 Steven Green Tidied up CEdit After fixing find town edit problem yesterday, decided to rewrite the Custom Edit box and find dialog to use strings instead of the error-prone buffer allocation strategy.
28Jul2001 Steven Green GenericCP reference count non-zero and contains CampaignInfo at exit Investigating problem... it is AI's side
28Jul2001 Steven Green About Dialog didn't appear Microsoft Resource Compiler slightly different than Watcom when defining resource types by name instead of a number. MS leaves quotes in whereas Watcom strips them out.
28Jul2001 Steven Green Text Colours in Town/Unit Info Windows were unreadable DCHolderBase was leaving member unitialised leading to undefined behaviour. Partly due to DevStudio not implementing T() correctly for fundamental types in template constructors
28Jul2001 Steven Green Crash when running low on resource DCHolder was throwing uncaught exception resulting in non-predictable state of town display. Temporary fix was to ignore the errors, and let windows muddle on as best it can, which is possibly better than crashing or quitting. A better solution may be to change the town display start/endDisplay() mechanism to cope with exceptions being thrown.
28Jul2001 Steven Green Find Town Dialog Crashed Program Custom Edit Box was using passing null pointer to strlen.
28Jul2001 Steven Green Debug Windows infinite recursion on closedown Log Windows called LogWinPtr::clear() in onDestroy() which deleted it. Deleting it had the side effect of destroying the window again leading to infinite recursion and a stack overflow. Fixed it by removing the strange mechanism where the window had a pointer to the pointer.
28Jul2001 Steven Green Despatcher Deadlock problem Found deadlock situation when AI tried to send orders while the logic was in the middle of processing existing orders. AI had some data locked for reading, but message despatcher wanted to write to it and both were waiting for each other. Changed GDespatch to use STL list, and does not have the list locked whilst executing an order.

Back to top