UnitAttachment Which Allows/Requires Another Unit To Move

redrum

@cernel It would at least in theory work for any units. I don't see any reason to only allow it for land units.

Cernel

@redrum It may be really good if two related options may be added, one "isRail" and the other one "isPort". If "isRail" is true, loaded/unloaded units are not accounted. If "isPort" is true, only loaded/unloaded units are accounted. Of course, if both are false or absent, all units are accounted.

For your main user case, I'm not sure if you think that a shipped train should limit how much other trains can move through the same territory or not.

Hepps

@cernel If done as a unit property... the applications are varied.... since "is rail" would be a parameter defining ONLY the a specific type of transport which the ability is restricted to, you could in theory have multiple types of "allows movement" unit types within the same game... including "Ports" or "Beaches" or even "Roadways". Thus you could... potentially... even limit the number of units which could do an amphibious landing in any given territory based on how approachable the coast is, thus giving a designer the ability to tweek a map and give certain area's more or less beach slots.

If the unit allowing movement has a list of units (as well as the quantity of those units) then you could create any number of movement combinations which may or may not be allowed. Including different rail lines that may not connect despite being in adjacent territories....ie. "Major Rail", "Minor Rail" or "Regional Rail" or "German Rail" and "Russian Rail".

Cernel

@hepps What I was saying is that if the units moving from Egypt to Libya are counted as well as the ones unloaded into Libya, for the max of the "allowsmovement" unit in Libya, that would not work well for port limits (as said, would require to cut a "port" territory, likely as a circle). On the other hand, you might want to avoid that if USA dumps a lend-lease train in Archangel from the sea that limits the number of trains that can move through that territory at the same time?
The other main question is if this is going to be kept track through turns. For example, if there is a limit of 5 trains for the Germany territory, and Germans used it fully during their turn, up to the point no more Germans trains would be able to move there, will then the Italians be able move any of their trains in Germany, in their next turn? My suggestion was the reset to be at the start of the Combat Movement phase of the owner (thus, if the limit is 5 in Germany, and the Germans used 3, then the Italians or the Japanese can use max 2 total).

Hepps

@cernel I still don't see how any of this is relevant.

redrum

@Hepps @Cernel Alright, let's bring back some focus to what we'll actually initially implement. My thought is to just have a "requiresUnitsToMove" option which would work like "requiresUnits" does except for movement into territories instead of production.

Example
<attachment name="unitAttachment" attachTo="germanTrain" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="requiresUnitsToMove" value="germanRail"/>
</attachment>

Variations

1 choice, 1 unit:
<option name="requiresUnitsToMove" value="germanRail"/>
1 choice, multiple units (AND):
<option name="requiresUnitsToMove" value="germanRail:germanRailAdvanced"/>
multiple choices (OR), 1 unit:
<option name="requiresUnitsToMove" value="germanRail"/>
<option name="requiresUnitsToMove" value="russianRail"/>
multiple choices (OR), multiple units (AND):
<option name="requiresUnitsToMove" value="germanRail:germanRailAdvanced"/>
<option name="requiresUnitsToMove" value="russianRail:russianRailAdvanced"/>

This could be used for any type of unit and will check if all required units are operational (if maxOperationalDamage option is set).

Cernel

@redrum How about having a "count" being how many of these units can move into the territory per the target unit and stay in there at that exact moment.
For example:

This would mean that if in the target territory there are 2 "germanRail" you can move in there up to 6 of these units, if none already there. Only the units present at that exact moment you do the move count.
If the "count" is absent, it defaults to infinite (which, then, would be the same as you said).

However, in this case, it would be better to reword it as "canMoveIntoIfPresent", or in a way that it won't read that you need 3 "germanRail" per moved unit.

Since this would be a check that would be done in the exact moment you try to do the move, I guess it should be an easy addition. I think the concept of having it numbered, not "1 to infinite", was very interesting. I definitely believe you should not drop it, as an option ("1 to infinite" should be the default).

redrum

@cernel I think for some kind of unit limit it would make more sense on the allowing rather than requiring unit (rail in this case). So something like this:
<option name="allowsUnitsToMove" value="germanTrain" count="3"/>

Cernel

@redrum I guess whatever works best for the main usercase you have in mind, but I tend to think it is better to be on the requiring unit, since the default behaviour of any units is to move freely. Maybe something like:

germanTrain:
<option name="requiresUnitsToMoveInto" value="germanRail"/>

germanRail:
<option name="allowsUnitsToMoveInto" value="3"/>

Default being infinite.
Also, it should be cumulative, so that, in the above case, 4 germanRail units on the same territory would count like a single unit having name="allowsUnitsToMoveInto" value="12".

Cernel

This way, you could also have:

germanTrain:
<option name="requiresUnitsToMoveInto" value="germanRail" count="1"/>

germanRailGun:
<option name="requiresUnitsToMoveInto" value="germanRail" count="2"/>

germanRail:
<option name="allowsUnitsToMoveInto" value="3"/>

That would mean each Rail allows 3 Trains or 1 RailGun or 1 RailGun plus 1 Train. I would have it purely cumulative, so that 2 Rail allow up to a total of 3 RailGun (or 6 Train or whatever combination not going over the cap of 6).

Cernel

And this:

may represent something that takes no space at all on the Rail, but still requires it to move into the territory (it would need to be explained in pos2, that a count equal to 0 actually means infinitesimal).

RogerCooper

Couldn't you achieve much the same effect in the current engine by making rail a terrain type and train a land transport?

Cernel

@rogercooper If you meant only the count equal to 0, that would be just a minor additional element in the whole system. If you are asking why to do this whole thing, instead of using the available terrain effects, I'm probably not the most qualified to answer you about what exactly is the additional aim to what you can already do with terrains, as I guess this matter has behind some private talking I didn't partake.

Clearly, the main enhancement of this new feature would be the ability to have a count, if it gets made. I agree that if this feature would be merely a "1-to-infinite" thing, it would not add that much. Entering or not entering is currently easily achievable with terrain effects, as you point out (just have a no-train terrain everywhere there is not a rail). The other item would be being able to purchase and place rail, but this is fairly easily achievable, by having a set of triggers that remove the anti-rail territory effect, if a rail is present, or by a set of user actions for making rails, removing such territory effect. However, this is still a bit of work more, and unfeasible to be supported by the AI at any point. Theorically, also the count limit is achievable with the current option, by having a high limit and stuffing the territories with otherwise pointless units, so to leave the difference for other units to move into, creating different actual limits for the various territories, but this would be definitely a dirty hack.

TripleA may really benefit from the ability to somewhat set different stack limits per territory, instead of only the same for any, as now. If this comes as a unit ability, allowing you to manage such limits, mainly by placing new units of the kind, that may be an added value, as well.

My guess is that this thing started mainly out of the need of being able to purchase rail, if wanted, otherwise just doing it with territory effects would be very easy, if rails are supposed to allow infinite trains and not supposed to be purchased or placed (I guess what's behind this feature request is that they aren't).

A side note is that this feature would increase the need for a "remove units" phase, in this case for removing the existing rail units, as opposed to placing new ones. This would also add some additional depth for realistic games, as a WWII game with a realistic rail representation would actually have rail units almost everywhere you need, thus much limiting the impact of this requirement.

Finally, one of the main reasons to have rail is to save fuel cost, which would lead to the matter that, currently, the fuel feature is not very well handled (in particular, having an option for land transported units not to consume fuel themselves, when transported).

Hepps

@redrum This looks very versatile. I like it.

Hepps

@rogercooper You can use terrain... but it is pretty limiting and it is also quite cumbersome to try and work with in the XML if you want to produce or destroy something like portions of a rail network.

This would provide for far more flexibility to a designer.

Cernel

The other suggestion, besides having a way to have it with a count, instead of only 1 to infinite (in particular, maybe to use it for ports (sea and air ones)), was to call it "requiresUnitsToMoveInto", instead of "requiresUnitsToMove", if this is meant to limit moving into only (not sure).

Cernel

To be clear, the renaming above only in case you need the other unit only in the territory you move into, not also in the one you move out (don't know your plans).

redrum

The initial implementation is now in the pre-release: https://github.com/triplea-game/triplea/pull/2298

To test it, I edited the TWW XML with the following for reference:
<attachment name="unitAttachment" attachTo="germanTrain" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="movement" value="5"/>
<option name="attack" value="0"/>
<option name="defense" value="0"/>
<option name="transportCost" value="2"/>
<option name="canBeGivenByTerritoryTo" value="Germany"/>
<option name="requiresUnits" value="germanFactory"/>
<option name="canInvadeOnlyFrom" value="none"/>
<option name="requiresUnitsToMove" value="germanRail"/>
</attachment>
<attachment name="unitAttachment" attachTo="germanRail" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="isInfrastructure" value="true"/>
<option name="canBeDamaged" value="true"/>
<option name="maxDamage" value="12"/>
<option name="maxOperationalDamage" value="8"/>
<option name="movement" value="0"/>
<option name="attack" value="0"/>
<option name="defense" value="0"/>
<option name="isConstruction" value="true"/>
<option name="constructionType" value="fProduction"/>
<option name="constructionsPerTerrPerTypePerTurn" value="1"/>
<option name="maxConstructionsPerTypePerTerr" value="1"/>
<option name="canDieFromReachingMaxDamage" value="true"/>
<option name="consumesUnits" value="1:Material"/>
<option name="requiresUnits" value="germanCombatEngineer"/>
</attachment>

Hepps

@redrum Ok... got this up and running. All I can say is FREAKING AWESOME!!!!

Great step forward! Thank you for implementing this... really adds to the potential for the game. You have my complete appreciation for making it happen.

Hepps

Have been testing and tweeking my test XML all day. This works flawlessly without any mechanical issues thus far. Both Trains and Rail behave as expected... both can be bombed, disabled, destroyed, repaired and captured. The transport is simple and easy... everything works like a charm.

From the tests thus far... here is my only observable issue which I think needs to be addressed....

It needs a validation process for the territory where a train is originating from. Feels all kinds of wrong that you can move out of a terr. with either no rail present what-so-ever, or a territory with a disabled rail.

So far every other test has passed with flying colours.

Once again, great work!