[REL] Automated Campaign Editor v0.3

[mcoca]

Yanaran, that should work fine, although you will find your subchaser groups a bit boring

I would consider adding a few minesweepers into the mix, but changing them to patrol craft in the roster (edit roster\japan\sea\msno13.cfg to set type=0), so they get escort AI. I have done that and so far it's working out well enough.

Otherwise, from my tests, I think task forces should get a drastic reduction. I set them down to 40% of stock, and still managed to find two of them in one patrol.

[mcoca]

BTW, for those who have downloaded and tested the program. Are there any specific features you would like to see in a future version?

[akdavis]

Originally Posted by U-Bones

It would be nice to have both brown and blue water hunter/killer groups

Blue: DD/Subchaser/Minesweeper
Brown: Subchaser/Minesweeper/Gunboats

or similar.

Brown groups would also be common near smaller ports.

I believe the devs confused these gunboats with accounts of US sub encountering "converted gunboats." While I can't find an view of a specific wartime Japanese example, here is a US converted gunboat from between the world wars:



Her upper decks had been removed to increase open water stability. A variety of different ships were converted to gunboat status during the war. Steamships were common.

The gunboats in the game should probably be excised entirely. Both the Atami and the Hira were not part of the Combined Fleet, but rather assigned to the Japanese naval forces in China, as can be seen in this document:

http://www.ibiblio.org/pha/pha/misc/45-41.html

They and their sisters (Atami class: Atami, Futami; Seta class: Seta, Katata, Hira, Hozu) were Yangtze River patrol boats. To show where they where later in the war, references indicate that the Atami was damaged by Chinese aircraft near Tung Ting Lake in China on June 10, 1943, while the Hira was damaged in an air attack at Kiukiang, China.

At the most, they might appear occasionally in Shanghai harbor.

Here are some examples of converted gunboats sunk by US submarines:

SHOSEI MARU

Japanese Navy; 1929; Amagasaki Zosensho; 998 tons; 210 x
30-5x18-7; triple-expansion engines.
The steamship Shosei Maru was taken over by the Japanese Navy

for use as an auxiliary gunboat. On May 20th, 1944, she was torpedoed
and sunk by a U.S. submarine [U.S.S. Silversides] about 50 miles S.W. of
Guam.

NIKKAI MARU
Nissan Kisen K.K.; 1938; Uraga Dock Co.; 2,562 tons; 297-9 x
45x23-8; 201 n.h.p.; compound engines & L.P. turbine. The

steamship Nikkai Maru was taken over by the Japanese Navy and

converted into an auxiliary gunboat. On November 26th, 1943, she

was torpedoed and sunk by the U.S. submarine Ray 350 miles N. of

the Admiralty Islands.

KEIKO MARU
Osaka Shosen K.K.; 1938; Uraga Dock Co.; 2,929 tons;
297 -9x45x23-8; 255 n.h.p.; compound engines & L.P. turbine.
The steamship Keiko Maru was taken over by the Japanese Navy
and converted into an auxiliary gunboat. On November 8th, 1942,
she was torpedoed and sunk by the U.S. submarine Seawolf off
Mindanao Island, Philippines.

[Redwine]

Many thanks !

[mcoca]

I'm currently working on the next version. Features will include:

• Separate entries for input and output folders, so you can run the same changes repeatedly, adjusting them, without having to restore your backups.
• A config file where you can put code and definitions for use in your changes. I intend to start this file with some useful functions.
• Improvements to the Waypoint API. I think with some small changes it would be possible, for example, to make all convoys zig-zag according to a set plan without having to change each one separately. Right now this is difficult because there is no simple way to insert new WPs.

Anyone has a specific request?

[FinnN]

I've not taken a look at this as I'm a .NET user but I think it's a great thing that you're doing here.

Can I make a suggestion in terms of something that would be good, and leave to it you to see if it could be accommodated by your library (assuming it isn't already)?

Basically in a campaign (mission even if you're 'lucky') you can sink the same battleship/cruiser multiple times - fine for destroyers but not so good for
the Yamato. How about a function to search and replace generic ship entries in the campaign file with specific ones? So, someone could then write a little utility that when you run it fills the random battleship entry with a specific one from a database, then it'd fairly easy to only have two Yamato class BBs in the game world. Then when the Yamatos run out, the rest can be filled with a different BB, when they run out it might then be missing altogether from the battlegroup or replaced by a cruiser. If cruisers have all been allocated then a destroyer could be used. Straight away it'd make rare ships rarer, and more of a find when you chance across one. I guess with some research the ships could go into their historical stations/battlegroups in the database when selection occurs.

A second function would then be needed, to look inside a save game file for sunk ships - and then the same routines as above could be run to ensure that you don't bump into it again. This would mean that you don't sink a converted Mogami several times for example, by running the campaign updater between missions. I had a quick look in the save game files and it does seem that ships sunk are in there.

Just a suggestion from someone that's not actually looked at your library so I hope I'm not asking for something already in there. I guess I'm suggesting a search and replace function, something for reading in ship and convoy data from an external source (easy enough to write, but a standard would be good for encouraging people to build on each others work) and something for reading relevant data from a save game file.


Have fun
Finn

[tater]

Wow, the ability to code in zig zags would be amazingly cool. Would it work where you would pick 2 waypoints, then input a degree change off the base course and some interval?

tater

[mcoca]

Originally Posted by FinnN

I've not taken a look at this as I'm a .NET user but I think it's a great thing that you're doing here.

You can take a look at the IKVM (a JVM implemented in .NET) if you still want to play around with it And you can install both Java and .NET without problems, IIRC.

Basically in a campaign (mission even if you're 'lucky') you can sink the same battleship/cruiser multiple times - fine for destroyers but not so good for
the Yamato. How about a function to search and replace generic ship entries in the campaign file with specific ones?

Can be done already, but on what would you base what specific type to use for each case? The whole task force business needs a real overhaul anyway. Less movements of entire fleets and more small forces redeploying to/from home ports to advance bases, for example.

So, someone could then write a little utility that when you run it fills the random battleship entry with a specific one from a database, then it'd fairly easy to only have two Yamato class BBs in the game world. Then when the Yamatos run out, the rest can be filled with a different BB, when they run out it might then be missing altogether from the battlegroup or replaced by a cruiser. If cruisers have all been allocated then a destroyer could be used. Straight away it'd make rare ships rarer, and more of a find when you chance across one. I guess with some research the ships could go into their historical stations/battlegroups in the database when selection occurs.

I think some people are already working on this. I agree with the basics, but I think scripting 100% accurate historical data could be a mistake, since in the end it takes away the mystery of what you will find. Adding some fuzzyness to the data would be very good.

For example, according to combinedfleet.com, the Yamato left Truk for Japan on May 8th 1943. In Japan it was drydocked for maintenance and didn't leave until August 17th. Armed with those facts, a player could easily ambush the Yamato in every career. I think random groups should be used to make the BB leave at some point in May and come back at some in August, for example.

A second function would then be needed, to look inside a save game file for sunk ships - and then the same routines as above could be run to ensure that you don't bump into it again. This would mean that you don't sink a converted Mogami several times for example, by running the campaign updater between missions. I had a quick look in the save game files and it does seem that ships sunk are in there.

Sounds very interesting and certainly doable. It would something to integrate in a SH3 Commander kind of program. Any volunteers to implement it? The save game format is very similar to the mission format (Windows INI files, both of them), so it's easy to parse it.

Not something I plan to do, but if someone gives it a try, I'll be happy to help.

[mcoca]

Originally Posted by tater

Wow, the ability to code in zig zags would be amazingly cool. Would it work where you would pick 2 waypoints, then input a degree change off the base course and some interval?

We can only do that by inserting new waypoints. My idea would be to automate the generation of those waypoints. For example, to replace a waypoint with a zigzag course alternating 30 degrees off the base course at intervals of 10nm, you could do something like:

waypoint.zigzagTo(30,10)

The problem I see with that method is that it conflicts with random waypoints, so every instance of the group would follow essentially the same (zigzagging) route. Really, this should be implemented by the devs, not hacked in by us.

[mcoca]

I just made a new release. Aside from the new "output" field, which allows you to select a destination for the changed files, so not to overwrite the originals, the most useful change is the support for zigzagging via new waypoints.

There is sample zigzagging code in the README. If anyone knows how to make that a bit cleaner, I would love to see it. In any case, zigzagging as currently implemented will cause odd behaviour when it interacts with random waypoints, so check your changes.

Enjoy!

Originally Posted by mcoca

I just made a new release. Aside from the new "output" field, which allows you to select a destination for the changed files, so not to overwrite the originals, the most useful change is the support for zigzagging via new waypoints.

There is sample zigzagging code in the README. If anyone knows how to make that a bit cleaner, I would love to see it. In any case, zigzagging as currently implemented will cause odd behaviour when it interacts with random waypoints, so check your changes.

Enjoy!

Is this the actual new release you're talking about?

[mcoca]

Originally Posted by terrapin

Is this the actual new release you're talking about?

Yep. I had edited the first post with the correct URL, changes, etc. I guess I should have made it clear in my post Sorry about that.

Originally Posted by mcoca

Yep. I had edited the first post with the correct URL, changes, etc. I guess I should have made it clear in my post Sorry about that.

Thank you!

[Yanaran]

I'm having problems removing units from groups. Specifically I want to remove all tankers from task forces (so I can speed them up)

if group.groupName.find("TaskForce") != -1:
    for unit in group.units:
        if unit.type == UnitType.TANKER:
            group.units.remove(unit)

I get an error that says:
Traceback (innermost last)
File "<string>", line 2, in ?

Any ideas?

[mcoca]

Originally Posted by Yanaran

I'm having problems removing units from groups. Specifically I want to remove all tankers from task forces (so I can speed them up)

I get an error that says:
Traceback (innermost last)
File "<string>", line 2, in ?

Any ideas?

Does it say something about a ConcurrentModificationException too? That's what I get if I try your code.

The problem is removing items from the middle of a list while you are iterating over it. It's a very common problem, and IMO Java doesn't fix it too well. You can work around it like this:

if group.groupName.find("TaskForce") != -1:
    i = group.units.iterator ()
    for unit in i:
        if unit.type == UnitType.TANKER:
            i.remove ()

I'll try to find a better syntax for the next release...