AE Naval and OOB Issues [OUTDATED]

[cantona2]

LY

Not much given away, pretty much what you've written in your emails! Ive not encountered as many problems as you and the two times I've tried to use merge, then follow it seems to have worked fine. Knowing how meticulous you are in the composition of your TF's it precludes any issues such as different ship speeds within TF and son on. Hope it doesn't mean then end of our Watchtower game.

[cantona2]

ORIGINAL: Local Yokel

Following on from my post #706, I am still having considerable problems with task forces that disregard the orders I have given them. I have already posted two relevant saves in a Tech Support thread, in which I gave the following details of one set of problems I had encountered:

ORIGINAL: Local Yokel

Final problem. There are various TF's with 'follow' orders, with the lead ASW TF 51 being followed by other TF's, each with an order to trail TF 51 by 1 hex, but with no stand-off at destination. In turn these following TF's are followed by other TF's but with NO separation. Thus, for example, TF 52 is to trail TF 51 by 1 hex, and in turn TF 12 is to trail TF 52 by 0 Hex - hope that's clear! Problem is that save 010 shows all these TF's in the same hex (short of their destination); i.e. the orders issued have failed to make TF 51 perform its role as a vanguard anti-submarine sweep.

Another turn has now passed, before which I had modified these TFs' orders so that TF 51 should still remain out in front by one hex, and all the other TF's should stand off TF 51 by one hex when it reached its destination hex. Following the combat resolution phase of the turn in which these amended orders were entered, the position is now as follows:

(1) TF 51 is one hex short of its destination hex.
(2) One TF that was ordered to trail TF 51 by one hex is occupying the same hex as TF 51
(3) Three TFs that were ordered to trail TF 51 by one hex are trailing it by 2 hexes
(4) Three more TFs that were ordered to trail the TFs mentioned in (3) by zero hexes are trailing them by three hexes. As a result of the orders issued these last three TFs should have ended up one hex behind TF 51, along with the TFs mentioned in (3); in fact they have ended up five hexes behind.

This outcome bears no resemblance to what should have happened, and has resulted in my major fleet units being spread out over a distance of 200 miles rather than 40. I could have no complaint if my ships had been dispersed by enemy action, but nothing like that has occurred, and my careful attempts to advance the fleet in mutually supporting task groups have been completely nullified by this failure to follow the orders I gave.

This isn't the only problem I am having with disobedient TFs. In this same turn I had a FT TF ordered to meet, then follow, an ASW TF ordered to sortie from its base then return. Instead, the FT transport simply went straight to the ASW TF's home base, leaving the ASW TF stranded at the point at which I had expected the meeting to take place and from which I expected it to return. It did not return ahead of the FT TF as ordered.

Another ASW TF was ordered out to meet an incoming convoy which it was then ordered to follow. It appears to have gone out to the meeting point, since it is now showing expenditure of op points, no doubt from refuelling. Trouble is, it didn't stay with the TF it was ordered to meet, but just went out and came straight back to base.

I'm sorry to have to say that I have lost all confidence in the game's ability to make task forces follow what appeared to me to be reasonably straightforward and sensible orders of the kind for which I assume the 'meet' and 'follow' mechanisms were devised. I can accept that some departure from given orders could take place, reflecting the effects of the elements and enemy action. However, when there is such a total failure of TFs to follow the movement orders I have given, there really isn't much point in my attempting to make effective plans for the use of my units. Instead, I might as well order a headlong charge at the enemy on the basis that the outcome is going to be determined entirely by chance and in no way influenced by anything I've done to enhance my prospects of victory.

I suppose I could follow Chad Harrison's suggestion and move the individual TFs manually to explicit destination hexes, but I can't say that I'm any more confident about how far task forces are going to move per turn. Rather than have a whole lot of new features for task force movement that cannot be relied upon to work, I would much rather have a few simple features that do work and that I can rely upon. Otherwise playing the game is just a waste of my time.

There. I've probably given much useful intelligence to my PBEM opponent in this post, but I'm past caring. Sorry, but I have well and truly exceeded my exasperation quotient for the day.

I had no idea orders such as these could even be attempted to be implemented

[Don Bowen]

I'm sorry you are having these difficulties.

Several issues have been found and corrected in this area - with significant help from the saves you have posted. I do not know if every item is fully corrected, but I do believe that all of the specific items from the saves have been addressed.

A majority of the issues were caused by two things:

1. A Bleed over from AI processing. The AI has several special TF movement features that "help" it with complex instructions. There is a different and richer set of options available to the human player. Late in the development cycle, some of the "human" functions were enabled for the AI. This "tightened" the coupling between AI and human TF processing and allowed the bleedovers. Unfortunately they are each rather specific and no all encompassing solution has been found. We just keep sticking Dutch Boy’s Fingers into it. Hopefully it is nearly solved, although more complex series of instructions to a TF may still find a gap in the process. Note that you can always correct such a problem by simply reassigning a TF to a destination (even if it is the same as the current destination). This will reset the controls that are confusing things.

2. A series of design alterations in Meet TF processing. The original Meet (and Follow) used to have a path convergence process that attempted to find a meeting point x moves ahead. If necessary, one or the other TFs would stop to allow the other to catch up. Both of these functions were unpopular during Beta testing, especially the stop and wait. We also found that players made somewhat more excessive demands on Meet that we had expected. TFs from distant locations and disparate speeds, for instance. Also a tendency to use Follow and Meet interchangeably - the original design of follow was for TFs behind the followed TF with Meet being for TFs ahead of the met TF.

Follow was adjusted to resort to direct closing and a speed adjustment that did not include full stop. To compensate, the following TF could “automatically” increase to full speed for one or more turns to attempt to catch up.

Meet was also adjusted but with an eye of movement efficiency. The offending part of this adjustment was the selection of meeting point when the “meeting” TF was closer to the destination of the “met” TF that the “met” TF was. In effect, both TFs would move to the destination and meet there. This was removed in Patch 1 and replaced with a somewhat complex calculation of a meeting point – one that fell back to the Follow process if necessary. Since Patch 1 we have found a couple of “typo” level issues with this process as well as a “damn, how did I ever make that mistake” level one.

[Local Yokel]

ORIGINAL: cantona2

LY

Not much given away, pretty much what you've written in your emails! Ive not encountered as many problems as you and the two times I've tried to use merge, then follow it seems to have worked fine. Knowing how meticulous you are in the composition of your TF's it precludes any issues such as different ship speeds within TF and son on. Hope it doesn't mean then end of our Watchtower game.

Merge I haven't found a need to use, but 'follow' I regard as highly important. I want my ASW screen to find your sub before it finds my SAG [:D]

I'm trying work around this as best I can. As I write this, I'm concocting a fresh set of TF orders, but just now the supper bell tolled, so there will be a delay before I can send the next turn.

It tolls for thee. [;)]

[cantona2]

of that i'm sure! but it may toll back[:)]

[cantona2]

ORIGINAL: Don Bowen

I'm sorry you are having these difficulties.

Several issues have been found and corrected in this area - with significant help from the saves you have posted. I do not know if every item is fully corrected, but I do believe that all of the specific items from the saves have been addressed.

A majority of the issues were caused by two things:

1. A Bleed over from AI processing. The AI has several special TF movement features that "help" it with complex instructions. There is a different and richer set of options available to the human player. Late in the development cycle, some of the "human" functions were enabled for the AI. This "tightened" the coupling between AI and human TF processing and allowed the bleedovers. Unfortunately they are each rather specific and no all encompassing solution has been found. We just keep sticking Dutch Boy’s Fingers into it. Hopefully it is nearly solved, although more complex series of instructions to a TF may still find a gap in the process. Note that you can always correct such a problem by simply reassigning a TF to a destination (even if it is the same as the current destination). This will reset the controls that are confusing things.

2. A series of design alterations in Meet TF processing. The original Meet (and Follow) used to have a path convergence process that attempted to find a meeting point x moves ahead. If necessary, one or the other TFs would stop to allow the other to catch up. Both of these functions were unpopular during Beta testing, especially the stop and wait. We also found that players made somewhat more excessive demands on Meet that we had expected. TFs from distant locations and disparate speeds, for instance. Also a tendency to use Follow and Meet interchangeably - the original design of follow was for TFs behind the followed TF with Meet being for TFs ahead of the met TF.

Follow was adjusted to resort to direct closing and a speed adjustment that did not include full stop. To compensate, the following TF could “automatically” increase to full speed for one or more turns to attempt to catch up.

Meet was also adjusted but with an eye of movement efficiency. The offending part of this adjustment was the selection of meeting point when the “meeting” TF was closer to the destination of the “met” TF that the “met” TF was. In effect, both TFs would move to the destination and meet there. This was removed in Patch 1 and replaced with a somewhat complex calculation of a meeting point – one that fell back to the Follow process if necessary. Since Patch 1 we have found a couple of “typo” level issues with this process as well as a “damn, how did I ever make that mistake” level one.

So can we be correct in assuming these issues will be dealt with in Patch 2?

[Don Bowen]

ORIGINAL: cantona2

So can we be correct in assuming these issues will be dealt with in Patch 2?

Why yes, of course.

[cantona2]

[:D]

[Don Bowen]

Three truths.

1. All Generalities are lies.
2. Programming causes bugs.
3. Fixing bugs is programming (see #2).

[JWE]

ORIGINAL: Don Bowen
Three truths.

1. All Generalities are lies.
2. Programming causes bugs.
3. Fixing bugs is programming (see #2).

The most pithy description of the issue I've ever seen.

Attempting to model real life requires:
An infinite set of inputs;
An infinite set of variables; and
An infinite set of outputs.

Resulting in:
An infinite probability of error.

So, one must generalize, but all generalizations are lies, so one must use analogs. Ain't life fun? [;)]

[Don Bowen]

ORIGINAL: JWE

ORIGINAL: Don Bowen
Three truths.

1. All Generalities are lies.
2. Programming causes bugs.
3. Fixing bugs is programming (see #2).

The most pithy description of the issue I've ever seen.

Attempting to model real life requires:
An infinite set of inputs;
An infinite set of variables; and
An infinite set of outputs.

Resulting in:
An infinite probability of error.

So, one must generalize, but all generalizations are lies, so one must use analogs. Ain't life fun? [;)]

Of all the posts I have ever read - this is the most recent.

[JWE]

ORIGINAL: Don Bowen
Of all the posts I have ever read - this is the most recent.

Yeah, been trying to teach the dog to piss in bowl; every time she hops up, the phone rings!

[Mynok]

LMAO!

[Local Yokel]

Don, thank you for your comprehensive response in post #723.

FWIW, both the failed meets to which I referred involved head-on intercepts, but I could have been guilty of pre-empting the meet code by predicting where one meet would occur and ordering the TF that was to be met to go to that point then return.

I had a good chuckle at "We also found that players made somewhat more excessive demands on Meet that we had expected." You mean you weren't aware that the end-user will always find an ingenious way to turn your code into a train wreck?!

I also got a laugh out of “damn, how did I ever make that mistake”. I've spent enough time staring in dropped jaw disbelief at my own code to know that my capacity for such elementary error knows no limit.

When the dust settles on patch #2 or whatever, all I ask is to be confident the game will do what I am told it will do, so it's my opponent I can be fighting and not the game itself. Simple but reliable works much better for me than "really, really clever, but it may never happen."

[Don Bowen]

I absolutely guaranty that, except for any mistake, everything will be perflecdt.

[Mynok]

perflecdt

Ok, if I knew what that meant would I  be happy or concerned? [&:][:D]

[Don Bowen]

ORIGINAL: Mynok

perflecdt

Ok, if I knew what that meant would I  be happy or concerned? [&:][:D]

Yes

[Adronson]

The title of this thread mentions "OOB Issues," but I'm not sure if this is the place to mention this. It definitely involves OOB but likely doesn't rise to the level of "Issue."

There seem to be a lot of missing type II LST's in the ship availability list. Is there some reason they were left out?

I know they are just numbers to some folks and it's not a big deal in the game which numbers are in and which are out, but some of the ones gone saw a lot of action later in the war. My Dad's ship is among them, LST-681, which was in the Philippine invasions and Okinawa and had either two of three battle stars, depending on the source.

Edit: Another non-issue in the Typo division is that some of the LST's have a dash between the letter and the number "LST-674" and some don't "LST 538" with the result that the list of LST's doesn't alphabetize properly.

[JWE]

ORIGINAL: Adronson
The title of this thread mentions "OOB Issues," but I'm not sure if this is the place to mention this. It definitely involves OOB but likely doesn't rise to the level of "Issue."
There seem to be a lot of missing type II LST's in the ship availability list. Is there some reason they were left out?
I know they are just numbers to some folks and it's not a big deal in the game which numbers are in and which are out, but some of the ones gone saw a lot of action later in the war. My Dad's ship is among them, LST-681, which was in the Philippine invasions and Okinawa and had either two of three battle stars, depending on the source.

There are literally hundreds of LST/LCIs built on the west coast that may, or may not, have served in-theater, not to mention hundreds of others that may, or may not, have transited the ditch. And when you add the hundreds of Liberties, you end up with over a thousand vessels.

Now, who did, and who didn’t, serve in Pac for a sufficient period of time to be included in the OOB? And how does one know? There are hints and indications, but they are valid for maybe 8-10% of the possibilities; and there has never, ever, been a listing of class-type service by theater.

Could be done, perhaps, but would take some years, a great deal of effort, and have no real value even in situations like this. For example, if the Liberty ship SS Ben Dover was historically in the Alaska Theater in September 1943, what would happen to “reality” if a player put her into a convoy to Sydney in August? Woof!! So, yes, the very large ship classes are representational, and not specific. Sorry about your Dad’s boat – lemme see if I can sneak it in.

Edit: Another non-issue in the Typo division is that some of the LST's have a dash between the letter and the number "LST-674" and some don't "LST 538" with the result that the list of LST's doesn't alphabetize properly.

Not a typo, but a differentiation. An LST (-) is US, an LST (sp) is British.

[Adronson]

ORIGINAL: JWE
Sorry about your Dad’s boat – lemme see if I can sneak it in.

Thanks for the personal service. I've been playing since the original SSI version came out and have always been amazed at the level of detail. It gets better with every redesign.

Sorry, I should have picked up on the difference between US and UK designations.

Regarding LST's, the Dictionary of American Naval Fighting Ships have recently updated and expanded their listing of LST's. It is now fairly complete and usually includes details of service. Transfers to the UK, theater of operations, assaults and landings, and number of battle stars are all there now. I'm not sure when they updated it, but I don't recall that level of detail last time I checked it.

Not that I am advocating a redo of the LST OOB. There are hundreds of them.

DANFS - L listings