Atheory's Project: PzB-Normandy Campaign

[Paul]

I have bad news.  Simply put, yes, the scenario is now so large as to exhaust available Windows graphics system resources.  Without major code redesign and reworking, there is no fixing this AFAIK.

I am at wits end.  I gave it my best shot, but missed the mark.

Sorry this has not worked out as we had hoped.

Aww poopy. Well, thanks for looking into it nonetheless.

Cheers

Thanks for all the hard work guys.

[LordDeadwood]

So disappointing... Have been following this closely and was really hoping this would work out.

[Ocito80]

Having slept on the setback. I will attempt to split the Grand Campaign in two. Essentially dividing the American and British sectors. Knowing the limitations intimately now, I can better plan accordingly.

The intent is to do the American AO first, with an emphasis on three sectors (St Lo, Carentan and Cherbourg). The American campaign will cover the first 24-ish days, ending when historically cherbourg was captured. Sub-maps have already been created, and just finalizing a few oob updates.

I'm still holding out that I can use supply units, but because it would increase the unit count, and thereby increase the scenario file size, it may not be possible to incorporate them.

Stay tuned.

[berto]

If I understand the code correctly (it is JT's code, not my own), if my investigations and diagnosis are correct, I don't think the limitation is the gross number of units.  Rather it is the number of unique unit graphics images.

Indeed, this would explain how in more than one of my tests I was able to add dozens more German units, because they were units using counter graphics in use by other units already on map.  Eventually, yes, I could add one more German unit that locked up the program.  Presumably (I can't say for sure, I didn't check) it was a new unit type, with a new set of counter graphics not already in use.

As it pertains to potential program lock-up, it should make no difference if you have one supply unit, or 10, or 100, since they all share the same several unit counter images (for the several different zooms, and the NATO variant).

I think your revised plan is a reasonable one.  I would be surprised if you can't implement as many supply units as you need.

[Ocito80]

If I understand the code correctly (it is JT's code, not my own), if my investigations and diagnosis are correct, I don't think the limitation is the gross number of units.  Rather it is the number of unique unit graphics images.

Indeed, this would explain how in more than one of my tests I was able to add dozens more German units, because they were units using counter graphics in use by other units already on map.  Eventually, yes, I could add one more German unit that locked up the program.  Presumably (I can't say for sure, I didn't check) it was a new unit type, with a new set of counter graphics not already in use.

As it pertains to potential program lock-up, it should make no difference if you have one supply unit, or 10, or 100, since they all share the same several unit counter images (for the several different zooms, and the NATO variant).

I think your revised plan is a reasonable one.  I would be surprised if you can't implement as many supply units as you need.

Thanks for the insight.

[LordDeadwood]

If I understand the code correctly (it is JT's code, not my own), if my investigations and diagnosis are correct, I don't think the limitation is the gross number of units.  Rather it is the number of unique unit graphics images.

Indeed, this would explain how in more than one of my tests I was able to add dozens more German units, because they were units using counter graphics in use by other units already on map.  Eventually, yes, I could add one more German unit that locked up the program.  Presumably (I can't say for sure, I didn't check) it was a new unit type, with a new set of counter graphics not already in use.

As it pertains to potential program lock-up, it should make no difference if you have one supply unit, or 10, or 100, since they all share the same several unit counter images (for the several different zooms, and the NATO variant).

I think your revised plan is a reasonable one.  I would be surprised if you can't implement as many supply units as you need.

Interesting. I assume you are referring to the graphic images used for the counters? Would it be possible then to design a mega-scenario where the counters all used generic "Nato" style images, thereby reducing the number of graphic images? Just curious...

[berto]

In theory, that might work, yes.  In practice, I am not sure how you would bring that about.

[berto]

If I understand the code correctly (it is JT's code, not my own), if my investigations and diagnosis are correct, I don't think the limitation is the gross number of units.  Rather it is the number of unique unit graphics images.

Indeed, this would explain how in more than one of my tests I was able to add dozens more German units, because they were units using counter graphics in use by other units already on map.  Eventually, yes, I could add one more German unit that locked up the program.  Presumably (I can't say for sure, I didn't check) it was a new unit type, with a new set of counter graphics not already in use.

As it pertains to potential program lock-up, it should make no difference if you have one supply unit, or 10, or 100, since they all share the same several unit counter images (for the several different zooms, and the NATO variant).

Indeed, more evidence suggesting that the above is so:

  BONAtheoryBug5.JPG (Size: 447.89 KB / Downloads: 2)

In the screenshot, I have added dozens of British Supply Truck units without pbedit locking up.

(These additions are to the version of the scenario where before, in our experiments, the program would invariably lock up after adding a single new unit counter representing 23/E/12 Devonshire Regt (UK AL MG (mot)).  A new unit with counter graphics not already in use (presumably).)

But then, after the many Supply Truck additions, if I attempt to add a new unit type with a new set of unit graphics, the British airborne Supply Drop, the program locks up.

In an earlier experiment, I was able to similarly add many dozens of Supply Drop units in the manner depicted by the Supply Trucks test (but without any Supply Truck additions), and similarly without the program locking up.

So, the system limit leading to lock-up does not seem to be the gross number of units.  Rather, it seems to be the number of unit types.  Limit the unit types, limit the number of graphics images loaded for those types, and you should be good.

If I am right about all of this, if we can somehow avoid loading up the picture counter graphics, and confine all counter graphics to just NATO symbols, I believe we should be good in this way also.

No proof of any of this, the proof is in the trying.  Maybe worth a try?

[Strela]

Hi,

As one of the main scenario designers I am probably most qualified to comment on possibilities.

The issue appears to be distinct unit types, rather than the number of units overall. 

If you want to trim the number of unit types in play, then you need to build more 'generic' units in the OOB and adjust strengths etc in scenarios. For example, you could build a generic German machine gun unit and use that to cover what is a range of different units currently. 

Do we know what the number of unit types in a scenario that is causing the crash? That should guide when looking at how many units to rationalise.

David

[berto]

Do we know what the number of unit types in a scenario that is causing the crash? That should guide when looking at how many units to rationalise.

No, don't know the number.  I could implement a counter.  But we only have this one proven test case (proven to lock up with addition of one more new unit type).  We would need other test cases (scenarios) to determine what generally the number might be.