Glad you found the problem...I think. I've been having the game crash more frequently...it seemed the problem cropped up while the game was running and I placed several orders in quick sequence or tried something complex, like banding together units, but recently its been happening when the game has been paused and I've placed a relatively simple order, like move to a single unit.

As can be seen in the pic, the very first thing that I do, is give CCR 9 a movement order .. to the area marked by the Destination Box.

However, depending on the setting of Orders Delay, .. this Movement Order will either work, .. or result in the ... Lack of Time problem.

At Orders Delay settings of None, Partial, .. or, Painfully Realistic .. the Move Order is executed fine. At Orders Delay settings of Regular or Realistic .. the Move Order is Not executed due to a Lack of Time .. and CCR 9 then temporarily Bunkers down.

However, if I increase the End Time by >25 mins in Regular Delay, .. or >40 mins in Realistic Delay, .. the Move Order is executed fine.

Does this not suggest, that something, relating to time, .. is not being calculated correctly?

The other thing I've noticed, .. is that, if I click, drag and move the destination ... closer to CCR 9, or further away .. the End Time is not being re-calculated. So, it's obviously not dynamic. You have to delete the Move Order, .. and re-create it at the new destination.

I haven't tried to test this 'Time Issue' with anything other than a Move Order, but, I assume that similar problems would exist.

Well the end time used is based on an estimate and yes this can sometimes be out. The old way of always putting the end time equal to the scenario end introduced worse problems. So that i why we have changed to this approach. If we ad time then we will complaints that forces are waiting around all the time. So it's a balancing act. Perhaps what is needed is a task option that allows for automatic slipping of player created Move tasks.

ORIGINAL: wodin Hmmm..if thats the case I'm not sure that it should cancel the order altogether as it's not really the players fault. Either the game should give the estimate with a couple of hours added on or it should just inform you it's slipped but carry on with the order.

Well the game should do the latter - ie automatically slip the time. I have tested this here and that is what is happening. If you have a case of where this is not, then send me a save. I need it before the task time runs out for the first time.

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.

This is not directly related to this patch, but if you order an artillery bombardment as first order in a fresh started scenario (when the time is still paused), you cannot give orders with multiple waypoints thereafter.

First off saving after a command has been issued is not that useful for bug finding. What is useful is having a saved game just before you issue the commands. The rerason for that is that when you issue an order the AI then immediately develops the plan and it's that porocess that usually needs to be stepped through.

However, I agree that some enhancements to the autosave feature would be good, like being able to set the frequency and perhaps also the number of saves you want to maintain - eg last ten. I am a bit loathe to allow an unlimited number of autosaves less we end up with users complaining their hard drive is full.

Just took a quick look. The easiest thing to do without major surgery to the code is to allow for a fixed number of autosave files at a fixed time period. Currently the time period is every 20 minutes of real time. I propose storing 10 saves. That way you get saves for the last three hours of play. I propose resetting the count each time you load a save or start a new scenario. When it goes to do the autosave it will increment the count till it reached 10 and then start back at 1 again. It will append the count to the file name - eg "Autosave #1". Any existing save of the same name will be automatically overwritten.

If it's going to take you away from other matters I'd rather you left it alone, really it was an idea (well when I mentioned something similar a few days ago in the Beta Attack bug thread)to help you in testing for bugs..I'm not sure the autosave every twenty mins and saving the last ten will help with that regard. Rfizz I think is mentioning it for the reason so I presume would say the same thing, if it wont help in testing then turn your attention to other bugs and the other games.

I think having ten past saves will help. I have already implemented it and am testing it as I type. So the real question is at what frequency. I just tried adding a text box on the options tab to set the frequency interval but I have run into an issue with the UI focus and will need Paulk's help to resolve that. But I can easily change the hard coded interval, currently set to 20 minutes.

If it's for more testing purposes maybe every 5 mins playing time..that gives 50 mins of saves. That shorter the time the more likely it will catch something..Plus for the player it's unlikely they will need anything longer than 50 mins playing time worth of saves.

If we keep 20 saves then I might agree but depending on how fast the game is running 50 minutes of real time may only go back a day in game time and that might not be enough to catch some decision points. What about a compromise of 10 minutes. On the other hand everyone has big hard drives now so perhaps we could have an interval of 5 and maintain twenty saves. What do others think?

BTW my test just finished and it works fine. So we just need to settle on the values for interval and number of saves to keep.

Even when the save size reaches 1MB per save and we would save every 5 minutes with an unlimited amount of saves it wouldn't be enough to cause problems, who runs so low on disk space that he can't spare 4+ GB at the worst estimate.

If possible the solution to the question is to add a preference setting for number of saves / disk space max to use for saves. (Or making a relevant entry in a text file which gets read by the game at startup). Of course if this is going to take valuable dev time then I think setting it at 20 saves is OK. Given the number of times saves are requested for bug-hunting it's a great addition to the game to have multiple auto-saves.

Still have concerns on how routing units is handled in the game. While routing distance wasn´t a problem for me so far, it´s still the oftentimes routing of units towards enemies, or into enemy territory. In my last test play today, I had a friendly unit routing, literally ping ponging between the frontlines and enemy units, as it hasn´t had the slightest idea about frindly and enemy lines.

IMHO, when it comes to routing paths, cover terrain and enemy AperFP should really come secondary. The main hook should be the friendly superior HQ (in organic COC), or the Base unit maybe. THEN a covered path THERE TO should be next consideration.

As a further side effect of routing units far into enemy terrirory, is that it gives a "free" advance guard, once this unit recovers. This unit then is capable to interfere with supply lines and also provide a nice FO for bombarding rear area units, that would be otherwise out of sight and safe.

Here´s the situation showing german infantry coy 2.752 routing, with possible move to lacations marked by yellow arrows. I´ve rerun my save from before the route several times, so got my results from there repeatable.