RHS 7.757 Errata

[witpqs]

Errata Found in EOS 7.757

Slot 1821 - USN VF-3 on board Saratoga is missing - record has delay = "9999" instead of "0".

Slot 2311 - CNAC/PanAm Squadron at Asansal - Reports to US Western Command. Should report to India or UK SE Asia.

Slot 1579 - RCAF No. 413 Squadron at Aden - Reports to US Western Command. Should report to India or UK SE Asia.

Slot 392 (Class) - This USN AO type displays graphic for a Japanese AR.

Slot 178 (Class) - Colorado class BB's displays graphic for South Dakota class BB's.

[el cid again]

ORIGINAL: witpqs

Errata Found in EOS 7.757

Slot 1821 - USN VF-3 on board Saratoga is missing - record has delay = "9999" instead of "0".

REPLY: One wonders why? It is present in all other scenarios. And we already fixed this a few weeks ago. Is there some way to get 9999 in a field from a utility?

Slot 2311 - CNAC/PanAm Squadron at Asansal - Reports to US Western Command. Should report to India or UK SE Asia.

REPLY: Should be UK SE Asia.

Slot 1579 - RCAF No. 413 Squadron at Aden - Reports to US Western Command. Should report to India or UK SE Asia.

REPLY: Should be UK SE Asia

[el cid again]

ORIGINAL: witpqs

Slot 392 (Class) - This USN AO type displays graphic for a Japanese AR.

Hmmm

Slot 178 (Class) - Colorado class BB's displays graphic for South Dakota class BB's.

Hmmm - should be bitmap 400

[el cid again]

ORIGINAL: el cid again

ORIGINAL: witpqs

Slot 392 (Class) - This USN AO type displays graphic for a Japanese AR.

Hmmm - Theoretically impossible. Must be Japanese art in the bitma. Need to ask Cobra.

Slot 178 (Class) - Colorado class BB's displays graphic for South Dakota class BB's.

Hmmm - should be bitmap 400 - also would be for slot 177 - but maybe there is older art down around 180.
We need to ask Cobra.

Or your ship art (allied) is messed up.

Such things are handled by Cobra unless I have the pointers wrong. We will look at it.

[witpqs]

"Slot 1821 - USN VF-3 on board Saratoga is missing - record has delay = "9999" instead of "0".

REPLY: One wonders why? It is present in all other scenarios. And we already fixed this a few weeks ago. Is there some way to get 9999 in a field from a utility?"

I really don't know. I realize that this has happened several times - where an old problem that was already fixed somehow got back into the data.

Approaching it logically, there are two possibilities.

1) The editor is buggy.

2) Your own practice of version control has problems.

If # 2) were true, we should see old problems come back in bunches, because presumably you perform edits in bunches. So, I rule out #2).

I know too little about what data is contained in which scenario sub-file, so I admit I might be wrong in ruling out #2).

We are left with # 1) - the editor is buggy. It's kinda scary, but I suspect it's true.

[el cid again]

There are a number of people who think you may be right. And many have migrated over to the rather wonderful Editor X. I am unable to follow them most of the time - although I have now mastered it - and I think it is indeed far safer to use than other editors. My problem is time and the way Editor X works prevents efficient management of a large number of mods. For a person doing one mod I join the chorus saying go that way. The ony problem is when you need to edit some field not present in Editor X - but at least it DOES do pwhex - and now I use it for pwhex most of the time. It is actually easier to use. Andrew and Cobra wrote special pwhex editors - and I limped a long with WITP Excel - which does work. WITP Excel also gives you access to certain fields not present in other editors - e.g. that field that determines the unit symbol.

For other fields - I have to work at a lower level. As a machine language programmer - with files that are straitforward like ours - I can just dump the databases - find the field - modify it - and "put" it back into the original file. This is not something most modders would find easy. So if you have a specific issue:

a) Ask the Forum (works most of the time)

b) Ask Matrix (works sometimes - at least for serious modders with unresolved matters)

c) Ask me to "put a box around it" with diagnostic testing and other tricks. I don't want to solve every problem for everyone all the time - but I will support a serious modder hitting a brick wall. I find a lot fewer things stop us than I at first expect. I think we have found over a hundred ways to do things not in the original system design.

All of that said, note that I do not think it is safe to do what you are doing. You are going to have undocumented hard code in slots messing you up - and little way to address that. The only thing is - we all live with that anyway - just most of the time the hard code that says "unit xyz go to location abcd" makes sense in WITP games - only some of it is legacy code from pacwar, busted, or not used and waiting as a trap in a seemingly empty slot. You need to expect some unexpected behaviors - and maybe if identified - we can get around them (e.g. by changing slots). So plan for that - and never never ever fill all the slots.

[el cid again]

We are not there yet:

The problems above with carrier fighters and ship art pointers mean that I must release another update.

So I am investigating the carrier squadron matter.

First issue: hard code in the Matrix (and presumably other) editors limits reporting of air units on carriers to four per ship. It will make breaking the limit risky - prone to errors by modders - if we violate that.

First test: I modified our three five squadron ships to have five squadrons. USS Hornet was date set to game start.
Lex is at sea - I set her to meet up with Enterprise - and that was happy: Neither got into trouble

Sara is at San Diego. I left her there.

Hornet I formed up into a TF and sent to Hawaii

All three ships did not have any problem with the 9 plane active issue on the first day. This appears to indicate we have different code than a year ago.

This is dangerous. Aside from the editor issue I note above, you keep saying "fly off the fifth squadron." Why I wonder?
It would not be required IRL. But whatever the answer - if there is any answer at all - we cannot go this way.
Ships with five squadrons need to FUNCTION with five squadrons. OTH - I cannot confirm why you say fly them off? Time will tell.

[el cid again]

OK - after 15 days - we lost Lex and Enterprise - Sara went to San Francisco - for no good reason - and put herself in port - which is almost what I wanted - for her to stay at San Diego. No problem with the air group - but in SF it will resize when the time comes. Hornet went to Pearl - where I sent her - got in a fight - got hurt - but made it - and all five squadrons remain apparently in good shape. So two of my three five squadron carriers are in port - for days apparently - with no problem. WHY do you fly off before entering port?

[el cid again]

ORIGINAL: witpqs
Slot 392 (Class) - This USN AO type displays graphic for a Japanese AR.

Looks to me like this is bitmap 90 instead of 390: a calssical editor error (it drops a digit)

Slot 178 (Class) - Colorado class BB's displays graphic for South Dakota class BB's.

cannot explain this - but 400 works fine

[witpqs]

ORIGINAL: el cid again
WHY do you fly off before entering port?

This is why:

...but in SF it will resize when the time comes.

I know that the code will do a re-size. I presume that the re-size will be catastrophic with 5 squadrons on board. Why? Because Matrix said the code expects 4 and will often do bad things when it gets 5 instead. Like making all the squadrons 9 planes as you cited.

Now, I understand that both you and I have done tests in the past few days that showed a re-size with 5 squadrons on board worked at least 'kinda' okay. Still, I believe it prudent to proceed with the presumption that 'one of these days' (meaning 'one of these re-sizes'), the code will re-size the carrier's air group very badly. So, until Matrix says the issue is changed/resolved, I will fly off any 5th squadron before disbanding in port (or at least in a theater command HQ port).

[el cid again]

At the time we redid CVs to four squadron ships,

Mike Wood came on the Forum and explained the way resizing works in detail

He forgot some of it - but eventually interacting with those who were testing - we got it all

The resize divides a carrier into two kinds of planes: fighters and non-fighters

It also looks at the number of squadrons of both kinds

It gives a % to each category - e.g. 40% fighters and 60 % bombers or vice versa

It multiplies the % times capacity of the ship - and divides by the number of squadrons of that kind - and rounds down

It should work fine - except recon detachments and night fighter detachments will both tend to be relatively too big
and other squadrons slightly too small -

To deal with any case you don't (or won't) like I

a) say don't allow resize - it isn't hard to avoid - only happens twice - and it only happens in certain places

b) say change the squadrons - and I give you squadrons on CVEs that will 'resize' to the standard size CVs want

I am implementing five squadron ships in IJN - Unryu and Shinano at least.

I am investigating putting a night fighter squadron on some Essex class

[el cid again]

Good news: they DO resize - but acceptably. The Lex and Sara go to 2 fighter squadrons of 24 and two SBD squadrons of 16 and one TBD squadron of 13. None historically correct - but all tolerable. The deck is NOT overloaded.

[witpqs]

The only thing I will add is re-sizes can occur MORE than twice. I know there is a 'later game' re-size, but even during my 30 turn test I was able to see a re-size occur twice on the same carrier (Lexington).

The first when it had only 4 squadrons on board, the second when it had 5 squadrons on board (which sized as you just noted).

The reason I mention this is that: if someone sees a re-size happen, then a few turns later they change the composition of the squadrons on the carrier (say, add one or exchange some), another re-size will happen. So, if the player thinks they worked around the re-size and the next one won't happen for a couple of game-years, they will get a surprise.

[el cid again]

I remain convinced that resizing is a design error of second order magnitude. It forces squadrons into ahistoric sizes.
I remain convinced that players should seek to avoid it. I don't find it very hard - although I am a micromanager I admit.
Just stay out of the wrong port at the wrong time.

But I do note that resize may occure more than twice. The first one seems to occur just after 1942 begins, which is earlier than I thought Mike told us. Learn how to control your operations. No reason on Earth to use San Francisco when you have Seattle, Vancouver, Portland, Tacoma, LA, Long Beach and San Diego as options. Pearl is more difficult.
So use Lahaina - and move assets there to speed repair. It was the alternate fleet base, after all. You think that is hard, try not using Truk as the IJN! Yet the Japanese have an elegant solution: move the HQ.

Bottom line: if you let them resize, it is your choice - having been forewarned. Only AI must do this, if you play vs AI.

[witpqs]

SF is the biggest repair yard on the west coast.

You've made some of the HQ's unable to move. Also, repair shipyards do not move (PH to Lahaina). That means to stay out of PH a refit must occur on west coast.

I have the solution I need (that you provided - thanks!) - I edit the carrier squadrons before I begin and split up the double squadrons.

[witpqs]

Errata Found in EOS 7.757

Slot 1588 (Class) - SN S Class SS submarines display graphics for some merchant type ship.

Slot 1353 - USAAF 21st Transport - arrives in Townesville - reports to US Western Command. Should report to US Southwest Pacific.

Slot 1353 - USAAF 22nd Transport - arrives in Brisbane - reports to US Western Command. Should report to US Southwest Pacific.

[witpqs]

Pwhex.dat Errata

Hex 27,85 is defined as "LC". It should be "CC" because it is a coastal hex. As it is now TF's in the hex show red and '99999' fuel needed for any destination you set (regardless of how close). However, TF's do seem to move through, into, and from the hex just fine, so this is a low priority error.

[To avoid confusion note this is a similar situation to hex 34,120, which has already been fixed.]

[witpqs]

Question about C-46 Commando:

In CHS and I think (if I remember correctly) in early versions of RHS the C-46 Commando had a 50% greater payload and a slightly greater range than the C-47.

Currently, the C-46 has the same payload and a much shorter range than the C-47.

Does this sound correct or is it errata?

[el cid again]

ORIGINAL: witpqs

SF is the biggest repair yard on the west coast.

You've made some of the HQ's unable to move. Also, repair shipyards do not move (PH to Lahaina). That means to stay out of PH a refit must occur on west coast.

I have the solution I need (that you provided - thanks!) - I edit the carrier squadrons before I begin and split up the double squadrons.

HQ unable to move are unable to move for two unrelated reasons:

a) Politics, They would not move.

b) Communications infrastructures. These are very expensive and uneconomic to move.

Repair shipyards do not move because they don't move. BUT repair SHIPS do move. So do other HQ. Remember - a naval HQ is just a bunch of support squads. So move some other HQ - and they will supporty your ships. Further, you can build up the port - and that de facto builds up the repair facilities.

Finally - note that damaged ships at Pearl Harbor DID move to the US West coast for repair. One of the battleships not counted as sunk at Pearl Harbor was indeed sunk - after the war ended - patched up just enough to move - she sank en route to the West Coast. The idea a major repair job SHOULD be done on the West Coast is valid in principle. Nothing wrong with it in a strategic sense either- not much risk of attack there.

[el cid again]

ORIGINAL: witpqs

Errata Found in EOS 7.757

Slot 1588 (Class) - SN S Class SS submarines display graphics for some merchant type ship.

REPLY: ALL three Soviet Submarine classes pont at (different) merchant ship art. Sent this to Cobra. Not sure if it is our original art - or the "standardized art" rework? But I don't manage art. So we will see.

Slot 1353 - USAAF 21st Transport - arrives in Townesville - reports to US Western Command. Should report to US Southwest Pacific.


Slot 1353 - USAAF 22nd Transport - arrives in Brisbane - reports to US Western Command. Should report to US Southwest Pacific.


REPLY: I agree but this surely is the wrong slot - can't be two units in the same slot. = Nope - the first is slot 1352.