Shannon V. OKeets
Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
|
quote:
ORIGINAL: David Clark
I'm agnostic about the value of a "known bugs list", but I definitely see the value of a "known, current bugs with work-arounds" list. For example, Steve improperly implemented a MDI, so people are constantly getting pop-up windows hidden behind other forms. The solution for this problem is straightforward, but the fact that we're still getting bug reports for it indicates that people don't know the workaround. So:
- Matrix should, at a minimum, contract a well-respected beta tester to produce and maintain a "Current known bugs and their workarounds" document, which would be stickied in the forums. This would be a paid contract position, the exact details of which would be left to people better-informed about the scale of the problem.
While I'm at it, I might as well suggest the obvious minimal steps that could be done to improve software quality:
- Matrix should contract a Delphi programmer to provide a unit test suite, covering at a functional-level 100% of all non-UI code in the codebase. Regression bugs have been a constant problem in this application. A robust testing suite could be implemented by a intern-level coder using DUnitX, and much of this process could be automated. A pre-build testing pass would ensure that previously-working functions were not changed by new updates, and would take a lot of pressure off of Steve, who could focus on new features. Again, this wouldn't require an experienced Delphi developer; function-level unit test creation is typically assigned to entry-level people as it doesn't require any domain knowledge or skill.
- A moratorium on toolchain upgrades is a no-brainer. No serious developer should change their compiler version in the midst of debugging a complex project. Deciding to take over maintenance of four upstream libraries is similarly problematic. A more professional approach to the problem would not just result in higher-quality releases to the public, but less workload and stress for the developer.
None of this really matters to me that much - I viewed the $120 I spent on the game as a sort of charitable donation to Steve, who's living that vanity-project dream that those of us stuck developing other peoples' software for a living fantasize about - if he's enjoyed the process, that's enough for me. It's tough to watch such evident frustration though, when the solutions are straightforward. This isn't the first time a software project has collapsed due to a solo developer getting in over his head, and there are ways out of the hole.
I only upgraded the compiler (from 2010 to 2015) because I had no real choice. My old computer system was fried.
690,000+ lines of source code. 427 modules. 400+ Object Classes. 350+ forms. In my opinion, detailed unit testing of this much code is a fantasy. There are simply too many interactions: 152 phases/subphases/sub-subphases/digressions, 58 optional rules, 64 unit types, 252 'countries'. The number of special rules is seriously insane.
I spent today rewriting the description (code specifications) of the rules concerning factories. I hadn't understood the subtleties of the differences between repairing Captured and Damaged factories depending on the optional rules selected.
===
// ****************************************************************************
// Class TFactoryHex.
//
// GENERAL INFORMATION ON FACTORIES
// A FactoryHex can contain up to 3 factories. The factories in the hex are
// differentiated using an index (0-2). Red factories are always listed first
// followed by Blue and then Green. Printed factories are designated Permanent
// internally. Green factories are newly built (i.e., they are not Permanent).
// Note well that the following paragraphs about destroying, damaging, and
// repairing factories only apply if the optional rule FactoryConstruction is
// being used. The rules for repairing factories vary, depending on whether the
// optional rule ConstructionEnginneers is being used.
//
// A factory typically has no associated unit counter. Instead, the factory is
// displayed as an colored icon in the hex. This is true for all Permanent
// (Printed) and also for newly created and moved factories. At various times
// during a game, temporary unit counters are created to represent factories in
// off-map pools:
// 1 - A Production Pool (New, Repaired, or Moving factory 'reinforcements').
// 2 - The Reserve Pool (Blue or Green factories in an enemy controlled hex).
// 3 - The Repair Pool (captured/recaptured Red & damaged Red/Blue factories).
//
// There is only one meaningful difference between Blue and Green factories: a
// Blue factory that is 'destroyed' is merely Damaged, and a temporary unit
// representing the damaged factory is placed in the Repair Pool, while a
// 'destroyed' Green factory is removed from the game.
//
// BUILDING A NEW FACTORY
// Building a new factory causes a New Factory unit to be created and placed in
// a Production Pool. Once the factory arrives as a 'reinforcement', the New
// Factory unit is removed from the game and the factory icon in its arrival hex
// is modified to display a new Green factory.
//
// MOVING A FACTORY
// Moving a Blue or Green factory by rail causes a Moving Factory unit to be
// created and placed in a Production Pool. The factory icon in the departure
// hex is shown with a 'blank'. Once the factory arrives as a 'reinforcement',
// the Moving Factory unit is removed from the game and the factory icon in its
// arrival hex is modified to display an additional Blue or Green factory.
//
// Some scenarios start with the USSR having Moving Factory units in the Setup
// tray and/or a Production Pool. The USSR player can placed these factories in
// any valid city hex in the USSR. On the other hand, factories that are moved
// by a player during a game have their destinations specified by the player
// when they are first moved. Those destinations cannot be changed and the
// factory must arrive in the city hex originally chosen by the player.
//
// CAPTURING/RECAPTURING FACTORIES
// When control of a factory hex changes sides, there are 2 possibilities:
// (1) the factories are 'Captured' by the enemy, or
// (2) the factories are 'Recaptured' by the side that originally controlled it.
// For instance, Germany occupying Lille 'Captures' the factories in the hex;
// while if the Allies later occupy Lille, then they 'Recapture' the factories.
//
// Undamaged Blue and Green factories are never usable when Captured. A
// temporary factory unit is paced in the Reserve Pool for each factory. When
// the original owner retakes the hex, these factories are Recaptured and
// immediately usable.
//
// Undamaged Red Factories are immediately usable by the new owner when they are
// Captured or Recaptured, except when the optional rule ConstructionEngineers
// is being used. If that optional rule is being used, then for each undamaged
// Red factory in the hex, a TFactoryUnit is created and placed in the Repair
// Pool.
//
// Capturing or Recapturing a factory hex containing damaged factories does not
// affect the damaged factories unless they are in the process of being
// repaired. If they are being repaired, then that process is aborted and the
// damaged factory units are moved from a Production Pool to the Repair Pool.
//
// DESTROYING FACTORIES
// Factories can only be 'destroyed' if playing with the optional rule
// FactoryConstruction (which includes rules for factory destruction).
//
// There are 2 ways in which a factory can be 'destroyed':
// (1) By strategic bombing (applies to Red, Blue, and Green factories),
// (2) During the Factory Destruction phase when a major power chooses to
// destroy a Blue or Green factory using one of its land units that occupies
// the hex.
//
// If during the Factory Destruction phase a Blue or Green factory is destroyed,
// its Factory unit in the Reserve Pool is removed from the game. If a Red or
// Blue factory is 'destroyed', by either means, then it becomes 'Damaged' and a
// unit representing the damaged factory is placed in the Repair Pool.
//
// MAP DEPICTION OF CAPTURED AND DAMAGED FACTORIES
// While both Captured/Recaptured and Damaged factories are shown on the map
// with a diagonal red slash through the factory icon (indicating they are not
// usable), the text in the Main form's panel describing the factories in the
// hex is different: Captured/Recaptured factories are indicated by a 'C' and
// 'destroyed' factories are indicated with a 'D'.
//
// TEMPORARY FACTORY UNITS
// Temporary factory units are created under four circumstances, when:
// (1) a new factory is built [FactoryCreate -> RLID_UCrF -> PickFactory],
// (2) a factory is moved [FactoryCreate ...],
// (3) a factory is damaged [DamageAFactory -> RLID_FacD ->
// FactoryDamagedOnMap -> FactoryDamage ->
// PickFactory, and
// (4) an undamaged Blue or Green factory is controlled by the enemy
// [SetHexControl -> TFactoryHex.SetOwner -> PrepareMoveRemovedPool /
// PrepareMoveReservePool / PrepareMoveRepairPool / DamageAFactory ...].
//
// In all these cases the temporary factory units are placed in off-map pools so
// players can see the status of factories that are not currently usable but
// which may become usable in the future.
//
// REPAIRING FACTORIES
// When a factory hex is Recaptured, for each undamaged Blue and Green factory,
// there should be a Factory unit in the Reserve Pool. If not playing with the
// optional rule ConstructionEngineers, those units are removed from the game
// and the corresponding Blue/Green factories immediately become usable by the
// original owner.
//
// When playing with the optional rule Construction Engineers, Recaptured
// undamaged Blue and Green factories remain in the Reserve Pool until there is
// a friendly engineer in the factory's hex during the Production phase. Once
// that condition is fulfilled, the factory is repaired with zero build point
// cost and the repair is effected immediately.
//
// Repair of a Damaged (not Captured) factory in the Repair Pool is initiated
// during the Production phase by spending build points to repair the factory.
// When a factory is repaired, the Damaged Factory unit for the repaired factory
// is moved from the Repair Pool to a Production Pool to arrive as a
// reinforcement. Upon arrival, the Damaged Factory unit is removed from the
// game [ProcessReinforcement -> RLID_FcRp -> FactoryRepair] and the factory is
// shown as usable on the map (and in the Production Planning form).
//
// ****************************************************************************
_____________________________
Steve
Perfection is an elusive goal.
|
Printable Version
Known Bugs - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread