UnitAttachment Which Allows/Requires Another Unit To Move
-
So the idea is to have the ability to design a unit (rail in this example) that would allow a unit (train in this example) to move in and out of the territory. If there is no (functional) rail then the unit would not be capable of moving into or out of the territory.
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).
https://github.com/triplea-game/triplea/pull/2298
https://github.com/triplea-game/triplea/pull/2315
https://github.com/triplea-game/triplea/pull/2326 - 1 choice, 1 unit:
-
@Hepps So thinking about this some I wonder whether its better to have in the UnitAttachment XML:
- An option on the "rail" to allow movement of specific units
- An option on the "train" to require specific units for movement (similar to how "requiresUnits" works for production)
- Both 1 & 2
Other questions:
4. Are there other use cases that we can think of besides rail/train that this system could be used for?
5. Should maxOperationalDamage work for this new options (I believe this only works for isAirBase, repairsUnits, givesMovement)My initial thought is to have it work very similar to "requiresUnits" option then only territories which have the required unit(s) allow the unit to be moved into (potentially could make it so the required units also need to be operational).
-
Nice stuff with many more uses than just trains.
However, as far as trains are concerned, especially if the aim is realism, I suggest not going that way, but doing it with canals (already possible). That way, you can define what connections have railways, which is better. This has the limit of being unable to purchase railways, but you can do it with user actions (tho it's a lot of coding). If you just have railways as a static element (you can't produce nor destroy any), which is fairly sensible, then you can draw on the map, likely as a decoration, your railway network.
Personally, as far as logistic is concerned, I believe that the most important limit that needs to be supported is, instead, portual capacity (meaning that from a sea zone to a territory you should be able to load or unload a max number of units, not infinite, for normal transports (the ones unable to conduct sea-borne assaults)).
Finally, all these kinda things should be tracked not at a turn level, but the capacity should regenerate at start of combat move of the owner, preferably customisable as a step, not end turn or somesuch. It would make no sense if a player can move up to 5, but 3 players, going one after the other, can move up to 15 in total. In this case, a visual display of the capacity used so far would be nice.
-
Off topic, but kinda on the same level, it would be great being able to specify, in the canal attachment, the max number of units that can move through the canal, but with this being set to 0 when any control territories change hands and being reset to max only at start of combat move of the owner. The units excluded by the canal (default all air) would be not counted, of course.
This would also cover the portual capacity need, as you would make a port "sea zone" with a canal between it and the respective land territory.
-
@redrum That all looks bang on.
I have some other idea's for its use. Yes. We can chat about it when we see each other.
Operational damage is important. Certainly for the sake of flexibility.
-
@cernel Canals has way to many limitations to be of any use. It is far from an ideal way to manage something like a train system effectively.
BTW what does port limits and canals have to do with this thread?
-
@hepps Canals, nothing. Port limits, this thing you could use it to some extent (you have a port as a sea unit allowing movement of some ships; tho, that would require having infinite capacity "port" units everywhere in the map, where ships are supposed to move freely). However, the matter would be not really how much ships can fit in a sea zone with a port, but rather the ability to load/unload from/into there. This might be addressed by having these units limiting movement in a land territory supposed to represent the port (in this case, this thing allowing movement would be a land unit); likely all this should have a series of canals, to limit what can go where.
-
The above would be only partially true if the "UnitAttachment Which Allows/Requires Another Unit To Move" would work only on land territories.
@redrum Is it for land units only, or for any units, comprising sea and air? -
@cernel It would at least in theory work for any units. I don't see any reason to only allow it for land units.
-
@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.
-
@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".
-
@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). -
@cernel I still don't see how any of this is relevant.
-
@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).
- 1 choice, 1 unit:
-
@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:<option name="requiresUnitsToMove" value="germanRail" count="3"/>
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).
-
@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"/> -
@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". -
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).
-
And this:
<option name="requiresUnitsToMoveInto" value="germanRail" count="0"/>
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).
-
Couldn't you achieve much the same effect in the current engine by making rail a terrain type and train a land transport?
