Expand givesMovement Option To Require Specific Units At Destination

Hepps

@hepps Really what I am trying to say is you are trying to manipulate the code to accommodate a hack.

Now, while conceptually I love the idea of what you are going for... I feel like a broader view is the better approach.

A) Like... what are the underlying factors in the engine that are causing me to go to these extremes for a solution?

B ) In lieu of of these extremes what changes to the engine would allow for a behavior that achieves similar results?

OR...

If a departure to the existing behaviors is warranted....

How can this be expanded to encompass all land/Sea/Air behaviors uniformly.
How do these improvements / changes impact compatibility?

redrum

Alright so trying to think about this in a reusable way that is fairly simple from an XML standpoint, what about just adding a 3rd parameter to the unit option "givesMovement" to indicate it only works if "X" unit is at the final destination of the units route?

Sea Example (surface ships but not subs get +1 move between harbors)

<attachment name="unitAttachment" attachTo="harbor" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="givesMovement" value="1:transport:harbor"/>
      <option name="givesMovement" value="1:destroyer:harbor"/>
      <option name="givesMovement" value="1:battleship:harbor"/>

Material Example (can only move materials from harbor on to transport)

<attachment name="unitAttachment" attachTo="harbor" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="givesMovement" value="1:material:transport"/>

General_Zod

@hepps Well yes, but I think most feature request are born of necessity to ones plans. I am just trying to keep my requests simple in the end , so they get implemented. But I would love to see bigger improvements that encompass more.

Hepps

@general_zod I get it. I am not trying to be a dock. Just trying to underscore that some of the ideas you have are work-arounds for some very concerning underlying issues with mechanics. If we focused on those underlying issues... we could create a far more versatile engine.

General_Zod

@redrum Nice idea. I think that does it. The NCM component should be doable by triggers so it simulates navalBase nicely once that is added.

General_Zod

@hepps And you get a fix too,

Hepps

@general_zod This is why I like to paint @redrum into a corner.

General_Zod

@redrum Question, does disabling the end point unit via sbr cancel the +movements for this attachment. Also I am assuming that disabling the start point unit still will. Is that a correct assumption?

redrum

@general_zod That's what I was thinking. Essentially try to build off of what givesMovement already does and include the checks to ensure the start and end units aren't disabled by damage for it to work.

Hepps

@redrum That is a nice addition to the feature.

Hepps

@general_zod I applaud the creativity this inspired.... For those about to submerge... we salute you!

redrum

@hepps Now if only we can find someone to implement it

Hepps

@redrum Good help is hard to find.

General_Zod

@redrum I'm currently working out the details for my German SubPens. I just wanted to confirm how this feature will function. So my main question at the moment is.

Regarding the unit that will give the + movements to other units. If this unit is giving + movement to sea units, can the giving unit be on land and or sea? I assume either but wanted to make sure. Also I should probably ask for starting point units and end point units to be clear.

redrum

@general_zod Yeah, it'll work like givesMovement already works today in terms of it the unit that is giving movement is a land unit and you specify to give it to sea units then it checks adjacent sea territories (port, etc). My intention would be for the end point to work the same way.

General_Zod

@redrum cool

redrum

I added this to the feature list. It will require a non-compatible release but should start working on one once we stabilize the bots.

Cernel

@redrum said in "isNavalBase" For "unitAttachments":

Material Example (can only move materials from harbor on to transport)

<attachment name="unitAttachment" attachTo="harbor" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="givesMovement" value="1:material:transport"/>

Yep, this is really a problem when you have, like, a game in which, instead of having the PUs collection, you have to go take the resources with your transports and such, that is, after all what the Battle of the Atlantic was for. A limit of the basic games is that, like, in the moment you have your British that collect all their PUs wherever, no questions asked, that takes away the very basics of why the Germans even produced 1 submarine. But currently there is the issue that if you have stuff you can move with transports or trains you need it to have at least 1 movement to get into the transports, but actually you don't want your raw materials to be able to walk on their own (so you would have them 0 movement and move them around with trains and lorries). Now that canals don't block transported, you could make canals in all land to land connections, to enforce that, but this sounds definitely easier. Tho I still believe doing it this way feels off the mark, and I think really (a bit of off topic here) movement 0 units should be generally allowed to move to transports if they have a transport cost assigned (and, of course, always selectable if they have a transport cost assigned); basically make moving from land to sea generally cost 0 movement points, instead of 1, yet charging unitary fuel cost when from land to sea (you would still lose all remaining movement, like now it happens for 2+ movement units; so no difference for any basic games). This would seem the most straight way, since anyways units not having a transport cost defined in the attachment are unable to load on transports; so no reasons to require them having 1+ movement to do it, as you already decide it in the moment you define a transport cost for them (and default is that they cannot load, so you'll still be unable to load NWO bunkers on transports).

Also, another item for ships is that (at least when not damaged) they never need to go back to ports, while actually ships worked sort of like aeroplanes, in that you would have to "fly" off from your port and "land" back to it after a period; tho of course this is a matter of weeks rather than hours. I can see this new options can go a fair way to partially enforce that behaviour, tho still it doesn't oblige you to have to go back to port to be able to fight again, even in the same sea zone. So it doesn't fully solve the matter here.

General_Zod

I think this topic should be renamed "Expand givesMovement Option" so people immediately know what this is doing. The topic has evolved into something much more useful than originally proposed.

redrum

@general_zod Yeah, renamed it. Good call.