Known Bugs

World in Flames is the computer version of Australian Design Group classic board game. World In Flames is a highly detailed game covering the both Europe and Pacific Theaters of Operations during World War II. If you want grand strategy this game is for you.

Moderator: Shannon V. OKeets

User avatar
Zorachus99
Posts: 788
Joined: Fri Sep 15, 2000 8:00 am
Location: Palo Alto, CA

Known Bugs

Post by Zorachus99 »

Some people have been requesting to know if there are bugs in the current or beta versions of the game. The developer is too busy to deal with this publicly; but plenty of people have time to post the bugs that they find and are confirmed. Hopefully this will be helpful.

If you would like to post here, feel free, but please note the version you tested with to find the bug. Otherwise there is little public value.

Bugs outstanding in release 1.4.5.0 (Public release) that I know

1.4.5.0 Subs cannot intercept and initiate combat during the same impulse. They may only do either. Verified on bug list.
1.4.5.0 Advance after combat during offensive chits has issues. Reported previously, and it was claimed there was no such bug. However, if units cannot advance after combat, I'd call it a bug.
1.4.5.0 Taking additional Chinese cities generates a loop when the die roll is successful for U.S. entry.

I found these pretty quickly, I'm sure there are more that are important.
Most men can survive adversity, the true test of a man's character is power. -Abraham Lincoln
Numdydar
Posts: 3271
Joined: Fri Feb 13, 2004 9:56 pm

RE: Known Bugs

Post by Numdydar »

If you are not going to use the latest beta to describe bugs then this thread will not be of much use in my opinion. Simply because many bugs have been fixed since the last release in the betas. And to be fair new ones created :)

But describing outdated information is just going to be confusing to some people. So I would suggest to only publish bugs here as of the last beta release since that is the version that the development efforts will be continuing from.
David Clark
Posts: 39
Joined: Thu Feb 24, 2005 5:20 pm

RE: Known Bugs

Post by 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.



Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Known Bugs

Post by Shannon V. OKeets »

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.
nilssone85
Posts: 57
Joined: Fri May 29, 2015 8:52 am

RE: Known Bugs

Post by nilssone85 »

If you are not going to use the latest beta to describe bugs then this thread will not be of much use in my opinion. Simply because many bugs have been fixed since the last release in the betas. And to be fair new ones created :)

But describing outdated information is just going to be confusing to some people. So I would suggest to only publish bugs here as of the last beta release since that is the version that the development efforts will be continuing from.
I strongly disagree. Most of us are playing with the latest official release and it is in this version we are suffering the bugs. If there is a list of known bugs for the latest release we know it is identified, fixed in the latest beta or not...
Numdydar
Posts: 3271
Joined: Fri Feb 13, 2004 9:56 pm

RE: Known Bugs

Post by Numdydar »

Let me try again [:)]

If bug A is in the official release but fixed in a beta patch, how does saying bug A exists help the development team when they know it has been fixed? Also it would give the impression that in the months since the last official release nothing has been done to fix any of these. Which is totally false.

So I still do not see any value to describing bugs where a lot of them have been addressed is going to help anything. It is certainly not going to help the beta testers or Steve. Nor do I see how it will help the community. However, I am willing to listen as to why this would be a good idea as I just do not see it. Especially since there are a lot of people that post games in the tech forum about issues they have so it is not like the bugs are hidden/being secret. No commercial software I know of posts open bug lists, including games, so why is there such a demand for it here? It is not like any of us can do anything about them [:)]

I could also say that most of us are using the latest beta too [:)] versus the last official release. Neither of us has any data to prove the other one incorrect [:)] You may not want to use the beta but I always do. I use the betas but I am willing to have the minor risk of new bugs showing up versus playing with a bunch of bugs I know about. Since the patch notes describe what was fixed. But that is just me [:)]

If you are involved in any kind of software development, there is not any difference between an 'official' release and a beta anyway. The only difference is a legal one, not a software one. But if you think there is a huge difference between an official release and a beta one, then feel free to continue to play a game where bugs exist instead of a version where many of them have been fixed.
pzgndr
Posts: 3486
Joined: Thu Mar 18, 2004 12:51 am
Location: Maryland

RE: Known Bugs

Post by pzgndr »

ORIGINAL: David Clark
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 don't see this project as collapsed. As Steve described, it is an insanely complicated game to program. As it has been for years and no doubt will continue for a while, it is a project in progress. So be it. Slowly but surely it is progressing.

I will continue to be patient while these latest bugs are worked through and NetPlay gets going for others. Sooner or later I will be able to play the Fascist Tide ETO scenario against a challenging computer opponent. I'll wait.
Bill Macon
Empires in Arms Developer
Strategic Command Developer
CrusssDaddy
Posts: 330
Joined: Fri Aug 06, 2004 6:05 am

RE: Known Bugs

Post by CrusssDaddy »

Hey guys, Steve just learned about damaged factories, which is such a tiny part of the game. Give him a break it's only been 10 years.
Numdydar
Posts: 3271
Joined: Fri Feb 13, 2004 9:56 pm

RE: Known Bugs

Post by Numdydar »

I suppose you know every rule perfectly and could program it correctly the first time [:)]

I still wish you would provide constructive feedback than continuing to take potshots all the time. I know you can be a big help (as you have help me in the past with the game mechanics). I guess its easier making these comments versus helpful ones?
User avatar
michaelbaldur
Posts: 4800
Joined: Fri Apr 06, 2007 6:28 pm
Location: denmark

RE: Known Bugs

Post by michaelbaldur »

ORIGINAL: CrusssDaddy

Hey guys, Steve just learned about damaged factories, which is such a tiny part of the game. Give him a break it's only been 10 years.

it have been known by me and by association the team, for years. we just looked at it now, because steve just activated paying for repair of factories. before this time it was just free.

paying BP to repair factories was really low on the priority list. (as it have almost zero effect on the games playability)

it just shows that the team works, when steve got to it, we all helped to make sure it was coded right.

and when he get to the next options not yet coded, it will be coded right the first time.
the wif rulebook is my bible

I work hard, not smart.

beta tester and Mwif expert

if you have questions or issues with the game, just contact me on Michaelbaldur1@gmail.com
nilssone85
Posts: 57
Joined: Fri May 29, 2015 8:52 am

RE: Known Bugs

Post by nilssone85 »

ORIGINAL: Numdydar

Let me try again [:)]

If bug A is in the official release but fixed in a beta patch, how does saying bug A exists help the development team when they know it has been fixed? Also it would give the impression that in the months since the last official release nothing has been done to fix any of these. Which is totally false.
It helps ME. It stops me having to brows through pages of reports to find out if the specific bug has already been reported or not (saves me time dont having to report a bug that is already understood). Also it helps me during gameplay to make sure I dont end up in situations where there is a game-ending bug.
So I still do not see any value to describing bugs where a lot of them have been addressed is going to help anything. It is certainly not going to help the beta testers or Steve. Nor do I see how it will help the community. However, I am willing to listen as to why this would be a good idea as I just do not see it. Especially since there are a lot of people that post games in the tech forum about issues they have so it is not like the bugs are hidden/being secret. No commercial software I know of posts open bug lists, including games, so why is there such a demand for it here? It is not like any of us can do anything about them [:)]
Well no commercial software is released with this amount of bugs either...
I could also say that most of us are using the latest beta too [:)] versus the last official release. Neither of us has any data to prove the other one incorrect [:)] You may not want to use the beta but I always do. I use the betas but I am willing to have the minor risk of new bugs showing up versus playing with a bunch of bugs I know about. Since the patch notes describe what was fixed. But that is just me [:)]
This is true. I went on previous experience claiming this. The "sane" thing would be to stay on a "stable" release until a beta has been evaluated, but in this case jumping from beta to beta might be the way to go. Not sure how and where to find this magic members area though. If the plan is to do it like this an "update to latest beta"-button should be implemented in the game start up menu.
If you are involved in any kind of software development, there is not any difference between an 'official' release and a beta anyway. The only difference is a legal one, not a software one. But if you think there is a huge difference between an official release and a beta one, then feel free to continue to play a game where bugs exist instead of a version where many of them have been fixed.
I'm not part of any software development. I bought a game... a game I thought was released and "done"...
User avatar
michaelbaldur
Posts: 4800
Joined: Fri Apr 06, 2007 6:28 pm
Location: denmark

RE: Known Bugs

Post by michaelbaldur »

I'm not part of any software development. I bought a game... a game I thought was released and "done"...


or at least I hoped it was more bug free by now.
the wif rulebook is my bible

I work hard, not smart.

beta tester and Mwif expert

if you have questions or issues with the game, just contact me on Michaelbaldur1@gmail.com
Numdydar
Posts: 3271
Joined: Fri Feb 13, 2004 9:56 pm

RE: Known Bugs

Post by Numdydar »

Here is the direct link to the last beta. You have to login to download it though

http://www.matrixgames.com/members/privateDL.asp?gid=296

You need to go under Community, login, and then go to 'Downloads for Registered Games'. Look for WiF and click, then you see the download.

I totally agree this should be a LOT simpler but until they do this is the way to get any patch/beta when the launcher does not support it [:(]
User avatar
Courtenay
Posts: 4372
Joined: Wed Nov 12, 2008 4:34 pm

RE: Known Bugs

Post by Courtenay »

ORIGINAL: Numdydar

Here is the direct link to the last beta. You have to login to download it though

http://www.matrixgames.com/members/privateDL.asp?gid=296

You need to go under Community, login, and then go to 'Downloads for Registered Games'. Look for WiF and click, then you see the download.

I totally agree this should be a LOT simpler but until they do this is the way to get any patch/beta when the launcher does not support it [:(]
The latest public beta has several new, fatal errors in it, introduced by the new compiler. Use it for testing purposes only, not for playing!
I thought I knew how to play this game....
David Clark
Posts: 39
Joined: Thu Feb 24, 2005 5:20 pm

RE: Known Bugs

Post by David Clark »

ORIGINAL: Shannon V. OKeets

I only upgraded the compiler (from 2010 to 2015) because I had no real choice. My old computer system was fried.

I don't really understand this, to be honest. Delphi 5 still runs fine on 64-bit Windows 10, and it's more than fifteen years old. Could you be more specific? What exactly was the issue that made upgrading the compiler necessary?
ORIGINAL: Shannon V. OKeets

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'm not sure why you're telling me this either. I specifically said function-level unit testing. You're telling me that feature-level unit testing or integration testing are impractical - I completely agree! The advantage of testing at the method level is it can catch digressions that would invalidate the contract between function-level inputs and outputs. This (again) can be done with no domain-knowledge, and is usually assigned to junior coders. Nothing to do with what we call the 'business logic' of the application at all.

I'm sure you know all this; you must have meant something different by your reply.
Shannon V. OKeets
Posts: 22135
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Known Bugs

Post by Shannon V. OKeets »

ORIGINAL: David Clark

ORIGINAL: Shannon V. OKeets

I only upgraded the compiler (from 2010 to 2015) because I had no real choice. My old computer system was fried.

I don't really understand this, to be honest. Delphi 5 still runs fine on 64-bit Windows 10, and it's more than fifteen years old. Could you be more specific? What exactly was the issue that made upgrading the compiler necessary?
ORIGINAL: Shannon V. OKeets

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'm not sure why you're telling me this either. I specifically said function-level unit testing. You're telling me that feature-level unit testing or integration testing are impractical - I completely agree! The advantage of testing at the method level is it can catch digressions that would invalidate the contract between function-level inputs and outputs. This (again) can be done with no domain-knowledge, and is usually assigned to junior coders. Nothing to do with what we call the 'business logic' of the application at all.

I'm sure you know all this; you must have meant something different by your reply.
Delphi 2010 never worked correctly for the MWIF code. I spent 3 months back in 2011 trying to get the debugger to run and eventually gave up. There were other fatal errors that I devised work-arounds for but using Delphi 2010 was a real pain.

Since I had to install a fresh copy of Delphi on a virgin computer system, installing Delphi 2010 again seemed pointless. Delphi XE8 has a working debugger which is a real plus. I still have one other minor annoyance with XE8 that I had with Delphi 2010 (each global search has an individual tab in the message panel but none of them can be closed, so I typically have dozens of old tabs displayed), but that doesn't really interfere with my productivity.

The definition of function varies depending upon decade and language. If you are referring to 'function' and 'procedure' in Pascal, then MWIF has 9000+ of those.

Grabbing one at random (which has a second embedded), you can see that devising a testing routine to check this would be non-trivial.

The purpose of this procedure is part of the logic for Units Affected by the movement of other units.
.
.
.
// Case (6) A unit's movement changes the FTC restrictions on another unit.
// Code = TUnit.FTCChange CheckHQFTC
//
// If movement of U changes FTC restrictions for V, then if V moves in the
// future, U cannot undo its move unless V's move is undone first.
.
.
.


// ****************************************************************************
procedure TUnit.FTCChange(const UL: TUnitLocation; const Amt: Integer);
var
UnitC: TMinorCountry;
MapC: TGovernedArea;
ULF: TUnitLocationFull;
Co, Ro: Integer;
MULF: TUnitLocationFull;
HStack: TMapStack;
StckIndx: Integer;
StckUni: TUnit;

procedure CheckHQFTC(const U: TUnit);
var
HC: TMinorCountry;
begin
HC := UnitHomeCountryCommonwealth(U);
// ****************************************************************************
// Check if movement of Self changes FTC restrictions on U.
// ****************************************************************************
if (U.UnitType in HeadquartersSet) and
(HC = PassedMinorCountry) and
(Map.HexHomeCountry[U.Column, U.Row] = PassedCountry) and
(U.UndoData <> nil) then
begin
if (U.UndoData.UUL.UnitPlace <> upOnMap) or
(Map.Terrain[U.UndoData.UUL.Column, U.UndoData.UUL.Row] = teSea) or
(Map.HexHomeCountry[U.UndoData.UUL.Column, U.UndoData.UUL.Row] <>
PassedCountry) then
// ****************************************************************************
// Record how many movement points used by U at this time.
// ****************************************************************************
UnitAffected(PassedUnit.ID, U.ID, U.UndoData.UMPUsed); // FTC Change.
end;
end;

begin
// ****************************************************************************
// TUnit.FTCChange. FTC: Foreign Troop Commitment.
// ****************************************************************************
if UnitType in NotStackingSet then Exit;

ULF := FullLocation(UL);
// ****************************************************************************
// If the target destination is the MovingStack, then use the MovingStack's old
// location. Change the ULF to from where it was picked up.
// ****************************************************************************
if ULF.UnitPlace = upMoving then ULF := MovingStack.PickUpPoint;
// ****************************************************************************
// If target destination isn't on land then there's no foreign troop commitment
// check. Carrier air units aboard carriers do not count towards FTC.
// ****************************************************************************
if (not ULF.OnLand) or OnCarrier then Exit;

if Name = rsStilwell then UnitC := UnitedStates
else UnitC := Countries[Country].HomeCountryCommonwealth;

MapC := Map.HexHomeCountry[ULF.Column, ULF.Row];
// ****************************************************************************
// FTCNeeded returns True when Self counts towards MapC's foreign troop
// commitment.
// ****************************************************************************
if (MapC <> nil) and (MapC is TSubCountry) and FTCNeeded(MapC.ID) then
begin
if UnitType in HeadquartersSet then
UnitC.CommitmentMax[MapC.ID] := UnitC.CommitmentMax[MapC.ID] +
(TLandUnit(Self).Reorg * Amt)
else
begin // Self is not an HQ unit.
UnitC.CommitmentTotal[MapC.ID] := UnitC.CommitmentTotal[MapC.ID] + Amt;

if Amt = 1 then
begin
PassedUnit := Self;
PassedCountry := MapC;
PassedMinorCountry := UnitC;

for Ro := 0 to MapRows - 1 do
begin
for Co := 0 to MapColumns - 1 do
begin
MULF := FullLocation(Co, Ro);

if MULF.AtSea then Continue;

HStack := MapStacks[Co, Ro];

if (HStack <> EmptyStack) and (not HStack.Empty) then
begin
StckIndx := 0;

while StckIndx < HStack.Count do
begin
StckUni := TUnit(HStack[StckIndx]);

if not StckUni.Flying then CheckHQFTC(StckUni);

Inc(StckIndx);
end;
end;
end;
end;
end;
end;
end;
end;

Steve

Perfection is an elusive goal.
User avatar
Zorachus99
Posts: 788
Joined: Fri Sep 15, 2000 8:00 am
Location: Palo Alto, CA

RE: Known Bugs

Post by Zorachus99 »

ORIGINAL: Zorachus99

Some people have been requesting to know if there are bugs in the current or beta versions of the game. The developer is too busy to deal with this publicly; but plenty of people have time to post the bugs that they find and are confirmed. Hopefully this will be helpful.

If you would like to post here, feel free, but please note the version you tested with to find the bug. Otherwise there is little public value.

Bugs outstanding in release 1.4.5.0 (Public release) that I know

1.4.5.0 Subs cannot intercept and initiate combat during the same impulse. They may only do either. Verified on bug list.
1.4.5.0 Advance after combat during offensive chits has issues. Reported previously, and it was claimed there was no such bug. However, if units cannot advance after combat, I'd call it a bug.
1.4.5.0 Taking additional Chinese cities generates a loop when the die roll is successful for U.S. entry.

I found these pretty quickly, I'm sure there are more that are important.

2.0.2.3 Subs cannot intercept and initiate combat during the same impulse.

This bug prevents the player from learning the game correctly, and pretty much makes subs less than half as good. Sub marginal value is less.

You can play with the game as it is, but it's wrong.

No point in verifying the other bugs. They probably aren't on the list. Back to waiting for a playable version of the game.
Most men can survive adversity, the true test of a man's character is power. -Abraham Lincoln
User avatar
paulderynck
Posts: 8356
Joined: Sat Mar 24, 2007 5:27 pm
Location: Canada

RE: Known Bugs

Post by paulderynck »

In what circumstances would subs need to intercept and initiate combat in the same impulse?
Paul
User avatar
Orm
Posts: 27767
Joined: Sat May 03, 2008 7:53 pm
Location: Sweden

RE: Known Bugs

Post by Orm »

ORIGINAL: paulderynck

In what circumstances would subs need to intercept and initiate combat in the same impulse?
When the juicy target stay in the sea area to avoid interception combat?
Have a bit more patience with newbies. Of course some of them act dumb -- they're often students, for heaven's sake. - Terry Pratchett
AlbertN
Posts: 4201
Joined: Tue Oct 05, 2010 3:44 pm
Location: Italy

RE: Known Bugs

Post by AlbertN »

If I spend a ship into intercepting, and the enemy stops in the sea area I always need a new ship (don't remember for subs though) to be disrupted to initiate combat (assuming the phasing player does not want to initiative it himself).

Not sure if that is abug though as I read about subs.
Post Reply

Return to “World in Flames”