Slitherine

quote:

ORIGINAL: governato

quote:

ORIGINAL: kmitahj
Speaking of patch deficiences here is one discovered in latest tests. As I said above it is rather dumb patch: it is allowing literally all units in range to participate in AAA fire. All units in this case means that also AIR units within fixed range (50km) may contribute to AAA fire as if they were equipped with long-range SAM missiles. BAD!!!
I'm going to find a way to exclude AIR units (and only AIR units) from participating in AAA procedure. However such bit smarter version won't be ready before weekend when I should have some time to work at it.

Hey Obertst et al.
What do you think of the above feature? I gave it some thought and I am actually fine with nearby Air units contributing AA. These are not really 'SAM missiles', but rather a possible representation of what would happen in real life, fighters closeby would definitely be scrambled to intercept incoming planes. So why not in TOAW? My only concern is to make sure that they can be hit as well and that these planes use us supply and readiness as they intercept. Curious to get some opinions on the topic.

quote:

ORIGINAL: governato

quote:

ORIGINAL: kmitahj
Speaking of patch deficiences here is one discovered in latest tests. As I said above it is rather dumb patch: it is allowing literally all units in range to participate in AAA fire. All units in this case means that also AIR units within fixed range (50km) may contribute to AAA fire as if they were equipped with long-range SAM missiles. BAD!!!
I'm going to find a way to exclude AIR units (and only AIR units) from participating in AAA procedure. However such bit smarter version won't be ready before weekend when I should have some time to work at it.

Hey Obertst et al.
What do you think of the above feature? I gave it some thought and I am actually fine with nearby Air units contributing AA. These are not really 'SAM missiles', but rather a possible representation of what would happen in real life, fighters closeby would definitely be scrambled to intercept incoming planes. So why not in TOAW? My only concern is to make sure that they can be hit as well and that these planes use us supply and readiness as they intercept. Curious to get some opinions on the topic.

quote:

ORIGINAL: Shazman
You can already set the appropriate air units to intercept. Do you really want them to possibly intercept the same air units twice? Also, if all air units AA strengths are used then the bomber units can also take part. And then will bomber units also conduct bombing missions or ground support? The air game should be left as it was meant to be where you assign air units to missions and that is all they do.

quote:

ORIGINAL: governato

quote:

ORIGINAL: Shazman
You can already set the appropriate air units to intercept. Do you really want them to possibly intercept the same air units twice? Also, if all air units AA strengths are used then the bomber units can also take part. And then will bomber units also conduct bombing missions or ground support? The air game should be left as it was meant to be where you assign air units to missions and that is all they do.

You make good points and yes I see the value of having a clean 'ground-only AA'. kmitahj is looking into how the code works (..from the executable, did I mention that I am impressed?), so we can make an informed decision. I agree that there is no need to do things twice if the code already takes care of air intercepts.

quote:

ORIGINAL: HPT KUNZ

kmitahj, very impressive. Who would have thought just a couple of weeks ago we would have work being done on the code to resolve the AAA issue. I am not a big fan of the smileys, but.... And much thanks to you guys who are testing the alpha version of the patch (if we can call it that).

signed
Kunz, HPTM

quote:

ORIGINAL: BigDuke66

Good, good, now I wonder if there are any negative effects not yet discovered...

quote:

ORIGINAL: BigDuke66

Good, very good, if he can turn off the SAM effect a big stone will be out of the way.

quote:

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.

quote:

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?

quote:

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.

quote:

ORIGINAL: Oberst_Klink

quote:

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

quote:

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?