Expand givesMovement Option To Require Specific Units At Destination

redrum

@general_zod So adding a unit list to navalBase is probably pretty easy but seems you realized that doesn't really solve all the problems as then purchasing/upgrading is fairly difficult.

Enhancing givesMovement for units to consider say a list of start territories would be fairly easy. The bigger challenge is the end points as you don't know the end points until you move the unit and the way it works currently it gives the extra movement at the start of the move phase.

General_Zod

@redrum Actually, I can make it work with a unit list added to "navalBase".

Plan would be to swap (trigger) the submarines that end NCM in a uw-sz with a new unit called submerged-submarine. Then I could add the submerged-submarine to the unit list and not the submarine. Once the submerged-submarine ends a turn in a surface sz I can trigger it back into a submarine.

General_Zod

@redrum For the endpoints version I would have to add a big list of end points if you did it that way. But what ever is easiest for you is fine by me.

Hepps

@general_zod Not for not.... but this seems like an overly complex way to deal with submersible subs.

I applaud all endeavors to improve the flexibility of the engine, but this system feels really awkward to begin with and only gets more convoluted the further you look at it.

General_Zod

@hepps From a gameplay standpoint I think it will play well. From a coding standpoint, sure it's complex, but I don't see a better approach that is worth doing. But enlighten me if you have some suggestions to simplify the code.

Hepps

@general_zod Enticing invitation.

I always enjoying watching the act of enlightenment!

General_Zod

@hepps Btw, this isn't just submersible subs. This is getting the Atlantic war more realistic. It will incorporate blockades, convoys, and a feasible strategy for Germany to strangle UK by sea. But I need submersible subs that are realistic to do it right.

I doubt most would invest in sea strategy for Germany if their subs just die or sit in stacks.

However I can be completely wrong too. But I have been planning something like this for sometime and it's getting there. So why not try it.

General_Zod

@hepps I think navalBases function does a decent job in controlling subs movement as to not overpower them. And then they will also simulate shipping lanes for other vessels once a technology for improved sea navigation gets achieved. However there will be a realistic tech model too, completely overhauled and many to pick from, but my plan is to only allow nations to achieve about 5 or 6 maximum for a 15 round game, if they want to be successful. So tuff choices will need to be made.

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