Matrix Games Forums

I am trying to build a small "how to" manual on behalf of guys like me, who are not able to benefit from current
DaBabes improvements because they are dedicated to a grand campaign they do not want to terminate and have a slow
turnaround rate, but at the same time want to implement the fix for the Japanese E class.


If I understood John correctly it goes like this - please bear with me I usually do not play around with the Editor and just launched it for
the 2nd time in my whole life, but since I am an IT guy I probably get this pretty fast...


- I use the standard editor? Not the 64-bit editor? Does it make a difference? (OS: W7 64, might be different on my PBEM partners)


Prerequisites for a flawless transition to non-super E are:

- The modification needs to be done on the scenario we are playing, so in our case scen#1

- Under optimal circumstances the ship classes should not yet be available, so the modification can be implemented before the first ships arrive to avoid data issues on on-map units
(as experienced with the torp tube split patch).

- All parties involved have to do exactly the same modification (so in our example myself, my Ally Rob Brennan, and our honoured opponent Mike "Offenseman" Toth),
and the modification obviousely has to be done within the same turn.

- I assume I have to not only modify the base version, but also all future upgrades (e.g. for Ukuru I need to modify the 1312 and 1313 dataset, for Type-C 1317 and 1318,...)

Is the above correct?



Could you DB wizards please tell me again the exact values required to be modified, and to which values?

Are the fields requiring modification below complete and correct?




Also, if you could spare the time, a step by step instruction would be helpful how to conclude the update process after the values have been modified.

And last, any information of potential impact on an ongoing PBEM (data or error/warning message popup on load) would be great.



Thank you very much in advance!

LoBaron,

Unfortunately....and I may very well be mistaken...once a game is started some of the scenario data is baked into the game and cannot be changed.

You can certainly change and save the data in the scenario file with the new information. HOWEVER for a good portion of that data, the data is captured by the game AT START and is kept in the SAVE GAME....which is why the SAVE GAME files are so large.

Now whether the number of devices on a class is one of the data elements captured... especially for classes that have yet to enter the game...I have no idea. I do know that Mundy and I tried to use an edited Location file with no success. Not saying that you should not try...just warning that the update may not be successful.

I have no WITP here, but I think, what you have in red square is number of ammo. The number of weapons is the first field after name.

Also, it is impossible to save onto original Scenarios. Maybe it could be possible, if you save modification into other slot, and then manually copy those files onto Scenario 1, but game can check checksum, and it will probably scream FILE MODIFIED!

ORIGINAL: LoBaron
I am trying to build a small "how to" manual on behalf of guys like me, who are not able to benefit from current
DaBabes improvements because they are dedicated to a grand campaign they do not want to terminate and have a slow
turnaround rate, but at the same time want to implement the fix for the Japanese E class.

Oh, a large rat poop in a small jar !!! I did it again and forgot something !!! Shijt und Ondergang !!! Woof !!!

There's two parts for the answer to your question. The gnarly part of the answer, first. I totally forgot that the commercial editor can't edit scenarios 1 - 25, unless saved in a slot > 25. Have been editing and updating stuff for Babes (which are all scen >25) for a couple years, that I just got used to that system. Also, the developers have a special editor that 'can' edit scenarios 1 - 25, so never really confronted that problem. Act of contrition happening now.

But, since I 'can' do database edits on stock scenarios, I certainly will do so. Know how to go about it. Checked it this morning, and it works. Only thing is, I will have to do the edits on any scen01 - scen25 and send ya'll the "new" scenario. This is perhaps a good solution, because both players will get exactly the same files (and changelogs). Once you both get them, it's time for part - 2.

1. Only data changes, in certain database files, are "directly" updable with no issues whatsoever. Primarily the Device file, because its internal data content does not have a ripple effect through any other files. It is consulted "directly" and not in conjunction with anything else.

2. Certain other database files, like Classes, update well, but the change propagation through the rest of the database files can become problematic. If a Class weapon change is correctly updated in the Ship file, throuth the "Set Ship - Update from Class" procedure, it will update correctly in the Ship file; BUT there will be many Ships in TFs, which are defined in the Locations file and thus will not pick up the change. This was the problem with the sub-tube update: ships disbanded and sitting in harbor (i.e., on the Ship file end of the propagation string) were ok, but ships in TFs (on the Location file end of the propagation stream) bit the Great Wazoo.

3. That is why it makes all the difference in the world as to when you make the database change with respect to your game time, and the ship introduction time. If your game time is before the Ship intro time, all will be well. If not, you will have to do that silly upgrade dance that happened with sub-tubes.

So, once you get an "updated" scenario, and get back to loading your game, you will see a screen like this.



The engine consults the original scenario even when loading savegames, so this is a good thing. If you and your opponent are comfy with the source of the database changes, just click on yes and you are good to go, subject to the little pieces of nastiness in 2. and 3. above.

Can help you out with this. It's a bit obscure, but hopefully intelligable. Further info and tweaks to your scenario, cheerfully provided.

I have an unofficial update for scen 2 to fix this and another of other issues in the works

Non Upgrading Jap radar etc

PZB and I are testing aspects of it now as a test bed

(John in order to update I think the scen needs to be stamped certainly thats what I found when checking it earlier)

Below is the current change log for the changes I am testing

Scen 2 AMC Amended

Fixed Japanese Radar upgrade
780 Type 2 Tank SA set to 14
1467 Japanese Army SD set to upgrade to 1468 Ta-Chi 13 Radar
1685 reduced load cost to 1.5x to allow AD reloading of Jap torpedoes
1686 reduced load cost to 1.5x to allow AD reloading of Jap torpedoes
1698 Type 95 DC : change Range (depth) from 164 to 175
1699 Type 95 Mod-2 : change Range from 295 to 275
1700 Type 2 DC : change Range from 476 to 375
1759 3in A/S Mortar : change Range from 1000 to 150; change Accuracy from 30 to 3; change Load Cost from 16 to 70
Added more LI to Sendai
All Mine Production Doubled
Add 5000 fuel to Chichi Jima
Added small Ohka Factory to Osaka
Reduced additional pilots to limit impact of HI tax




Fleet Air Air Arm Aircraft set to CW Nationality
All nationities set to minimum 1 piot replacement in every year
996 12”CD gun changed from DP gun back to Naval Gun
1044 Dutch KNIL upgrade loop corrected
1066 3.7” Gun set to DP changed to AA
All Mine Production Doubled
Dutch 8cm Sub Deck Gun changed to DP
UK Box supply generation reduced to 100/100
Ramree Island set to Monsoon Affected and supply cap added

Lots of those are in Babes already, lots of others aren't. Understand about the stamp; I can do it, but, that's where I forgot about the regular folks. But can fix things for regular folks.

Hey, thanks for dialing in Andy. Always look forward to your evil, blue painted, sweaty, pieces of nastiness.

Ciao. John

A small thing in Scenario 2 is the Japanese Infantry Squads. Besides there are not much difference in Anti-Soft and Anti-Armor values (why is beyond my limited knowledge) from the at start to the '43 version, the labeling needs to be changed so I know which units have the '43 version. See Device 710 which upgrades from 709 on 1/43.

ORIGINAL: LoBaron

I am trying to build a small "how to" manual on behalf of guys like me, who are not able to benefit from current
DaBabes improvements because they are dedicated to a grand campaign they do not want to terminate and have a slow
turnaround rate, but at the same time want to implement the fix for the Japanese E class.


If I understood John correctly it goes like this - please bear with me I usually do not play around with the Editor and just launched it for
the 2nd time in my whole life, but since I am an IT guy I probably get this pretty fast...


- I use the standard editor? Not the 64-bit editor? Does it make a difference? (OS: W7 64, might be different on my PBEM partners)


Prerequisites for a flawless transition to non-super E are:

- The modification needs to be done on the scenario we are playing, so in our case scen#1

- Under optimal circumstances the ship classes should not yet be available, so the modification can be implemented before the first ships arrive to avoid data issues on on-map units
(as experienced with the torp tube split patch).

- All parties involved have to do exactly the same modification (so in our example myself, my Ally Rob Brennan, and our honoured opponent Mike "Offenseman" Toth),
and the modification obviousely has to be done within the same turn.

- I assume I have to not only modify the base version, but also all future upgrades (e.g. for Ukuru I need to modify the 1312 and 1313 dataset, for Type-C 1317 and 1318,...)

Is the above correct?



Could you DB wizards please tell me again the exact values required to be modified, and to which values?

Are the fields requiring modification below complete and correct?




Also, if you could spare the time, a step by step instruction would be helpful how to conclude the update process after the values have been modified.

And last, any information of potential impact on an ongoing PBEM (data or error/warning message popup on load) would be great.



Thank you very much in advance!

For ships, device changes are instantaneous at the moment the question "add database changes to this user designed scenario" is answered -
not everything works like that. So if you modify a device ALREADY on the ship, it will be immediately modified. You also could change things
like speed with immediate impact. But if you change which devices are on the ship on a ship already in play, apparently they will not change
for a game in progress - or not immediately.

The problem of ASW escorts being too effective is not limited to Japanese ones. And it is structural IMHO - an opinion not shared by some others.
The model used - weapons on bearing EACH get a "die roll" - is completely unrelated to how submarines under water are engaged. [If surfaced,
it is fine for guns.] Submarines have unknown locations - even when detected. That location cannot be hit at supersonic velocity with shells
(except maybe if depth is almost nil - for which Japan DID have AS shells!) And sinking weapons take time during which the sub can and should
move in an unpredictable way. So ASW is really done with "patterns" around an aim point (called a "datum") - and the entire pattern expends
ammo generally from all the throwers, rails, etc. [A DC track might drop several times in one pattern - for a modest one - say once to start,
once in the middle, and once at the end; while moving from end of the pattern to the other throwers will throw to both sides as well - in this case -
probably two each way - for a pattern of 7. For this reason I have modeled ASW on "patterns" for DC - and the "direction" of the pattern is
"all sides" - but every shot expends the entire pattern. But a "hit" - if it happens - is only by one DC (or possibly halfway between two of them,
same same effect wise). An early escort ship typically only carries 3 patterns; a good one virtually never more than a dozen or so. This really
impacts escort effectiveness, particularly on a long voyage. The message "vessel name is out of ASW ammo" is now common in my mod. As it
should be after several tries. Ahead Throwing Weapons are different - in size and in area - and also can engage before the DC can - so they should get a separate attack. But it is still an area thing - note they are circular (or elyptical) around the datum point, or in the case of squid, triangular - with NONE aimed actually AT the datum point!

The other side of the coin is that submarines are too easily sunk (except by mines perhaps). One might toughen up the subs. I give them "armor" in the form of 1/3 of pressure hull thickness in mm. Subs can and usually do survive even "hits" by DC - cases exist where numbers like 640 DC were counted by the sub but it returned to report! What usually matters is cumulative damage. So anything you can think of that increases a submarine's ability to survive will be realistic.

Thank you for your responses, gentlemen!
It is disappointing that the "do it yourself" option is off the table, another reason for starting every new game with a version
of DaBabes.

John, special thanks for offering to edit the game, I hope I have not opened a Pandora´s Box with everybody
spamming you now. I will talk this over with my ally and opponent. If they agree, a modding of our DB would be highly
apprechiated.

I do hope though that it is a bit more clear why some people are stuck with the original scenarios. It is in many cases
not reluctance to play a mod (because it is not original and unsauber! Oh mein Gott! [;)]), rather it is a long time dedication
to a game with and against friends, with too much time and thought invested to call it off just because of some small
data or code troubles.
Personally I am very aware of the advantages DaBabes scenarios hold. But I don´t have to think twice whether this is enough reason
to terminate our game - it is not. I´d rather create special Anti-Super-E hunting groups all over the Pacific and use my subs for
Radio/EM signal spying only.


el cid, thanks for going into details. I understand the mathematical differences in hit probability in real life, where it probably looks
similar to a moving 3D bell curve, to in-game where it is "flatter". I also followed the debate on this with interest.

IMHO, the discussion on that topic is situated in an area where you can either adress results from an algorithm POV, or from a statistical+DB
POV. Both more or less work, since there is a high ammount of abstraction required for the calculations anyway (location, bearing, heading,
relative horizontal speeds, relative vertical speeds,...). And from what I have read, please correct me if I am wrong, it seems very much
like a tradeoff between accessability vs. complexity where the cost/benefit relation might be just a tad over the top.
Iain once said with regards to the air combat model: 'there is no air in the game'. Same applies to water.
This just widens the options how to adress ingame behaviour me thinks.

I simply miss the technical background with regards to DC patterns - and naval stuff in general - to form a strong opinion on either
solution, so I better leave that up to you guys. [8D]

ORIGINAL: Andy Mac
1759 3in A/S Mortar : change Range from 1000 to 150; change Accuracy from 30 to 3; change Load Cost from 16 to 70

Just read your update log with interest, and, wow, is this really as radical as it looks? Was this super-Mor before? [:D]

ORIGINAL: LoBaron
Was this super-Mor before? [:D]

Okey dokey LoBaron. Understand. If you do wish to fix up the E's at some time in the future, just give a shout. Should do it no later than Jan '44 game time, though.

Oh, yes, the Super-Mor !! A comedy of errors in the original data definition. It is an ordinary infantry mortar, shouldn't even be listed as an ASW weapon, but since the silly bugger is part of the weapons loadout for so many ships it wasn't worth the hassle to get rid of it. So just nerfed it. Definitely was not a DC with a 1000 foot setting [:D][:D]

It was indeed an infantry mortar - although details in references seem confused. Generally listed as a
"three inch ASW mortar" it was, in fact, a "heavy" 81mm (IJA also had a lighter weight 81mm firing the
same ammunition, easier for infantry to carry - IJN got the older, heavier stuff - and didn't care about
the weight - and it did have slightly better range]. IJN loved ASW shells, and might have had special bombs
for ASW work, but very likely simply used regular ones. This isn't as poor an idea as it might seem:
mortars deliver rounds much faster than sailing to the drop point - then waiting for the DC to sink - all that
time the sub is moving. IF you had (or a plane had) sighted the sub, and knew where it was, dropping
bombs all around that point - in particular along the course the sub was on - isn't a bad idea. An 81 mm
shell would not be fun for a pressure hull. On the other hand, it was virtually a point weapon - no hit = no
detonation = no damage. Sort of like firing Hedgehog (or Mousetrap - same same) bombs one at a time -
but pretty fast. It was not effective as an ASW weapon, or was not effective very often (submarines that
don't come back don't tell us what hit them?). But it was a statistical threat, as indeed DC also are. It should
not be rated very highly however. [FYI an AS shell was generally contact fused - not depth fused like a
DC or ASW bomb was. The "AS" part was merely to make it more predictable in trajectory in the water
and less likely to glance off instead of detonate, that is, a special nose shape. AE does not model AS
shells from guns per se - but it kind of is represented when the sub is on the surface - AS shells are only
used just after it submerges - so surface shells represent them just fine. Not a USN concept as far as I know,
it was popular in IJN.]