Expand givesMovement Option To Require Specific Units At Destination

General_Zod

@redrum This will also allow them to move 3 surface sz if they wanted too. Assuming they start in a uw-sz. Unless I'm misunderstanding what your saying.

redrum

@general_zod I'm saying moving from an underwater SZ to surface SZ would cost 2 movement so they could only move 2 then. If they start in a surface SZ then they don't get the extra +1 movement so can only move 2.

prastle

@general_zod cor gz
thus subs need a 1 underwater movement and two at surface
thus my ? about three?

General_Zod

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

@general_zod I'm saying moving from an underwater SZ to surface SZ would cost 2 movement so they could only move 2 then. If they start in a surface SZ then they don't get the extra +1 movement so can only move 2.

@redrum Ah I see where the confusion is. It does not cost 2 movement to go from uw-sz to surface sz, only 1 movement. Thus your idea does in fact allows movement of 3 to either.

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

@general_zod cor gz
thus subs need a 1 underwater movement and two at surface
thus my ? about three?

@prastle However technically, each uw-sz is under the surface sz. This means they are not really moving faster or further if they had 3 movement points between uw-sz's, only. But you are correct they would in real life move faster on surface. But I think subs might be overpowered if I let them. They are already hard to kill and can lurk for whole game, or tie down allied vessel for convoy duty. Without any tech only a depth charge can kill a sub if it's underwater and they are suicide, so 1 try and they done.

redrum

@general_zod I mean if you make it cost 2 movement by having an extra invisible SZ between the uw-sz and surface sz. That then means they move 3 underwater but only 2 if they surface.

General_Zod

@redrum I see what you mean, I reread above. I read it so quickly and thought you meant an invisible land territory for a navalBase attribute. Since that was my initial plan, since navalBase won't work off land.

redrum

@general_zod Yeah, I'm approaching it from more of a "movement cost" perspective where you could treat surfacing as costing more movement then moving between underwater sea zones. Somewhat of a different take on it but you end up with similar behavior.

Cernel

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

@general_zod I mean if you make it cost 2 movement by having an extra invisible SZ between the uw-sz and surface sz. That then means they move 3 underwater but only 2 if they surface.

Or maybe having a canal option for consuming additional movement points when/for passing through (if not excluded).:upside-down_face:

General_Zod

@redrum Is it possible to at least get an option added that will allow selection of which units get the bonus movement from the "navalBase" territoryAttachment property? Just like "givesMovement" does. This will at least allow me to have my rules engine enforced.

This is a very cool feature, just lacks this functionality.

Or I wonder if it make more sense to alter "givesMovement" to get more control. So it can pick which territories for start points and end points. As well which phase it will function during, although this last piece can be done with triggers too.

General_Zod

@redrum Hmm, thinking it through more. Adding the unit selection to "navalBase" will not resolve it for me.

Although adding functionality to "givesMovement" should.

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"/>