Wish list

[Curval]

At the top of my wish list would be an indication from a task force whether or not it thinks it has been sighted.

I know we get reports during the review of combat..but highlights on sighted TFs would be very nice.

Thanks.

[estaban]

My wish list would be to be able to set targets better on naval attack missions. The ability to concentrate on certain kinds of ships/TFs (carriers, transports, escorts) or the ability to set range limits that your bombers will not attack beyond, or only on rare occasions when they get confused.

[RevRick]

a little arrow or something to indicate the last reported course of a sighted enemy TF?

[estaban]

That would be useful, sometimes you lose track of enemy TFs that are near the edges of the map. It would be nice to have a "list enemy TFs" button for spotted enemy task forces.

[demonterico]

I wish the intellegence reports given during the combat replay were stored in a file so they could be reviewed after the combat was finished.

[Veer]

A way of vectoring in your surface combat TF to intercept a spotted approaching or retreating enemy TF.

[mbatch729]

Originally posted by demonterico
I wish the intellegence reports given during the combat replay were stored in a file so they could be reviewed after the combat was finished.

Lots of people have requested this one. Last I heard, it was on the list of things to be added to WiTP, and hopefully retrofitted to UV.

[Micah Goodman]

I wish you could transfer task force commanders from one ship or another, or at least have an indicator of what ship in your TF he is flying his flag from. And secondly I wish you had the ability to remove excess planes from squadrons at will. I hate trying to return squadrons back to damaged aircraft carriers after they have landed some where else. The current system is very screwy as far as I am concerned.

[estaban]

The first ship listed in each TF is the flagship.

Also, it would be nice if you could choose which squadrons drew replacements and which didn't. I hate it when my carrier squadrons are heavily attrited, but they have to wait to draw full replacements becuse some land based squadrons of the same kind are drawing them as well.

[pasternakski]

Sh1tcan the individual pilot name thing.

[Rainerle]

I'd like to know how long a ship will be in repair beforehand either in Truk/Noumea and/or Tokio/Pearl. The only way to know now is to save the game send the ship back and have a look at the availability date. With on-map repairs nobody tells you (nobody even guesses for you).

[m10bob]

Very minor...The graphic for the Nakajima "Nell" needs to be changed.It was a twin rudder bomber,like the American B-25..Presently,it is represented "top-down view" by a single rudder rendering..Very impotant plane..
(How would you like a B-24 being represented with a B-17 tail assembly?)

[tangent]

This has been piling up for a while so here goes. My wish list in no particular order:

1) A vector indicating a TF's direction and speed.

2) The ability to set target class priorities for naval air attack missions. Such priorities would not be absolute but improve the likelihoods of certain ship classes being targeted. Such a prioritizing exists already but it is fixed to carriers first, BBs second, etc. This means that currently experienced players can game the system by putting say a cruiser or BB in a transport group, or by having surface action TF follow a tansport TF in order to attract aircraft away from the transports. This is artificial behavior. I want to be able to prioritize aircraft to attack transports, for example, and occasionally have the AI be able to perform a similar prioritizing.

3) The ability to load and unload landing craft from ship to shore, ala the movie Away All Boats. I am not sending my landing craft across the Pacific! They are supposed to ride on ships to get there and back. If the designers are arguing that carried landing craft used in a ship to shore role are abstracted into the existing beach landing system (and that the landing craft that show up are extras) then the abstraction needs to make the ships carrying the landing craft less vulnerable to shore batteries, perhaps on a progressively less vulnerable basis as time goes by (to reflect more landing craft as time goes by). I don't have a big problem with the idea that the landing craft are abstracted but the abstraction is not working as well as I think it should. Currently troops landed by real landing craft get ashore faster and are apparently less vulnerable in the aggregate than troops landed by abstract "landing craft."

4) An end to to some of the artificial distinctions of when a ship is in port and when it is not. Ports are more of psychological barrier than a real barrier to surface naval and air naval attacks.

a) Air naval attack missions may attack ships in port under some conditions (but torpedoes will be ineffective).

b) Air naval search missions may under the right conditions provide information on ships in port. Ports are not necessarily a cloaking device against standard air searches.

c) Ships that are docked should considered to be inside the port if the port is large enough to have an anchorage (size 3 or larger). It is absurd that docked ships are more exposed to naval surface attack than anchored ships. Indeed anchored ships are in reality more vulnerable because they are closer to the harbor entrance.

d) Shore batteries should be able to protect docked ships as well as ships at anchor from naval surface attack. Again they are further inside the port than anchored ships are. Conversely it should be possible to have naval surface attacks operate against docked or anchored ships (the horror!) but such attacks require that the surface task force commander make the calculation to risk taking fire from any shore batteries that might be protecting the port; because of this calculation he may very well choose to engage only targets outside of the port (or targets inside the port at long range only).

5) Task force interceptions at sea. I know that submarines have been fixed to intercept a TF at any point on the TF's course, but has this been fixed for between ship TFs as well? I don't think so.

6) Allow TFs to target enemy TFs for interception. Incidentally this requires no change in interface design since there is a control for a TF to follow a friendly TF already and if one looks carefully one can sometimes see this same control being used by sub TFs to indicate an enemy TF as a target. Allow the player to use the same interface control to target an enemy TF for interception. Similarly if the AI is reacting toward an enemy TF have the same "follow TF" control indicate what the target was. Targeting a specific enemy TF for interception should not be an absolute however as the AI may be able to override this (even stupidly) and it will depend upon the level of detection gained on the targeted enemy TF.

7) Make the one hex carrier reaction rule (8.23) apply only when a carrier TF is set to react. Note that the documentation on this rule is incomplete; if a carrier TF is set to follow another TF it will not perform a one hex reaction although it has clearly not aborted its mission. If this proposal is not accepted, then improve the documentation so that players know that have only limited control over this special reaction. I had one game end because my opponent did not understand how this rule worked, he set up his carriers to Do Not React, but they reacted one hex anyway exposing his carriers with only limited CAP to my combined carriers (and losing the campaign). He quit the campaign then and there.

8) Allow ships to exit the map by going off of a map edge rather than from a specified port. It is absurd to have a situation where one's ships are trapped against the map edge even though they are closer to Pearl Harbor than Noumea is. The time back to Pearl Harbor or Japan should vary depending upon which map hexes are exited. Some map edges probably should be prohibited as exit points for specific navies. This can be done in two ways without changing the interface:

a) activate the "Return to Pearl Harbor"/"Return to Japan" control on a ship's record whenever a TF's DH is on a valid map edge and have the program remember to exit the ships ordered to leave when they arrive at that DH; or more simply,

b) Whenever a ship is in a valid exit hex during the orders phase, activate the "Return to Pearl Harbor"/"Return to Japan" control on a ship's record and, if it is selected by the player, the ship leaves the map like it does when it is at Truk or Noumea.

9) Make some trails harder to move vehicles and guns on than others, e.g. Kokoda. This is certainly too late for UV but it deserves consideration for WITP.

10) Put in the trail from Port Moresby to Gilli Gilli as shown on the WITP map.

11) I think that it is cool and realistic that army units transported on barges will shoot back against submarines (and I assume that this is true for army units on landing craft but I have not seen it). However, this is not documented anywhere.

12) Signals intelligence indicating the identity of ground units, especially HQs. This can show up in the popup field that appears when one is looking at enemy land units.

13) A saved text file of the current turn's combat phase's scrolling spotting and supplementary combat reports, or the inclusion of this extra data into the existing combatreport.txt file.

14) Different combat phase reports for each side to better reflect the fog of war. I know that this is a long shot.

15) A suppression of extraneous information that is really known only to one side during the Combat Phase. Given that 14) above is unlikely, I am only referring to those things that have no relationship to combat during the phase in question, such as announcing to the enemy that my subs are loading mines.

16) Perhaps there should be an AAA penalty for having more than x core ships (e.g. carriers or battleships) in a TF similar to the AAA penalty for having more than 10 ships providing AAA defense. This may encourage players to disperse their carriers into separate TFs without forcing them to do so. In reality I would think that AAA coverage for a core class ship might very well go down if there are too many core ships in the TF.

[tangent]

I forgot one.

17) Integration of the combat phase into both side's files so that the Japanese player is not required to send two files to his opponent.

[Ron Saueracker]

Originally posted by Rainerle
I'd like to know how long a ship will be in repair beforehand either in Truk/Noumea and/or Tokio/Pearl. The only way to know now is to save the game send the ship back and have a look at the availability date. With on-map repairs nobody tells you (nobody even guesses for you).

How could anyone know the extent of damage, dockyard availability, refit requirements etc until they arrived at the naval yard?

[mogami]

Originally posted by tangent
I forgot one.

17) Integration of the combat phase into both side's files so that the Japanese player is not required to send two files to his opponent.

Hi, How is this to occur? Since the game file needs both players input before resolving one player will always be a half turn behind or a half turn ahead.

Japan enters orders send to US who enters orders. Turn now must be resolved. It can be at end of US turn (and he could see turn. Then complete turn resolves again as current for Japanese (but a file would need to be included to keep synch)

The current system updates map at end of combat phase but before Japanese player enters new turn. Then this updated data (plus Japanese orders) is sent tho US player. He has to view the "old" data because the file is no longer the same as that which produced the combat phase (the Japanese have altered it based on the changes from the combat)

I'm one of the players who don't want both combat views to be the same (I want a Japanese view of the battle and a US view of the battle. The Japanese view would not include Allied spotting reports and would base air combat reports on Japanese pilot reports. The US view would not show Japanese sightings and would use US pilot reports. But the important thing would be all damage (reported or not reported) would be the same in actual effect on units.

Since the Japanese see the combat first hand (and this is always what has actually occured no matter what the replay shows) They always know more detail then the allied player (if replay is out of synch)
The Allied replay should be password protected so the Japanese player can not view the enemy point of view.

[tangent]

I don't see the logical difficulty, although I am certain that it is not trivial to program this.

Currently the Combat Phase file is generated by the Japanese player when he opens his order file and then this file is supposed to be sent by the Japanese player as a separate attachment. It does not seem to be impossible to incorporate the data of the Combat Phase file as a separately treated set of records in the Japanese player's completed order file so that he has only one file to send to the Allied player.

When the Allied player opens the Japanese player's sent orders file, he sees the replay first just as the Japanese player sees the newly generated Combat Phase first. However, in this case the Allied player is not looking at a file that is actually being generated, he is seeing just a repeat of what was already generated for the Japanese player. It is, after all, the same data as the Combat Phase file; it's simply put into a different place. It's not really a symmetrical relationship but each player interacts with the data as if it is a symmetrical relationship, synch issues aside. The point is to simplify the required actions for PBEM play.

Mogami writes..
Hi, How is this to occur? Since the game file needs both players input before resolving one player will always be a half turn behind or a half turn ahead.

Of course, separate Combat Phases with different reports for each side would be even better, as you have suggested, but even there I see no logical difficulty with incorporating the Combat Phase data into the orders file.

[mogami]

Originally posted by tangent
I don't see the logical difficulty, although I am certain that it is not trivial to program this.

Currently the Combat Phase file is generated by the Japanese player when he opens his order file and then this file is supposed to be sent by the Japanese player as a separate attachment. It does not seem to be impossible to incorporate the data of the Combat Phase file as a separately treated set of records in the Japanese player's completed order file so that he has only one file to send to the Allied player.

When the Allied player opens the Japanese player's sent orders file, he sees the replay first just as the Japanese player sees the newly generated Combat Phase first. However, in this case the Allied player is not looking at a file that is actually being generated, he is seeing just a repeat of what was already generated for the Japanese player. It is, after all, the same data as the Combat Phase file; it's simply put into a different place. It's not really a symmetrical relationship but each player interacts with the data as if it is a symmetrical relationship, synch issues aside. The point is to simplify the required actions for PBEM play.

Mogami writes..
Hi, How is this to occur? Since the game file needs both players input before resolving one player will always be a half turn behind or a half turn ahead.

Of course, separate Combat Phases with different reports for each side would be even better, as you have suggested, but even there I see no logical difficulty with incorporating the Combat Phase data into the orders file.

Hi, OK I was not too clear. Go check property of your game file size. Now look at replay file. Check every turn. You'll see the game file stays the same but the replay does not. (This is because some turns have more events then others.)
It does not matter to the program if the replay file does not remain the same size. No data is used to run the program from the replay. However I think the game file has to stay the same size from turn to turn. (To insure it is not being tampered with and other reasons)

Also the complete sequeance after turn 1

Japanese
Allied
combat
Japanese
replay
Allied

Suggested

Japanese
Allied
combat (now all data at this point would need to join file for replay.)
Japanese (before allied player gets file Japanese player alters data)
replay
Allied (Allied player alters data more)

I hope you see it is much simpler to have 2 files for these 2 different functions.
Replay and input/resolution

(Do you remember PacWar? Japanese had to send 4 files and Allied 3)

[Rainerle]

Originally posted by Ron Saueracker
How could anyone know the extent of damage, dockyard availability, refit requirements etc until they arrived at the naval yard?

I'd say some competent navy person (not me) could make a good guess or some rough estimate at least.

[mbatch729]

Originally posted by Rainerle
I'd say some competent navy person (not me) could make a good guess or some rough estimate at least.

The appropriate term would be WAG, or SWAG, depending upon whom you talk to.

WAG - Wild A$$ Guess
SWAG - Stupid(Silly) Wild A$$ Guess