Musings over the future of backwards compatibility
Moderators: Panther Paul, Arjuna
- Deathtreader
- Posts: 1058
- Joined: Tue Apr 22, 2003 3:49 am
- Location: Vancouver, Canada.
Musings over the future of backwards compatibility
Hi all,
Musing over the many directions the the series could go down the road leads to a couple of questions/observations (none critical in intent) born of a few threads in the COTA forum:
1/ Will BFTB be able to import Estabs and/or maps and/or scenarios from COTA?? This might save many requests from the community for you to update existing estabs etc. for inclusion in the next releases. Adding updated HTTR estabs to BFTB being the prime example. If not doable for BFTB is it something you would consider for the next game in the series?? Ditto with the maps and scenarios. I admit I've no idea how much work this would entail.... but I'd be willing to pay an additional 10 to 15 per cent to have this ability -- ideally for all 3 components but I'd settle for 1 or 2.
2/ In terms of the discussion surrounding the availability of of an estab editor would you consider updating the estabs of previous releases with each new release in lieu of a marketable editor or # 1 above?? This would allow the community to at least do their own retrofits if so inclined. Or could be packaged as a seperate download for say 10 bucks.... or maybe "bonus" estabs with each release or as an add on that are related to the topic of that release such as a set of Yugoslavian estabs to go with COTA for example so that scenarios could be generated in that theatre concerning the initial German assault..
Just musings on a quiet rainy day..... with perhaps more to follow (if I don't drift off to sleep first). [>:]
Rob. [:)]
Musing over the many directions the the series could go down the road leads to a couple of questions/observations (none critical in intent) born of a few threads in the COTA forum:
1/ Will BFTB be able to import Estabs and/or maps and/or scenarios from COTA?? This might save many requests from the community for you to update existing estabs etc. for inclusion in the next releases. Adding updated HTTR estabs to BFTB being the prime example. If not doable for BFTB is it something you would consider for the next game in the series?? Ditto with the maps and scenarios. I admit I've no idea how much work this would entail.... but I'd be willing to pay an additional 10 to 15 per cent to have this ability -- ideally for all 3 components but I'd settle for 1 or 2.
2/ In terms of the discussion surrounding the availability of of an estab editor would you consider updating the estabs of previous releases with each new release in lieu of a marketable editor or # 1 above?? This would allow the community to at least do their own retrofits if so inclined. Or could be packaged as a seperate download for say 10 bucks.... or maybe "bonus" estabs with each release or as an add on that are related to the topic of that release such as a set of Yugoslavian estabs to go with COTA for example so that scenarios could be generated in that theatre concerning the initial German assault..
Just musings on a quiet rainy day..... with perhaps more to follow (if I don't drift off to sleep first). [>:]
Rob. [:)]
So we're at war with the Russkies eh?? I suppose we really ought to invade or something. (Lonnnng pause while studying the map)
Hmmmm... big place ain't it??
- Sir Harry Flashman (1854)
Hmmmm... big place ain't it??
- Sir Harry Flashman (1854)
RE: Musings over the future of backwards compatibility
It's been mentioned somewhere that HTTR Estabs have been included in BFTB.
Gen. Montgomery: "Your men don't salute much."
Gen. Freyberg: "Well, if you wave at them they'll usually wave back."
Gen. Freyberg: "Well, if you wave at them they'll usually wave back."
RE: Musings over the future of backwards compatibility
HTTR estabs will be included in the BFTB estab file. HTTR maps can be converted within the BFTB MapMaker. However, scenarios cannot - there's just too many changes since then. So it will be up to users to redesign the HTTR scenarios as they see fit. We will not be doing so.
COTA estabs will not be rolled into the BFTB estab file.
COTA estabs will not be rolled into the BFTB estab file.
RE: Musings over the future of backwards compatibility
What do the estab files contain? What is the advantage in including them in BFTB without scenarios?
Thanks
Thanks
RE: Musings over the future of backwards compatibility
bink,
The estabs contain the base level or generic data for each type of unit. You need these to build a force list. In the ScenMaker you create a unit and assign it an estab. This seeds the unit with a set of data common to all units using that estab - eg how many and what type of weapons it has, the number of personnel etc. The individual estabs are contained within a single compiled estab file. When you create a scenario in the ScenMaker, you must link to an estab file.
So by incorporating the HTTR estabs within the BFTB estab file we will give access to scenario designers to the full range of estabs necessary to recreate any of the HTTR battles/scenarios.
The estabs contain the base level or generic data for each type of unit. You need these to build a force list. In the ScenMaker you create a unit and assign it an estab. This seeds the unit with a set of data common to all units using that estab - eg how many and what type of weapons it has, the number of personnel etc. The individual estabs are contained within a single compiled estab file. When you create a scenario in the ScenMaker, you must link to an estab file.
So by incorporating the HTTR estabs within the BFTB estab file we will give access to scenario designers to the full range of estabs necessary to recreate any of the HTTR battles/scenarios.
- Deathtreader
- Posts: 1058
- Joined: Tue Apr 22, 2003 3:49 am
- Location: Vancouver, Canada.
RE: Musings over the future of backwards compatibility
ORIGINAL: Arjuna
HTTR estabs will be included in the BFTB estab file. HTTR maps can be converted within the BFTB MapMaker. However, scenarios cannot - there's just too many changes since then. So it will be up to users to redesign the HTTR scenarios as they see fit. We will not be doing so.
COTA estabs will not be rolled into the BFTB estab file.
Hi,
Didn't know about being able to convert the HTTR maps with BFTB's MapMaker. Is this a new feature or more evidence of my imperfect understanding of the game's existing capabilities?? Great news either way.........
I also gather that my ramblings about some way to obtain updated existing estabs with each new release were not terribly well received?? Even if enough of us were willing to pay a little extra to cover the cost of someone's time?? You can hardly fault people for wanting to find a way to enjoy older titles with the latest versions of the engine (even if they have to be recreated from scratch in the scenario and map maker applications). That's most likely why there's so much history around combined HTTR scenarios etc. and BFTB. Maybe the way is to go by theatre...roll the COTA estabs over into the next Med theatre game. Anyhoo......I've said my piece and thanks for listening. [:)]
Now then, tell us a little more about BFTB please and thank you!!

Rob.
So we're at war with the Russkies eh?? I suppose we really ought to invade or something. (Lonnnng pause while studying the map)
Hmmmm... big place ain't it??
- Sir Harry Flashman (1854)
Hmmmm... big place ain't it??
- Sir Harry Flashman (1854)
RE: Musings over the future of backwards compatibility
Rob,
That is what we are doing. We have a number of Data Design Teams, each focusing on a particular theatre. The estabs for each title within that theatre will be rolled into the next title within the theatre.
Well we're going like the clappers here at the moment. I'm nearly finished the task options. Spent yesterday on the Ambush option, which when set will prevent a force from opening fire until the enemy is within its ambush range ( ie damm close ) or it has received fire in the last few minutes. I've added additional range rings so now we have max, effective and ambush range rings for both APerFP and AArmFP. Well we'll be trialing thse with the upcoming build. I know there are some "old salts" within the Panther Prowlers who are not sure about this change. Here's a screen dump.
Note the light green = max APerFP, mid green = effective APerFP, dark green = ambush APerFP. Similarly the light, mid and dark red = max/eff/ambush AArmFP.
For the moment I have set effective range to be that at which 50% of the units firepower can be brought to bear. Ambush = 67%.

Maybe the way is to go by theatre
That is what we are doing. We have a number of Data Design Teams, each focusing on a particular theatre. The estabs for each title within that theatre will be rolled into the next title within the theatre.
Well we're going like the clappers here at the moment. I'm nearly finished the task options. Spent yesterday on the Ambush option, which when set will prevent a force from opening fire until the enemy is within its ambush range ( ie damm close ) or it has received fire in the last few minutes. I've added additional range rings so now we have max, effective and ambush range rings for both APerFP and AArmFP. Well we'll be trialing thse with the upcoming build. I know there are some "old salts" within the Panther Prowlers who are not sure about this change. Here's a screen dump.
Note the light green = max APerFP, mid green = effective APerFP, dark green = ambush APerFP. Similarly the light, mid and dark red = max/eff/ambush AArmFP.
For the moment I have set effective range to be that at which 50% of the units firepower can be brought to bear. Ambush = 67%.

- Attachments
-
- NewRangeRings.jpg (108.03 KiB) Viewed 533 times
- Deathtreader
- Posts: 1058
- Joined: Tue Apr 22, 2003 3:49 am
- Location: Vancouver, Canada.
RE: Musings over the future of backwards compatibility
Hi,
Looks good....... I like the idea of the 3 range rings. Maybe the "old salts" would feel better if there were 3 player selectable options for displaying the rings:
1/ do not display rings, period.
2/ display traditional max. effective range only rings.
3/ display max., effective, and ambush range rings.
Forward!!
Rob.
Looks good....... I like the idea of the 3 range rings. Maybe the "old salts" would feel better if there were 3 player selectable options for displaying the rings:
1/ do not display rings, period.
2/ display traditional max. effective range only rings.
3/ display max., effective, and ambush range rings.
Forward!!
Rob.

So we're at war with the Russkies eh?? I suppose we really ought to invade or something. (Lonnnng pause while studying the map)
Hmmmm... big place ain't it??
- Sir Harry Flashman (1854)
Hmmmm... big place ain't it??
- Sir Harry Flashman (1854)
RE: Musings over the future of backwards compatibility
Yes well we'll see if we get time enough to add in extra options to the display tool bar. One change I did make since my prev post was to reduce the percentage for effective fire to 33%. After stepping through a range of units and tabling the results, 33% worked best. At this value infantry companies armed with LMGs and rifles have an effective range of 500m - ie the range of their LMGs. MG Coy's armed with HMG have an effective range of 1000m.
RE: Musings over the future of backwards compatibility
ORIGINAL: Arjuna
At this value infantry companies armed with LMGs and rifles have an effective range of 500m - ie the range of their LMGs. MG Coy's armed with HMG have an effective range of 1000m.
What happened to "hold your fire until you can see the white of their eyes" ? [:D]
Greetz,
Eddy Sterckx
RE: Musings over the future of backwards compatibility
Eddy,
That's ambush range, mate!
That's ambush range, mate!

RE: Musings over the future of backwards compatibility
ORIGINAL: sterckxe
What happened to "hold your fire until you can see the white of their eyes" ? [:D]
Greetz,
Eddy Sterckx
Erm... seriously now, Eddy's comment made me think.... hmm 2 questions now:
1) some COTA or HTTR(?) inf units (for example) have several mortars (note: i am not talking about mortar coys) ...
a) do they actually use the stuff?
b) is the usage being rendered in the game (visually)? ...
I'm asking because i think I've seen occasional mortar fire from such units.
2) If the above observation isn't about me having hallucinations only hehe.... an ambush button/switch would make sense, no? So that the player can issue a hold fire order, where the friendly unit in question would not fire any weapon (and reveal its location) until the enemy unit would get as close as XY meters (value should be adjustable by the player, that would be a real nice feature).
I'm convinced that there were plenty of opportunities to prepare surprise fire, close quarters (at night, woods, city environments etc.) .
And I don't think these opportunities were limited to missions conducted by resistance fighters in the Balkan mountains or in the rear of the Russian front.
Sometimes units "pop" up on the map (city terrain, woods), but a "vague" intel would often give an idea about enemy presence in such environments, although intel (recon-) possibilities were really limited back then (compared to today's possibilities with drones, sat pictures, "Tornado" jet recon. with cams and IR pics).
So, telling a particular unit to hide/hold fire and prepare an ambush, in addition to the existing defend task, for example, or.... in conjunction with an automatism like the "dig-in" / "fortify" automatism, just with a shorter "set-up" time, would really add some spice there.
This feature could be limited be used like once a day only... or like a few times only for the entire mission time ( but available to ANY front line unit, except to support/command units, armored or motorized units), in order not to be exploited by the player.
hmmm ?
"Aw Nuts"
General Anthony McAuliffe
December 22nd, 1944
Bastogne
---
"I've always felt that the AA (Alied Assault engine) had the potential to be [....] big."
Tim Stone
8th of August, 2006
General Anthony McAuliffe
December 22nd, 1944
Bastogne
---
"I've always felt that the AA (Alied Assault engine) had the potential to be [....] big."
Tim Stone
8th of August, 2006
RE: Musings over the future of backwards compatibility
The way the new Ambush option works is that the unit will not open fire on enemy outside its ambush range unless it is under fire or has been in the last fifteen minutes. Ambush range depends on the unit/force. It is that range at which the force can bring 67% of its firepower to bear. This range will vary depending on the target and the type of fire - eg an Inf Coy may have an APer ambush range of 300m and an AArm ambush range of 100m.
RE: Musings over the future of backwards compatibility
ORIGINAL: Arjuna
The way the new Ambush option works is that the unit will not open fire on enemy outside its ambush range unless it is under fire or has been in the last fifteen minutes. Ambush range depends on the unit/force. It is that range at which the force can bring 67% of its firepower to bear. This range will vary depending on the target and the type of fire - eg an Inf Coy may have an APer ambush range of 300m and an AArm ambush range of 100m.
I understood that part, as you've explained that in another posting already, and I've viewed the screen dump showing the ambush range before.
But this is like an automatism. My idea was to give the user additional "power" to tell a given unit to prepare an ambush on purpose. An ambush is different than a situation where a given enemy unit approaches (probes) or charges a friendly defensive perimeter, right?
Setting up an ambush with the friendly unit's troops hiding in a city environment, or in the woods, should cause way more casualties than regular defensive or offensive actions once the friendly troops open fire, imho.
The word ambush implies that it's about surprise fire that seems to appear from nowhere. According to my observations, the engine prevents these kinda situations at times, as a good LOS will often reveal info about the presence of an enemy unit nearby. Keeping the ambush feature to be a feature controlled by an automatism only would be like half of the real deal only, i think. Enabling the player to freely choose an ambush location, with him being able to set a minimum distance where it's "fire at will", would make a real difference, IMHO. Hmm, a more flexible ambush feature as I've just outlined, may require a change in sighting procedures within the engine as well, as a small unit would really find ways of staying put, in order to avoid detection, if ordered to do just that... -> to conduct a mean + tricky ambush.
The most classic example would be the mini-KG during the battle in Arnheim (Group Butlar, consisting of 6 soldiers, incl. CO). A small group like that shouldn't be seen even from medium distance at all, if it would hide in woods or in a city environment, and IF it would hold fire, IMHO. In the Arnheim scenario, Group Butlar is being spotted from a distance most of the time, as if it would consist of let's say 50-60 troops.
That leads to the next question. If I'm not mistaken, a given unit would still fire occasionally, if set to MIN aggro? Right? That's where I really wish that there'd be a hold-fire button, as it would make withdrawal or sneak-around-moves easier, since it would be easier for units to disengage or to avoid that the given unit would reveal its presence. That way, custom scenarios at platoon level (SP/MP) would start to make sense and I can imagine that these would be fun, as they'd be less time consuming in MP. Imagine close combat fights in a city environment with "hit and run" tactics.
Right now, withdrawal tasks are almost useless, since units with heavy losses (which aren't routing yet) can't be pulled out most of the time (even if playing without order delay), as they would not disengage in time. In real life, if the shyte would hit the fan, a commander would just say "let's get out of here" or "run", hehe, maybe even if he'd have to sacrifice/drop some or all of his heavy weapons.
That said, a hold-fire button would be useful in such situations as well, i think... or, alternatively, a RETREAT task. We've got a withdrawal task that can be issued by the user and the automatism that triggers/controls retreating and routing. The withdrawal task appears to be a pretty time consuming but well-regulated procedure. I for one, wish there'd be a third option, where I, as the "commander", would be able to determine the direction of a retreat. Also, in real life, commanders were able to abort a fully fledged attack (due to unexpected heavy enemy defense for example) in a timely manner (minutes only).
For the imaginary retreat-task, order delay should be set to "1" or something like that (means less than 2 mins basically), if issued on a company level, as a retreat order does NOT take up to one hour in real life...... really.
This is like this engine's only drawback:
All those situations, where it lets a single Coy either retreat, without the player being able to do anything about it, or where it lets a Coy just execute the last order stubbornly (it's worse if playing with order delay) with it "patiently" taking casualties and returning fire (if not routing/retreating), make we wish to issue such a retreat order. Even MIN aggro would not make it completely detach from the enemy on many occasions, it feels like the soldiers are digging for their ties and full dresses and are waiting for their wifes to receive a fare-well kiss first, before they are ready to leave the perimeter, being attached to enemy units like magnets at times.
Abort of attacks (attacks against long odds) had been done and will be done in the future, in real life combat. If a given unit is not going to be surrounded, there are plenty of opportunities to use withdrawal routes/retreat routes.
Oh hey and a "drop everything and run"-button would be neat [8D], too [;)].
EDIT: One more thing comes to my mind. Looking at the "retreat"-automatism, there's a tendency of friendly units retreating or routing towards enemy perimeters... a good example would be a mission objective residing in a major city, with enemy units deploying within the objective "ring".
On quite some occasions a friendly attacking unit would then start to retreat (it would first move away [retreat] from the most dangerous enemy unit/fire i guess), but it would start to bounce once the enemy fire would start to do some serious damage. Often, the very next step would be that the enemy units would make the friendly unit rout, with the friendly unit stumbling over every enemy unit available on this perimeter. I'm exaggerating here, but some instances feel like that.
One should think that a soldier's/group's instinct would tell them to try and reach a friendly/uncontested perimeter, in order not to face destruction/captivity, no?
The changes that had been made to the engine's code -COTA-, triggering a higher likelihood that a given unit surrenders (it feels like foes do it somewhat earlier than friends now) concealed the problem with bouncing units and the need to detach troops to chase and destroy vital enemy AI units to some extent, but it still doesn't feel right.
It wasn't the "speed" which caused the problem, "speed" describes the time frame from first contact to final surrender, but the freaky behaviour of retreating/routing units, where even the tightest ring of friendly units would not be able to crush a trapped enemy unit and where such enemy units would even rout through the tightest friendly defenses.
Whatever, in fact, I've outlined the idea of having an ambush task (maybe with fixed amounts of available ambush orders.... similar to the air strike feature... or like once a day... once per line unit - like the bridge-building capability-, whatever) in my initial posting, i think you might have overlooked that.
I hate to quote myself, but I'd still love to get an answer to this:
These few mortars carried by line troops would display less than 67% of the weapons for sure... but do they fire right now (COTA)? ... and they won't fire in the future (BFTB etc.) if ambushing?1) some COTA or HTTR(?) inf units (for example) have several mortars (note: i am not talking about mortar coys) ...
a) do they actually use the stuff?
b) is the usage being rendered in the game (visually)? ...
What kind of algorythm decides which encounter happens to be an ambush, and what exact preconditions have to be met to trigger an ambush? Would the player be able to see the enemy's location beforehand, prior to the ambush?
This automated version of an ambush makes me think of it as a rather artificial (not very realistic) feature, sorry, as it sounds as if the terrain types/weather conditions won't be taken into account, but only the force ratio and appearance of incoming fire. It sounds like anything could turn into an ambush-fest IF the player would place a string of single Coys along an imaginary defensive line and if he'd just give them time to deploy, resulting in the poor enemy chap stumbling over these ambushing units, in case the chap is not conducting an attack mission in this very moment. No?
My personal wishlist for the game after BFTB:
- 1) Loss of XY percentage (depending on type of terrain, weather, season - this will be great for a game focusing on the Russian or African theater) of heavy equipment if unit is routing and suffering severe casualties ("loss" as in leaving a percentage of weaponry [that hadn't been destroyed in the process] on the battlefield !!!!!!!!!!! ),
- 2) Ability to pick up and incorporate servicable heavy weapons (means to regain or capture abandoned vehicles and or heavy equipment in general),
- 3) Option to let the user decide whether captured equipment should be incorporated or not (who'd want a Stuart tank? ..... on the other hand, the Germans liked [to use] Russian T-34s and the Russians liked the Panther tanks later on, but they ignored the Tigers..too unreliable for their liking
), - 4) Hold fire button as in...ZERO fire,
- 5) Ambush button/task where the player can determine a minimum distance from where it's "fire at will", along with an impact on an ambushing unit's visibility (could be rendered as "type of deployment", just like "dug in" or "fortified" modes)
- 6) New terrain types:
a) "bombed city" layer (* almost impassable for armor/mot. units, unless the scenario designer would add streets..... , * reduced movement values for inf, as ruins, rubble and obstacles would hamper troop movement ....., * extremely low movement values for tanks if they leave the streets),
b) "bomb crater" layer (would look nice and would enhance immersion, it could be placed on top of any terrain, similar to the river/water layers, * impassable for all vehicles but tanks), - Booby traps (the Russians used to set up these in woods on the eastern front, the Germans used those excessively in Huertgenwald Forest, here and there in woods in the Ardennes, and to some extent behind the Siegfried Line .... mostly consisting of anti-personnel mines or hand grenades attached to trees at waist/stomach level, not sure if the Russians invented it) ... they caused quite some casualties among inf troops. Would be neat as addition to the delayed mine field feature.
- Sequential orders being able to take into account timer settings (discussed in another thread)
"Aw Nuts"
General Anthony McAuliffe
December 22nd, 1944
Bastogne
---
"I've always felt that the AA (Alied Assault engine) had the potential to be [....] big."
Tim Stone
8th of August, 2006
General Anthony McAuliffe
December 22nd, 1944
Bastogne
---
"I've always felt that the AA (Alied Assault engine) had the potential to be [....] big."
Tim Stone
8th of August, 2006
RE: Musings over the future of backwards compatibility
GoodGuy,
I don't have time right now to respond in depth to your suggestions. My mother has just died and I'm off to Newcastle for the funeral. I'll get back to you in a weeks time.
I don't have time right now to respond in depth to your suggestions. My mother has just died and I'm off to Newcastle for the funeral. I'll get back to you in a weeks time.
RE: Musings over the future of backwards compatibility
Oh I'm sorry to hear that. Please accept my deepest sympathy for the loss of your mother.
"Aw Nuts"
General Anthony McAuliffe
December 22nd, 1944
Bastogne
---
"I've always felt that the AA (Alied Assault engine) had the potential to be [....] big."
Tim Stone
8th of August, 2006
General Anthony McAuliffe
December 22nd, 1944
Bastogne
---
"I've always felt that the AA (Alied Assault engine) had the potential to be [....] big."
Tim Stone
8th of August, 2006
RE: Musings over the future of backwards compatibility
I don't know if you've read my huge post up there, and it may be like expecting too much of you, since you're pretty busy.
Still, a little reminder: The 'lil wishlist at the end of post #14 lists the suggestions / questions which I discussed in my massive essay.
Still, a little reminder: The 'lil wishlist at the end of post #14 lists the suggestions / questions which I discussed in my massive essay.
"Aw Nuts"
General Anthony McAuliffe
December 22nd, 1944
Bastogne
---
"I've always felt that the AA (Alied Assault engine) had the potential to be [....] big."
Tim Stone
8th of August, 2006
General Anthony McAuliffe
December 22nd, 1944
Bastogne
---
"I've always felt that the AA (Alied Assault engine) had the potential to be [....] big."
Tim Stone
8th of August, 2006
RE: Musings over the future of backwards compatibility
GoodGuy.
I'll probably answer your points bit by bit as I am flat out right now.
Re Mortars in Inf units. Yes they do fire but only in the direct mode - ie they do not provide indirect fire. Visually when the inf unit fires its mortars you will see the standard direct fire line. You will not see the explosion graphics that indirect fire units cause.
I'll probably answer your points bit by bit as I am flat out right now.
Re Mortars in Inf units. Yes they do fire but only in the direct mode - ie they do not provide indirect fire. Visually when the inf unit fires its mortars you will see the standard direct fire line. You will not see the explosion graphics that indirect fire units cause.
RE: Musings over the future of backwards compatibility
re use of captured equipment. First off, there are real problems in implementing this as that would require augmenting estabs on the fly during a game and I am definitely not in favour of that.
re ambush. We considered option of allowing the user to specify a range, but this brought up a whole swag of issues, like what happens if the range set is too great for the weapons the unit now has. Do we then second guess the user - not really recommended. In the end I opted for the current solution incorporated in BFTB ( we're now testing it ). This will determine the range dynamically based on the range of its current weapons.
re ambush. We considered option of allowing the user to specify a range, but this brought up a whole swag of issues, like what happens if the range set is too great for the weapons the unit now has. Do we then second guess the user - not really recommended. In the end I opted for the current solution incorporated in BFTB ( we're now testing it ). This will determine the range dynamically based on the range of its current weapons.
RE: Musings over the future of backwards compatibility
Hello All,
I quite like GoodGuy's idea of having a different delay applied to the withdraw order. To prevent a gamey use of it (i.e. to bypass the orders delay to place force in an advantageous position), I would be happy if it was implemented like an in-situ meaning that the forces ordered to withdraw move back to the FUP (in case the withdraw order is given after an attack order) or towards the map boss or base (both of which, unless you are a ruthless player or in deep sh*t should be in a safe area) if defending.
Cheers,
Michele
I quite like GoodGuy's idea of having a different delay applied to the withdraw order. To prevent a gamey use of it (i.e. to bypass the orders delay to place force in an advantageous position), I would be happy if it was implemented like an in-situ meaning that the forces ordered to withdraw move back to the FUP (in case the withdraw order is given after an attack order) or towards the map boss or base (both of which, unless you are a ruthless player or in deep sh*t should be in a safe area) if defending.
Cheers,
Michele
God fights on the side with the best arty -- Napoleon


