Matrix Games Forums

What fixes or improvements will be in WITP 1.807?

Undecided. We have this little other thing that's more important to finish first.

Hi Terminus. Spreckin Zie Deutche? If not 'vas los'?[:D]

There is some discussion about what fixes from AE can be ported over to WitP for patch 1.807, but it hasn't gotten very far yet.

Bill

ORIGINAL: Footslogger

Hi Terminus. Spreckin Zie Deutche? If not 'vas los'?[:D]

Hi Footslogger,
Just to let you know, it has to be:
"Hi Terminus. Sprechen Sie deutsch? If not "was ist los" ?[;)]

ORIGINAL: Kaletsch2007

ORIGINAL: Footslogger

Hi Terminus. Spreckin Zie Deutche? If not 'vas los'?[:D]

Hi Footslogger,
Just to let you know, it has to be:
"Hi Terminus. Sprechen Sie deutsch? If not "was ist los" ?[;)]

If Terminus did not speak German....why would you ask him a question in German??

Fragen sie?

Jeg taler dansk.
I speak English.
Ich spreche Deutsch.
Je parle Francais.

Before we put 1.8.0.7 on the shelf roughly late 2007 - I had added in about 7 changes - not even sure I recall what they were (they are of course documented in the change log in the code [:)]) except I remember the "fuzzy flak gap" was in there. When we take 1.8.0.7 back off the shelf, Yammy and I will be the primary 1.8.0.7 work team - I will be the coder he will be the priority setter and the test team. We already have a thread going in the DEV forum to list out ideas. We will solicit suggestions from the AE Team - and we have the public wish list to draw from as well. But primarily we will be trying to put in the "bug fixes" that are in AE that provide the most "bang" for the "buck". In this case the "buck" being the amount of coding time I will have. Some things that might be considered to be "bug fixes" will not be portable - because the AE solution might rely on a completely different process. But a number of "bug fixes" will directly port. So these will be candidates because they will be "low buck". But then we also want to consider the "bang" and YH will be the "bang judge". So the problem is to maximize the "bang" with minimal "buck". My personal priority will be to try to port over some of the "synch bug" improvements we've put into AE - that is about all I really have on my "personal list".

Sounds bang on, yer buckaroo. [:D]

Seriously, Consider making it a consideration just how many people will still actually play stock after AE is released. I know that some will finish PBM's, and perhaps a very few will just stick with it. Beyond that, maybe a poll or something. I suggest this simply from the point of view of not wanting to waste your time. Even if certain changes are 'high buck', maybe the number of people impacted make some of them 'low buck' if only a very small number plan to continue with stock. Just IMO.

I suspect I will continue to play WITP. I would like to see way points added. I understand there is a problem with pilots disappearing and would like to see that fixed as well.

Waypoints are a clear AE enhancement - not a WITP "bug fix" - so waypoints are not a candidate for 1.8.0.7.

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.

As to how many people will play WITP - we cannot know. We believe the forum represents only a (very vocal) fraction of the players - and may not even be representative - but as to the "silent majority" we have no data.

The "pilots disappearing" appears mainly due to player abuses of the system. By this I mean putting 200 pilots in a group and then wondering why you ran out of pilot slots. The only way to "fix" this is to enlarge the array that holds pilots. And I would think that this option wouldnt be able to be implemented in ongoing games.

ilots disappearing" appears mainly due to player abuses of the system. By this I mean putting 200 pilots in a group and then wondering why you ran out of pilot slots. The only way to "fix" this is to enlarge the array that holds pilots. And I would think that this option wouldnt be able to be implemented in ongoing games.

I see. Then that should not be a problem. In my early games, I tended to respond to the request to add pilots to a squadron that was split, not realizing that some pilots were back in the original airfield. Once I figured that out, I dont add pilots until the squadron is back together. If you have 200 pilots and 24 planes, then the exp level isnt going to up up real fast.

In the stock games we've looked at that had the "pilot array overflow" issue - the number of pilots in some air units was in the many hundreds. What players cannot see in stock is the pilots that are wounded. These pilots are still in the air unit. Hecque even the dead ones are. Every pilot that was ever in the air unit is always in the air unit - at least that is the original design. So if an air unit losses 500 planes during the war - and has 50 current pilots and 50 wounded pilots - then it could have 600 total pilots.

Now over the patches we've added as much to the pilot array as we can - given the current data structure (meaning allowing current games to continue to be played) and we've added more and more "culling" of the dead pilots. This pushes out the "date of doom" when a game overflows the pilot array and suffers pilot loss - but a full solution requires changing the data structure and thus would only apply to newly started games.

BTW in AE a player will be able to see all the pilots in the pools - if a player could see this in stock - he might pull his units out of the line for a few weeks and let the wounded pilots return - as it stands now - we have to cull some of these pilots to postpone the doom - and this penalizes the player for always refilling his air units immediately because we have to kill off the more experienced wounded pilots - but the player does not know this in stock - because he cannot see the wounded pilots.

BTW in AE a player will be able to see all the pilots in the pools - if a player could see this in stock - he might pull his units out of the line for a few weeks and let the wounded pilots return - as it stands now - we have to cull some of these pilots to postpone the doom - and this penalizes the player for always refilling his air units immediately because we have to kill off the more experienced wounded pilots - but the player does not know this in stock - because he cannot see the wounded pilots.

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?

ORIGINAL: jwilkerson

As to how many people will play WITP - we cannot know. We believe the forum represents only a (very vocal) fraction of the players - and may not even be representative - but as to the "silent majority" we have no data.

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

AE doesnt require any more hardware than WitP.

Edit: At least to play. Sending save files gets a little taxing as the game goes on. Treespider has resorted to using "You Send It" in our current game.

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.

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;

BTW, if you want me to write a operator()(double mean) implementation for poisson, I can. It has to be done carefully, and I can't dash it off here. You need to tell me what compiler to use and how you handle random number generation.