Build 4.4.259 Feedback
Moderators: Panther Paul, Arjuna
Build 4.4.259 Feedback
OK Guys,
So what do you think of this build. I know there is one reported CTD. Are there any other showstoppers?
So what do you think of this build. I know there is one reported CTD. Are there any other showstoppers?
RE: Build 4.4.259 Feedback
No crash to desktop for me yet.
Seems much more stable, for me anyway [:)]
Seems much more stable, for me anyway [:)]
RE: Build 4.4.259 Feedback
The ammunition change, combined with
Tweak the combat code, including reducing the area per man constants, tweaking the global accuracy settings (especially for close range and overlapping forces).
Is making the game much more fluid, and dynamic now.
It feels much better in this regard IMHO
Tweak the combat code, including reducing the area per man constants, tweaking the global accuracy settings (especially for close range and overlapping forces).
Is making the game much more fluid, and dynamic now.
It feels much better in this regard IMHO
- RockinHarry
- Posts: 2344
- Joined: Thu Jan 18, 2001 10:00 am
- Location: Germany
- Contact:
RE: Build 4.4.259 Feedback
Just downloaded today. Didn´t expect the patch to be available THAT fast! [8D] [:D]
RE: Build 4.4.259 Feedback
As we speak of fluid & dynamic I think there maybe something wrong with the "build up" to an attack.
Can't really nail it down but let me describe.
-Started Elsborn Ridge and issued all the battalion attacks.
-I let the 2 Bats south (I of the 27th and I of the 48th) attack in left & right echelon towards Losheimergraben.
-They start moving up to the FUPs(Behidn the rail for 27th and at the T crossing for 48th).
-When the first 2 coys of each bat. hit the FUP the movement task is reported as complete but the 3rd coys(I guess used as rear guard but they don't have that role listed) are still far behind and in road column, these coys deploy and do not move up to the FUP anymore.
-Now the first 2 coys get tasks to switch places with each other while the 3rd should still move up to the FUP. Strange here is that these movement orders are far in the future, 2 first coys hit FUP shortly before 7.00 but these new move orders don't start about a 45 minutes later. In the meantime they are all still listed as moving but deployed
-When they start moving the 3rd coys also start moving again up to the FUPs.
-After moving a bit they get reorg tasks a bit away and move to them, this seems like taking the actual positions for the attack formation.
Anything took so long that the actual attack moves from the Fup didn't start almost 2.5 hours after the initial attack was ordered.
The strange for me is this huge delay between first units hitting FUP and the time the get into the actual attack position, I doubt that the orders delay has somewhat to do with it.
I send the whole save set to contact@panthergames.com, I hope that is OK.
You should see what is going on when using Autosave #4.
Can't really nail it down but let me describe.
-Started Elsborn Ridge and issued all the battalion attacks.
-I let the 2 Bats south (I of the 27th and I of the 48th) attack in left & right echelon towards Losheimergraben.
-They start moving up to the FUPs(Behidn the rail for 27th and at the T crossing for 48th).
-When the first 2 coys of each bat. hit the FUP the movement task is reported as complete but the 3rd coys(I guess used as rear guard but they don't have that role listed) are still far behind and in road column, these coys deploy and do not move up to the FUP anymore.
-Now the first 2 coys get tasks to switch places with each other while the 3rd should still move up to the FUP. Strange here is that these movement orders are far in the future, 2 first coys hit FUP shortly before 7.00 but these new move orders don't start about a 45 minutes later. In the meantime they are all still listed as moving but deployed
-When they start moving the 3rd coys also start moving again up to the FUPs.
-After moving a bit they get reorg tasks a bit away and move to them, this seems like taking the actual positions for the attack formation.
Anything took so long that the actual attack moves from the Fup didn't start almost 2.5 hours after the initial attack was ordered.
The strange for me is this huge delay between first units hitting FUP and the time the get into the actual attack position, I doubt that the orders delay has somewhat to do with it.
I send the whole save set to contact@panthergames.com, I hope that is OK.
You should see what is going on when using Autosave #4.
RE: Build 4.4.259 Feedback
ORIGINAL: BigDuke66
As we speak of fluid & dynamic I think there maybe something wrong with the "build up" to an attack.
Can't really nail it down but let me describe.
-Started Elsborn Ridge and issued all the battalion attacks.
-I let the 2 Bats south (I of the 27th and I of the 48th) attack in left & right echelon towards Losheimergraben.
-They start moving up to the FUPs(Behidn the rail for 27th and at the T crossing for 48th).
-When the first 2 coys of each bat. hit the FUP the movement task is reported as complete but the 3rd coys(I guess used as rear guard but they don't have that role listed) are still far behind and in road column, these coys deploy and do not move up to the FUP anymore.
-Now the first 2 coys get tasks to switch places with each other while the 3rd should still move up to the FUP. Strange here is that these movement orders are far in the future, 2 first coys hit FUP shortly before 7.00 but these new move orders don't start about a 45 minutes later. In the meantime they are all still listed as moving but deployed
-When they start moving the 3rd coys also start moving again up to the FUPs.
-After moving a bit they get reorg tasks a bit away and move to them, this seems like taking the actual positions for the attack formation.
Anything took so long that the actual attack moves from the Fup didn't start almost 2.5 hours after the initial attack was ordered.
The strange for me is this huge delay between first units hitting FUP and the time the get into the actual attack position, I doubt that the orders delay has somewhat to do with it.
I send the whole save set to contact@panthergames.com, I hope that is OK.
You should see what is going on when using Autosave #4.
I have seen this kind of behaviour, but put it down to them moving tactically in the dark/twilight, over very difficult, muddy terrain, in very cold conditions.
I don't know if that is the right answer or not, but am happy to roll play/use my imagination for a delay this short in the grand scheme of things.
RE: Build 4.4.259 Feedback
Well in such cases slow movements would make sense but these aren't slow movements, they simply stop the movement before all are at the FUP and new orders for taking the actual attack position are set 45 minutes ahead.
Seems to me like something isn't working correctly.
And I've seen that also with other battalion attacks but these 2 battalions I mentioned are the best example, they delayed so long that the 2nd battalion of the 48th that starts several kilometers further back and that I ordered to attack on the track that leads to the road north of Losheimergraben is almost on the same height when the other 2 battalion get their attacks finally rolling.
Can't believe that it should work that way.
Seems to me like something isn't working correctly.
And I've seen that also with other battalion attacks but these 2 battalions I mentioned are the best example, they delayed so long that the 2nd battalion of the 48th that starts several kilometers further back and that I ordered to attack on the track that leads to the road north of Losheimergraben is almost on the same height when the other 2 battalion get their attacks finally rolling.
Can't believe that it should work that way.
RE: Build 4.4.259 Feedback
I'll check out your save tomorrow BigDuke66.
-
- Posts: 2922
- Joined: Tue Sep 28, 2010 12:26 pm
RE: Build 4.4.259 Feedback
Dave? Not sure if this is a .259 prob specifically, or just something I can't get my head around, but see the dump below. I've only noticed this this build, so I'm posting it here.
I'm trying desperately to get 2 bases over the Arnhem highway bridge. The base above 1 AL, in the pic, 1 Para XX, has exactly the same issue.
Originally, I had tasked them to get over the bridge and all those 'stalled and waiting' messages appeared. Thinking it might be the proximity of the threat circled in red and yelow that was causing this I moved the task (hence the 'new orders' message) so that they only had to get as far as the new task marker you can see, well short of the nearest threat. Still no joy. Stalled and waiting. What on earth is causing this? It's maddening because everything else can get over (and to safety) no probs, but not the bases!!! They are going to be stuck there at nightfall and the Axis are going to find and destroy them. What should I do? And why does this happen?
I'm trying desperately to get 2 bases over the Arnhem highway bridge. The base above 1 AL, in the pic, 1 Para XX, has exactly the same issue.
Originally, I had tasked them to get over the bridge and all those 'stalled and waiting' messages appeared. Thinking it might be the proximity of the threat circled in red and yelow that was causing this I moved the task (hence the 'new orders' message) so that they only had to get as far as the new task marker you can see, well short of the nearest threat. Still no joy. Stalled and waiting. What on earth is causing this? It's maddening because everything else can get over (and to safety) no probs, but not the bases!!! They are going to be stuck there at nightfall and the Axis are going to find and destroy them. What should I do? And why does this happen?
- Attachments
-
- movingbasesprob.gif (945.41 KiB) Viewed 53 times
RE: Build 4.4.259 Feedback
Its because of this Phoenix
There is still a 1000m rule for Depots and higher echelon HQ's I belive?
Dave turned down the range for Bn HQ to 500m but the bases, and higher HQ are still 1000m I think.
Ahhh
That explains what I have been experiencing a lot, that I thought was a bug.
It happens quite often when I try to start new attack orders while the HQ is still on route to the new FUP.
It just stops and waits for hours.
Would it be possible to turn down the range for Bn HQ from 1000m to say 500m as when in close terrain, like the forest here, I quite often have my FUP close to the enemy, or should we just get into the habit now of setting it further back now?
Think this belongs here too [;)]
There is still a 1000m rule for Depots and higher echelon HQ's I belive?
Dave turned down the range for Bn HQ to 500m but the bases, and higher HQ are still 1000m I think.
ORIGINAL: Arjuna
The messages "stalled and waiting", "stalled and bypassing" an "stalled and replanning" were introduced in the last build. These all relate to cases where the subject of a Move task comes within threat range of an enemy ( 1000m plus unit radius ) and where the subject is a senior HQ (ie. Bde and above) or a Base for any type of Move task or is a support unit or any type of HQ conducting an advance to the Reserve position as part of an attack. If Bypass is allowed they will try to bypass. They may get several attempts at bypassing as sometimes the bypass route may not get them out of threat range. In such cases they will wait till the next attempt. With each attempt they increase the caution factor of the route thus giving a wider berth around known threats. If they can't bypass either because the option is not checked on the order setting or they just can't get a suitable route, then they will replan. This may not help. It depends on the orders they have and the situation around them.
So if you see these messages take a good look at the subject's situation and if necessary change its orders. HQs and support units are not meant to be placed in harms way.
The message "stalled attack" has been in the engine in for quite some time and relates to cases where an attack has failed to make progress. If the stalled force is part of a complex attack then it will bunker down leaving other subAttacks to continue. If it's just part of a basic attack then it will replan.
Ahhh
That explains what I have been experiencing a lot, that I thought was a bug.
It happens quite often when I try to start new attack orders while the HQ is still on route to the new FUP.
It just stops and waits for hours.
Would it be possible to turn down the range for Bn HQ from 1000m to say 500m as when in close terrain, like the forest here, I quite often have my FUP close to the enemy, or should we just get into the habit now of setting it further back now?
Think this belongs here too [;)]
-
- Posts: 2922
- Joined: Tue Sep 28, 2010 12:26 pm
RE: Build 4.4.259 Feedback
Thanks Daz. I wonder what the 1000m rule is meant to achieve? Something, no doubt. Was it put in to stop HQ and support units leading attacks, way back? I think we ought to be able to override it. 1000m for airborne units in a dense urban zone? It's a huge exclusion zone. Predictably, my bases were destroyed in the game above. They had no real option but to make that run through what was actually a very low threat zone, take the losses. The alternative, stuck where they were, was death. I could see they were going to get stuck and destroyed, but could do nothing to prevent it.
RE: Build 4.4.259 Feedback
Yes I agree there should be a user over ride. Something like a new X box maybe.
to go next to Basing, and ignore straglers, we could have ignore threats.
I would also like to see the HQ defend in situe when it can't get to the FUP, and conduct the attack from there, but alowing the line units to form at the FUP that you set, instead of just stalling because it can't get there.
Or even allow the last 3 clicks to be:
1, Reserve position for the HQ and mortar.
2, FUP for the line units
3, Assault objective
to go next to Basing, and ignore straglers, we could have ignore threats.
I would also like to see the HQ defend in situe when it can't get to the FUP, and conduct the attack from there, but alowing the line units to form at the FUP that you set, instead of just stalling because it can't get there.
Or even allow the last 3 clicks to be:
1, Reserve position for the HQ and mortar.
2, FUP for the line units
3, Assault objective
RE: Build 4.4.259 Feedback
Thanks for this one BigDuke66. It's taken me most of the day to work out why there was a StartAt delay for these subsequent tasks when there should not have ben one. It turns out that while I had passed down the line of calling functions the OrdersDelay type I had failed to pass down the line the StartAtDelay type in quite a few cases. I put that down to not enough sleep - senility hasn't claimed me yet! Anyway that's my line and I'm sticking to it. [;)]ORIGINAL: BigDuke66
As we speak of fluid & dynamic I think there maybe something wrong with the "build up" to an attack.
Can't really nail it down but let me describe.
-Started Elsborn Ridge and issued all the battalion attacks.
-I let the 2 Bats south (I of the 27th and I of the 48th) attack in left & right echelon towards Losheimergraben.
-They start moving up to the FUPs(Behidn the rail for 27th and at the T crossing for 48th).
-When the first 2 coys of each bat. hit the FUP the movement task is reported as complete but the 3rd coys(I guess used as rear guard but they don't have that role listed) are still far behind and in road column, these coys deploy and do not move up to the FUP anymore.
-Now the first 2 coys get tasks to switch places with each other while the 3rd should still move up to the FUP. Strange here is that these movement orders are far in the future, 2 first coys hit FUP shortly before 7.00 but these new move orders don't start about a 45 minutes later. In the meantime they are all still listed as moving but deployed
-When they start moving the 3rd coys also start moving again up to the FUPs.
-After moving a bit they get reorg tasks a bit away and move to them, this seems like taking the actual positions for the attack formation.
Anything took so long that the actual attack moves from the Fup didn't start almost 2.5 hours after the initial attack was ordered.
The strange for me is this huge delay between first units hitting FUP and the time the get into the actual attack position, I doubt that the orders delay has somewhat to do with it.
I send the whole save set to contact@panthergames.com, I hope that is OK.
You should see what is going on when using Autosave #4.
I have done global searches and fixes and it looks all good now. Here's a shot taken from your Auto Save #1 and run with the new code. Note that the two attacking Bns moved straight from the Move to the Reorg without any delay.
- Attachments
-
- Reorgwithoutdelay.jpg (358.59 KiB) Viewed 53 times
RE: Build 4.4.259 Feedback
Ah great, looks pretty!
Was a pleasure to help.
Will you make another beta right away or wait for more feedback?
Was a pleasure to help.
Will you make another beta right away or wait for more feedback?
RE: Build 4.4.259 Feedback
I have a nasty crash courtesy of our mate Ramses, which is being particularly hard to track down. I need to fix that first before putting out another build. Also Miquel is looking into the attack time coordination issue. So it will be a few days yet.