1. A supply CAP basically its th eamount of supplies a base can send or recieve in a single day and its a formula of Supply Cap Number as defined in editor x (Fort+Port+AF - a proxy for infrastructure)

2. Monsoon check box that defines if a bases supply cap should be reduced by 50% during the monsoon.

This is and was a band aid applied to Burma and North Australia but it works.

The suply cap numbers were defined by me and I cannot fully remember how I did it (at work now)

I think it was 50 minimum 50 for every secondary road 100 for a major road 100 for a minor railway 100 for a major railway (200 if only railway in hex) and 50 minor navigatable river 100 major river.

It was something like that cannnot fully recall but it bas basically used to control the amount of supply sent to some areas specifically Burma and Northern Australia

It could be aplied to NG, China etc but we ran out of time on the data patch to test it so had to narrow it down to the two specific problem areas that needed soe kind of fix

One thing they are really needing to address the issues under discussion is an outgoing supply cap. That would limit the number of troops/amount-of-combat/whatever that takes place in bad terrain outside a base. Still takes a bunch of programming, testing and tuning.

Closer to ideal I suppose would be limiting the total number of supply that could pass through a given hex. I presume that would be a pretty big programming, testing, & tuning deal.

The supply cap is better than nothing for sure. And if it is applied using the editor only (without hard coding which I thought was present - apparently mistakenly), then that is all the better.

However there is one thing I would like to see improved with these supply limits: Does the amount of supply able to be pulled to a base with a supply limit dependent on the cost of the supply path? My understanding is that it isn't. If not, then a base in, say, Burma that has a supply cap specified, can only draw that amount whether it is from an Indian base via roadless jungle, or from Rangoon via a railway.

I would prefer the supply cap figure be modified by the supply cost of the supply path to the remote base from which the supply is being transferred. This could be done using a simple formula applied to the supply cap figure to get a modified supply cap value. For example, a formula could be:

Actual supply cap = Supply cap x 100 / (supply path cost + 50)

So a supply path cost of 100 would result in the supply cap being reduced by one third. A low supply cost would result in the cap being almost doubled. This would allow more supplies to be drawn over a low cost path, like a good road or railway, than via a roadless jungle route, which makes sense to me. I do not think that this would be a major modification to make.

Regarding stacking limits for non-island hexes, I think this could be applied by doing the following:

- Add several new "island size" values (currently they range from 0 to 4). The values above 4 could would be used for various terrain types, and differing stacking limit values could be used, apart from the ones used for islands already (6000 and so on). In addition, the effects of the new values could be disablement of excess devices, rather than a supply penalty, as Blackhorse suggests. The new values could then be added to the map data as desired. This would also mean that existing games and official scenarios would be unaffected by the changes (unless the official map data file is updated at some point).

Alternatively, the penalties for exceeding the stacking limits could be changed from the current system to one that combines a gradual disablement of excess devices, plus a supply penalty, and the new system be applied universally, including to islands.

Regarding stacking limits for non-island hexes, I think this could be applied by doing the following:

- Add several new "island size" values (currently they range from 0 to 4). The values above 4 could would be used for various terrain types, and differing stacking limit values could be used, apart from the ones used for islands already (6000 and so on). In addition, the effects of the new values could be disablement of excess devices, rather than a supply penalty, as Blackhorse suggests. The new values could then be added to the map data as desired. This would also mean that existing games and official scenarios would be unaffected by the changes (unless the official map data file is updated at some point).

Alternatively, the penalties for exceeding the stacking limits could be changed from the current system to one that combines a gradual disablement of excess devices, plus a supply penalty, and the new system be applied universally, including to islands.

Andrew

Andrew,

I prefer a universal approach, where practical, and there is a lot to like about the approach you outline above.

For example, for the sake of discussion assume a universal rule that every turn, 20% of devices above the manpower limit are disabled (and perhaps a similar +20% supply penalty). On an atoll, an overstrength attacking force could assault with 80% of its overage on D+1, 64% on D+2, and 51% on D+3. That's enough time to try to overwhelm a maximum-sized defending force on an atoll or a very small island.

Apply the same penalty to land stacks marching through a roadless jungle, swamp, or mountain hex, and after ten days moving through the hex, the overage is reduced to barely 10%. If it takes 15 days to get across the hex, then 96.5% of the overage would be disabled by the time the unit emerges. In any kind of rugged terrain, off-road, "land death stars" would waste away before they could reach the next hex. A rule like this could protect Port Moresby from a corps-sized overland invasion from Buna. It also means that it would not be practical for a defender to overstack atoll defenses for anything more than a few days at a time.

In addition to the daily 20% disablements, for certain types of terrain it would still make sense that all non-infantry or engineer devices with a load cost >9 be disabled when a stack enters the hex, regardless of the stacking limit, if there is no road/rail through the hexside crossed by stack. Easy for me to say -- I have no idea how easy that would be to code.

_____________________________

WitP-AE -- US LCU & AI Stuff

Oddball: Why don't you knock it off with them negative waves? Why don't you dig how beautiful it is out here? Why don't you say something righteous and hopeful for a change? Moriarty: Crap!

I have to wonder, would there be a way to modify the game in such a way that all hexes that have no large roads or rails could have a default stacking limit?

Limit the resupply rate. That's what imposes a stacking limit in reality.

_____________________________

Harry Erwin "For a number to make sense in the game, someone has to calibrate it and program code. There are too many significant numbers that behave non-linearly to expect that. It's just a game. Enjoy it." herwin@btinternet.com

Playing a bit of devils advocate here, what about the commando style units that were designed to work in "hexes" with out roads. Won't this cause an adverse effect on them?

Shouldn't be a problem as those "commando" style units would be sized under the stacking threshold. If they were in the same hex as a moving oversized stack, then they wouldn't be a real commando unit. Think of the Chindits and the Australian commandoes on Timor, they operated well away from main force lines.

I have to wonder, would there be a way to modify the game in such a way that all hexes that have no large roads or rails could have a default stacking limit?

The way I read Andrew Brown's thoughts, and certainly the way I would approach it, is that each type of terrain (mountain, jungle, desert etc) would be given it's own size limit universely. The same as currently all size 1 islands have a 6k stacking limit, all jungle hexes, for arguments sake, be made size 5 which would have a 10k stacking limit. This in turn would be checked to see if a road or railway existed in the hex - if yes then no stacking limit, if no then the universal stacking limit for that type of hex would apply.

ORIGINAL: Alfred The way I read Andrew Brown's thoughts, and certainly the way I would approach it, is that each type of terrain (mountain, jungle, desert etc) would be given it's own size limit universely. The same as currently all size 1 islands have a 6k stacking limit, all jungle hexes, for arguments sake, be made size 5 which would have a 10k stacking limit. This in turn would be checked to see if a road or railway existed in the hex - if yes then no stacking limit, if no then the universal stacking limit for that type of hex would apply.

Alfred

Yes that is pretty much what I am thinking. The change would require map data changes, thus leaving stock scenarios unchanged. It would also be useful if some additional "size" values were accounted for in the code equating to different stacking limit values.

Regarding roads/railways, their presence could be used to increase the stacking limit of a hex, or even make it infinite, which makes sense. The only thing this change does not account for is that units entering such a hex (say, jungle with a road) across a hexside that does not contain a road would not be penalised in any way compared to a unit entering the hex along a road. However trying to account for that as well may make the changes too complex to consider. Any such change would need to be kept simple.

ORIGINAL: Alfred The way I read Andrew Brown's thoughts, and certainly the way I would approach it, is that each type of terrain (mountain, jungle, desert etc) would be given it's own size limit universely. The same as currently all size 1 islands have a 6k stacking limit, all jungle hexes, for arguments sake, be made size 5 which would have a 10k stacking limit. This in turn would be checked to see if a road or railway existed in the hex - if yes then no stacking limit, if no then the universal stacking limit for that type of hex would apply.

Alfred

Yes that is pretty much what I am thinking. The change would require map data changes, thus leaving stock scenarios unchanged. It would also be useful if some additional "size" values were accounted for in the code equating to different stacking limit values.

Regarding roads/railways, their presence could be used to increase the stacking limit of a hex, or even make it infinite, which makes sense. The only thing this change does not account for is that units entering such a hex (say, jungle with a road) across a hexside that does not contain a road would not be penalised in any way compared to a unit entering the hex along a road. However trying to account for that as well may make the changes too complex to consider. Any such change would need to be kept simple.

Andrew

Simplicity is good!

Sure, having the distinction of whether an LCU enters via a hexside with or without a road/railway would be a nice touch, it isn't really that important.

The entire logistical aspect of the game is extremely abstracted as it is. Roads are divided only into major or minor. No allowance is made for how many lanes, how much tar weight they can support, the cost/transportation cost of fixing normal wear and tear, how big the local truck park is, the differences in average speeds between one road with another "similar" road et al.

To me, in the context of the game's abstracted logistical model, the much more important point is whether there is or isn't a road/railway in the hex which facilitates the movement of units and supplies. Hence I would go with simplicity; if road/railway present no stacking limit, if no road/railway present stacking limit associated with that type of terrain applies.

Playing a bit of devils advocate here, what about the commando style units that were designed to work in "hexes" with out roads. Won't this cause an adverse effect on them?

If you disregard the Hollywood versions of these and go back to original sources you'll see they had a helluva job operating and when they came out of the operation were wrecked units. See my previous comment on this thread for the book to read.

ORIGINAL: Alfred The way I read Andrew Brown's thoughts, and certainly the way I would approach it, is that each type of terrain (mountain, jungle, desert etc) would be given it's own size limit universely. The same as currently all size 1 islands have a 6k stacking limit, all jungle hexes, for arguments sake, be made size 5 which would have a 10k stacking limit. This in turn would be checked to see if a road or railway existed in the hex - if yes then no stacking limit, if no then the universal stacking limit for that type of hex would apply.

Alfred

Yes that is pretty much what I am thinking. The change would require map data changes, thus leaving stock scenarios unchanged. It would also be useful if some additional "size" values were accounted for in the code equating to different stacking limit values.

Regarding roads/railways, their presence could be used to increase the stacking limit of a hex, or even make it infinite, which makes sense. The only thing this change does not account for is that units entering such a hex (say, jungle with a road) across a hexside that does not contain a road would not be penalised in any way compared to a unit entering the hex along a road. However trying to account for that as well may make the changes too complex to consider. Any such change would need to be kept simple.

Andrew

Simplicity is good!

Sure, having the distinction of whether an LCU enters via a hexside with or without a road/railway would be a nice touch, it isn't really that important.

The entire logistical aspect of the game is extremely abstracted as it is. Roads are divided only into major or minor. No allowance is made for how many lanes, how much tar weight they can support, the cost/transportation cost of fixing normal wear and tear, how big the local truck park is, the differences in average speeds between one road with another "similar" road et al.

To me, in the context of the game's abstracted logistical model, the much more important point is whether there is or isn't a road/railway in the hex which facilitates the movement of units and supplies. Hence I would go with simplicity; if road/railway present no stacking limit, if no road/railway present stacking limit associated with that type of terrain applies.

Alfred

I always wondered if this is an attribute you could add to a hexside, like the one which designates the ownership. At least it looks like the same location could be used to store such data. Developing this further you could also designate in which direction a road/rail goes contrary to current road/rail yes/no.

I'm a little lost by the discussion of roads and hex sides. What I mean is, the pwhex already contains data on which hex sides have what kind of roads, and the code already uses that information for both unit movement and supply movement.

I'm a little lost by the discussion of roads and hex sides. What I mean is, the pwhex already contains data on which hex sides have what kind of roads, and the code already uses that information for both unit movement and supply movement.

Yes it does, as well as telling the game which hex sides have roads and those that do not.

One interesting thing is that you could set up hexes to be 'impenetrable jungle' on all but 2 sides, thuse forcing a trail through the hex, even without a trail being there. Remember any hex-side that shows as red can not be crossed by any means. With some hex editing, you could make a trail through the Owen Stanley Mtns range simply by choosing the correct trail, and making it so that only a 'trail' of hexes can cross it.

This seems like a lot of work for what is essentially a minor area though. But that is just my opinion.

ORIGINAL: witpqs I'm a little lost by the discussion of roads and hex sides. What I mean is, the pwhex already contains data on which hex sides have what kind of roads, and the code already uses that information for both unit movement and supply movement.

I don't normally participate in map discussions because I really don't know that much about it, and, trusting in Andrew, don't really care in large measure. But some of the suggestions in the thread have tweaked my interest.

Understand that the Owen Stanleys have written about, described, cussed, and discussed, ad infinitum. And there are an infinite set of data that can be used to compel any sort of movement restriction that anyone desires.

The only problem with all this is there are thousands of hexes that are susceptable to the same kind of strict specificity demands and imperatives (both positively and negatively). It opens a Pandora's Box of unintended consequences, as I have found in every other area of the game. Making a change to the whole on the basis of a change to a single, individual, part, no matter how historically "relevant", will distort the whole as the square of the changes to the part. Without "COMPLETE", "CONSISTENT" and "UNIFIED" approach that applies to "EVERY SINGLE HEX", "AT THE SAME TIME", "EVERYWHERE", all you are going to do trade one known can of worms for a rain of vipers and salamanders. What are ya gonna do to the connection between Subic and Olongapo? Swettenham, Batu Pahat? "Secret" Samarinda II? And don't even think about China/Burma!

Having said this, there is one approach I really like; again fraught with horror, but having a certain elegance.

I like the idea of not allowing movement through certain terrain types by certain Devices. Those Devices could be tagged in a way similar to light, medium, heavy, vehicle equipment in accord with the ship and plane load cost factors, i.e., squads and light mortars and tigers may move through the hex; anything bigger, and bears, oh my, can't. Huge coding bitch, allowing LCUs to strip off their heavys; talking fragments and all of that horror show. And should it be limited to no more than regiment size LCUs? And if so, why? Just 'cause Kokoda was a bitch, should the limitation apply to China/Burma interface? And what to do with all the fragments left on the back-side of a bad-boy hill? Disband them, and let Chinese units rebuild in Burma/India? But that would also allow Japanese regiments to rebuild in Moresby, so yet another can of worms.

What I'm saying is ... it ain't as easy as just applying it to a single, specific situation. One must think it through to the bitter end. Once that's done and it works, we got a winner. Otherwise, we got a wiener.

ORIGINAL: witpqs I'm a little lost by the discussion of roads and hex sides. What I mean is, the pwhex already contains data on which hex sides have what kind of roads, and the code already uses that information for both unit movement and supply movement.

I don't normally participate in map discussions because I really don't know that much about it, and, trusting in Andrew, don't really care in large measure. But some of the suggestions in the thread have tweaked my interest.

Understand that the Owen Stanleys have written about, described, cussed, and discussed, ad infinitum. And there are an infinite set of data that can be used to compel any sort of movement restriction that anyone desires.

The only problem with all this is there are thousands of hexes that are susceptable to the same kind of strict specificity demands and imperatives (both positively and negatively). It opens a Pandora's Box of unintended consequences, as I have found in every other area of the game. Making a change to the whole on the basis of a change to a single, individual, part, no matter how historically "relevant", will distort the whole as the square of the changes to the part. Without "COMPLETE", "CONSISTENT" and "UNIFIED" approach that applies to "EVERY SINGLE HEX", "AT THE SAME TIME", "EVERYWHERE", all you are going to do trade one known can of worms for a rain of vipers and salamanders. What are ya gonna do to the connection between Subic and Olongapo? Swettenham, Batu Pahat? "Secret" Samarinda II? And don't even think about China/Burma!

Having said this, there is one approach I really like; again fraught with horror, but having a certain elegance.

I like the idea of not allowing movement through certain terrain types by certain Devices. Those Devices could be tagged in a way similar to light, medium, heavy, vehicle equipment in accord with the ship and plane load cost factors, i.e., squads and light mortars and tigers may move through the hex; anything bigger, and bears, oh my, can't. Huge coding bitch, allowing LCUs to strip off their heavys; talking fragments and all of that horror show. And should it be limited to no more than regiment size LCUs? And if so, why? Just 'cause Kokoda was a bitch, should the limitation apply to China/Burma interface? And what to do with all the fragments left on the back-side of a bad-boy hill? Disband them, and let Chinese units rebuild in Burma/India? But that would also allow Japanese regiments to rebuild in Moresby, so yet another can of worms.

What I'm saying is ... it ain't as easy as just applying it to a single, specific situation. One must think it through to the bitter end. Once that's done and it works, we got a winner. Otherwise, we got a wiener.

Well somehow (?) I am still ok with like it is (don´t break/change what actually may work not as bad as some of you think if you get my drift??) , yeaaahh it is a bit unrealistic (esp. with heavy weapons) but you should also consider how long it takes in game to slog through this area(s)... you can count this in weeks actually. So this will also mean your troops marching there are "out of the game" for quite a while. Means: There is already a disadvantage if you decide to march so much troops through these areas.....what if you need them suddenly at another place ? Also player no.2 can easily recon these masses and take some precautions....(imo)

Another point: In the case of the game GJ vs. Rader you need also consider that this is scen 2 which gives the Jap some (much?) more assets. So in this scen it is possible for Japan to mass this much troops.... maybe it is not in Scen 1 ? Also in case of Allies as far as I know they walked through this area in reality and took Buna finally The Japs tried it before to reach PM but got bogged down, but if the resistance of the Aussies wasn´t there I bet they would have reached PM also. Taking of the palce would be another matter of cause. The Allied stopped the Jap OUTSIDE PM in the junge.....in reality...if I am wrong please advise.

In 1 sentence: Don´t fix what is not (really) broken

However I would like a change that units in cities are better supplied as those NEAR the cities, like in China or Malaysia seems to case (bit OT but still).

Just noticed this thread. Supply movement is a little broken, but it definitely cuts both ways. I was actually alerted to the fact that the Own Stanleys were no supply issue because in my other game, Jzanes marched a huge army from from PM to Buna as the allies. And even more broken is that the allies seem to have no trouble pulling supplies from india deep into Burma - this is the main reason IMO why Burma is practically impossible to defend as Japan and we see it fall in 1943 or so in almost every game. I would be the first to support increased supply movement difficulty, but it must be done at the army, not unit level. If you simply check/limit supply unit-by-unit, that actuallt encourages more units to pile along a poor supply line because each of them draw supplies individually. I.e., it would be much better if you could supply up to, say 5000 men equivalent *no matter how many units they were in*, rather than say each unit, no matter if there are 3 or 100, have some supply limit. Of course this is much harder to code.

On the subject, I actually hate automatic supply movement between bases. I wish we just had a click-click button we could press to move supply overland between bases (with some loss and imposed supply movement limits each turn that would build up over time to a maximum of say every 10 days). But I think that's another thing that's harder to code...

Hmm... just a thought: bases in Burma/North Australia have supply draw caps... is it not possible to put supply draw caps on terrain-specific non-base hexes for drawing supply to units in a hex? I.e., can only draw up to 50 supply per turn to ALL units located IN or THROUGH a rough jungle/mountain hex? This would also force people to spread out their forces more and rsult in less of a 'Death Star' style combat system.

Just noticed this thread. Supply movement is a little broken, but it definitely cuts both ways. I was actually alerted to the fact that the Own Stanleys were no supply issue because in my other game, Jzanes marched a huge army from from PM to Buna as the allies. And even more broken is that the allies seem to have no trouble pulling supplies from india deep into Burma - this is the main reason IMO why Burma is practically impossible to defend as Japan and we see it fall in 1943 or so in almost every game. I would be the first to support increased supply movement difficulty, but it must be done at the army, not unit level. If you simply check/limit supply unit-by-unit, that actuallt encourages more units to pile along a poor supply line because each of them draw supplies individually. I.e., it would be much better if you could supply up to, say 5000 men equivalent *no matter how many units they were in*, rather than say each unit, no matter if there are 3 or 100, have some supply limit. Of course this is much harder to code.

On the subject, I actually hate automatic supply movement between bases. I wish we just had a click-click button we could press to move supply overland between bases (with some loss and imposed supply movement limits each turn that would build up over time to a maximum of say every 10 days). But I think that's another thing that's harder to code...

As an Allied player I certainly have not had the experience you cite here. In Andy Mac's AAR he gives a good accounting of how much supply he can draw and what kind of troops that can support, which I believe is after he maxed out the bases along the border.

Just noticed this thread. Supply movement is a little broken, but it definitely cuts both ways. I was actually alerted to the fact that the Own Stanleys were no supply issue because in my other game, Jzanes marched a huge army from from PM to Buna as the allies. And even more broken is that the allies seem to have no trouble pulling supplies from india deep into Burma - this is the main reason IMO why Burma is practically impossible to defend as Japan and we see it fall in 1943 or so in almost every game. I would be the first to support increased supply movement difficulty, but it must be done at the army, not unit level. If you simply check/limit supply unit-by-unit, that actuallt encourages more units to pile along a poor supply line because each of them draw supplies individually. I.e., it would be much better if you could supply up to, say 5000 men equivalent *no matter how many units they were in*, rather than say each unit, no matter if there are 3 or 100, have some supply limit. Of course this is much harder to code.

On the subject, I actually hate automatic supply movement between bases. I wish we just had a click-click button we could press to move supply overland between bases (with some loss and imposed supply movement limits each turn that would build up over time to a maximum of say every 10 days). But I think that's another thing that's harder to code...

As an Allied player I certainly have not had the experience you cite here. In Andy Mac's AAR he gives a good accounting of how much supply he can draw and what kind of troops that can support, which I believe is after he maxed out the bases along the border.

witpqs,

What you say about Andy Mac's AAR is quite correct but I feel it isn't a good riposte to rader's point. Andy is quite conservative in his logistical arrangements. He very much pays attention to ensuring his units are able to be 100% supplied, those which can't be are sent back to where they can be.

Rader on the other hand is alluding to a situation where a player doesn't mind pushing on even though his units will not be 100% supplied. Those units will receive some supply and even if they were completely wihout supply, they still retain 25% of their AV. This also overlooks those situations where the march is of such a short distance that the intrinsic organic supply embedded in the units at the start of the march will suffice to get them to their destination in reasonable shape. There are situations where a big enough sized mass will trump under supply.

I think the two situations you cite are quite acceptable. If the march is short such that on-hand supply suffices that should not be unhinging anything. The other case - where units will be as low as 25% combat effective seems also to be no problem. It forces the Allied player to bring from twice (for 50% effective) to four times (for 25% effective) the forces.

Also relevant is my own experience. I found overland supply only trickling into my most forward base, yet my opponent (without any factual basis) complained as though supply must be flowing there with fire hose ferocity. Bizarrely, the complaint was forthcoming even though no land combat had taken place in Burma since the Allies' return there. I'm wondering if Rader's perception is being influenced by reports of that nature. I noted he wrote "seem" and guess that he might be going by the reports of others.

ORIGINAL: LoBaron Create a dot base with size -3,-3, built up to size 0 (or if possible a base which cannot be built up which would yield the same result). This way no airbase or port can be created but you can assign attributes usually limited to bases.

That is very interesting suggestion, however I am not sure base limitations apply for side not-controlling the base (although it is possible base will auto-convert, if there is no friendly unit in it). Obviously there is no reason to conquer it, if it will only limit your operations But still, it will probably block your supply path.

As a side note, if Kokoda Track is THE ONLY path between Buna, and Port Moresby, there should exist NO other supply path, between eastern coast, and PM. That would require special terrain type, with supply cost of 99, to not let any supply to travel through this hex. Example of such solution you can see in picture below.

quote:

ORIGINAL: Andrew Brown Another possibility is to apply the island hex stacking limits to hexes with difficult terrain, to limit the size of the force that can be placed in a single hex, even in non-island hexes. Such limits might have to take into consideration the presence of roads/railways, however.

Excellent idea! If the extra supply is taken also from unit pool, that should solve most problems.

1. A maximum of 6,000 men in Jungle, Jungle Rough, or Mountain hexes 2. All devices above this limit are disabled 3. All non-infantry / non-engineer devices with a load cost >9 are disabled (mortars and pack howitzers can make the trek, but not vehicles and heavier artillery)

And how will they be "enabled/repaired" later? Automatically, or by normal means? Actually, that got me thinking... Should not every large Device be "disabled" when loaded on ship in Transport TF? After all, they will be disassembled for ease of transportation.

quote:

ORIGINAL: Alfred

quote:

ORIGINAL: oldman45

Playing a bit of devils advocate here, what about the commando style units that were designed to work in "hexes" with out roads. Won't this cause an adverse effect on them?

Shouldn't be a problem as those "commando" style units would be sized under the stacking threshold. If they were in the same hex as a moving oversized stack, then they wouldn't be a real commando unit. Think of the Chindits and the Australian commandoes on Timor, they operated well away from main force lines.

Maybe we need third LCU type (there is now only Infantry, and Motorized type)? Namely "Light Unit", which would have not get supply/move penalties in difficult terrain? And, in the same time, increasing those penalties for other LCUs?

quote:

ORIGINAL: Shark7 One interesting thing is that you could set up hexes to be 'impenetrable jungle' on all but 2 sides, thuse forcing a trail through the hex, even without a trail being there. Remember any hex-side that shows as red can not be crossed by any means. With some hex editing, you could make a trail through the Owen Stanley Mtns range simply by choosing the correct trail, and making it so that only a 'trail' of hexes can cross it.

Another solution will be to put impenetrable borders in such a way to create longer paths. Not quite historical, but take a look at my example. That way there is always at least 2 hexes between Buna, and PM.

The Kokoda Track was the best route over the Owen Stanleys. It was not the only track across them.

I very much suspect the answer from the devs to your suggestion of a new LCU type is the same as the famous American answer to the German demand at Bastogne to surrender. Besides there already are more than two types of LCU plus the issue is not really about LCUs but the different types of devices within them.

It is my impression that it is far to difficult to move overland - in particular at PM - at least unless you are using a revised pwhexe file. As I reported about two months ago, there are NO trails at all in New Guinea - or in the NW Frontier of India/Burma area - so units will not tend to use the existing trails - and supplies cannot use them. I also found no trails on other places - although sometimes there are what looks like efforts to "program" the game by defining dissimilar trails, roads, nothing, etc - on a hex side basis - something I approve of entirely. Probably a lack of time prevented this being done for the entire map area.

The larger problem LoBaron is trying to address here is fairly easy to fix. Adopt something like the basic "house rule" of RHS: "It is it impossible, or if it is utterly impractial, or if you do not believe historical commanders would try it - don't do it." I have indeed seen a quarter of a million men reducing PM - all the way back to Uncommon Valor - but the reason for that is players not being reasonable about the forces committed.

Clearly a regiment could cross on the Kokota Trail - the 144th Regimental Combat Team (aka the South Seas Regiment) did just that - and then attacked - and won the battle for the position it attacked - never mind the (Aussie) Allies held the high ground and had not been depleted by crossing the Owen Stanley Range. The 144th was heartbroken when ORDERED to withdraw - having paid such a high price. It was not logistically broken or combat broken into giving up the campaign. It was events on Guadalcanal that caused the order to be given.

That does not mean corps or army size forces can use the tracks. In some game systems, if you put too much traffic on a trail or secondary road - it disappears! All you need not to have this problem is an agreement with players not to attempt such things.

Burma/India is a more interesting question. The Allies in Burma indeed evacuated the place using the trails. They also used them effectively in some of the campaigns. Then too, they build roads - something not easy for us to do here - so much of the later campaign used, for example, the Ledo Road as a logistical support element. Wether the Japanese offensive was realistic is very much in doublt? It is often written the planners simply did not understand the conditions - and certainly they did not understand the scale of the forces opposing them - or their preparations. Yet in fact they did cross using the trails - in corps strength - and the units did also cross back again - they were not actually wiped out in most cases. I do not think the game is going to be kind to an army crossing there vs an enemy army well dug in with lots of support - so I am not sure there is a problem with the defenders being overwhelmed by too many troops at all? Attacking an enemy frontally when he has the high ground, when you have lousy to non-existant lines of communications, and poor intelligence is pretty unlikely to work out well. Not sure any modifications are needed - other than that the two principle trails should be in the pwhexe file - so units will prefer these routes over just crossing anywhere.

The logistic penalty for using non-trail hexes is very severe. The vast majority of supplies are lost moving just a single hex - and you cannot move - if I remember correctly - more than four hexes period. You might use units to extend the LOC - units can hand supply to each other I think - but the greater the distance - the worse the cost. When you add slow movement, fatigue due to malaria as well as the effort of moving and fighting, it gets pretty bad pretty fast. So the system is actually pretty good. You are wiser to sail around the jungle than to march through it - unless the other end is close and not well defended.