Matrix Games Forums

ORIGINAL: Alfred

I think you are spot on and you will be surprised at how many will remain with WITP and not port over to AE. I suspect that many will quickly buy AE but then will return to WITP because

(a) will wait until the inevitable initial AE bugs are patched up
(b) may find that AE makes too much a demand on their hardware and therefore they they will wait until they upgrade
(c) may become disillusioned with some of the new AE features
(d) people who do not already have WITP will not necessarily buy both WITP and AE together, they may prefer to tip their toes into the water first by initially buying only WITP

Alfred

ORIGINAL: herwin

Description: LCU morale is sensitive to whether the unit is disrupted. If it remains disrupted, the morale converges linearly over time to 0. If it is not, the morale converges linearly over time to 99. Units in the malaria or cold zones (Burma, Thailand, Taiwan, Manchuria, DEI, Malaya, Philippines) outside of a small number of designated hexes remain constantly disrupted and lose morale over time. A unit in garrison in those areas will drop to a morale of about 20 by mid-1943 and will continue past that to zero.

Severity: Show-stopper for land operations in those areas past the beginning of 1943. This makes it impossible to replicate the 1944 campaigns in Burma and the other areas.

Conditions for reproducing: Play a game into 1943.

Recommended solution: Morale should gradually return (exponential convergence) to an appropriate value for each unit. This should reflect the hex type, presence of malaria/cold, supply status, hex development, leadership, and troop quality. A random number draw will be needed to determine the number of morale points gained or lost each turn. The following algorithm is recommended. I recommend coding this internally in double precision arithmetic.

double limit = Compute_morale_limit(args); // the arguments should be anything that you want to affect the morale limit.
// Use Test Driven Development to show that the method provides appropriate values
double delta = limit - double(current_unit_morale); // positive if the current morale is too low, negative if too high
// now what you want is a random number generator that generates a poisson output.
// the boost library has one that implements Knuth's recommendation on page 137 of Volume 2
// you pass it a positive rate, and it returns an integer. The rate should be some small number times the absolute value of delta
// unfortunately, it uses a constant rate, but you can adapt the code so you call it with the current rate. This allows you to use
// a single RNG process to generate the pseudorandom numbers with multiple rates.
// you may well want to use this function with other parts of the system when you need to model a poisson process efficiently
// assume factor is a slow-down that you're using to reduce the rate of convergence
double factor = some_small_positive_value;
double how_fast = abs(delta);
int sign = (delta>=0)?1:-1;
double rate = factor*how_fast;
int change = poisson(rate); // RNG draw from a poisson process parameterised by rate
// now change is a positive integer. Be paranoid here:
if(double(change)>how_fast) change = int(how_fast); // round down
morale += sign*change; // and there's your result
return;

ORIGINAL: jwilkerson

ORIGINAL: khyberbill
It is not a problem to pull a unit out of the line for a period of time. However, is there a recommended period of time? In on of my games now, I have a few units that have had a lot of battle and thus have two or three planes and the same number of pilots. I gather from what you say, if I stand down these squadrons for two weeks, I might find that there are now 6 pilots and 3 planes?

Yes. I often wondered why I sometimes seemed to be "growing" pilots - but that isn't something one would grip about. But now I know the reason. If a good air unit gets beat up - pull it out and it will grow some good pilots back.

ORIGINAL: USS America

And there, ladies and gentlemen, is my "learn something new about this game every day" fact for today. [8D]

Pilot issue is under discussion - main issue is treatment of ongoing games. A "true" fix would mean 1.8.0.7 would only work for new games and would not be a "patch" in the sense that we have done to date. All the 1.8.x.y series of patches will work for ongoing as well as new games.

ORIGINAL: herwin

I understand the problem has been addressed in AE. This is for standard WitP.

Also, the approach in the game produces opaque behaviour, probably making debugging a massive headache. This has the advantage of defining the problem to be an exponential convergence at some rate to a limit--which is what we see in these phenomena. All your variables either influence the rate or the limit.

ORIGINAL: wdolson

ORIGINAL: herwin

I understand the problem has been addressed in AE. This is for standard WitP.

Also, the approach in the game produces opaque behaviour, probably making debugging a massive headache. This has the advantage of defining the problem to be an exponential convergence at some rate to a limit--which is what we see in these phenomena. All your variables either influence the rate or the limit.

As I said, I don't know how stock works, but what's there for AE can probably be dropped into the stock code without any modification. That section of code doesn't use anything new to AE.

Bill