@frostion I see what you are getting at though I'm fairly hesitant to create a bunch of properties that allow lots of different behaviors for suicide units and even if we did want more flexibility then I start to think different unit properties might be better than global properties so you could have different functionality for say kamikaze planes vs ammo units on the same map.

Here are a few additional things you probably need to consider in the 'strike one at a time' situation:

How does it work with LL? How is order of suicide units rolls determined if there are different types of suicide units (attacking with say kamikaze and ammo units in the same battle)? Weakest rolls first? Strongest rolls first? Tie breaker? Essentially, you need a sense of ordering of the suicide units. Need to consider 'isSuicide' vs 'isSuicideOnHit' and whether they both would use the property as well as ordering.

As you can probably see from these questions, this gets a bit complex fairly quickly which is probably the primary reason it works as it does currently.

@Mahks I believe just about all delegates are optional though at some point you wouldn't really have much of a game without at least some sort of move and battle delegates. I'm not sure if you can leave out the InitializationDelegate as I can't remember exactly what that does and if you can create a map without it. That might be the only 1 that is absolutely required though it would be hard to have a playable map without at least a few of the others.

@general_zod Yeah, its something I've always wanted to add. Though you can kind of simulate it using 'createsUnitList' to generate suicide units and remove them if they aren't used. But that is a bit hacky overall.

@mahks

Correct.

@mahks said in non-combat unit:

destroyedWhenCapturedBy Comment: is a list of the players who destroy this non-combat unit instead of capturing it. all non-combat units are normally captured by default...

On Entering Units Destroyed Instead Of Captured Comment: Does not affect non-combat units...

In above cases non-combat =isInfrastructure ?

@mahks

Rockets have a set of options available specific to isRocket as well. Part of techAbilityAttachment's.

rocketDiceNumber
rocketDistance
rocketNumberPerTerritory

There are properties associated with rockets and SBR in production and damage related unitAttachment's as well. Also some in propertyList.

Essentially they are SBR units.

@mahks I see the comment in POS2 XML you are referring to and yeah that is incorrect. I went ahead and removed it: https://github.com/triplea-maps/the_pact_of_steel/pull/9/files

The comments before the unit attachments are correct: https://github.com/triplea-maps/the_pact_of_steel/blob/master/map/games/pact_of_steel_2.xml#L1707

ron-murhammer created this issue in triplea-maps/the_pact_of_steel closed Remove incorrect comment #9

Generally, isCombatTransport makes it so the transport is treated like a normal ship is most/all circumstances that involve battles/movement instead of like transports. Even looking through the code would be difficult to determine exactly which properties it affects and would take some time.

Never mind, I was confused. - resolved

@mahks All those should be changed to PUs. I'm not sure where they are still present anymore? Anyways, IPCs is the old way PUs were called, and just so they happen to also be the "money" of a known boardgame, and the change to "Production Units" (PUs) has been made because of copyright concerns over "Industria Production Certificates". I'm not sure if PCs is just forgetting the "I" or intended, but it is surely not currently in use.

@mahks

This unitAttachment dictates if a unit can die when max damage reached.

canDieFromReachingMaxDamage values: means that if this unit reaches its maxDamage, then it will die. maxDamage must be larger than zero

Hopefully someday PUs will be “just another resource”, meaning that any resource specified as being used in the XML/map will be handled on equal terms, and PUs will not be more game engine supported than for example Gold, Credits, Dollars etc.

Right now the AI seems to calculate a lot based on PUs, the TUV is probably just PU based and the Actions and Operations can only handle PUs. Because of this dependency on PUs, a map like Star Trek uses PUs as the science resource. Even though it is referred to as “Science” is actually just PUs, as this is the only way to have tech rolls working.

If this is to change some day, monetary units would not be the same as PUs.

@mahks

Yep my bad, I saw some without links, then I looked deeper into and see your on top of it. Nice!