Add "canSubmerge" and "mustSubmerge" Unit Attributes
Currently "isSub" unit attribute controls a number of different functions including submerging, not blocking other ships, and allowing subs to move through other ships.
Look to separate out "canSubmerge" so sea units can be allowed to submerge without requiring the other sub functions and add "mustSubmerge" so units must submerge first chance they get.
alkexr last edited by
@redrum I would go one step further and create three different abstract properties for not blocking movement, not being blocked, and submerging, not restricted to sea units only. Also add the option to customize the captions appearing on the dialog box asking whether to remain or submerge. Wait, that was like three steps further, never mind. I won't publish my whole wishlist for now, then
@alkexr Yeah, that is the eventual vision but given the code complexity around sub logic, the most reasonable approach is to implement one at a time. I figure submerge is probably the most interesting of the sub functions so would start with that.
@redrum Baby steps... wins the day!
It would be very nice to give the player the option to submerge or surface each submarine during CM or NCM via a prompt, something like.
Issue Orders To This Submarine. "Submerge" or "Surface" (when clicked on the submarine).
Depending on the orders, the submarine behavior could be different. Up until the owners nations next turn.
For instance, if the submarine was given orders to remain on surface. It can block all other surface ships from moving through its sea zone and stop transports from loading or unloading unless it is killed. And actually control a sea zone. Basically if surfaced it would get to act like any other combat surface vessel.
However this would come at the price of losing its 1st strike and stealth abilities, making it vulnerable to all attacks by air and sea, maybe even from land if AOT style mortars (or some other cool land based range weapon). And no destroyer should be needed as well. Perhaps the surfaced submarine could even suffer further attack/defend penalties of -1.
And if orders are to submerge it retains all normal submarine abilities.
This would make submarines more versatile as well as realistic. The extra ability could be offset by a slight cost increase to produce if needed. Or just go with the penalties mentioned as an offset. Depends on the map design ultimately.
While on topic of submarine, the destroyer anti stealth ability should really only work on a 1:1 basis. One destroyer can cancel one submarines stealth. Even if we think of each single submarine or destroyer as a wolf-pack or a task-force of several vessels each. A 1:1 ratio still makes most sense.
I know one of the hurdles is to keep existing maps functional, so maybe simply introducing it as for a new unit. That way can leave all existing maps functional and leave it up to the map makers if they want to recode with the new improved option or keep as is. Just a thought.
Furthermore, what would be really awesome, is if the xml AA options could be expanded, enhanced and used as the foundation of all unit options . Those options could be used much more creatively. That would increase TripleA's potential more than any other single project if done with a master plan for all units. But that's a new topic.
@general_zod I'd probably argue that a different mechanic around transforming the unit to a different type is a better fit for something like this instead of a specific submerge/surface function. That way you could have completely different stats and such for when its submerged vs surfaced.
Ok , changing the unit into a different unit altogether is reasonable. But then we have to figure out, how the player would be able to initiate the change, between a specific "normal submarine" and "surface submarine" in any given sea zone?
Short of a function per se, it would require some finagling with sea zone design, maybe by creating an area that the player can park his submarine, which is designated as surfaced or submerged sea zone for submarines. I'll have to think this through further, sounds like it can have other implications, if it is even possible to do in a logical design.