Back to Wargamer Home Page
Back to top
|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"|
Back to top
|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