AA Patch - unofficial and temporary.

[ogar]

@Carlos,

To help clarify, did you add the unzipped AAA2Opart3 exe to your TOAW folder, or did you replace the OpArt3 with the AAA version ? ( I think, and I hope you added the AAA version.)  If you overwrote/deleted the original, that may be the problem point.

Have you checked the target line in your shortcut to assure that it points to the AAA2Opart3 ?  My shortcut just starts the game bypassing autorun and that, uh, stuff.   Like others, I, too have had no problem with this version; I did make the effort to copy the whole TOAW folder and then load AAA2Opart3 to the copy, and I run the AAA version from that directory (although it still has its own Opart3 exe as well).

And, what kmitahj suggested, get one of the free checksum utilities and check the checksum of your AAA2Opart3 vs the ones he published, and check those against the checksum for the Opart3 from Matrix.  All should be the same.

And, there's always the get another copy of AAA, checksum, delete what you have, unzip and add the fresh copy, and try again. 

[SMK-at-work]

I just placed the exe in my TOAW folder and run it - i haven't renamed it or the original version.

[Oberst_Klink]

Important, which version have you installed? 3.4 or 3.2? As the others said; just unzip it in the main directory of TOAW and it should work fine. Not sure if there's a compatibility issue because you're using Vista. I am using Windows 7 and it's working fine. I got the version Kapitan Kloss sent me/shared with me. Drop me a line and I can email it. Get a checksum tool as well, to be on the save side.

Klink, Oberst

[sealclubber]

First: this is awesome, thank you. I have played governato's excellent Eastern Front 1941-1945 v3 that utilizes your patch. AA losses are working as intended/expected.

Second: if you can determine where in the assembly code the "retreat from combat" rules are applied and have the ability to modify them, I believe a reduction of the percentages for "fortified" and "entrenched" status units (barring a complete change in how these are calculated) would be sufficient to fix TOAW 3 v3.4. Ideally, the calculation would be totally overhauled but I think everyone could live with units in Fortified Lines and Dense Urban/Badlands terrain being hard to retreat. It's the units in open terrain that are Fortified and never retreat that are the real problem combats in TOAW v3.4.

Ralph: if you ever get around to reading this, _please_ apply one the AAA fix and a modified retreat from combat calculation BETA (no support). Curtis Lemay/Bob Cross has an idealized solution for this that from a programming standpoint, takes very little time to implement. Throw us a bone!

[kmitahj]

Hi sealclubber,
thanks for your kind words, overall it is just a small tweak but I'm happy if you found it adding a tiny bit to the fun of the game.

As for RFC, well it is no doubt much bigger issue. As usual there are good and bad things about it. Good thing (from my pov that is [;)]) is that I think I have reasonably good understanding of RFC procedure (or so I believe at least!). I was looking at it before my holidays break, in fact I was toying at that time with the idea of preparing flowchart diagram for RFC logic as a starting point for possible discussion of what should/could be changed (admittedly "what should" would have to fit within rather harsh limits of "what could" be changed by binary patching). Anyway I'm rather sure I can at the very least modify Terrain/Deployment Quality percentages you mentioned. The question is what values would be "right" or at least better. Possibly these used in version 3.2 could be considered as good reference point, we could also try to ask Curtis Lemay for help/hints though I'm not sure if he would be willing to be involved in any way in such hacking activity (besides - who knows for sure - he may be right now busy frying much bigger fish! [&o] )

I was also trying to think about some more sophisticated solutions beyond such a dumb change of few constants. Obviously I have read Curtis' thread on RFC and was looking for possibility of implementing his idea (as far as I understood it) of applying after-combat odds modifiers to RFC check. Unfortunately I found it too difficult to be done on binary level. Besides of general complexity it is so also because there seem to be (kind of) design problem here: currently RFC-check procedure is part of generic "CombatSmite" procedure (that is a procedure responsible for applying actual combat losses to fighting unit; the one which issues well-known "Smite xxxx-unit-name ..."/"End smite" messages in toaw log). Thing is "smitting" is done on unit-by-unit basis and so when given defending unit after beeing smitted is checked for possible RFC event (as well as evaporation etc.) the overall after-combat odds are - as far as I understand - not known yet in general because for some defending units in the stack losses were not applied yet (nor evaporation checked). Of course I'm not saying here that applying after-combat odds is impossible in general - using source code it should be possible if maybe a bit tedious to redesign code so it separates applying combat losses to all fighting units from after-combat RFC checks. It is just that such serious changes are beyond the realm of binary patching - at least as far as I'm concerned. There are probably a few other possible changes to RFC procedure which - though of disputable value - could be considered and should be in general doable:
* Unit Quality check can be replaced by Morale check to make units low on supply a bit more likely to retreat
* Terrain/Deployment factors can be modulated by unit Quality (or Morale) on the premise that higher quality (or morale) units are better able to use defensive terrain/deployment to their advantage then medicore ones. Thus fortified unit of perfect quality (UQ=100) would enjoy full 84% T/D factor but medicore unit (UQ=50) would have only 42% chances of using its "F" deployment or "F"-like terrain to their advantage and mob unit of lowest quality (10%) would have only 8% chance to use T/D advantage to avoid retreat in such conditions.
* Terrain and Deployment factors could be combined in a way similar like when calculating defender bonus (see IV.11 in "whats new" doc). Using such "square root of sum of squares" method and scaling numbers down such that only unit in both "F" deployment AND "fortified line" terrain will gain full 84% benefit we would get unit in "F" but in open terrain having only about 60% chance to avoid retreat (and same for unit in "fortified line" terrain but in none of F/E/D deployments). Similarly Enterenched unit in dense urban would have 65% chance but when Entrenched in the open only 46% (likewise in dense urban but in none of D/E/F).
* T/D factors can be scaled down linearly for units in low supply condition. For example once unit supply drops below given threshold (e.g. 33%) its effective T/D factor used in RFC check (if any) is going to go down; so unit with only 16% of supply will enjoy effective T/D factor value of only half of the nominal one.
There are probably other conceivable approaches but all share same disdvantage: they would need to be first seriously tested then voted by group of experienced players doing essentially beta testers job. Comparing time needed to implement and then test such more sophisticated solutions with quick & simple solution of adjusting T/D factors, then taking into account KISS principle we could have an easy winner I guess.

Now about bad thing: no matter what approach one would decide to take there is one very generic and very important problem to be solved before such binary RFC patch could be made public. I mean a problem of PBEM consistency. Right now as far as I understand it is not possible in PBEM game to switch from one version of TOAW to another (say from 3.4 to 3.2 or other way around). If it would be possible then someone could use it to gain unfair advantage. Similarly if RFC-patched toaw version would be able to open saved games of original 3.4 and vice-versa that would be a serious breach of PBEM safety. I guess it could make a lot of people angry and thinking rightly that such a patch is doing overall more harm then good.
I hope I will be able to solve that problem by bumping up the ScenarioLevel number in games saved by RFC-patched toaw version. That way original 3.4 version will not recognize and refuse to open games saved by patched version. It is basically the mechanics used currently when version 3.2 refuses to open game file saved under version 3.4. However I need more time to work on that thing and then once implemented it would need to be seriously tested to make sure there is no loophole. Only then I'm afraid it would be feasible to consider making RFC patch - in one form or the other - public.

So such PBEM-safe RFC patch - though hopefully possible - will need time to be implemented and tested and no matter what form it will take it will be imperfect - that is it will be different then final solution expected to be found in version 3.5 (the one based on after-combat odd modifiers). That leads to the last (well in fact to the very first one) point to be made: it could be that behind secret curtain there is something hatching out right now... something that will make instantly obsolete all that binary patching thingy... No, I don't have any special clues except one subtle, publicly visible trace but nevertheless I think there is good chance to be pleasantly surprised here. [:)]

[walkra]

[&o][&o] Excellent job!!!! Thank you, very much..... (in my opinion, add to all requests, an option to turn off the undo button in Set Advanced Game Options, the Playback is not as precise (some ghost units, or in different location), interdiction attacks to ships, etc).

[sealclubber]

Version level changes to ensure consistent binaries are being used in PBEM is the way to go (assuming it works).

I applaud if you're able to actually implement comprehensive calculation changes, but it's sort of an idealized, chrome solution. I think it's far more important that the feel of combat is improved and you could achieve that with much simpler modification of constants as well as less risk with unintended side effects. The combat calculations are complex and black box-ish as it is, mucking around with the combat calculations in the assembly code is asking for trouble... Occam's Razor!

And for any such patch to be worthwhile, people need to want to use it. A simple modification of constants is easy for folks to understand and its effects will be observable in game. This will give people confidence in the patch and give it a higher adoption rate.

Here are the current RFC Adjustments:

Fortfied Line, Fortified Deployment - 84%
Dense Urban (or Ruin), Badlands, Entrenched Deployment - 65%
Mountain, Dunes, Urban (or Ruin), Bocage - 50%
Forest, Jungle, Hills, Wadi, Defending Deployment - 26%

I would suggest Fortified Deployment @ 50%, Entrenched Deployment @ 26% and Defending Deployment @ 0%.

This keeps the number of binary adjustments to an absolute minimum with the lowest risk of unintended consequences.. although I can imagine some potential mathematical issues with making Defending Deployment 0% (depending on how clean [or not] the source code is) so that might require Entrenched and Defending Deployment @ 26%, which will be just fine based on how attacking "D" units feels at the present time (in my opinion, of course).

[BigDuke66]

Couldn't we simply(how unappropriated this word is here) halve all values as a starting point to see how it goes?

[Oberst_Klink]

ORIGINAL: BigDuke66

Couldn't we simply(how unappropriated this word is here) halve all values as a starting point to see how it goes?

I second this proposal! We have sandbox scenarios to test the results anyway. Thanks to Kapitan Kloss I am back enjoying scenario design. No volunteers for Kharkov '43?

Klink, Oberst

[kmitahj]

Hi,
It is true that keeping it simple is usually the rule to follow, even more so with regard to kind of changes we are talking here. It is also (arguably) true that there is a lot of abstraction and approximation embbeded into combat model. However no matter how high in the ladder of abstraction I'm climbing I still feel somewhat uneasy with the situation where in respect to RFC all units seem to behave very similarly with their chance of beeing forced to retreat depending only a little on their internal state. Currently probability (I'm talking here about conditional probability actually - under condition that a unit first took enough losses to fail low casualties test) of beeing forced to retreat for unit with IL-stance is basically (1-UQ)*(1-TDQ). So for F+IL elite unit (UQ=90%) that chance is 1.6% (per combat round) whereas for comlete junk unit (UQ=10%) in same situation it is slightly below 15% (again, overall probabilities are lower yet because it is usually not that easy to incur enough losses on the fortified unit to make it fail low casualties test). One can say that the whole range of unit quality (about 90%) is here effectively compressed into only 14% segment of probability space. Having such limited difference in retreat chances for elite and medicore units I think there is no surprise that players are tempted to throw junk units in F+IL deployment as cheap roadblocks against enemy advance.

Such concerns aside another question regarding fixed T/D numbers is if they are going to work good enough over vast set of existing scenarios - pehaps it would be better to have them as parameters adjustable by designers on per scenario basis. If however regardless of the above we prefer to stick to single, fixed set of numbers (and besides arguments listed in post above there is another pragmatic reason to stick to simplest solution: if works on official version 3.5 were indeed lately restarted then there is no point to waste time and energy devising unduly sophisticated concepts) then besides numbers used in 3.4 (which can be considered as upper boundary limitation) we have also numbers used in version 3.2. In that version for F/E/D deployed units RFC procedure used 50/33/25 % factors correspondingly and there was no terrain influence. I have not much experience with playing version 3.2 (nor 3.4 for that matter) so the question for experienced players/designers would be what was the common opinion about units (especially IL-units) RFC behaviour in that version. Was it percived as an issue at all? If so how much and was it common problem in most scenarios or observed only for some specific cases? Assuming that version 3.2 was considered okeish in regard to retreats of IL-units one could treat the numbers in 3.2 version as bottom boundary and look for the "proper" solution somewhere in the middle between 3.2 and 3.4 numbers. Surely it is possible to experiment with a few different sets of numbers and see which one works best, but for the sake of PBEM safety each such experimental version with different numbers embbeded would have to have assigned different Scenario Level number.

Anyway I think that first issue to be solved now is to implemet the ability to store game save/scenario files with ScenarioLevel number higher then used in original version 3.4. I think I will have some time in the weekend to work on it. Assuming I do get it working the question is if there would be at least a few experienced players willing to invest their time into testing of such mechanism. By testing I mean here using their experience to trick original 3.4 version to successfully open and process save/scenario file stored by modified version. If during such testing period nobody finds a way to circumvent scenario version control mechanism we could consider it as a guard for PBEM safety and proceed to release of rfc patch for testing (one or more versions with different sets of numbers).


@Oberst_Klink: Hello Herr Oberst, looks like you doing well. Congrats on the finishing of Kharkov scenario! And bw nice looking texture on that picture attached. Some kind of modernish-style graphic mod?

[Oberst_Klink]

Kapitan Kloss,

It's Telumar's Grey GUI WW2 mod; I really like it, gives it a new style and revived my spirits to design more scenarios

Klink, Oberst

[sealclubber]

Sadly I'm not around this weekend, but whenever you're done and need testing, let me know I'll lend a hand if I can.

[kmitahj]

Hi seaclubber,
appreciate the offer and sorry for beeing late with the answer. During the weekend I got the working version of exe using modified ScenarioLevel numbers. As planned original opart 3.4 is apparently not able to open game save/scenario files creted by that modified version although that would be yet subject of testing for possible loopholes.
Despite that it seem to be working as intended I'm afraid it may be not the solution for PBEM safety I was aiming for. The reason is - no matter how funny or confusing it may sound - the solution in current form is too simple. Too simple means it can be rather easily circumvented and as such won't provide real PBEM security. Let me know if you interested and want to see it for yourself - if so can send you via email modified exe file toghether with some more details about what I mean by "beeing too simple" to be real security measure.

[Oberst_Klink]

ORIGINAL: kmitahj

Hi seaclubber,
appreciate the offer and sorry for beeing late with the answer. During the weekend I got the working version of exe using modified ScenarioLevel numbers. As planned original opart 3.4 is apparently not able to open game save/scenario files creted by that modified version although that would be yet subject of testing for possible loopholes.
Despite that it seem to be working as intended I'm afraid it may be not the solution for PBEM safety I was aiming for. The reason is - no matter how funny or confusing it may sound - the solution in current form is too simple. Too simple means it can be rather easily circumvented and as such won't provide real PBEM security. Let me know if you interested and want to see it for yourself - if so can send you via email modified exe file toghether with some more details about what I mean by "beeing too simple" to be real security measure.

Kapitan Kloss!

Could you drop all your latest developments in Fabio's and my D/B? Can't wait to see you fix the Ignore Losses issue or tweaking the game to make it even more enjoyable and realistic!

Yours,

Klink, Oberst

[kmitahj]

Hello Herr Oberst,
sure I will put the file at the dropbox folder. However the file by itself does not deliver any new game feature or fix. Whole idea of that file was to test a way to provide PBEM security before releasing planned RFC patch (aka Fortified@IgnoreLosses patch as these are conditions where the problem seems to manifest itself most). Though many players are pbem-ing mostly seeking for higher fun factor of games against another human and/or they enjoy the benefit of having well-known and well-trusted opponents there are also many players which approach PBEM games in more competitive way, some may even be involved in various ladder/league rankings. So overall I think PBEM consistency is important factor for toaw community as a whole and release of RFC patch compromising such consistency may for many not be welcomed event.
I was hoping to preserve PBEM consistency by bumping up ScenarioLevel number in game save files stored by RFC-patched exe file. It is mechanics used currently for example to quickly differentiate between save files stored by versions 3.2 and 3.4. Intended goal of the pached file mentioned above was to test effectiveness of that method. It seems to be working well with its save files declared uncompatible by original version 3.4 (though that would be yet to be tested for possible loopholes) nevertheless it is unlikely to provide real PBEM safety. It is because it is simple change (just another couple of bytes flipped) and beeing simple means beeing easily reversible - re-reverse-engineerable so to say by anybody determined enough. Looks like there is kind of Catch-22 here: any solution simple enough to be acceptable is unlikely to provide real PBEM safety, whereas any solution providing reasonable PBEM safety will be likely too complex to be acceptable from untrusted source. C'est la vie! [:o]

[Lobster]

Being a moron I am not completely clear about what you are saying. Pro: You have a way to heal the Fortified Ignore Losses problem? Con: There might be a PBEM security problem with it?

If that is what you are saying then I think most people would be ok with not so much security if you can fix the ignore loss problem.

Then also you are saying it looks like someone has started working on 3.5 again. I see Ralph has been checking in lately. If 3.5 has risen from the ashes like the phoenix bird then just fixing the fortify/ignore loss problem would be the way to go and not so much worry about PBEM security. No reason to knock your head on a wall if it's temporary for 3.4. But then what is temporary time in Matrix mind might be same as geological time. lol.

[governato]

* T/D factors can be scaled down linearly for units in low supply condition. For example once unit supply drops below given threshold (e.g. 33%) its effective T/D factor used in RFC check (if any) is going to go down; so unit with only 16% of supply will enjoy effective T/D factor value of only half of the nominal one.

I am finally catching up with this thread! The above is my favorite solution. A unit can be as fortified as it can be, but with no food or ammos it should find it very difficult to hold ground.

I'd not use morale as a modifier because morale tends to 'drift up' in long scenarios.

[Ruppich]

ORIGINAL: kmitahj
any solution simple enough to be acceptable is unlikely to provide real PBEM safety

if i dont trust my pbem opponent then i dont play him...

[governato]

ORIGINAL: Ruppich

ORIGINAL: kmitahj
any solution simple enough to be acceptable is unlikely to provide real PBEM safety

if i dont trust my pbem opponent then i dont play him...

A simple solution should be enough for 99% of the cases, which is good enough for me. If a hacker is that good they should go somewhere else to fry bigger fish. It's a game afterall!

[Oberst_Klink]

Tak! Go ahead with the simple I-L fix, Kapitan Kloss!

Klink, Oberst