Build 4.6.273 Feedback
Moderators: Panther Paul, Arjuna
-
BletchleyGeek
- Posts: 4460
- Joined: Thu Nov 26, 2009 3:01 pm
- Location: Living in the fair city of Melbourne, Australia
Build 4.6.273 Feedback
Let's start the thread to focus discussion.
RE: Build 4.6.273 Feedback
With reference to my post tm.asp?m=3556932#, I obviously (from my preceding posts [:)]) thought to the order cancellation bug (15 - 20 cancellations in the brief scenario Hoefen Ho-Down).
When I say HTTR v.2.286, I mean exactly HTTR v.2.286: this is the last official version of HTTR by Matrix.
Don't be dejected, Bletchley_Geek, I realize I'm perhaps the only one to be annoyed by this bug, so it will not be important for you. You know, we old people have often quirk whims [:)].
Take care.
When I say HTTR v.2.286, I mean exactly HTTR v.2.286: this is the last official version of HTTR by Matrix.
Don't be dejected, Bletchley_Geek, I realize I'm perhaps the only one to be annoyed by this bug, so it will not be important for you. You know, we old people have often quirk whims [:)].
Take care.
-
BletchleyGeek
- Posts: 4460
- Joined: Thu Nov 26, 2009 3:01 pm
- Location: Living in the fair city of Melbourne, Australia
RE: Build 4.6.273 Feedback
ORIGINAL: Renato
With reference to my post tm.asp?m=3556932#, I obviously (from my preceding posts [:)]) thought to the order cancellation bug (15 - 20 cancellations in the brief scenario Hoefen Ho-Down).
When I say HTTR v.2.286, I mean exactly HTTR v.2.286: this is the last official version of HTTR by Matrix.
Don't be dejected, Bletchley_Geek, I realize I'm perhaps the only one to be annoyed by this bug, so it will not be important for you. You know, we old people have often quirk whims [:)].
Take care.
Thank you for the clarification - I was quite confused. Regarding this order cancellation thing: which one of the "order cancellation" issues you refer to? Tasks running out of time? Forces bunkering down - and being reported to do so as a staff message? Are you setting an H-Hour for those tasks? Something else? I am through the third replay of the first day of Elsenborn Ridge, and I am not seeing any of these problems any more.
Sincerely, that someone comes forward and tells us that he prefers HTTR over the latest version of BFTB, is basically saying that we haven't moved forward in 10 years. That makes me feel sad, as in really sad [:(]
RE: Build 4.6.273 Feedback
I'm playing Losheim Gap as Axis and ere are my super critical observations. Anything that is historically accurate I can accept.
a. Mortar platoons occasionally lead the formation.
b. Successive lines with 'auto' formation leads to all the units using road column. If the player adjusts the formation the units move as intended.
c. M8s are no longer invincible.
d. Smaller units now flee much quicker than previously.
e. Artillery is horrible! Units take 20% casualties within two hours of the scenarios start and then go into 'retreat' or 'retreat recovery' and my glorious offensive begins to grind to a halt. The Fuhrer will have my head at this rate.
f. Units that have retreated take a very long time to recover. I suppose this is because if 20% of a company are dead, then at least another 20% are injured and in need of medical treatment.
g. There is perhaps an order cancellation bug. I'm not sure but some units are stationary for hours when they are given an order which indicates that they should be moving somewhere. These units are not retreating, or being bombarded, or even under attack.
a. Mortar platoons occasionally lead the formation.
b. Successive lines with 'auto' formation leads to all the units using road column. If the player adjusts the formation the units move as intended.
c. M8s are no longer invincible.
d. Smaller units now flee much quicker than previously.
e. Artillery is horrible! Units take 20% casualties within two hours of the scenarios start and then go into 'retreat' or 'retreat recovery' and my glorious offensive begins to grind to a halt. The Fuhrer will have my head at this rate.
f. Units that have retreated take a very long time to recover. I suppose this is because if 20% of a company are dead, then at least another 20% are injured and in need of medical treatment.
g. There is perhaps an order cancellation bug. I'm not sure but some units are stationary for hours when they are given an order which indicates that they should be moving somewhere. These units are not retreating, or being bombarded, or even under attack.
Have: Socks. Deodorant. £2 gloves. Mince pies.
Want: Line formation banned until I give a specific order to use line formation. Troops that don't take lie-ins until 0800 unless ordered to never rest.
Want: Line formation banned until I give a specific order to use line formation. Troops that don't take lie-ins until 0800 unless ordered to never rest.
RE: Build 4.6.273 Feedback
Mahatma,
Re "b". Please elaborate. I'm confused.
Re "e". Again I'm confused. Am I correct in assuming that you think the arty is too effective?
Re order cancellation. I need a save.
Re "b". Please elaborate. I'm confused.
Re "e". Again I'm confused. Am I correct in assuming that you think the arty is too effective?
Re order cancellation. I need a save.
RE: Build 4.6.273 Feedback
ORIGINAL: Bletchley_Geek
...
Thank you for the clarification - I was quite confused. Regarding this order cancellation thing: which one of the "order cancellation" issues you refer to? Tasks running out of time? Forces bunkering down - and being reported to do so as a staff message? Are you setting an H-Hour for those tasks? Something else? I am through the third replay of the first day of Elsenborn Ridge, and I am not seeing any of these problems any more.
Sincerely, that someone comes forward and tells us that he prefers HTTR over the latest version of BFTB, is basically saying that we haven't moved forward in 10 years. That makes me feel sad, as in really sad [:(]
Here are some excerpt (not all) from old posts of mine, relative to the Order Cancellation bug:
- quote:
ORIGINAL: wdkruger
Am seeing odd behavior regarding slippage. Seems that when I get an order slippage message, the order of the offending headquarters is eliminated and the HQ now has no orders. Is this working as intended?
I too have observed this behaviour; sure it doesn't always happen and not only with HQ, but it's difficult to nail down.
excerp
- I've seen another case in which a unit cancels its task a few game minutes after a Move slippage. Unfortunatly, I'm not able to replicate it, even after many attemts. I hope to find a reproducible case, but it will not be easy.
- In my opinion, the order cancellation bug, which is present from v4.4.255, is pretty irksome and may negatively affect the play, especially if painfully realistic delay orders are adopted.
At present, I don't have a recent and repeatable save, but it happens quite often and should be easily visible.
I suggest to remove it, if possible.
- It's a bug I reported some time ago after v4.4.255: the order given to a unit or a HQ is cancelled during play, and the units remain without any order.
- The order cancellation bug is still present: now and then during play, some units cancel their order and remain still.
This should be quite visible by a human player; of course, if the test is performed with a computer, it may go undetected because the AI will do a replan after some time.
- That's not the case, wodin: I'm referring to orders accepted and partially performed.
It's quite easy to perform a test:
- choose a scenario and give all the orders you like,
- verify that every unit has an order (pressing the key "-"),
- start the scenario at maximum speed without intervening,
- after some time check again (pressing the key "-").
Some units will be without any order.
- 1. The order cancellation bug is still present: now and then during play, some units cancel their order and remain still indefinitely.
At any rate, don't loose your sleep, Bletchley_Geek, I'll try to reinstall Command Ops with a patch preceding the infamous v4.4.255, so I'll run a more recent game, and you'll be much less sad [:)]
Take care.
RE: Build 4.6.273 Feedback
Re "b" if one gives a unit a move order with successive lines and leave the frontage and/or depth to auto, the Bn will move in road column formation instead. But if one changes the formation then the Bn moves in successive lines.
Re "e" not 'too effective' just 'very effective'.
I'll get back to you on order cancellation.
Edit: corrected this post after GBS pointed out an error. I meant frontage not formation.
Re "e" not 'too effective' just 'very effective'.
I'll get back to you on order cancellation.
Edit: corrected this post after GBS pointed out an error. I meant frontage not formation.
Have: Socks. Deodorant. £2 gloves. Mince pies.
Want: Line formation banned until I give a specific order to use line formation. Troops that don't take lie-ins until 0800 unless ordered to never rest.
Want: Line formation banned until I give a specific order to use line formation. Troops that don't take lie-ins until 0800 unless ordered to never rest.
RE: Build 4.6.273 Feedback
Successive lines is a formation, correct? How can you give a move order with successive lines "and" leave the formation to auto??
"It is well War is so terrible lest we grow fond of it." -
R. E. Lee
"War..god help me, I love it so." - G. Patton
R. E. Lee
"War..god help me, I love it so." - G. Patton
RE: Build 4.6.273 Feedback
ORIGINAL: Bletchley_Geek
Let's start the thread to focus discussion.
As with the previous patch, under the latest beta I'm still getting "TF ... abandoned its Exit task for lack of time," even when there are days left in the scenario.
In the Cracking the Goose Egg scenario, I only managed to exit 10 units, and I've been playing HttR/BftB for some time now.
If you need a save -- and I'm sure you do -- what email address is it sent to?
Stratford, Connecticut, U.S.A.[center]
[/center]
[center]"The Angel of Okinawa"[/center]
Home of the Chance-Vought Corsair, F4U
The best fighter-bomber of World War II
[/center][center]"The Angel of Okinawa"[/center]
Home of the Chance-Vought Corsair, F4U
The best fighter-bomber of World War II
-
Phoenix100
- Posts: 2946
- Joined: Tue Sep 28, 2010 12:26 pm
RE: Build 4.6.273 Feedback
Arjuna or Bletchley,
When you tweak the code as you did with the assault and road column problem, does this also improve the AI we fight against? So that every slight improvement makes the game more challenging to the player, which is really very interesting because I'm guessing the ultimate goal is an AI that no human player could ever beat. Not even Dazkaz micromanaging every unit to death.
When you tweak the code as you did with the assault and road column problem, does this also improve the AI we fight against? So that every slight improvement makes the game more challenging to the player, which is really very interesting because I'm guessing the ultimate goal is an AI that no human player could ever beat. Not even Dazkaz micromanaging every unit to death.
Have: Socks. Deodorant. £2 gloves. Mince pies.
Want: Line formation banned until I give a specific order to use line formation. Troops that don't take lie-ins until 0800 unless ordered to never rest.
Want: Line formation banned until I give a specific order to use line formation. Troops that don't take lie-ins until 0800 unless ordered to never rest.
RE: Build 4.6.273 Feedback
Ref the orders cancelation as I understand it, please correct me if its inacurate:
When you place a move order (note I am only talking about a move order, not attack, defend, or exit order, which are handled differently) on the map, the end time of that move order is estimated to take into account the command delay, the time taken to move to that location at normal speed, and a small contingency time is allowed to take into account minor holdups.
If your move order should encounter enemy, on route it starts to move more tactically depending on the weather conditions, the slower it will move in close proximity to the enemy.
This will alter the time it takes for your unit to get to the ordered location, and it may run out of time.
Move orders do not slip like attack orders.
This may have been implemented like this to let you know that the move has run into a problem, because when the order expires you get a message saying move complete, and you can also filter the units to see which ones have not orders, or it may have been to prevent a move from running into problems but making no progress until the end of the scenario.
Would need dev confirmation to confirm why it does not slip indefinately, because I don't really know myself, these are all just guesses.
Anyway this problem can easily be solved, all you need to do is make sure you increment the estimated end time of the move to whatever you want, before you want the unit to give up.
I personally just increment it a few days, as this is just a few clicks in the day box.
Joe D
The same sort of thing happens for an exit order, except for some reason its just gives it a set time of about 5 hours to reach the exit.
All you need to do it increment the end time for the order to the end of the scenario to ensure it never expires.
Now there is a quirk to this.
If you place a move order then increment the end time, if you then place another move order to extend the distance of the move it will re-set the end time again, so you will need to increment it again to a time that you are happy with for it to expire.
All this is off the top of my head, from experience, I have not had time to do tests to confirm what I have written here.
I will do so as soon as I am able.
When you place a move order (note I am only talking about a move order, not attack, defend, or exit order, which are handled differently) on the map, the end time of that move order is estimated to take into account the command delay, the time taken to move to that location at normal speed, and a small contingency time is allowed to take into account minor holdups.
If your move order should encounter enemy, on route it starts to move more tactically depending on the weather conditions, the slower it will move in close proximity to the enemy.
This will alter the time it takes for your unit to get to the ordered location, and it may run out of time.
Move orders do not slip like attack orders.
This may have been implemented like this to let you know that the move has run into a problem, because when the order expires you get a message saying move complete, and you can also filter the units to see which ones have not orders, or it may have been to prevent a move from running into problems but making no progress until the end of the scenario.
Would need dev confirmation to confirm why it does not slip indefinately, because I don't really know myself, these are all just guesses.
Anyway this problem can easily be solved, all you need to do is make sure you increment the estimated end time of the move to whatever you want, before you want the unit to give up.
I personally just increment it a few days, as this is just a few clicks in the day box.
Joe D
The same sort of thing happens for an exit order, except for some reason its just gives it a set time of about 5 hours to reach the exit.
All you need to do it increment the end time for the order to the end of the scenario to ensure it never expires.
Now there is a quirk to this.
If you place a move order then increment the end time, if you then place another move order to extend the distance of the move it will re-set the end time again, so you will need to increment it again to a time that you are happy with for it to expire.
All this is off the top of my head, from experience, I have not had time to do tests to confirm what I have written here.
I will do so as soon as I am able.
RE: Build 4.6.273 Feedback
ORIGINAL: Mahatma
Not even Dazkaz micromanaging every unit to death.
Well they don't usually die when I micro manage them, but sometimes they do if I don't [:D]
Especially when trying to get unhistorical results when fighting a vastly superior force [;)]
RE: Build 4.6.273 Feedback
Ok I have been messing around with the move order, and can see why it has been done like this now.
It is to help with your planning as it gives you an estimate of what time your unit will reach the location of the move order, taking into account the distance, and the command delay.
What it doesn't do is take into account any enemy activity that will hinder the move on route.
This is down to you to determine, or if it is an important move you never want it to expire, then increment the end time to end of scenario.
Bare in mind that if you do this, and it gets held up for a long time, it could end up very fatigued, and you won't get a warning that it has encountered problems, and may need the route cleared with an attack order.
The reason the end time gets re-set if you place another move order onto the existing route is because it updates the estimated time to reach that location.
Its actually a very cool feature [:)]
To summarise:
To prevent the orders being abandoned, make sure the end time is set to a time when you no longer want the move to continue.
For important moves, or ones that you are closely monitoring, this may be the end of the scenario, so just keep clicking in the day box until it no longer increments the end time.
It is to help with your planning as it gives you an estimate of what time your unit will reach the location of the move order, taking into account the distance, and the command delay.
What it doesn't do is take into account any enemy activity that will hinder the move on route.
This is down to you to determine, or if it is an important move you never want it to expire, then increment the end time to end of scenario.
Bare in mind that if you do this, and it gets held up for a long time, it could end up very fatigued, and you won't get a warning that it has encountered problems, and may need the route cleared with an attack order.
The reason the end time gets re-set if you place another move order onto the existing route is because it updates the estimated time to reach that location.
Its actually a very cool feature [:)]
To summarise:
To prevent the orders being abandoned, make sure the end time is set to a time when you no longer want the move to continue.
For important moves, or ones that you are closely monitoring, this may be the end of the scenario, so just keep clicking in the day box until it no longer increments the end time.
RE: Build 4.6.273 Feedback
For an Exit order the end time is hard coded for 4 hours to reach the exit no matter where you are on the map.
This is also easily fixed by increasing the end time to whatever you like.
Why this order has been coded to expire after 4 hours I have no idea?
It maybe have been inadvertently changed when the work was implemented to the move orders, and gone un noticed.
I'm fairly sure that it used to be set automatically to the end of the scenario, and should be implemented like the move order where it first gives you an estimate of when it will reach the locaton, for planning reasons, then you can increase it by the amount you want, or end of scenario if you never want it to expire.
I guess this is an easy to work around bug.
This is also easily fixed by increasing the end time to whatever you like.
Why this order has been coded to expire after 4 hours I have no idea?
It maybe have been inadvertently changed when the work was implemented to the move orders, and gone un noticed.
I'm fairly sure that it used to be set automatically to the end of the scenario, and should be implemented like the move order where it first gives you an estimate of when it will reach the locaton, for planning reasons, then you can increase it by the amount you want, or end of scenario if you never want it to expire.
I guess this is an easy to work around bug.
RE: Build 4.6.273 Feedback
I'm still looking into this move issue, and noticing that the move orders do actually slip, and am receiving routine messages to say so, when not incremented from the original estimate.
Its not clear yet when they eventually stop slipping, and abandon it.
Ill keep testing.
Its not clear yet when they eventually stop slipping, and abandon it.
Ill keep testing.
RE: Build 4.6.273 Feedback
More observations Ref an Exit order:
Units will slip the exit orders initial 4 hour time so long as they are not resting.
If you give an exit order to a unit that has just started the night time auto rest, it will not wake to complete the task.
It will continue to rest, until the 4 hours expires when it will abandon it with a routine message of "failed to complete its Exit mission"
Make sure you click NO REST for all exit orders.
Units will slip the exit orders initial 4 hour time so long as they are not resting.
If you give an exit order to a unit that has just started the night time auto rest, it will not wake to complete the task.
It will continue to rest, until the 4 hours expires when it will abandon it with a routine message of "failed to complete its Exit mission"
Make sure you click NO REST for all exit orders.
RE: Build 4.6.273 Feedback
I usually use the tutorial St. Vith scenario as a benchmark of sorts as I have played it so many times with relatively similar battle plans that I can quickly pick up on changes in behavior. There was some sketchy attack pathing going on (using the default settings for an attack on Breitfeld Crossroads the AI took an avoidance path way out of the way, almost 2km north and east of the objective). The artillery seemed a great deal more active (at least the explosion animation), however the casualties caused did not seem out of line with previous games.
Path Example
AAR Stats
Path Example
AAR Stats
RE: Build 4.6.273 Feedback
Joe D
I have just managed to replicate your "TF ... abandoned its Exit task for lack of time,"
It happens after the initial orders delay if the unit is a long way from the objective i.e. more than 4 hours away via its chosen route, if you leave the end time at the default of 4 hours.
Incrementing the end time to a more realistic time solved this for me.
Can you confirm that?
I have just managed to replicate your "TF ... abandoned its Exit task for lack of time,"
It happens after the initial orders delay if the unit is a long way from the objective i.e. more than 4 hours away via its chosen route, if you leave the end time at the default of 4 hours.
Incrementing the end time to a more realistic time solved this for me.
Can you confirm that?
RE: Build 4.6.273 Feedback
I'll check out the exit code an find out why it's not using a proper estimate.