Expand givesMovement Option To Require Specific Units At Destination

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

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,