RE: RHS File Set 4.4x File Set update (Full Version)

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



Message

witpqs -> RE: RHS File Set 4.4x File Set update (9/16/2006 12:45:46 AM)

quote:

ORIGINAL: Monter_Trismegistos

witpqs:

Naval Weapons part is moved to: http://www.navweaps.com/Weapons/index_weapons.htm


Thanks - found it and looking at various entries.



witpqs -> RE: RHS File Set 4.4x File Set update (9/16/2006 12:47:24 AM)

This image shows why the bursting charge is so small in naval projectiles.

[image]http://www.navweaps.com/index_inro/no21987-German_38cm_apc.jpg[/image]



witpqs -> RE: Projectile Weights and Charges (9/16/2006 2:53:55 AM)

Sid,

I've gone through that navweaps website and gathered the data on all the Japanese naval guns that are relevant to WWII (that are listed at the site) and put it in a table. I collected ship class, gun type, projectile type, projectile weight, and bursting charge weight. The web publisher cites his sources as:

Naval Weapons of World War Two - John Campbell

Battleships: Axis and Neutral Battleships in World War II - W. H. Garzke and R. O. Dulin

Japanese Cruisers of the Pacific War - Eric Lacroix and Lintern Wells II

I have the list in a PDF file and an OpenOffice Writer file. Not sure if I will succeed in posting the data here, so I will email to you before I try posting. Let me know if this data is useful to you. If so, I will continue on and get the US and UK data.



el cid again -> RE: Projectile Weights and Charges (9/16/2006 12:43:49 PM)

If we get enough data to do all countries - that includes obscure ships like those of Russia, the old "Soerabaja" coast defense ship, etc - we might be able to come up with a more sophisticated shell/bomb model. But right now RHS is ahead of the pack - the first to do anything other than weight of shell - and we are in our second generation (differentiating AP from HE - a suggestion from a forum member). These changes - originally adopted on principle -
solved the problem of "nuclear bombardments." Probably also made land combat more difficult (less prone to domination by a BB raid). I think this is good - and so if we can go farther - we will - as time permits processing.



el cid again -> RE: RHS File Set 4.45 Status (9/16/2006 12:55:47 PM)

Cobra has ALREADY made map changes for Alor Star and Great Natuna Island.

SO I must issue an appropriate pwhex file - and a location file - to match.

The location file is done - and part of unreleased version 4.45.

This version itself is essentially completed - but a number of land units need revisions -
mainly in respect to pointers, device numbers, device locations (which much match the
formation line numbers), and device counts (which - amazingly - sometimes are grossly
inflated).

The AI vs AI validation test of an early form of 4.45 has reached the end of 1942,
and it is revealing much more historical play. All the major points have fallen except for
Palembang - which has not been engaged. But the IJA is cleaning up Banka Island - and
all the other points on Sumatra - so I think it will go there bye and bye. Java and the
rest of the main chain fell, Borneo fell, and parts of New Guinea are occupied - including
to my great surprise Port Moresby! Under AI control! For reasons unknown - the Allies failed
to build up Hollendia - as in previous tests - and the game looks a good deal like the historical
war. Me-109s were briefly important - but already are replaced in production by the Ki-44 -
as intended (but executed entirely automatically by the AI). Me-264 Marlinas have managed to
get into service - but fears they might be mass produced may be exaggerated:
they produce slowly - and require unique engines - which for some reason also produce slowly
(a fact I find quite acceptable). [I think WHERE you produce things matters. For example,
the engine plant at Toyohara may NEVER produce anything. Or it may - under conditions that
have not yet obtained. There are several other plants like that. And Gumma and Tokyo have
too many things going on - so production is very limited at any one facility.] But the very first
squadron to get these planes promptly automatically deployed to Rabaul - so the way the AI uses
them makes sense.

I will attempt to correct all the land unit issues tomorrow. I will issue 4.45 wether or not this process
is completed. It is suitable for the sort of testing we need to see if we like the new ground combat situation
and to begin measuring long term economic issues. Tweeking Allied land units is a process that probably
never will end.

The only unknown is when will Mifune finish the data for the planes? We have now agreed on an algorithm - one working better than I dreamed possible in all respects - and it is only a question of getting 249 sets of calculations.
When that happens we will go directly to 5.0. Lacking contrarian comments, we will also fold into that a change
in ranges - focused on operational rather than ferry range.



el cid again -> RE: RHS File Set 4.45 Status (9/17/2006 12:18:20 AM)

PWHex for 4.45 is now done and uploaded.

The map art was also sent to the upload list.

4.45 will upload in about an hour.



el cid again -> RE: RHS File Set 4.45 Uploaded (9/17/2006 6:45:45 AM)

4.45 files uploaded - in two batches of 3.

4.45 pwhex and 4.45 map art revision for panel 5 alsu uploaded an hour before that.

All should appear on the RHS site in due course.

Plane data for 5.00 being calculated.



witpqs -> RE: RHS File Set 4.45 Uploaded (9/17/2006 9:28:57 AM)

Sid,

In the DEI there are still a whole bunch of non-coastal hexes that pose a problem according to what Mike Wood posted last week. The list below is what I posted on another thread and it seems to still be valid. It should help you zero in on the trouble areas without having to go through hex by hex.


quote:


Based on the note that Mike Wood put out about coastal hexes and your pwhex release with modifications in the PI, I looked over the DEI. I have come up with some hexes that probably exhibit the kind of problem that Mike described. Warning: I am not a pwhex expert, although I think I have interpreted things correctly, you should look at them yourself to be sure. I conducted the examination using the '1' key while inside the game (I have not edited the pwhex.dat file).

Andrew: These hexes might be the same in CHS - I have not looked.

These hexes have code Ls (Land Swamp?), but probably should have code Cs (Coast Swamp?):
25,57
25,58
21,52
21,53
21,54
28,32
28,33 (these last two hexes are near Rangoon)


These hexes have code Lw, but probably should have code Cw:
34,59
29,64


These hexes have code Ow. Based on adjacent hexes, they should have a different code but I do not know what they should be:
21,49
21,48
26,63


The following two hexes are adjacent to each other. One of them should be a coastal hex:
24,59 (Ow) and 25,59 (Lw)


The following two hexes are adjacent to each other. One of them should be a coastal hex:
24,60 (Ow) and 25,60 (Lw)



el cid again -> RE: RHS File Set 4.45 Uploaded (9/17/2006 12:02:51 PM)

I did check all the coastal hexes of Malaya and Sumatra - and previously Japan and Philippines.
These I will now look at. If ANY are wrong I will issue a new pwhex file. PWhex can upgrade DURING
a game. I hope to start 6 plus human games - and I expect others to start some as well - so it will be nice
to have routing functions work as well as they can. Back in a few.



m10bob -> RE: RHS File Set 4.45 Uploaded (9/17/2006 9:47:10 PM)

Sure would be nice if Sid were brought in to be on the "planning stages" (professionally) for an upgrade of Age of Sails, (if ever released as a further upgrade to include Civil War ironclads and riverines.......................................)



witpqs -> RE: RHS File Set 4.45 Uploaded (9/18/2006 12:50:33 AM)

quote:

ORIGINAL: el cid again
If ANY are wrong ...


Thanks. When I say I reviewed them according to Mike Woods' post, I mean that they are places where Land and Sea hexes have no Coast hexes between them, as he said is required. I cannot swear that I found all such examples, of course.



el cid again -> RE: RHS File Set 4.45 Uploaded (9/18/2006 2:32:29 AM)

I agree with you: if there needs to be coast between land and sea - than any adjacent land and sea hexes are bad programming- pwhex wise. \



el cid again -> RE: RHS pwhex level 4.46 issued (9/18/2006 11:47:16 AM)

The promised review of coastal hexes - per Mike Wood's post - is done for the hexes spotted by WITPQS -
and to that I also inspected the Solomans and Sakhalin Island. Changes were made in the Strait of Malacca,
near Borneo, and in the Solomans - no errors were found in the far North - and also off the coast of Australia
and New Guinea.

A pwhex update is never a problem - you can change it in the middle of a game - and we might do that if we ever get a serious team campaign going (to represent things like construction or demolition - assuming we figure out how to DO it ).



el cid again -> RE: RHS pwhex level 4.46 issued (9/18/2006 2:34:37 PM)

Changes which will appear in 4.46/5.00 include:

Revision of the production rate of CPS-1 radar downward to 1 - appearing 7/44.

Revision of US Artillery units to include machine guns. Also correcting some pointers.

Revision of EOS economic settings for Japan - now I understand better what AI does with
them. Also, some aircraft production was missing (mainly light bombers and Pete),
while some plant capacity was overstated. About 180 plane production slots were removed
and others reclassified by type. This will actually benefit Japan in two ways: some early
production of types they otherwise run out of but need and faster ramping up when those
extra slots are not in the pools.

I am going to turn out a standard opening move for test purposes - and this will cause me to review many
things - so any eratta I find I will fold in. I know the data well enough to spot errors that might not be
obvious to everyone.

Still no major problems in AI vs AI validation testing.




el cid again -> RE: RHS pwhex level 4.461 issued with art (9/19/2006 11:25:53 PM)

PWhex 4.461 differs from 4.46 only in regard to a single hex - the Nanao pinnensula of Honshu.

Art changing the east coast RR of Honshu to secondary line - and the Nanao RR to trail -
is now released to work with this pwhex level.



el cid again -> RE: RHS 4.46 files, pwhex 4.461, art (9/20/2006 12:53:46 AM)

Scenario files with all refinements and corrections since 4.45 uploaded.

Until the update to aircraft data is done, I do not intend to issue any more updates. I intend to do human
testing. I am now doing a test turn for volunteers.

Our aircraft data guy is sick - and there is a delay in getting all the numbers.



el cid again -> RE: RHS 4.4x update - there will be a 4.47 (9/20/2006 7:41:11 PM)

I have found one missed supply sink (that doesn't matter too much unless ROC is winning the war)

and one mis entered supply sink (that does matter a bit more - on sumatra - a coal mine hex).

I have found Japanese regiments grossly overstrength - and reduced them.

I found "Yobo Eiki" should be "Yobieki" - and it should replace the term "reserve" in many unit names.

I have found a way to reduce names by up to 8 characters - so many of the subset of reports too long for
the box won't be too long to read any more.

I was told about a small number of Australian units with incorrect names.

Because the supply sink issues are of some import for longer term play, I will release a 4.47 version today -
and then proceed to do the test games based on it.

I also am running a 4.46 version out to 1945 - to insure the economy will work all the way.
This is AI vs AI - with quarterly inspections. It will take a couple more days to complete.



witpqs -> RE: RHS 4.4x update - there will be a 4.47 (9/20/2006 9:19:19 PM)

I'm curious - a short time ago you mentioned that Palembang still will not be attacked by the Japanese AI. Have you found a way to correct that bugger?



witpqs -> RE: RHS 4.4x update - there will be a 4.47 (9/20/2006 11:52:21 PM)

Sid,

In EOS 4.46 (and prior versions) there is a problem with the Soviet L class subs (slot 1585) - the ones with the mine racks. Whenever you reload them, they get messed up. Here's what I mean. There are 2 mine racks, with 14 ammo (which means 7 ammo each rack). Upon reloading (after laying the initial mine loadout), the ship display changes to now say there are 7 mine racks, with a total ammo of 2, and the '2' is displayed in red.

I looked at the database and tried to correct the problem so I could pass that on to you. First, I noted that Turrets (Mounts on the in-game ship display) is set to 0. Other mine-laying subs have 1, so I changed that to 1 and updated the ships. No change.

Second, I noted that the weapon is set to facing R, while other mine-laying subs have their mines as facing C. So, I changed the facing to C (leaving Mounts as 1). Still no good (same results as initially described).

At this point, I don't know what else to try changing, because everything else looks fine. I also looked at the device record and compared it to other mines - it looks okay as far as I can see.



el cid again -> RE: RHS 4.4x update - there will be a 4.47 (9/21/2006 1:32:46 AM)


quote:

ORIGINAL: witpqs

I'm curious - a short time ago you mentioned that Palembang still will not be attacked by the Japanese AI. Have you found a way to correct that bugger?



I may have been incorrect. We will see. It appears that AI does go for Palembang - but not in historical order - because I stole its slot for Baguio city for technical reasons (it is malaria free). AI seems to take all of Sumatra and reduce Banka - then it goes for Palembang - because it is enemy, present and also probably because it is a major base.



el cid again -> RE: RHS 4.4x update - there will be a 4.47 (9/21/2006 1:34:00 AM)


quote:

ORIGINAL: witpqs

Sid,

In EOS 4.46 (and prior versions) there is a problem with the Soviet L class subs (slot 1585) - the ones with the mine racks. Whenever you reload them, they get messed up. Here's what I mean. There are 2 mine racks, with 14 ammo (which means 7 ammo each rack). Upon reloading (after laying the initial mine loadout), the ship display changes to now say there are 7 mine racks, with a total ammo of 2, and the '2' is displayed in red.

I looked at the database and tried to correct the problem so I could pass that on to you. First, I noted that Turrets (Mounts on the in-game ship display) is set to 0. Other mine-laying subs have 1, so I changed that to 1 and updated the ships. No change.

Second, I noted that the weapon is set to facing R, while other mine-laying subs have their mines as facing C. So, I changed the facing to C (leaving Mounts as 1). Still no good (same results as initially described).

At this point, I don't know what else to try changing, because everything else looks fine. I also looked at the device record and compared it to other mines - it looks okay as far as I can see.


Will look at it in 9 hours.



el cid again -> RE: RHS 4.4x update - there will be a 4.47 (9/21/2006 1:35:05 AM)

I have found a way to further reduce manpower counts and possibly difficulty in taking static points.
This will delay 4.47 release by about 12 hours (I have to go to work).

Have figured out some more things - and asked some questions. Maybe we can make static units without static devices - even static big guns? And reduce reported manpower in the position - wether or not it matters. Maybe. Working on it.



el cid again -> RE: RHS 4.4x update - Reducing manpower counts (9/21/2006 11:39:18 AM)

I have asked if manpower matters in combat? And the answer is clear: no.

However, it looks wrong to have too much manpower. And ALL units with
static devices of any kind - including CD guns and naval guns ashore - get 9999 men
per device! Further - it appears there is NO need to assign devices static values at all.
We can make a unit static by calling it a "fortification."

To this end I will remove all static facility squads EXCEPT those in the guerilla regiments -
where their flaky nature is just what we want anyway. And I will redefine static devices
with real weight (or manpower) - no 9999 guns any more. Any unit that must be
static all the time will be called a fortification. If reasonable, the unit will have a pair of
6 inch guns - or more - and a value in the "fort" field = number of fixed batteries (or quality of
the fort). If not reasonable, the unit will be called an "industrial fortification" and have zero
in the "fort" field.

All this will be comprehensively folded into 4.47 - which releases in a matter of hours - whenever it is
done.

The effects of this should be two fold: slightly reduce the strength of some points (every squad counts,
and a static device IS a squad in all cases) - and reduce the reported manpower of all units presently
having static devices.



Nemo121 -> RE: RHS 4.4x update - Reducing manpower counts (9/21/2006 4:50:02 PM)

Would it be possible to create a PBEM ONLY version of EOS which features supply sinks which CAN be moved to out of the way areas if the city is threatened? While the manpower doesn't matter the presence of 18,000 support squads in a city hex in India sure as hell will. I think that the supply sinks are a great idea but their current implementation could be changed in PBEMs with benefit IMO.



Nemo121 -> RE: RHS 4.4x update - Reducing manpower counts (9/21/2006 9:25:37 PM)

Hmm I've downloaded V4.46 of everything and checked it out... I still see tens of thousands of support squads in cities.

E.g. Vladivostok features 18,000 support squads ( vs a need of about 700 ). In any ground combat after the fire phase is resolved these support squads will add 1/10th of their number ( not firepower) to the defending forces. End result this support squads add 1,800 AV to the defender or to put it another way they add the equivalent of about 5 divisions to the defence.

I know I keep banging on at this but as I see it it just rules entire areas "off limits" to assault ( and some of these areas are in the DEI which is extremely problematic). Fine if you want to do that but I think that isn't the intention.

In one or two places on the map I've found allied bases where resources appear at a given rate... Could this not be made widespread instead of supply sinks?

E.g. If a place produced 500 resources per day but no supply would it not be possible to just create an RHS variant in which supply sinks were removed and so were on-map resources in that base. Instead the same sort of thing as happens at Kodiak and Noumea could be done with these resources and./or supply would just appear at the base.

The only drawback would be that one couldn't bomb those resources and supply but I think that's a small price to pay.


IF you didn't want to do that then would you consider hosting a mod if someone else made it?



witpqs -> RE: RHS 4.4x update - Reducing manpower counts (9/21/2006 10:16:29 PM)

quote:

ORIGINAL: Nemo121

support squads will add 1/10th of their number ( not firepower) to the defending forces.



Sid,

Is this (the large number of support squads) what you are changing in relation to manpower (that you mention above)?



Nemo121 -> RE: RHS 4.4x update - Reducing manpower counts (9/21/2006 11:32:17 PM)

witpqs,

My understanding is that the change EL Cid is talking about is reducing manpower by removing Static Facilities, not support squads.


El Cid,
Possible database errors:
1. 094- Torpedo Transport. Is a 10 knot ship really meant to have a manoeuvre of 92?

2. 121 & 122. They have torpedo tubes in the rear... Surely it would make more sense to make these torpedo tubes be in the Front?

3. 169 should be a CL not an AP... Probably accounts for why they have done so poorly in surface combat in my game...



el cid again -> RE: RHS 4.4x update - Reducing manpower counts (9/22/2006 1:42:27 AM)


quote:

ORIGINAL: Nemo121

Would it be possible to create a PBEM ONLY version of EOS which features supply sinks which CAN be moved to out of the way areas if the city is threatened? While the manpower doesn't matter the presence of 18,000 support squads in a city hex in India sure as hell will. I think that the supply sinks are a great idea but their current implementation could be changed in PBEMs with benefit IMO.



Boy am I confused. Who would move them? And also, they are static so they will not move - so supply is consumed at the point of creation - so it does not go somewhere else - which it will if it can. Under AI control I see no way at all to get AI to move such things intelligently - but I can testify from tests the AI WILL move them ALL the time - unintelligently. I am not grasping your concept.

Anyway - there are pros and cons to everything. I have divided big supply sinks by 10 squad count wise - de facto - by converting them to support squads. And Asonol got divided by 3 again on top of that. It SHOULD be hard to walk in and take over - and I think we need to test now to see if we like it. Also - I doubt Japan can GET to Asonol -
AI sure doesen't - and the logistics are going to be stretched to do it. Lets see what happens.

I have come up with what may be a better system - but it is going to take another day to enter all the location changes. No pure supply sinks will ever move now. And no static squads will add to manpower counts to make things seem worse than they are (manpower is pure chrome and has zero meaning in combat terms). But the static squads count at full value - so converting them to support will divide their real combat value by 10 as well.



el cid again -> RE: RHS 4.4x update - Reducing manpower counts (9/22/2006 1:46:20 AM)


quote:

ORIGINAL: Nemo121

witpqs,

My understanding is that the change EL Cid is talking about is reducing manpower by removing Static Facilities, not support squads.


El Cid,
Possible database errors:
1. 094- Torpedo Transport. Is a 10 knot ship really meant to have a manoeuvre of 92?

Don't think we use them - this is probably its CHS value - where they get used.

2. 121 & 122. They have torpedo tubes in the rear... Surely it would make more sense to make these torpedo tubes be in the Front?

Correct

3. 169 should be a CL not an AP... Probably accounts for why they have done so poorly in surface combat in my game...


Correct in the RHS system - AMCs are CLs for code reasons.




el cid again -> RE: RHS 4.4x update - Reducing manpower counts (9/22/2006 1:48:04 AM)


quote:

ORIGINAL: witpqs

quote:

ORIGINAL: Nemo121

support squads will add 1/10th of their number ( not firepower) to the defending forces.



Sid,

Is this (the large number of support squads) what you are changing in relation to manpower (that you mention above)?


Manpower is a strange fictional beaste - code gets it from the weight of a device! So a static device with 9999 weight = 9999 men - apparently. We are changing ALL static devices to a real weight (or crew size) value. And not using the one static device that cannot change - the static facility squad - most of the time.



Page: <<   < prev  1 2 [3] 4 5   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
1.4375