Slitherine

quote:

ORIGINAL: treespider

quote:

ORIGINAL: hades1001

Would you please tell me how fast should a Jap inf div go in this particular hex I highlighted in the pic?
And how do you do the math?

Thanks!

I think your first problem is you are confusing the AE- Secondary Road with the WitP- Trail. The screen shot shows a hex with a secondary road.

IIRC movement rates from one hex to the next is an average of the two hexes.

So assuming the other screen shot above is accurate and the movement was due west...then the movement rate per day would be 4 for the current hex + 15 for the cultivated hex = 19 /2 = 9.5 miles per day modified by disruption and fatigue among other things ...assuming move mode.

quote:

ORIGINAL: CV 2
IMHO, the way it SHOULD work is a unit not in a base draws supply from the closest base. PERIOD. (ed. Closest base being defined as in supply movement points not raw distance - wanted to clarify that). If there arent supplies at that base, then someone (the player) or someTHING (the program) had better move some there. The unit in the bush should die BEFORE the unit in the base does, and the closer a unit is to a given base, the more likely it should be to get supplies from that base vs a unit further away does.

quote:

ORIGINAL: Rainer

m7a with all due respect post #836

quote:

ORIGINAL: Andrew Brown

FWIW I agree with this. There should also be limits on how much supply can move between adjacent bases, based on the supply cost of the move.

Andrew

quote:

ORIGINAL: witpqs

quote:

ORIGINAL: Andrew Brown

FWIW I agree with this. There should also be limits on how much supply can move between adjacent bases, based on the supply cost of the move.

Andrew

Andrew, basing supply solely on the closest base does not make sense, and here is why. Units moving toward the front lines or behind the front lines by any appreciable distance are certainly, IRL, going to be supplied from the base to their rear. The alternative is for supplies to move all the way forward, and then backward. In cases where units are close to the forward base that makes sense. But in cases where the unit is only a little closer, or somewhat closer to the forward base this does not make sense. The problem of course is how is the programmer to sort out which base is which in many situations. I think switching over to that motif would make things worse, not better.

BTW, with the recent Betas I have noticed that supplies flow more slowly in general, and seemingly somewhat smoother with less in the way of dead spaces (meaning bases that are starved while all nearby bases are flush).

quote:

ORIGINAL: championzhao

http://ishare.iask.sina.com.cn/f/11974021.html

1939 China maps

quote:

ORIGINAL: CV 2

quote:

ORIGINAL: witpqs

quote:

ORIGINAL: Andrew Brown

FWIW I agree with this. There should also be limits on how much supply can move between adjacent bases, based on the supply cost of the move.

Andrew

Andrew, basing supply solely on the closest base does not make sense, and here is why. Units moving toward the front lines or behind the front lines by any appreciable distance are certainly, IRL, going to be supplied from the base to their rear. The alternative is for supplies to move all the way forward, and then backward. In cases where units are close to the forward base that makes sense. But in cases where the unit is only a little closer, or somewhat closer to the forward base this does not make sense. The problem of course is how is the programmer to sort out which base is which in many situations. I think switching over to that motif would make things worse, not better.

BTW, with the recent Betas I have noticed that supplies flow more slowly in general, and seemingly somewhat smoother with less in the way of dead spaces (meaning bases that are starved while all nearby bases are flush).

Units coming out of supplied bases have a months worth of supply within the unit itself (in the game), so "feeding" the unit is a non-issue. I dont see what your problem is with it.

If you are talking about if the unit engages in combat "as its moving toward the front" (lets say the "front" it is moving to is the India boarder near Imphal and it engages in combat in the hex north east of Mandalay). You are saying that the bullets should come from Rangoon because thats where the unit started it move weeks ago? Rather than Mandalay where it got off the trains and started moving forward?

I just want to be clear. Is this what you are saying?

Or are you saying that a unit moving to say Akyab from points south should not get their supply from Akyab until they actually get there? Again, because the unit carries enough supply with it to last a month if not in combat, I see this as a non-issue. If it does engage, then clearly the bullets it needs are going to come from the closest source, wouldnt you agree?

quote:

ORIGINAL: asdicus

Using 1108m7 beta in my pbm game vs japs.

if you right click on pilots in the aircraft squadron screen you used to get a list of damaged aircraft repair times etc - with this new m7 beta it just displays the list of squadron pilots same as if you left click on pilots. This was working ok up to m6 beta.

quote:

ORIGINAL: Alfred

quote:

ORIGINAL: asdicus

Using 1108m7 beta in my pbm game vs japs.

if you right click on pilots in the aircraft squadron screen you used to get a list of damaged aircraft repair times etc - with this new m7 beta it just displays the list of squadron pilots same as if you left click on pilots. This was working ok up to m6 beta.

Read post #807.

Alfred

quote:

ORIGINAL: BigDuke66

Is there anything that lifts the limit(Level 7 AF + 20k supply) of upgrading AGs?
If not than I wonder why I can upgrade a unit in Calcutta, supply is big enough but airfield is only level 5.

quote:

ORIGINAL: michaelm

[1108m8]
Added Show speed mode in TF list [MEM]
Tweaked No spoilage on excess supply/fuel at SPS level for bases in first week of scenario [MEM]

quote:

ORIGINAL: erstad

Do any of the beta updates affect the way a few units in an enemy hex will hog all of the supply, leaving other units in the stack in the red? I thought I had seen that somewhere as being addressed, but when I look at the beta fix list in post#1 I didn't see it.

One of my PBEM partners is being disadvantaged by this problem.

quote:

ORIGINAL: littleike

Great support Michaelm!!


Please could you give me an update to a request i made sometime ago for a feature to know the hex coordinates of an
hex hovering with the mouse? You told me that you had to do some tests due to the game engine design but i have seen
nothing from that day on the various patches so i don't know if this implementation is not possible or you dont have had
yet the time to look at that request due all the other hard work you are doing for much important things than this.

In any case, because i would like to mantain things simplest as possible with the minimum effort for you i ask:

If the hovering with the mouse is not possible or too difficult to implement could it be possible to have a toggle key (like the 4 key for the supply)
to show/unshow the hex coordinates of the hexes on the map or (at least) to mark/unmark a single hex for subsequent reference?

Many thanks for your astounding support.

quote:

ORIGINAL: michaelm
I think there are basically 2 DLLs - the one in the main game directory which should be last official one, and the one the beta2 directory off the game directory for m4+ games.
The beta one should be able to handle earlier games as it was  only updated to include an extra piece of data in the save.
The extra complication was that at about the same time Microsoft updated their 2005/8 C++ libraries which got built into the new DLL.

quote:

ORIGINAL: witpqs

This is a small request to help pilot management. Pilot management has been improved so much it's not a huge deal if this can't be squeezed in. I don't mean to be wordy, but to explain the request clearly:

In a squadron on the pilots list you can see the pilots assigned to that squadron. If a pilot has a delay of 0 or 1 you can send him to the general reserve (other conditions being met), but if a pilot has a delay of 2 or more you can not send them to the general reserve. Could this be changed so that you can send a pilot to the general reserve even if they are 'still in transit' to the squadron (have a delay 2 or greater)?

The reason that this would help is that many, many pilots arrive at squadrons long after the squadrons have been deployed to the front lines. Those pilots, while often good with Experience, are poor in skills (this is because the pilots do not have skills assigned in the database). This is just a natural consequence of the pilot skills and the way that players have evolved in their training habits. An example is that front line fighter pilots are considered 'fully trained' by most players when they have about 70 Air skill and some acceptable value of Experience and Def skill. But when a new pilot arrives directly to that front line squadron, the great majority of the time their Air skill is in the 50s (although sometimes in the low 60s or high 40s). Being in a squadron in combat, the player will send that pilot to the reserve as soon as he sees him, and later pull that pilot into a rear area squadron to get his Air skill trained up.

As the game gets into '43 and '44 there are many, many of these pilot arrivals and a lot of squadrons to check. So, the player will often see such a pilot but can not send him to the reserve because the delay is 2 or greater. This means that the player has to remember to go back to check that squadron on the correct turn to catch the pilot with a delay of 1 (before the pilot gets into combat and loses an air frame while getting KIA). Sometimes in fact a squadron will have a few pilots arriving over a few day period, resulting in even more visits to the squadron. If a pilot could be sent to the general reserve straight away regardless of delay then the player could deal with any such pilots as he finds them.

A lot of words to explain a simple concept, but I wanted to show why this proposed change would be of value to players. Thanks for considering it.

quote:

ORIGINAL: viberpol

quote:

ORIGINAL: michaelm
I think there are basically 2 DLLs - the one in the main game directory which should be last official one, and the one the beta2 directory off the game directory for m4+ games.
The beta one should be able to handle earlier games as it was  only updated to include an extra piece of data in the save.
The extra complication was that at about the same time Microsoft updated their 2005/8 C++ libraries which got built into the new DLL.

Michael, doesn't the problems with beta saves and Tracker stem from save file incompatibility? Or it's only because of different dlls used during save?

Something weird happened between m3/m4/m5 betas... previously it was possible to load up a save from beta (m3) with the engine of the latest official patch/official ongoing PBEM installation.
Now when you try to load a save under beta in latest official (it's v1.01.06i me thinks) you've got "save game failed to load" info. It's just a guess, but maybe this is why people have problems with Tracker and the latest betas... any way to fix this incompatibility?