UnitAttachment Which Allows/Requires Another Unit To Move

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!

redrum

@hepps Glad its working well and thanks for testing it out. I'll make the change to check the starting territory as well since I agree that makes more sense for this feature.

Hepps

@redrum Just giving credit, where credit is due. Rarely is something integrated into an existing system with such flawless efficiency.

If I were wearing a hat.... it would surely be off for you fine sir.

redrum

@hepps Change to check the starting territory as well should now be in the pre-release: https://github.com/triplea-game/triplea/pull/2315.

redrum

@hepps Change to include checking for allied units should be in the pre-release: https://github.com/triplea-game/triplea/pull/2326

Hepps

@redrum Worked like a charm. I think this feature is where it needs to be. I will continue testing for issues, but the last release seemed to correct all remaining issues.

RoiEX

@redrum Might be a bit late, but I think AND and OR should be reversed.
IMO this is more intuitive, you'd expect the xml to always add everything together.
If you read the xml without any colons, you'd read requireUnitsToMove germanRail, requireUnitsToMove russianRail etc. and IMO you'd say AND instead of OR.
Just my opinion, what do the others think?

Cernel

@roiex I agree with you that it doesn't make sense that thing meaning OR, but the other thing meaning OR would not make sense, just as much.

I suggest you remove the "OR" capability, and add a count, instead, in the sense of a "rail" being able to allow up to a number of "train", and cumulative. That would be much more extensive than the "OR", as well. I mean in my mind, as I don't fully know your plans, obviously.

Again, I don't know what you guys talked about privately, so nevermind me if this suggestion of removing the "OR" in favour of a count is unacceptable for either of you two, for whatever reasons.

RoiEX

@cernel For me it actually does make a little bit more sense, but this might be because the : character reminds me of |, which is used for or in a lot of programming languages
But I get your point.
What I don't get is what exactly you mean with your alternative.
Having ORs allows you to use the rails of your allies for example, not sure how this would be done using your suggestion.

Cernel

@roiex Ah, right, didn't think about that. Here you have germanRail, italianRail. Nevermind then, as I said.

Still, normally the ":" in similar cases mean AND, for example this one, but also many others, if not all of them, especially the conditions testing:
https://github.com/triplea-game/triplea/issues/2325

Since you need the "OR", then probably you should have this thing on the "rail", not on the "train"; that way the "OR" would be intuitive, and it would also make more sense that when the rail is bombed it is disabled, as being the unit having the ability itself.

As said, probably having it on the "rail" would make also easier and more intuitive adding a count, in the sense of a "rail" allowing up to a number of "train".

On the other hand, since normally units move without this limitation, I would also add a count that gives up to a number of free movements to the target "train". In this case, you would have the train having itself movement 0 and the rail giving it the free movement that you would now assign the train, and you could also use this option for representing cases in which the network gives a bonus, rather than allowing/disallowing; for example, "street" units for an Ancient scenario, in which a "legionary" moves 1 normally but can move 2 or maybe 3 if all territories from start to finish have "street" units (in this case, the legionary has 1 movement and the street gives 1 or 2 to infinite legionaries).

Cernel

@cernel This was previously discussed in the thread about the development of Total Ancient War, relatively to the fact of having "road" units, giving bonus movement to units that can also move without roads, for which the current bonus movement system is not that good, because you just give it for the starting territory, while it would be correct only if it works in case all territories you are moving through have "road" units. So this would cover that too, if it would resurface, at any point in the future. In general, I surely suggest to expand this with counts both for:

Having 1 "rail" to some "train", instead of only 1 to infinite.
Having the ability to move faster, instead of only being able to move at all or not (in this case, the "train" case would be a subset in which the moved unit has movement 0 itself).

In the case nr. 2, it would be opportune that such units are always selectable, then (differently from the other movement 0 units, supposed to never move).

RoiEX

@cernel Such "road behaviour" will be added as part of my diplomacy extensions, the canConvoy feature should pretty much adress what you want.

Cernel

@roiex Cool, but, actually, right now I've no plans to use it (but who knows), but it came up in the past (and maybe Zim might want to update his TAW map still). Would it be possible to build it up on this railwayish thing, as I said? In general, extending a same thing, while keeping past functionalities, is better than having multiple. And I think, as you pointed out, that this thing looking like AND and meaning OR should be changed anyways, because it is counterintuitive and really inconsistent with almost anything else of how stuff works. Up to you, of course.

In the moment in which you have two separate entries of "requiresUnitsToMove", what that logically means is that you need the one and the other to move, as you said, and I believe this is how it works in all options cases so far.

Cernel

@cernel I meant still somehow supporting the "OR" (in a logical / intuitive way), of course, and the current functionalities or whatever you two want to have. I guess you need both the "OR" and "AND"? Like you also need having the "rail" plus something else, as well, to move the "train" through? Just wondering if both are needed for your user case.

Hepps

@cernel To be honest cernel... I tried to make the suggestion as simple as possible in order to make it achievable without complicating its design.

The reason I excluded any kind of "count" system in the original proposal was because it seemed to me that it would...

a) Make its integration into the code far more difficult. Obviously a big assumption on my part since I know nothing of the code... but an assumption made based on observations on how the XML works.

but more importantly, it would...

b) create a very complex system of management for players since you would either have to memorize where and how many times you had used a multitude of rail units... or require a brand new method of tracking movement on rail (with an accompanying visual display) to be devised. While pondering this it also struck me that even with a graphical representation... this would become a very taxing exercise in micro management leading players to have to undo and redo moves during a turn trying to figure out how to make moves along this system work optimally.

That was purely the reason for trying to keep this idea simple.

Cernel

@hepps Right. I get that all you think you need it's already there, so it's up to @redrum, at the end. I still think that a count would be better than 1 to infinite only (tho I've to admit I've no plans for any right now), but this is mostly because I tend to dislike all the 1 to infinite options in general, for principle (starting from "givesMovement" and "isDestroyer"; there are so many options already that would be so much better if they only had a count I would make 1 to infinite illegal), but let's then assume the case of not having a count, in the sense of "rail" allowing up to a number of "train", instead.

I want to point out that in the particular case of trains and railroads (as long as you are not adding maybe depots in an AND relationship) it is totally realistic that a railroad allows moving infinite trains. In WW2 the limit was almost not railroads at all: it was the quantity of trains available.

Actually, rethinking about the @roiex proposal (of inverting AND and OR behaviourally from your current fomula), and letting aside all my additional suggestions, keeping as close as feasible to your formulation, as long as there is a count equal to 1 thereafter, I think the options in the same one may be logically understood in a OR relationship, as @roiex tends to see them anyway:

What the above would logically mean is that:

You need at least 1 of germanRail or russianRail (OR)
You need at least 1 of germanDepot or russianDepot (OR)
You need both the above (AND)

I believe that, logically and for consistency with most, if not all, the default count should be equal to the sum; thus if you have only:

Without any count, that would be an "AND" relationship (the assigned count would be equal to 2, in this case). You can assure the "OR" by setting the count equal to "1" and, moreover, this different formulation of mine would expand on what you can do, as you would be also able to set intermediate values; like if you have 4 units in the option, you can set the count also at 2 or 3, not only as 1 (OR) or 4 (AND).

I also believe that the "owned/allied" only, or whatever the like, restriction is redundant, and you should rather allow all units, comprising neutral (I mean the relationship) and enemy ones, to allow movement. Meaning you would be allowed to move into an enemy territory, if there are the required units (in the specific case, an enemy "rail" would allow "train" to move into, as long as the starting territory has a, likely owned, "rail" too), albeit enemy owned. This may make some sense for trains, depending on the scope of the map, as the enemy railways were captured and used to move your own trains to aid in your offensive, right in the days after it starts (so, you may have the trains as infrastructures giving an offensive support to other units; artillery comes to mind).
The above would be purely extensive (limiting it to owned and allied only is a redundant limitation), as the mapmakers that prefer trains (or whatever) to not jump on the enemy, in any case, can easily assure it by having, either:

Of the two above, the first one would factually enforce the same thing as your current (unnecessary) behaviour of excluding enemy units from the requirement. I normally suggest using it, for aaGuns and the like as well, instead of totally disabling combat movement, also as making more sense and being more user friendly.