Patch #3

[Arjuna]

Hi all,

Following on from reports in this forum and our own beta testing we have found two issues we thought needed to be addressed in a third patch. These relate to another case of formation lockup and to a couple of bugs in the resupply code. The detailed fixes are:

• Ensure IsFeasible() test handles cases where the missionTask forceGroup end up unpopulated. This addresses the FPAssert at FPPLanningParams line 719.
• Ensure exiting and destroyed units clear their unitAhead field and relink any unit that had them as their unitAhead. This fixes a formation lockup.
• Ensure all vehicle types are factored in when determining resupply transport capacity. Previously was only using the transport capacity of first vehicle type. This improved delivery rates of supplies.
• Ensure the rationing code uses the drawing bases' current supply level and not the supplying base's supply level. This fixes the problem of too much supplies being sent to the Bde bases leaving very little for Div assets like artillery.

I am uploading new build for Matrix as I type. I am not sure exactly when they will release a new public beta build for these but stay tuned. Once this has been released and if we don't hear of any problems with it, it will become the final patch #3.

FYI the resupply issues came to light when Richard was testing the new HTTR Ex Pack and couldn't accept that the Airborne Divisions were getting virtually no supplies. It turns out that due to my error only the first vehicle type was being counted when determining the transport capacity of a supply run. In the airborne divisions this unfortunately was the motorcycles and they only have a 100kilo capacity. The total they could shift with their bikes amounted to a few tonnes and that was being gobbled up by the Bdes as fast as it arrived. This was a good catch. Take a bow Richard. [&o]

The formation lockup bug was due to an oversight when I added the new road column formation code. It's a classic trap for C++ coders in that I had forgot to handle the pointer to the unitAhead when removing a unit from the active list - ie when it is destroyed or exits. This may have caused the lockup reported by fleischer but there is no way of knowing for sure as we don't have a saved game that goes back far enough to test.

[BletchleyGeek]

ORIGINAL: Arjuna

Hi all,

Following on from reports in this forum and our own beta testing we have found two issues we thought needed to be addressed in a third patch. These relate to another case of formation lockup and to a couple of bugs in the resupply code. The detailed fixes are:

• Ensure IsFeasible() test handles cases where the missionTask forceGroup end up unpopulated. This addresses the FPAssert at FPPLanningParams line 719.
• Ensure exiting and destroyed units clear their unitAhead field and relink any unit that had them as their unitAhead. This fixes a formation lockup.
• Ensure all vehicle types are factored in when determining resupply transport capacity. Previously was only using the transport capacity of first vehicle type. This improved delivery rates of supplies.
• Ensure the rationing code uses the drawing bases' current supply level and not the supplying base's supply level. This fixes the problem of too much supplies being sent to the Bde bases leaving very little for Div assets like artillery.

I am uploading new build for Matrix as I type. I am not sure exactly when they will release a new public beta build for these but stay tuned. Once this has been released and if we don't hear of any problems with it, it will become the final patch #3.

Cool to hear and thanks for the hard work

ORIGINAL: Arjuna
FYI the resupply issues came to light when Richard was testing the new HTTR Ex Pack and couldn't accept that the Airborne Divisions were getting virtually no supplies. It turns out that due to my error only the first vehicle type was being counted when determining the transport capacity of a supply run. In the airborne divisions this unfortunately was the motorcycles and they only have a 100kilo capacity. The total they could shift with their bikes amounted to a few tonnes and that was being gobbled up by the Bdes as fast as it arrived. This was a good catch. Take a bow Richard. [&o]

That surely took quite some time to figure out. [&o] to Richard.

ORIGINAL: Arjuna
The formation lockup bug was due to an oversight when I added the new road column formation code. It's a classic trap for C++ coders in that I had forgot to handle the pointer to the unitAhead when removing a unit from the active list - ie when it is destroyed or exits. This may have caused the lockup reported by fleischer but there is no way of knowing for sure as we don't have a saved game that goes back far enough to test.

After many years dealing with C and C++ I've come to appreciate STL containers and forget about trying to do myself certain stuff. Too easy to forget about tedious bookkeeping, usually done to obtain marginal speed-ups

And I think I owe an apology to fleischer: even if his problem could not be reproduced (and I tried a few times) he made you to take a close look at the code and fix that. So [&o] to fleischer as well.

[PirateJock]

As always Dave, thanks for getting on to this and sorting it out. On your desk do you have a piece of string? And have you ever tried measuring it [;)]

Cheers

[wodin]

Excellent news Dave. Big thanks.

[simovitch]

Bow taken.[:D]

[Deathtreader]

ORIGINAL: Arjuna

Hi all,

Following on from reports in this forum and our own beta testing we have found two issues we thought needed to be addressed in a third patch. These relate to another case of formation lockup and to a couple of bugs in the resupply code. The detailed fixes are:

• Ensure IsFeasible() test handles cases where the missionTask forceGroup end up unpopulated. This addresses the FPAssert at FPPLanningParams line 719.
• Ensure exiting and destroyed units clear their unitAhead field and relink any unit that had them as their unitAhead. This fixes a formation lockup.
• Ensure all vehicle types are factored in when determining resupply transport capacity. Previously was only using the transport capacity of first vehicle type. This improved delivery rates of supplies.
• Ensure the rationing code uses the drawing bases' current supply level and not the supplying base's supply level. This fixes the problem of too much supplies being sent to the Bde bases leaving very little for Div assets like artillery.

I am uploading new build for Matrix as I type. I am not sure exactly when they will release a new public beta build for these but stay tuned. Once this has been released and if we don't hear of any problems with it, it will become the final patch #3.

FYI the resupply issues came to light when Richard was testing the new HTTR Ex Pack and couldn't accept that the Airborne Divisions were getting virtually no supplies. It turns out that due to my error only the first vehicle type was being counted when determining the transport capacity of a supply run. In the airborne divisions this unfortunately was the motorcycles and they only have a 100kilo capacity. The total they could shift with their bikes amounted to a few tonnes and that was being gobbled up by the Bdes as fast as it arrived. This was a good catch. Take a bow Richard. [&o]

The formation lockup bug was due to an oversight when I added the new road column formation code. It's a classic trap for C++ coders in that I had forgot to handle the pointer to the unitAhead when removing a unit from the active list - ie when it is destroyed or exits. This may have caused the lockup reported by fleischer but there is no way of knowing for sure as we don't have a saved game that goes back far enough to test.

Hi,

Aside from those listed in the above posting are there any other system changes unique to patch 3??

Thanks!

Rob. [:)]