OK so we have two different issues here. One is what affects a unit to rout and what affects it during the rout. The decision to Rout is first kicked off by a UnitMoraleCheck() function. This occurs each minute. I won't go into all the details as the algorythm runs for 500 lines. Suffice to say that yes it factors in nearby friendly ( and enemy ) retreaters. It determines the differential in retreat/rout personnel between friendly and enemy troops. The adjustment applied to the morale level will vary between 10 and 40%. Typically if there were 300 other friendly retreaters/routers nearby and no enemy then the effect would be to reduce the morale by around 16%. BTW the function also factors in the presence of a nearby superior HQ, adding in a mod based on its leadership, which could be negative if the guy is a jerk :).

OK so we have two different issues here. One is what affects a unit to rout and what affects it during the rout. The decision to Rout is first kicked off by a UnitMoraleCheck() function. This occurs each minute. I won't go into all the details as the algorythm runs for 500 lines. Suffice to say that yes it factors in nearby friendly ( and enemy ) retreaters. It determines the differential in retreat/rout personnel between friendly and enemy troops. The adjustment applied to the morale level will vary between 10 and 40%. Typically if there were 300 other friendly retreaters/routers nearby and no enemy then the effect would be to reduce the morale by around 16%. BTW the function also factors in the presence of a nearby superior HQ, adding in a mod based on its leadership, which could be negative if the guy is a jerk :).

So a more isolated (from other friendly) unit, is likely to get a rout trigger more oftenly (other factors left aside). Is physical distance a matter, or just visual distance? In example, two adjacent infantry Coys in a thick wood do not have LOS to each other, will it help to broaden the footprint of one or both, so they get in visual liaison to each other? Does that help for rout triggering, or avoiding?

Would be nice if statements like yours above, make it into the game manual anytime.

500 lines. Wow. Just for that. How many lines of code for the entire engine?

Thanks for the clarification.

Thats why fixes etc can take awhile..their dealing with a huge programme and I presume several thousand of lines of code minimum. It's why I say we have to be patient with CO, work wont stop on it even if it seems to take awhile to get a fix we'd like.

If I described in detail everything in the code the manuals would be so big no one would ever read them. I reckon most users would prefer I spend my limited time on coding rather than writing up manuals.

If I described in detail everything in the code the manuals would be so big no one would ever read them. I reckon most users would prefer I spend my limited time on coding rather than writing up manuals.

Well, not describing everything, rather supplementing key features that are asked for repeatedly in the forum. What about simovitch, MarkShot and Golf33, since these are mentioned to be suplementing authors for the manuals?

Dave and Co I imagine are too busy to redo the whole manual. Also the ones you mentioned aren't employed ..MarkShot for instance I'm not sure he still plays the game or even owns BFTB.

I can see Dave's point,, where do you stop when it comes to explaining things, Blimey Daves patch update rundowns\list mean nothing to me mostly so it's likely most of the info will wont mean anything unless you knew the code or coding language.

Harry your very much into details and finding out exactly how the game operates and I'm not so certain many are bothered enough to read that kind of thing aslong as the game appears to play within the realms of reality. Not sure if the time spent on it would be worth the detraction from improving the game and working on the new titles. I haven't read the manual since the HTTR manual came out.

I already posted this in the Patch thread but I guess here is a better place for it:

I wonder if there is a way to make the distance that a routed unit moves more variable without narrowing it too much, the other posts already mention that the retreat range was too low, then too high and I guess no matter what values are used there will be agaij and again situations where those values just don't fit. I thought about a check that compares the current view range for the unit against the distance retreated and if the view range is smaller than the distance moved the unit would stop. This should make units reaching covers like wood or dents in open ground that break the line of fire & sight use these beneficial positions for recovery.

The obvious follow on question is in what direction do we test this for in one direction you may be able to see only 300m but in another 3000m. Even if you assume back towards the location you routed from, this would mean we would have to store that loc, but it also ignores any other enemy threats that may be at a different angle than back to the point of origin. We have to be very careful here that we don't halt the router in a spot which is in dead ground to one enemy threat but totally exposed to another.

But in any event all this presupposes that the routers are behaving rationally, that they can cooly assess the situation around them and make optimum decisions. This is not what happens. Routers panic and in panic the focus is on fleeing. There are many cases where routers have fled for many kilometers unchecked.

Take a look at the mods I have made for the new public beta build 4.4.256 that will be out in the next few days and then we can discuss this further.