Two parts to this post. First is geographic. Attached to this post should be two images.
One image is the area around Apalachicola, FL. In the game, the map is drawn such that the harbor for Apalachicola is 20+ miles away from the actual river it sits on. Correct me if I'm wrong here, but you can't see the coast from where Fort Gadsden was located, and it wasn't a masonry fort. Ideally what I would do is whip out ExMap and redraw the coastal water regions there. ExMap requires fluency in the language of ancient Babylon, and must be operated whilst taking methamphetamine. However, I have managed to create the underlying gameplay structures that model what should be there. The image is to help you visual it.
From the Fort Gadsden region, I removed the adjacency to the Apalachicola Sound (it was originally called "Alabama Sound"). Now fire from Gadsden can only reach the river immediately adajacent. The current adjacencies are represented by the pink linss. Apalachicola was moved from the *wrong location* (the white oval) to the correct location, along with the harbor exit. The adjacency between Apalachicola and Ochlockonee Estuary were removed. If I could change the map, redrawing the regions where I have dotted white lines would match this set of adjacencies.
For Savannah, I removed its adjacencies to Savannah Estuary and Wassage Sound (the red X's). To reach Savannah you have to do it via the Savannah River or one of the adjacent land regions. To fire on it via ship it would have to be done from the Savannah River region, meaning you'd have to pass both Fort Pulaski and the now represented Fort Jackson. It can't be done from Wassage Sound, nor can troops be landed directly in Savannah from either Wassage Sound or Savannah Estuary. Unlike the game as delivered, now Savannah can't be taken simply by bypassing Fort Pulaski. Savannah Estuary is still adjacent to Beaufort, meaning that the Port Royal expedition can't be modeled well at all. If I could redraw the regions, the dotted white lines would be how I'd set it up. Beaufort wouldn't be adjacent to Savannah Estuary, meaning Port Royal could be attacked without having to run the batteries at Fort Pulaski.
There ought to be an additional coastal region between Savannah Estuary and Beaufort Bay, but I don't know how to make that happen. I can edit the region images to add those dotted lines and give the player an idea of how the adjacencies are set up, but I can't redraw the map to add or remove regions. I can completely block regions but that's a different subject.
Making these small changes doesn't change the fact that the coastline is a problem for the CSA, but it does mean that the larger cities can possibly hold out longer. I've included them in the force pool mod just to see how well they'd be received. The final force pool mod as a standalone probably won't include these changes.
//
What's in a name?
One of the goals of this mod is to eliminate or reduce the amount of redundancy in unit and model names. A long time ago a forum user called tripax worked up a mod to address this. I have that mod but I haven't looked at it lately. Just pointing out this isn't the first effort to try to address this.
Let me try to briefly explain, using analogy, how I believe this normally works in CW2.
Think of individual elements as eggs, and units as those styrfoam containers for the eggs. Containers usually have 6, 12, or 18 eggs. You could put white eggs or brown eggs in a container. But the container is still a shiny blue color, no matter what kind of eggs are in it. Each slot in the container only holds one egg. You could design a container that is a custom fit for 3 chicken eggs, 1 duck egg, and one snake egg (3 inf, one cav, 1 arty ...). Chicken eggs won't fit in the snake egg slot, but any color snake egg will fit in the snake egg slot, and so on.
Units are the containers, elements are the eggs.
This is all great when it comes to putting eggs on the shelf. Most of us want to be able to go into the store and find eggs as we expect them. Uniformity is the ideal; we usually disqualify eggs in a container if they are broken, opening a container to find white and brown eggs mixed at random would be unsettling if I wasn't expecting it. The only people who usually care about unique egg or egg container colors are people who raise their own chickens. But for some reason, we want uniquely colored eggs in uniquely colored egg cartons. We want something like 1000+ unique eggs, and hundreds of unique egg cartons.
Here's how the eggs (elements) are set up in the databases.
The eggs for all the containers are produced in a few different types (line inf, conscript inf, regular or alternate art, etc), depending on the nation. Each type comes in many colors (regiment names), but each type's list of colors is the same as the other types. If a nation has 3 different types of chicken egg, the list of colors for each of these 3 egg types is the same as the others. You can have a red-colored type 1, 2 or 3 egg.
Notice that the system for uniqueness is already busted.
Each state of a nation has 2-4 different egg container types (units), holding different numbers and types of eggs. Each type of container has a list of colors (Floyd's Brigade, Tuttle's Brigade, etc). Each type's list is the same as the other types. You can have a pink type 2 and a pink type 4 container from the same state.
Again, the design means uniqueness can't be achieved.
From observation of the design and the results in-game, this is how I think name selection was coded. Time to make some omelets!
Pick egg container type (CreateUnit)
Here's a container that will hold 2 platypus eggs.
Did egg container get a ~<*special name*>~?
(SetName by script)
No.
OK, go to the list of container names (unit file/unit record, CustomNames). Pick the first name from that list and see if any other existing container >exactly like me< already has that name (name in list: Rooster's Egg Brigade).
Well there's another container from your state that's >kind of like you<, holds 3 platypus eggs, that's called Rooster's Egg Brigade ...
Don't care, just care about containers >exactly like me<.
Then, no.
Great! I'll take that name.
Now there are two different containers from the same state named Rooster's Egg Brigade.
The more the merrier!
I won't bore you with further detail, but the process works similarly for the eggs (elements). I think it is possible, although unlikely, that you can have the same regiment name appear twice in a brigade.
How can this issue be addressed? Among other things, unique lists for each type of element and unit. Many units mix and match styles of regular or conscript infantry. The only difference in these styles is the artwork they use. Reducing the number of different styles of the same type of element in a unit is more generic, but it simplifies the list of names that has to be compiled.
Naming multi-element units in a way that is unique doesn't have to be difficult. With the example of Virginia, which uses three infantry brigade types under the mod, a total of brigades is tallied, and the names are distributed through the three lists. A name only appears on one list, and while it exists on the board it won't be duplicated. Trying to do that by using the historical brigade names is a project for someone with more time on their hands than I have. Maybe it could be done, but it would be ... <expletive deleted> difficult. Instead I have chosen sequentially increasing numerical designations, starting with 1st [state] Brigade and incrementing from there. Unique brigades like Barksdale's are created by event and named upon creation. This isn't as flavorful, of course, but neither were the duplicated and fictional names applied to multiple units or the wrong units. Personally, it's not enough for me to have Tuttle's brigade in the game unless Tuttle's brigade also has the historical regiments involved. Because of the way the game is designed, it is not possible to do that through building the brigade through the recruit panel. The only way to guarantee a set of regiment names in a brigade is to create the brigade through an event.
Single-elements and single-element units are also difficult. You can see this in practice in the vanilla game. Find a state like New York or Virginia that has many militia you can recruit. Recruit two militia. Stop. Combine them. Stop. Recruit a another militia. Stop. Note the name on the last militia you built, which should be a duplicate of the second one you built. Code steps involved checking for unit on board with that name, didn't find a >unit< (not >element<), used the first name off the list (in sequential order of the list) that isn't used on the board. Repeat those steps and you'll end up with umpteen 2nd NY militia units. If I ever see another 121st Tennessee ...
This problem can exist for any single element unit that can be combined with another. It was rampant for militia units in the vanilla game. It should be less so in the mod because the mod rarely allows elective combinations on base unit definitions (e.g. militia exploit removed). You will still see the issue if you combine a single element unit with a multi-element unit that is missing an element, but I hope to reduce the occurence of this by having a tailored list of names. Single element units will mostly appear at the beginning of the scenario and be named by event. Their list of names in the file won't include the names created by event, and the forcepool number available to recruit will be low. You'll probably have to lose 75% of the single elements units through combat or combination before the number on the board gets below the forcepool amount.
When militia upgraded to line, that changed the way they were viewed when it came to recruitment. For those who aren't familiar with it, say force pool contains 5 militia. Recruit one through build option, now 4 militia. Militia upgrades to line, force pool is 5 militia again. IIRC this is due to the fact that the family type changes. New militia units don't upgrade and can't be combined, an't be recruited so that exploit is removed.
I'm open to ideas if anyone has any. I feel like I've already significantly reduced this duplication issue by separating the arms types. I won't have made it worse with the design I have for names, but I won't have eliminated it altogether. That may be all I can hope for.