No AAA losses in combat?

[BigDuke66]

Oh very nice, I wonder if he can take down that "ignore losses" problem too, I'm not sure what exactly the problem there is but I guess it will be an even harder nut to crack.

[Oberst_Klink]

ORIGINAL: BigDuke66

Oh very nice, I wonder if he can take down that "ignore losses" problem too, I'm not sure what exactly the problem there is but I guess it will be an even harder nut to crack.

Not sure, would be nice though. One step at a time. If he can find a solution, great. Then we can continue 'producing' smashing scenarios, revise older ones, give our TOAW community some spirit back it was lacking in the last 1-2 years. Kharkov '43 is ready for beta-testing now. Looking into a Mius '43 scenario project...

Klink, Oberst

[Shazman]

ORIGINAL: kmitahj

Hi,
It seems it is common opinion that AAA fix is conceptually easy. I wonder if there is indeed an agreement WHAT the fix really should look like? I mean it would be possible - maybe even easy - to make binary patch of a game which would make all units behave kinda like AA units - that is all units would have a chance to contirbute to low alt. anti-aircraft fire. But would it be a solution?
I didn't test it really but I suspect that it may result in switching "no AAA loses" problem into "much too much AAA loses". The thing is that - as far as I understand - air attacks aren't resolved as point attacks (like one air unit againt one target unit) but rather as area attacks against whole hex. That means that in general program adds up AA fire strength of all units in the hex (and for some map scales probably even units from nearby hexes) and then uses such total AA fire strength together with attacking airunit defense strength in procedure which decides about airplane hits if any. Currently when adding up AA strength program skips over all units which are not designated as AA-units and perhaps, just perhaps it was done so deliberately because otherwise attacking hexes dense packed with land units with internal AA equipment would often - though depending on particular scenario and map scale - result in prohibitive, unrealistic loses of airplanes?

If the simplest fix would really turn out to be more the problem then a solution then what the refined solution should look like?
- should it simply disciminate non-AA-units by adding only a pctage (how much?) of its AA fire strength to the total?
- or should it maybe select only one non-AA-unit from the whole hex stack (in addition to AA-units if any) to contribute to AA fire? (if so which one? one with highest AA strength, one on the top of the stack, randomly choosen one?)
- or maybe it should scale down AA fire totals by factor related to aerial density of AA equipment (i.e. same number of AA equipment in a hex will result in a AA strength scaled down depending on the map scale/hex size)
- or it should rather scale it down based on AA equipment pctage compared to total of all equipment in the hex (that is based on how much of other equipment in a hex has to be covered by single AA barrel)
- something different yet?

Excellent fix. Well done. Tested it today and all seems to work well. [&o]

Would it be equally possible to make 3.4 more like the unfinished 3.5 version by increasing the map size, place name, unit limits and formation limits to 3.5 standards? The map was to be 700 x 700. Place names increased to 4,000. Unit limits were to be 10,000. Formation limits were to be 1,000. Not sure how the game handles these data structures. Just curious but there are those who are working on scenarios for 3.5 that cannot possibly work under 3.4 unless these limits are increased. And I really don't think 3.5 will see the light of day.

In any event, thanks for your work on the AA problem. [;)]

[BigDuke66]

BTW maybe a Checksum could be published by the Author of the patch to make sure the EXE is really THE EXE he did, larry send me already a link to a download location I'm sure that is OK but sooner or later that EXE might show up on very different locations and some may not be secure at all, a way to verify that this EXE is the original would be good.

[Oberst_Klink]

ORIGINAL: BigDuke66

BTW maybe a Checksum could be published by the Author of the patch to make sure the EXE is really THE EXE he did, larry send me already a link to a download location I'm sure that is OK but sooner or later that EXE might show up on very different locations and some may not be secure at all, a way to verify that this EXE is the original would be good.

Disclaimer including checksum is in the making... Kapitan Kloss will report about it in person.

Klink, Oberst

[kmitahj]

Hi Shazman,
thank you for the kind words, I'm glad the patch seems to be working for you.
Unfortunately I must disappoint you. I'm a fan of big scenarios myself but the change you are looking after are beyond a realm of possibility (imho). Thing is binary patching is a tool best used (if at all!) to make small, well localized changes - kind of unpleasant but sometimes neccessary surgical intervention. However resizing of various internal data arrays has global effects, in fact it is likely to affect virtualy all parts of the code. Trying to do it in binary format would be like cuting the patient to pieces and then trying to put all these pieces together in reliable way: chances that patient will be alive are basically zero.
This kind of changes are best to be done in source code where compiler & linker are taking care of puting all that pieces back together (though programmer must still do the cuting so to say! . As for 3.5 version, I have no clue but I think/hope there is still a chance. Maybe after summer holidays there will be some official statement?

[kmitahj]

ORIGINAL: Oberst_Klink

ORIGINAL: BigDuke66
BTW maybe a Checksum could be published by the Author of the patch to make sure the EXE is really THE EXE he did, larry send me already a link to a download location I'm sure that is OK but sooner or later that EXE might show up on very different locations and some may not be secure at all, a way to verify that this EXE is the original would be good.

Disclaimer including checksum is in the making... Kapitan Kloss will report about it in person.

Klink, Oberst

Hi,
noticed your posts just after pushing finish on the above one. Yes, there is kind of readme file in preparation which contains checksums to allow verification of the patch identity . I think I will follow the advice I got and post it (the readme) in separate thread for reference.

[BigDuke66]

I guess it's best to stay with the latest patch as base for this fix but could the fix be worked into the latest beta?

[Telumar]

The AA bug is fixed in the latest beta version. It was one of the first things that had been done.

[Shazman]

ORIGINAL: kmitahj

Hi Shazman,
thank you for the kind words, I'm glad the patch seems to be working for you.
Unfortunately I must disappoint you. I'm a fan of big scenarios myself but the change you are looking after are beyond a realm of possibility (imho). Thing is binary patching is a tool best used (if at all!) to make small, well localized changes - kind of unpleasant but sometimes neccessary surgical intervention. However resizing of various internal data arrays has global effects, in fact it is likely to affect virtualy all parts of the code. Trying to do it in binary format would be like cuting the patient to pieces and then trying to put all these pieces together in reliable way: chances that patient will be alive are basically zero.
This kind of changes are best to be done in source code where compiler & linker are taking care of puting all that pieces back together (though programmer must still do the cuting so to say! . As for 3.5 version, I have no clue but I think/hope there is still a chance. Maybe after summer holidays there will be some official statement?

Too bad. Some are working on large 3.5 scenarios and they will probably never see the light of day. All that wasted time. At least 3.4 is more enjoyable than it once was. [:)]






Only did a little work since Panama. Not doing more till 3.5 is certain instead of just a rumor. [:D]