Civil War | Units Issues

Cernel

I was en passant looking at the unit attachments, when I happened to notice there is a nonsense in this one, as you would be "changing" a unit into the same one (pointless by definition).

    <attachment name="unitAttachment" attachTo="foundry" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="isConstruction" value="true"/>
      <option name="constructionType" value="industrial_structure"/>
      <option name="constructionsPerTerrPerTypePerTurn" value="1"/>
      <option name="maxConstructionsPerTypePerTerr" value="2"/>
      <option name="isInfrastructure" value="true"/>
      <option name="destroyedWhenCapturedBy" value="FROM:Union:Confederate"/>
      <option name="whenCapturedChangesInto" value="Pro-Confederate:Union:true:foundry:1"/>
      <option name="createsResourcesList" value="2:Industry"/>
      <option name="canBeCapturedOnEnteringBy" value="Union:Confederate"/>
      <option name="canOnlyBePlacedInTerritoryValuedAtX" value="1"/>
    </attachment>

namely:
<option name="whenCapturedChangesInto" value="Pro-Confederate:Union:true:foundry:1"/>
should be:
<option name="whenCapturedChangesInto" value="Pro-Confederate:Union:true:foundry_u:1"/>

This wrong code causes the game bug that when Union takes a Pro-Confederate foundry, it remains a "foundry", instead of changing to "foundry_u", as it should, as now being owned by Union (and all foundry units owned by the Union are clearly intended to be "foundry_u").

And, then, I took a look at the one for the Union. Here, that thing was got right, but, nonetheless, there is a coding error, there, as well, but a different one:

    <attachment name="unitAttachment" attachTo="foundry_u" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="isConstruction" value="true"/>
      <option name="constructionType" value="industrial_structure"/>
      <option name="constructionsPerTerrPerTypePerTurn" value="1"/>
      <option name="maxConstructionsPerTypePerTerr" value="2"/>
      <option name="isInfrastructure" value="true"/>
      <option name="destroyedWhenCapturedBy" value="Union:Confederate"/>
      <option name="whenCapturedChangesInto" value="Pro-Union:Confederate:true:foundry:1"/>
      <option name="createsResourcesList" value="2:Industry"/>
      <option name="canBeCapturedOnEnteringBy" value="Union:Confederate"/>
      <option name="canOnlyBePlacedInTerritoryValuedAtX" value="1"/>
    </attachment>

namely:
<option name="destroyedWhenCapturedBy" value="Union:Confederate"/>
should be:
<option name="destroyedWhenCapturedBy" value="FROM:Union:Confederate"/>

This causes a conflict between the "destroyedWhenCapturedBy" property, that is practically saying the units is going to be always destroyed, and the "whenCapturedChangesInto", that it is saying the unit is turning into "foundry" when captured by Confederate from Pro-Union.
Upon testing (edited a bunch of Confederate combat units in Frankfort at start game), this appears to cause the game bug that Pro-Union "foundry_u" units captured by Confederate are destroyed, nullifying what appears to be intended by the coding of "whenCapturedChangesInto" (and, more importantly, as per game notes rules).
Side note, I believe spelling out both Union and Confederate is pointless, has having the Union only would be enough, as Confederate should never have the "u" units.

There is just the same problem for this other unit:

    <attachment name="unitAttachment" attachTo="storehouse_u" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="isConstruction" value="true"/>
      <option name="constructionType" value="supply_structure"/>
      <option name="constructionsPerTerrPerTypePerTurn" value="1"/>
      <option name="maxConstructionsPerTypePerTerr" value="2"/>
      <option name="isInfrastructure" value="true"/>
      <option name="destroyedWhenCapturedBy" value="Union:Confederate"/>
      <option name="createsResourcesList" value="3:Supplies"/>
      <option name="canBeCapturedOnEnteringBy" value="Union:Confederate"/>
      <option name="whenCapturedChangesInto" value="Pro-Union:Confederate:true:storehouse:1"/>
      <option name="canOnlyBePlacedInTerritoryValuedAtX" value="1"/>
    </attachment>

namely:
<option name="destroyedWhenCapturedBy" value="Union:Confederate"/>
should be:
<option name="destroyedWhenCapturedBy" value="FROM:Union:Confederate"/>

This can be tested, about the same way, and you will see that it causes the game bug that if the Confederate capture a Pro-Union territory with a "storehouse_u" that is destroyed, while it should be captured (and turned into "storehouse").
For example, just attack Pikeville with the Confederate on round 1, and you will see that the storehouse in it disappears.

On this matter, mostly as a side note, there are a lot of occurrences like these:

      <option name="destroyedWhenCapturedBy" value="FROM:Union:Confederate"/>
      <option name="destroyedWhenCapturedBy" value="FROM:Confederate:Union"/>
      <option name="destroyedWhenCapturedBy" value="FROM:Pro-Confederate:Union"/>
      <option name="destroyedWhenCapturedBy" value="FROM:Pro-Union:Confederate"/>

Here I assume the mapmaker (pulicat) didn't understood correctly what he was coding, in that I believe he assumed that the second entry was the player captured from and the third entry the player captured by (or at least I don't see a better way to mind-read this whole thing).

For example, among the many other cases, you have:

    <attachment name="unitAttachment" attachTo="recruitment_center" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="isConstruction" value="true"/>
      <option name="constructionType" value="manpower_structure"/>
      <option name="constructionsPerTerrPerTypePerTurn" value="1"/>
      <option name="maxConstructionsPerTypePerTerr" value="2"/>
      <option name="destroyedWhenCapturedBy" value="FROM:Union:Confederate"/>
      <option name="destroyedWhenCapturedBy" value="FROM:Confederate:Union"/>
      <option name="destroyedWhenCapturedBy" value="FROM:Pro-Confederate:Union"/>
      <option name="destroyedWhenCapturedBy" value="FROM:Pro-Union:Confederate"/>
      <option name="isInfrastructure" value="true"/>
      <option name="createsResourcesList" value="1:Manpower"/>
      <option name="canBeCapturedOnEnteringBy" value="Confederate"/>
      <option name="canOnlyBePlacedInTerritoryValuedAtX" value="1"/>
      <option name="unitPlacementOnlyAllowedIn" value="Lewisburg:New Madrid:Franklin:Marion:Yazoo Pass:Millikens Bend:Lawrenceville:Helena:Smithville:Mine Creek:Yellville:Parisburg:Valverde:Pimas Villages:Tampa:Spring Cottage:Wilkesboro:Sparta:Woodville:Dublin:Chattanooga:Leakesville:Lynchburg:Upperville:Mansfield:Plymouth:Playa De Los Pimas:Williamsburg:Brashear City:Mesilla:Franklinton:Bermuda Hundred:Augusta:Vicksburg:Peedee:Charlottesville:Front Royal:Tuskegee:Yorktown:Dahlonega:Hazelhurst:Greensboro:Thomasville:Charleston:New Bern:Centerville:Raleigh:Atlanta:Lexington:Brunswick:Charlotte:Houma:Little Rock:Blackville:La Grange:San Felipe:Marks Mill:Abbeville:Columbus Georgia:Warsaw:Fort Payne:Halifax:Palmyra:Bentonville:Center:Spotsylvania:Cold Harbor:Sussex:Cedar Mountain:Sabine Pass:Vermilionville:Fort St Philip:Kosciusko:Columbus Kentucky:Starkville:Fort Macon:Outer Bank North:Fredericksburg:Port Hudson:Yellow Bayou:Greenwood:College Hill:Brevard:Blountsville:Summerville:Elizabeth City:Clarkesville:Carrollton:Booneville:North Fork:Lovingston:Tuscon:Tappahannock:Jackson:Fort Pemberton:Fayette:Hawkinsville:Ridgeway:Suffolk:Corinth:City Point:Emporia:Norfolk:Winchester:Orange:Kingston:Falmouth:Asheville:Archedelphia:Fort Henry-Donelson:Houston:Greenville:Fort Pillow:Camden:New Market:Harrisonburg:Buckingham:Newport:Northumberland:Troy:Savannah:Memphis:Hot Springs:Paraclifta:Middlesex:Murfreesboro:Sentinella:Pine Bluff:El Llano Estacado:Robertsons River:Wilmington:Lebanon:Outer Bank South:Milford Station:Tallahassee:Westmoreland:Aquia Creek:Appomattox Court House:Mount Pleasant:Hanover Junction:Montgomery:Monroes Crossroads:West Point:Petersburg:Amelia:Poison Spring:Cross Keys:Macon:Waycross:Johnsonville:Biloxi:Warrenton:Jacksonville:Jasper:Selinas de San Andres:Blairsville:Mechanicsville:Tuscaloosa:Luray:Nottoway:Edwards Station:Fort Jackson:Waynesboro:Massanutten:Dome Mountain:Romney:Choctawhatchee:Santa Rosa:Staunton:Gordonsville:Milledgeville:Goldsboro:Cheraw:Branchville:Wharton:Chickamauga:Beaufort:Meridian:Allegheny Mountains:Perry:Rita del Cobre:Union Church:Pulaski:Harrison's Landing:Gilmer:San Andres Mountains:Newbern:Chester:Rosedale:Fort McAllister:Louisa:Aberdeen:Moulton:Decatur:South Fork:Culpeper:Leona:Brandon:Danville:Strasburg:Smithfield:Talladega:Liberty:Napoloen:Fort Hindman:Jefferson:Gainesville:Ogeechee:Apalachicola:Chancellorsville:Mobile:Monroe:Darbytown:Goochland:Galveston:Sand Mountain:Snyders Bluff:Selma:Shreveport:Erin:Columbia:Richmond:Port Republic:Florence:New Orleans:Cajuenches Cucapas:Grenada:Nashville:Natchez:Oro del Pueblo:Mill Springs:London:Stanford:Dorchester:Talbot:Pocahontas:Bolivar:Searcy:Tahlequah:Pea Ridge:Leonardtown:Bowling Green:Van Buren"/>
    </attachment>

Now, that is not an actual game bug, at the end, but just a major redundancy, as those 4 lines just equal having (sensibly):

<option name="destroyedWhenCapturedBy" value="FROM:Confederate:Union:Pro-Confederate:Pro-Union"/>

The whole coding for the many unitattachments looks a bit messy, at times, and I've not reviewed all of it very well; so there may easily be other issues.

I'd like someone to review this post of mine and at least confirm (or deny) the three actual game bugs, I pointed out.

Also, if any players of this map (even if not power user enough for looking at the folders), playing the map, noticed wrong units behaviour, this is a good topic for reporting them.

Then, instead of just correcting them in the referring two games of this map, I believe someone (who plays this map) should conduct a in-depth review of all its unit attachments, as well as extensive playtesting of the various possibilities, in search of other similar issues to address, so to hopefully fully proof all of the unit attachments. Use this topic I've opened to communicate about any Units issues, of course.

Anyway, am I missing something silly myself? Like, the notes clearly state that "infrastructure captured from sympathetic or hostile neutrals never downgrade". Does nobody ever, for example, attacked Pikeville with the Confederate and noticed that some of the infrastructures were destroyed, in violation of this clear universal rule? Are there bug reports, about such things, somewhere I'm not seeing? If there are bug reports about Civil War units issue, I suggest linking them all in here, and consolidate all of them in this topic.

If the above is confirmed, @redrum @LaFayette let me know if you would like the game bug relevant issues, I've spotted so far, to be corrected (I can do that) or waiting for a more in depth analysis and playtesting (not by me) of the map codes, to try to get all, if anything more.

redrum

@cernel I believe you are correct and I did notice some weird behavior around capturing the neutrals infrastructure but hadn't looked closely.

Cernel

"shipyard" and "shipyard_u" cannot be placed in the following territories, while it should be allowed:
Long Island

Additionally to the above, the Union (only) cannot place "shipyard_u" in the following territories, while it should be able to:
Annapolis
Nashville

Solution:
Add "Long Island" to the "unitPlacementOnlyAllowedIn" value of "shipyard".
Substitute the "unitPlacementOnlyAllowedIn" value of "shipyard_u" with the same for "shipyard".

Warning:
There may be other wrong or missing entries in the code for "shipyard_u" and "shipyard". Check that all entries correspond with all territories on the map adjacent to the sea and having production value 3 or a shipyard/shipyard_u in them at start game.

Comments:

Not a Civil War player myself, so it would be especially good if one confirms the above is correct.
On general terms, I disagree with having the special rule that you can place a shipyard if one already there in the starting setup. This means that either you have to remember where the starting shipyards were or keeping going back to start game history to look at it. Elements that are liable to be removed without leaving any trace (except for looking at history), during the course of the game, should not be the base for rules.
Generally speaking, having in the xml the full list of where something can or cannot be placed, based on unsupported rules explained in notes, really doesn't look like the best practice (and, obviously, cannot have a good tooltip for it). I'd say a property like "unitPlacementOnlyAllowedIn" should be used only when the rules themselves are just a plain list (communicated in notes or graphically or both), as well. If a developer thinks it may be worthwile, instead of spelling out the full list of territories based on the rule communicated in game notes, it would be rather better supporting such rules (limiting placement to production 3+ territories is already supported), except that I would not support a rule that allows placement based on a unit presence that is not there in the moment you actually place it (see the point above).

wirkey

@cernel @redrum There is an issue with the dockyards. It should be possible to place one in every territory worth 3 or higher and every one that has one at the beginning no matter which side (Galveston, Mobile, Pensacola, Key West, Vicksburg, Chattanooga, New Bern, Norfolk)

Cernel

@wirkey Clarifying that by "dockyards" you mean "shipyard" (and "shipyard_u").
Yes. I just made a post about it. Sadly, that is not really supported, so matter is writing down each one singularly.
This is the current full list for "shipyard" in the xml, if anyone wants to spot other missing ones, beside Long Island:
New York:South Jersey:Philadelphia:Baltimore:Annapolis:Washington:Norfolk:New Bern:Charleston:Savannah:Key West:Pensacola:Mobile:New Orleans:Galveston:Vicksburg:College Hill:Memphis:Nashville:Corinth:Chattanooga:Bowling Green:Louisville:Frankfort:Pittsburg:Ravenna:Zanesville:Marietta:Hillsboro:Cincinnati:Salem:Evansville:St Louis:Alton:Naples:Iowa City:Chicago:Toledo:Cleveland

All those listed by @wirkey are there.

Cernel

@cernel My solution/suggestion, instead of just fixing, would be:

Removing the (unsupported) rule that starting shipyard allow placement for the rest of the game.
Make shipyard downgrade upon capture to a nonfunctional version of the same or getting damage you can repair (instead of simply destroyed upon capture).
Have just the rule that you can place new ones in 3+ value territories but upgrade/repair captured ones anywhere.

At this point, the only unsupported rule would be that you can place shipyards in territories not connected to the sea (if value 3+), but that is just idiot proof.

wirkey

@cernel said in Civil War | Units Issues:

@cernel My solution/suggestion, instead of just fixing, would be:

Make shipyard downgrade upon capture to a nonfunctional version of the same or getting damage you can repair (instead of simply destroyed upon capture).

I had a discussion with pulicat about that one. Can you specify which resources are used for repair? On the other hand we had the issue that, if you can repair at the beginning of your turn, you could already use that shipyard to produce ships

Cernel

@wirkey Yeah I specifically didn't go into details, as those need to be defined by players of the map, or the risk is overlooking something dumb or breaking some intended dynamics. So, I cannot help you there; what at my previous post was just a suggestion for an actual player to take over (but it is possible to just debug by fixing the list).

I can only say that for the resources I would just go with half or so of what is needed to produce a shipyard from nothing.

Cernel

Ooor are you sure that the 3+ production restriction is really necessary? After all, those shipyards in poorer zones have been built sometimes in the past sooo...

wirkey

@cernel said in Civil War | Units Issues:

Ooor are you sure that the 3+ production restriction is really necessary? After all, those shipyards in poorer zones have been built sometimes in the past sooo...

There is at least one 2-territory, where a shipyard would change a lot (Cairo). Besides that, what should the restriction be? Nothing could become really ugly for the Confeds, once the Union is through Columbus/New Madrid or New Orleans.

For repairs I would go with one manpower, 3 supplies, 5 industry. But it should only happen after the turn, so you can't use it to build ships in that turn. On the other side that means, that Union couldn't use the +1 movement

Cernel

@wirkey Then it can only be done by downgrading it to another unit (that needs to be added). Not up to me (and not even a player), but I would take this opportunity to also make shipyard a unit you build in 2 turns (so this other unit would be both the downgrade of shipyard and the first build of it, for a new one).

redrum

@cernel I'd say let's not go and make significant changes to the map. Let's just focus on capturing anything that doesn't work as intended and consider if they would be easy to fix in the XML.

The 3 production or started with one, is a pretty important rule as it limits the places shipyards can be built.

wirkey

@cernel did you already change something? I'm in bot 501 trying to play CW and we get these errors:

0_1530206908382_d9055f08-151d-490f-95a8-745dbfba847d-image.png

redrum

Another bug is that Union subs are missing the required facility of "shipyard_u" and only have "shipyard" specified so can't be placed unless you edit in a "shipyard".

Cernel

@wirkey Are those 2 separate bugs at the same time?

What I see is a notification text missing and a fuel cost bug.

For the fuel bug, I suggest you open a bug report in Git Hub, if you have it again.

For the notification, that would be a matter relevant for this topic, so move it there if it happens again (but that (Confederate_Take_Loan_at30.OTHER_NOTIFICATION_SUCCESS) wasn't changed):
https://forums.triplea-game.org/topic/901/civil-war-war-financing-issues/17?page=1

It is not actually possible to test such notifications on local. You need another user to make the action.

Cernel

@wirkey For the notification display fail (NO: Confederate_Take_Loan_at30.OTHER_NOTIFICATION_SUCCESS set.), report/move it here if it happens again or you can find a way (for others) to reproduce it:
https://forums.triplea-game.org/topic/901/civil-war-war-financing-issues

Thanks for testing.

Cernel

@wirkey Me and @redrum just tested that notification in my host (me on 1.9.0.0.10402), and it worked fine for us both sides. So more info are needed (at the linked topic, not here) if that is to be reproduced.

wirkey

@cernel 0_1530267487586_e19c096b-16ce-4bfc-ae40-4c102a913480-image.png

Cernel

Moved to Maps & Mods.

I think this is a good collection of issues that the Civil War map has, and that can all be solved at a game (xml) level. However, it is needed a reliable player of the map to do that, as I'm not sure if making these changes without playtesting the game is really better than doing nothing (I'd rather not).

mattbarnes

Hi all. Just replying to this as a convenient thread to save creating a new one. I've enjoyed many maps (particularly the WWII, WWI and LoTR) and thought this looked like a good one to try next. Contrary to the view of one contributor, we do have awareness of the US Civil War here in the UK. Please can anyone let me know whether this scenario (either or both variants) is highly playable or not? Thanks, Matt