RE: RHS 6.15 Problem (Full Version)

All Forums >> [Current Games From Matrix.] >> [World War II] >> War In The Pacific - Struggle Against Japan 1941 - 1945 >> Scenario Design



Message


Bliztk -> RE: RHS 6.15 Problem (10/25/2006 1:05:18 PM)

You should have installed the pwhex.dat file that match the art. If not you are playing with the older map, even if you see the new art




davidjruss -> RE: RHS 6.15 Problem (10/25/2006 1:23:44 PM)

I thought I had the correct versions and all the necessary downloads.

I am using RHS v6 hexside map dated 7.10.06 and have added the hex data v6 release dated 13.10.06.

My map has the pathways in outline but there appears to be no barrier to prevent TF's from straying from the path.

Am I missing a different dated file? - all downloads obtained from akdreemer site.




Bliztk -> RE: RHS 6.15 Problem (10/25/2006 1:32:47 PM)

you need to copy the pwhex.dat into the main directory of witp, if not you are playing with the original or AB map`s pwhex




el cid again -> RE: RHS 5.15/6.15 update - UPLOADED (10/25/2006 1:46:33 PM)

Andrew reports problems with map edge hexes - specifically row 1 and column 1. Cobra ran tests to see if ships would run, fuel, etc. But we didn't test resources and oil. I will run some tests. Thanks.




el cid again -> RE: RHS 6.15 Problem (10/25/2006 1:47:42 PM)

quote:

ORIGINAL: DavidR

Just a quick Question - Using RHS V6 map how do you get the TF's to follow the long paths from say Panama or TDC to the main Pacific area?
My map is all blue without the grey barriers as shown in Andrew Brown's CHS extended map and in consequence the TF's ignore the pathways and take the shortest route.
Am I missing a map update?

Many thanks    



Probably you are missing the Level 6 pwhex file. Also - even if you have it - it must be in the top level WITP folder - not just in the SCEN folder. [I don't think it has to be in the SCEN folder - but it always is there as well. But the top level folder version is the one used when you load the game. If it is Level 5 - it won't have the ship channels for Level 6]




davidjruss -> RE: RHS 6.15 Problem (10/25/2006 1:53:57 PM)

Thanks BLiztk.

I have just copied the latest pwhex.dat to the RHS main folder  ( I have 3 versions of WITP on my HD with  RHS as a separate folder ).

Just looked at my save game for Scenario 65 RHSEOS and connot see any change - sorry to be a pain but with an up to date map should the pathways look any different from the rest of the ocean squares? - I just have the outline of the pathways but will TF's follow this?

many thanks 




el cid again -> RE: RHS 6.15 Problem (10/25/2006 3:22:34 PM)

If you have any doubt what pwhex files you have - PM me or Mifune or Cobra with an address and we will send it directly to you.




witpqs -> RE: RHS 5.15/6.15 update - UPLOADED (10/26/2006 1:57:26 AM)

quote:

ORIGINAL: el cid again

Andrew reports problems with map edge hexes - specifically row 1 and column 1. Cobra ran tests to see if ships would run, fuel, etc. But we didn't test resources and oil. I will run some tests. Thanks.


Well, if that turns out to be the case, maybe just move Tristan-dC and Cape-GH UP one hex, then change the hexsides around them. Since movement appears okay on the edge, making the two bases in a little bump should be enough to do the trick.




Mifune -> RE: RHS 5.15/6.15 update - UPLOADED (10/26/2006 2:02:46 AM)

LOL, I just e-mailed the same suggestion. Though my terminology was a bit different, it did imply the same result.




witpqs -> RE: RHS 5.15/6.15 update - UPLOADED (10/26/2006 2:34:14 AM)

Hah! You are obviously a genius! [:D]




Mifune -> RE: RHS 5.15/6.15 update - UPLOADED (10/26/2006 4:45:22 AM)

They say that great minds do think alike. [:D]




el cid again -> RE: RHS Level 6.2 pwhex - and revised EOS ship files uploaded (10/26/2006 12:43:37 PM)

There was a problem in all RHS Level 6 scenarios loading fuel, oil or resources at Tristan da Cunha or Capetown.
This was a pwhex file issue and - because it was - you may fix the problem without restarting a game. The new pwhex file set (pwhex.dat, RHSPW62.dat, and PANPW62.dat) are uploaded.

There was a problem in EOS only - both Level 5 and Level 6 - that Hiyo lost its date of appearance. This made the ship appear at the start of the game instead of in July 1942. New ship files are uploaded for EOS only.





Jo van der Pluym -> RE: LCU ERRORS? (10/28/2006 12:48:50 PM)


El Cid Again

1. The Corregedor/Bataan Fort has is the scenario's 12x 388 Soviet Mech SMG Squads. I think that this is a error or are they volunteers. [:D]

2. The AA Para Bn has USA 44 Airborne Squads. Must that not be ANZAC?

3. You have a BA 77th Chindit Bde (2827) and a IA 77th Chindit Bde. (2943)in the oob. PS thid brigade is in January 1945 reformed as Parachute Brigade.

4. I miss the BA 5th Airborne Brigade Group. Who arrive in July 1945. And take part in operation Zipper?





JeffroK -> RE: LCU ERRORS? (10/28/2006 12:54:22 PM)


quote:

ORIGINAL: Jo van der Pluym


El Cid Again

1. The Corregedor/Bataan Fort has is the scenario's 12x 388 Soviet Mech SMG Squads. I think that this is a error or are they volunteers. [:D]

2. The AA Para Bn has USA 44 Airborne Squads. Must that not be ANZAC?

3. You have a BA 77th Chindit Bde (2827) and a IA 77th Chindit Bde. (2943)in the oob. PS thid brigade is in January 1945 reformed as Parachute Brigade.

4. I miss the BA 5th Airborne Brigade Group. Who arrive in July 1945. And take part in operation Zipper?




1. This was probably inherited from CHS

2. If AA means Australian Army, at the least they should be Commonwealth.

3. Its that CHS again.





el cid again -> RE: LCU ERRORS? (10/28/2006 11:44:52 PM)

388 is a typo for 399 - they should be .30 cal AAMG

Since there are no ANZAC para squads they are US

If it isn't in CHS it isn't in RHS - unless someone mentions it.




el cid again -> RE: LCU ERRORS? (10/28/2006 11:50:15 PM)

We have learned that 200 Squadron RAF is a duplicate - it is a reformed 8 Squadron - and notified Matrix and Andrew - because both units appear in all scenarios.




witpqs -> RE: 6.15 ERRORS (10/30/2006 6:10:15 AM)

In 6.15 EOS

- Swordfish I is still equipped with rockets and bombs (el cid noted it should be torpedoes until a later variant).

- Bad news about the carrier squadron re-sizing work-around: CVL Hermes' two squadrons, each 6 a/c, both resized to 2 a/c when disbanded in Trincomalee. Previously we thought only disbanding where a theater HQ was present would result in re-sizing.

- USN Kennebec class AO is listed as 15,000 capacity. This was due to a bug in code where values over a certain amount were counted as negative. Bug was fixed in 1.802, so Kennebec class can be reconfigured with true (very large) capacity again.




el cid again -> RE: 6.15 ERRORS (10/30/2006 8:47:50 AM)


quote:

ORIGINAL: witpqs

In 6.15 EOS

- Swordfish I is still equipped with rockets and bombs (el cid noted it should be torpedoes until a later variant).

REPLY: This is confusion: there is no later variant. RHS now is flying the Swordfish I - as stated - and it has a tropedo - in all scenarios. It has an earlier radar and rockets. If you don't pick the right mission, it will drop bombs.

- Bad news about the carrier squadron re-sizing work-around: CVL Hermes' two squadrons, each 6 a/c, both resized to 2 a/c when disbanded in Trincomalee. Previously we thought only disbanding where a theater HQ was present would result in re-sizing.

REPLY: More confusion I think. You should NEVER disband ANY carrier squadron EVER. Period. The results will generally be bad. Joe says don't - so I don't - and so I never see the problem.

- USN Kennebec class AO is listed as 15,000 capacity. This was due to a bug in code where values over a certain amount were counted as negative. Bug was fixed in 1.802, so Kennebec class can be reconfigured with true (very large) capacity again.


REPLY: We have not been satisfied the "fix" works. The technical description of why the fix is certainly based on false data. When we are sure it is safe we have a number of classes to resize.




witpqs -> RE: 6.15 ERRORS (10/30/2006 12:35:49 PM)

quote:

ORIGINAL: el cid again

In 6.15 EOS

- Swordfish I is still equipped with rockets and bombs (el cid noted it should be torpedoes until a later variant).

REPLY: This is confusion: there is no later variant. RHS now is flying the Swordfish I - as stated - and it has a torpedo - in all scenarios. It has an earlier radar and rockets. If you don't pick the right mission, it will drop bombs.


No, the one in 6.15 EOS does not have a torpedo listed. It has rockets and 3 x 500lb bombs, just like it did in prior versions. If you made the change (to add back the torpedo) then maybe squadrons didn't get updated or something? When I mentioned 'variant' I was referring to an exchange of posts you had with someone one the board where there were 3 variants mentioned. It was stated that the first variant had torpedos, while later ones were introduced after the start of the game (if true I'm sure they were modifications rather than new manufacture).

quote:


- Bad news about the carrier squadron re-sizing work-around: CVL Hermes' two squadrons, each 6 a/c, both resized to 2 a/c when disbanded in Trincomalee. Previously we thought only disbanding where a theater HQ was present would result in re-sizing.

REPLY: More confusion I think. You should NEVER disband ANY carrier squadron EVER. Period. The results will generally be bad. Joe says don't - so I don't - and so I never see the problem.


So you never upgrade the AA on your carriers? You have to disband them in a port with a shipyard to upgrade. I suspect there is some misunderstanding. I'll pose the question to Joe.

HEY! Joe Wilkerson - are you reading this? [:D]


quote:


- USN Kennebec class AO is listed as 15,000 capacity. This was due to a bug in code where values over a certain amount were counted as negative. Bug was fixed in 1.802, so Kennebec class can be reconfigured with true (very large) capacity again.

REPLY: We have not been satisfied the "fix" works. The technical description of why the fix is certainly based on false data. When we are sure it is safe we have a number of classes to resize.


Okay - didn't know this.




el cid again -> RE: 6.15 ERRORS (10/31/2006 12:21:51 AM)

I see the problem: the plane is defined right - you probably can see it under aircraft data reports -
but the squadrons are not updated. Ugh. See x.17 update.




el cid again -> RE: 6.15 ERRORS (10/31/2006 12:39:05 AM)

I don't think you need to disband a squadron to get a carrier to upgrade. But lots of things go wrong if you ever send carrier planes ashore. I have a hard time getting them back on their carrier. And they tend to resize by mysterious rules - as you see.




witpqs -> RE: 6.15 ERRORS (10/31/2006 4:06:22 AM)

quote:

ORIGINAL: el cid again

I don't think you need to disband a squadron to get a carrier to upgrade. But lots of things go wrong if you ever send carrier planes ashore. I have a hard time getting them back on their carrier. And they tend to resize by mysterious rules - as you see.


Ahhh, I see the problem. I never meant 'disband squadron', I only meant 'disband TF'. And I never send carrier aircraft ashore because things get all screwed up - just ask Joe. [:D]

My bug report regarding CVL Hermes is strictly that the CVL (as part of TF) was moved to Trincommalee and TF was disbanded there. Subsequently, the squadrons (on board the CVL) underwent a re-sizing (both reduced from 6 a/c to 2 a/c), even though the closest theater command HQ is in another port (Colombo). I'm sure this is program code not the mod, I just reported it here because it shows that the procedure we thought was a useful work-around actually fails at least sometimes.




witpqs -> RE: 6.15 ERRORS (10/31/2006 4:06:40 AM)

quote:

ORIGINAL: el cid again

I see the problem: the plane is defined right - you probably can see it under aircraft data reports -
but the squadrons are not updated. Ugh. See x.17 update.


Thanks!




Don Bowen -> RE: 6.15 ERRORS (10/31/2006 4:08:20 AM)


There are several things that you-all need to be aware of concerning carrier air groups:

A carrier air group is an entity - moving it around does not break that relationship.

The carrier air groups reconfigure at various times (with some random factor involved in when). These reconfigurations change the mix of fighters, bombers, torpedo planes in the carrier air group. Note that this is the CAG and not the aircraft on the carrier. If one moves a squadron off of the carrier, it will still resize as part of the CAG (as of 1.8). If one moves other squadrons onto the carrier they will not be considered in the calculation of the CAG size and the carrier may become overloaded.

In order for reconfiguration to occur the CV must be at a well-supplied port, not badly damaged, and the CAG squadrons must have Replacements allowed.

Calculation of carrier air group squadron size is based on a percentage of home carrier capacity. Formulas vary with time of war, size and type of carrier, and nationality.

The old problem of unexpected growth of carrier airgroups temporarily based ashore was addressed in 1.8. EVEN IF NOT ON THEIR HOME CARRIER THEIR SIZE IS CALCULATED AS A PERCENTAGE OF THE HOME CARRIER'S CAPACITY. Up side of this is the ability to move the squadron back to the carrier is not impeded. Down side is that the squadron will not grow, even if permanently detached (or the carrier is sunk).

As of 1.8.0.2, carrier squadrons of HUMAN players are not re-headquartered when moved ashore.

There are several other ways this could have been done, but this is the way it is.

So:
Keep you carrier air groups intact and on their original carriers.

Only move them ashore if the carrier is lost.

You can safely disband your carriers for repairs, upgrades.

You can prevent carrier squadron resize by leaving the replacement control in "No Replacements".









witpqs -> RE: 6.15 ERRORS (10/31/2006 5:14:44 AM)

Sid,

Here is Joe Wilkerson's reply to my PM on the CVL Hermes thing:

quote:


Well sounds like the routine may be working as design (haha) even if the design isn't working for what you guys were trying to do. My data is that at least for 2-3 years before her sinking that Hermes airgroup had 12 Swordfish period. WIth a small detachment of Walrus' aboard on occasion. The game is apparently designed to support a single airgroup of swordfish .. or a hypothetical airgroup of fighter and torpedo bombers. This mixture is obviously a generic one (more related to the RN CVE).

Personally I favor removing the auto-resizing completely and giving the players some (restricted) ability to resize airgroups depending on the situation. But while there is a case for this, there are also fears that it will be abused. And given the current "uber cap" capability that everyone will opt for max fighters with no questions asked. And there is a case for this as well. So that is kind of where things stand at this point. So until we have a fix for uber cap - the resizing probably stays like it is and I would suggest giving Hermes back her single swordfish group or giving her a second group of fighters.




witpqs -> RE: 6.15 ERRORS (10/31/2006 5:17:51 AM)

Don,

Thanks much for the info. Just FYI, at no time were any parts of the carrier's airgroup ashore or disbanded. It looks like it was the fourth item on your hit-parade (below) - replacements were certainly 'ON'. The air group consists of two 6-plane squadrons of Swordfish torpedo bombers (total of 12 a/c on the carrier). They both re-size to 2 a/c each (total of 4 a/c on the carrier).


quote:

ORIGINAL: Don Bowen

So:
Keep you carrier air groups intact and on their original carriers.

Only move them ashore if the carrier is lost.

You can safely disband your carriers for repairs, upgrades.

You can prevent carrier squadron resize by leaving the replacement control in "No Replacements".





el cid again -> RE: 6.15 ERRORS (10/31/2006 8:15:40 AM)

quote:

ORIGINAL: Don Bowen


There are several things that you-all need to be aware of concerning carrier air groups:

A carrier air group is an entity - moving it around does not break that relationship.

The carrier air groups reconfigure at various times (with some random factor involved in when). These reconfigurations change the mix of fighters, bombers, torpedo planes in the carrier air group. Note that this is the CAG and not the aircraft on the carrier. If one moves a squadron off of the carrier, it will still resize as part of the CAG (as of 1.8). If one moves other squadrons onto the carrier they will not be considered in the calculation of the CAG size and the carrier may become overloaded.

In order for reconfiguration to occur the CV must be at a well-supplied port, not badly damaged, and the CAG squadrons must have Replacements allowed.

Calculation of carrier air group squadron size is based on a percentage of home carrier capacity. Formulas vary with time of war, size and type of carrier, and nationality.

The old problem of unexpected growth of carrier airgroups temporarily based ashore was addressed in 1.8. EVEN IF NOT ON THEIR HOME CARRIER THEIR SIZE IS CALCULATED AS A PERCENTAGE OF THE HOME CARRIER'S CAPACITY. Up side of this is the ability to move the squadron back to the carrier is not impeded. Down side is that the squadron will not grow, even if permanently detached (or the carrier is sunk).

As of 1.8.0.2, carrier squadrons of HUMAN players are not re-headquartered when moved ashore.

There are several other ways this could have been done, but this is the way it is.

So:
Keep you carrier air groups intact and on their original carriers.

Only move them ashore if the carrier is lost.

You can safely disband your carriers for repairs, upgrades.

You can prevent carrier squadron resize by leaving the replacement control in "No Replacements".









IF I understand this - and I am not sure I do understand it completely? = RHS is NOT compatable with 1.8 UNLESS we read the above like data lawyers and NEVER have "replacements allowed set" when a carrier might resize. Unless you know what will happen in this particular case is acceptable to you.

We CANNOT permit carrier squadron resizing because we are being historical. We do not have the regulation number of squadrons on a carrier - nor the names required for code to ID them (under the old system at least). We are putting four squadrons on most Japanese and some British CV - we would use 5 if we could - and the code simply is not geared for any number other than 3 squadrons per CV (except it did allow 4 on US CVs in some years and not in others under the old system). Did the combining of US carrier squadrons go away? While we do use 4 for US carriers - we don't change that to 3 and then back to 4 - and we don't use the names code needs to know which two squadrons to combine. [The service abbreviator USN kills the recognition of the unit]

This requires some analysis - and note I am not yet seeing this problem in 1.8 level tests.

We used to know what the resize rules were - and conditions (which is why WITPQS is writing about disbanding in a port with a command HQ). Can we know the new rules?

And - slight frustration here - what is wrong with letting us set the unit sizes correctly and leaving them alone? A recon flight need not resize as if it were a squadron, etc. It is much harder to write a general rule which is always true than to let the data entry people enter the right data - and leave it alone.




el cid again -> RE: 6.15 ERRORS (10/31/2006 8:22:04 AM)

quote:

ORIGINAL: witpqs

Sid,

Here is Joe Wilkerson's reply to my PM on the CVL Hermes thing:

quote:


Well sounds like the routine may be working as design (haha) even if the design isn't working for what you guys were trying to do. My data is that at least for 2-3 years before her sinking that Hermes airgroup had 12 Swordfish period. WIth a small detachment of Walrus' aboard on occasion. The game is apparently designed to support a single airgroup of swordfish .. or a hypothetical airgroup of fighter and torpedo bombers. This mixture is obviously a generic one (more related to the RN CVE).

Personally I favor removing the auto-resizing completely and giving the players some (restricted) ability to resize airgroups depending on the situation. But while there is a case for this, there are also fears that it will be abused. And given the current "uber cap" capability that everyone will opt for max fighters with no questions asked. And there is a case for this as well. So that is kind of where things stand at this point. So until we have a fix for uber cap - the resizing probably stays like it is and I would suggest giving Hermes back her single swordfish group or giving her a second group of fighters.




Joe has forgotten that (in the old system at least) a CVL MUST have two squadrons. We (CHS and RHS) DO give Hermes 12 Swordfish - in two "squadrons" of 6 - and we (both Andrew and I) tried to do it as one - and it does not work. Similarly, some other vessels (notably CVS types) MUST have two squadrons. In general (again in the old system) a CV MUST have 3 squadrongs - unless it is US - when it may have 4 to begin with - and 4 at the end of the war - but 3 in the middile (Go figure). Maybe all this changed - but I missed the notice. Anyway - I see no reason for a Hermes unit to resize as WITPQS reported here. What could possibly cause code - or a code writer - to want both squadrons of a CVL to resize to 2 planes each? [explitive deteted]




witpqs -> RE: 6.15 ERRORS (10/31/2006 11:06:30 AM)

Sid,

Joe understands about two squadrons on a CVL, he pointed out in another message that the code expects to size things (something like) 60% fighters 40% bombers. It seems like that might be the code pathway happening.




el cid again -> RE: 6.15 ERRORS (10/31/2006 12:40:13 PM)

Yea - but the way he explains it does not make sense. He said 6 times .4 = 2.4 round to 2. But the .4 is of group size, not squadron size. Otherwise how would 60 plus 40 = 100? His theory does not explain what happened to you.
Does not matter - it is intolerable. We need to figure out how to avoid it - or not use 1.8 at all. Too many ill effects of this stuff.




Page: <<   < prev  9 10 [11] 12 13   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.609375