AA Patch - unofficial and temporary. (Full Version)

All Forums >> [Current Games From Matrix.] >> [World War II] >> Norm Koger's The Operational Art Of War III



Message

kmitahj -> AA Patch - unofficial and temporary. (7/31/2013 2:26:41 PM)


* What is the AA patch?

The 'AA patch' fixes a well known bug in TOAW v3.4 (version 3.4.0.202 to be precise) that allows only units with the Anti-Aircraft (AA) icon to fire at aircraft.


* How to install it:

Unzip and then drop the "AAA2Opart 3" executable in the TOAW folder, make a shortcut to the desktop and double click on it. It will start a version of TOAW with the latest v3.4 that also includes the AA-patch.


* Where it comes from:

This patch is a home made, unofficial modification of the binary "Opart 3" exe file (version 3.4.0.202) made in an effort to find a fix for the so-called AA-bug. It is the result of modifying (or hacking) the latest official TOAW exe file (by me) and as such has nothing to do with regular software development process in general, nor with MATRIX Games company. Matrix was NOT INVOLVED in creation of that patch, it DOES NOT SUPPORT it in any way and is NOT RESPONSIBLE for any possible problems you may encounter if you decide to use the patch. As it is in no way associated with Matrix one may rightly ask what is Matrix's position regarding this patch. That is good question no doubt - and the one for which I don't know the answer yet. Given current situation I hope that Matrix won't take issues with it (nor me personally - if I didn't hope so I certainly would not post it on Matrix official forum after all!) Once Matrix restarts the official development of TOAW, the need for such binary patch will go away as it will be superseded - hopefully soon - by an official release of version 3.5 or similar.


* History

This project started when I looked for a way to improve gameplay in one particular WWII scenario I was interested in. I wanted to play it with version 3.4 but I wanted also to cure the AA problem. For reference (most people reading this know it better then me) the AA problem existing in version 3.4 means that no units other then those with a AA icon ever use their AA-capable equipment to defend itself (and/or their neighbour units) against air attacks. Having some programming background and being crazy enough, I decided it was worth to try fixing it and thus some time later I got working on a first version of the patch. Then I posted timidly a note about the patch on the forum and a few guys responded with interest to try the patch. Some were even kind enough to spend some time testing it and thanks to their help and positive feedback a second, improved and hopefully final version of AA patch was created. This version is the one that avoids Air units to participate in AA fire and is the one that is now distributed.


* How it works

It is fortunately a simple matter: in the original program (version 3.4) a procedure responsible for calculating total low-altitude AA-fire strength when looking through all units in the attacked hex (and sometimes also through units from neighbour hexes depending on map scale) was explicitly checking if given unit belongs to AA-unit class and was skipping all units which did not. That is why only AA units were contributing to 'Flak' fire. The patch changes that behaviour so that now that same procedure allows all units to participate in anti-aircraft fire (as long as they have any AA-capable equipment of course) with the exception of AIR units (without explicit exclusion of AIR units there would be a very ugly effect where air units would participate to AA fire twice, an effect dubbed by players testing the first version of the patch as "SAM effect" or "SAM I-16").
You can verify the simplicity of the patch yourself by using any tool capable of making binary comparisons between files. Comparing the patched file with the original "Opart 3" you should find only three bytes of difference between the two. Yup, only three bytes flipped amongst over 26MB (much ado about nothing one can say!). This is worth to underscore as it may ease somewhat fears of people concerned about security.


* Is it good enough?

Thanks to testing made so far I'm reasonably sure that it works as I intended from a technical point of view (well, because of mentioned above simplicity of the patch there is not that much that could go awry really). However, I'm only a beginner TOAW player and have literally zero scenario design experience so I'm not in position to make a judgment. Feedback of experienced scenario designers gives me enough confidence to think that it may have some good chance to be a solution, if a temporary one, at best until TOAW v3.5 comes out.
However if you are an experienced player or designer, you can decide yourself if the patch is good enough for you and/or for the scenario you're playing or designing. And if you don't feel experienced enough I think you shouldn't consider using the patch unless the designer of a specific scenario you're about to play advices that it is worth doing so.


*** DISCLAIMER ***

Despite all the testing, please remember that I CAN NOT give you any guarantee regarding the patch, and thus I hereby declare that I take no responsibility for any damages or problems (technical, legal or of any other nature) which may result from using the patch. The patch is only shared "as is", so if you have any doubts about it, stay away and don't touch it even with 10-foot pole! Your choice, your risk.
All I can say is that if you find an actual problem with the patch, you can contact me and I will TRY to help and/or to make a fix.


* Availability

So far I've sent final version of the patch to a few interested parties under the name "AAA2Opart 3". Not the best name to be sure but because I've already used it I think to avoid confusion it's better to stick to that name no matter how silly. Of course if you decide to distribute the patch (with your scenario or otherwise) feel free to adjust the name as you see fit, but please provide either these notes or in other way make sure to explain to potential players the nature of the patch and that it is not supported or endorsed by MATRIX company.
If you have read carefully all the above (particularly the Disclaimer section!) and nevertheless you are still willing to give it a try you can get the final version of the patch from following location: https://www.dropbox.com/s/joedmf8xlfm86pr/AAA2Opart%203.zip


* Checksums

To make it easier to verify the identity of the patch (thus avoiding any mistakes or possible malevolent fakes reposted as the original patch) below are checksums of the (final) patch version:

MD5: 4887107d99e08db5888c48746ae27319
SHA-1: 36a1b3de471b12dde2a78d7a5324069c404374e4
SHA-256: 2f9496d54f6139798c8f32a2b75efb1b07cd78f77f75ed6e858d324aee30b4a3

You can and should take your time and verify patch identity before using it. There are many freely available programs which can help you doing just that (example: WinMD5Free, or google: "free md5 checksum program").


* Acknowledgments
A well deserved "thanks" to all these who expressed their interest in the patch. Without such interest there would have not been any reason for me to polish its first version. I would like to thank specially Fabio Governato and Colonel Klink who both invested their time and knowledge into testing of the patch providing invaluable feedback and words of encouragement. Fabio, Klaus it was fun and pleasure - thank you!





ColinWright -> RE: AA Patch - unofficial and temporary. (7/31/2013 8:00:46 PM)

Good stuff. Thanks.



LLv34_Snefens -> RE: AA Patch - unofficial and temporary. (7/31/2013 9:20:56 PM)

Looking forward to testing it.
I named my file TOAWAAA, pronounced with a Schwarzenegger "get to the choppa" accent :)



Silvanski -> RE: AA Patch - unofficial and temporary. (7/31/2013 11:14:10 PM)

Fine job. Will carry out some tests with scenarios I'm very familiar with



Oberst_Klink -> RE: AA Patch - unofficial and temporary. (8/1/2013 8:48:27 AM)


quote:

ORIGINAL: Silvanski

Fine job. Will carry out some tests with scenarios I'm very familiar with

Try Boonie Rat's VCO! Uncle Ho's boys take on the 'chopppaaaassss...';)

Klink, Oberst



josant -> RE: AA Patch - unofficial and temporary. (8/1/2013 11:03:36 AM)

I do a simple test scenario and those are my conclusions:
The scenario have many units:
-the unit A: this unit is with AA icon and is equiped with Patriots
-the unit B: this unit is with infantry icon and is equiped with Patriots
-the unit C: this unit is with infantry icon and is equiped with Patriots
-the unit D: the attacking unit equiped with ouragan airplanes
The scale is set to 25Km so the patriots have a range of 2 hexes.


[image]local://upfiles/24398/74868923685D47548C1B7B23B5127097.jpg[/image]



josant -> RE: AA Patch - unofficial and temporary. (8/1/2013 11:05:14 AM)

In the first test D unit attack A unit and the result was this:


[image]local://upfiles/24398/24923EEF495541CA9DE8D4417C7E63C6.jpg[/image]



josant -> RE: AA Patch - unofficial and temporary. (8/1/2013 11:06:56 AM)

the second test was attack unit C (a non AA icon unit) and the result was:


[image]local://upfiles/24398/66C0EBA0BFB348B7987BC40C17088AFE.jpg[/image]



josant -> RE: AA Patch - unofficial and temporary. (8/1/2013 11:09:01 AM)

And the third test was attack a unit near the B unit to check if the unit participate in combat (it have a range of 2 hexes)


[image]local://upfiles/24398/DE672A653A1A456BB4B653C39D0AE5F4.jpg[/image]



josant -> RE: AA Patch - unofficial and temporary. (8/1/2013 11:16:10 AM)

The conclusión is that the patch work very well, units whit no AA icons also participates in AA combats (within their range)

kmitahj, has done a good job, thanks [&o]



Oberst_Klink -> RE: AA Patch - unofficial and temporary. (8/1/2013 11:50:05 AM)


quote:

ORIGINAL: josant

The conclusión is that the patch work very well, units whit no AA icons also participates in AA combats (within their range)

kmitahj, has done a good job, thanks [&o]

Hurrah, it confirms all my hours of tests with post-WW2 scenarios! Viva Kapitan Kloss; who's now on a little holiday he surely deserves!

Klink, Oberst



mllange -> RE: AA Patch - unofficial and temporary. (8/1/2013 9:24:13 PM)

Very nicely done, drinks all around!



PRUSSIAN TOM -> RE: AA Patch - unofficial and temporary. (8/3/2013 3:30:51 PM)

Excellent...now Manstein can get back on track demolishing my troops!

Thanks for the fix! [&o][&o][&o]



Silvanski -> RE: AA Patch - unofficial and temporary. (8/4/2013 5:35:38 PM)

Seeing is believing. The Wehrmacht can reap the benefits of their 88mm Dual Purpose Guns, as was intended. Good job [&o]

[image]local://upfiles/15265/731A78C8C16D44D4BC7CED2093219357.jpg[/image]



Catch21 -> RE: AA Patch - unofficial and temporary. (8/7/2013 7:33:30 PM)

Agree with all, brilliant job, thanks! [sm=sign0031.gif]

But it's surely a sign of the state of the TOAW system (and its development[sm=Crazy-1271.gif]) as a whole when we have to stoop to modifying binary exes rather than the traditional route. Couldn't MG permit someone (kmitahj?) to modify the source code (and in what would seem to be in the final analysis such a simple fix) given no-one else has been around to do it for years now?

But yes, sir kmitahj [sm=bow.gif]



Catch21 -> RE: AA Patch - unofficial and temporary. (8/7/2013 7:34:34 PM)

Since I duplicated a post in error- and apologies- might as well use it- any news on TOAW Development or clever interested parties like kmitahj being given access to source code?

LATE EDIT: Ah, I see: http://www.matrixgames.com/forums/tm.asp?m=3364185&mpage=1&key=



captain10 -> RE: AA Patch - unofficial and temporary. (8/11/2013 6:26:56 PM)

I have a problem when I open the AA patch. I unzip it, and drop the "AAA2Opart 3" exe in the TOAW folder, I make the shortcut to the desktop, but when I try to open it I have a windows vista message that says:

"There is an error with your serial number as entered. Please contact supprt@matrixgames.com for assistance. Error Code: 2" [&:]

Any idea why this happen and what could I do to open it properly?




kmitahj -> RE: AA Patch - unofficial and temporary. (8/11/2013 9:42:33 PM)


Hi,
first I'd like to take the opportunity to say thanks to all testing, playing or posting comments on the patch. [:)]
Second:

quote:

ORIGINAL: carlos2012
"There is an error with your serial number as entered. Please contact supprt@matrixgames.com for assistance. Error Code: 2" [&:]

Any idea why this happen and what could I do to open it properly?

I'm in the middle of holidays and away from my PC so going here from my memory only: when TOAW starts there is indeed serial code check and the message you quote suggests that Matrix - for whatever reason - does not like the serial number it sees. The real thing to wonder here would be to me why the version you used so far does not raise any problem. It is delicate issue so I would prefer to refrain from guessing here. Normally the right course of action would be to follow the message advice and contact Matrix support. However we are talking here about UNSUPPORTED program mod so they would have good reason to turn you away. Second before contacting Matrix I would make sure that program you used so far is original indeed - especially if you got it not directly from Matrix but bought it from second hand source (easy way to check would be to get checksum of your "Opart 3" and then compare it with similar checksum from any reliable source).




r6kunz -> RE: AA Patch - unofficial and temporary. (8/12/2013 12:01:06 AM)

I, for one, have not had a problem...works fine.



Shazman -> RE: AA Patch - unofficial and temporary. (8/12/2013 12:53:28 AM)

quote:

ORIGINAL: carlos2012

I have a problem when I open the AA patch. I unzip it, and drop the "AAA2Opart 3" exe in the TOAW folder, I make the shortcut to the desktop, but when I try to open it I have a windows vista message that says:

"There is an error with your serial number as entered. Please contact supprt@matrixgames.com for assistance. Error Code: 2" [&:]

Any idea why this happen and what could I do to open it properly?




I had this message long ago. I can't recall why or how I resolved it. The AA patch works fine for me too. I renamed the original exe Opart 3 original.exe. Hopefully you kept it too. Maybe see if the original works.

Maybe uninstall and reinstall.



ogar -> RE: AA Patch - unofficial and temporary. (8/12/2013 3:12:47 AM)

@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 -> RE: AA Patch - unofficial and temporary. (8/12/2013 3:43:11 AM)

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



Oberst_Klink -> RE: AA Patch - unofficial and temporary. (8/12/2013 7:41:44 AM)

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 -> RE: AA Patch - unofficial and temporary. (8/23/2013 6:03:15 AM)

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 -> RE: AA Patch - unofficial and temporary. (8/23/2013 9:00:19 PM)

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 -> RE: AA Patch - unofficial and temporary. (8/23/2013 10:47:36 PM)

[&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 -> RE: AA Patch - unofficial and temporary. (8/26/2013 6:56:28 AM)

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 -> RE: AA Patch - unofficial and temporary. (8/26/2013 7:57:15 AM)

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



Oberst_Klink -> RE: AA Patch - unofficial and temporary. (8/26/2013 12:30:18 PM)


quote:

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

[image]local://upfiles/28259/B44259C5C39A49F382A48951A7C2B8C3.jpg[/image]



kmitahj -> RE: AA Patch - unofficial and temporary. (8/28/2013 7:43:14 PM)

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?





Page: [1] 2 3 4   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.6411133