Zero movement cost to enter transports.



  • Right now it cost 1 movement for a land unit to enter a water zone for transport. Thus a 0 movement unit needs to be given movement before it can be transported which takes away all of it movement.

    Cheers...


  • Admin

    @wc_sumpton what would you propose be different to address this situation?



  • @LaFayette

    I'm not sure I understand what you are asking? If you are asking how I would do this? I would use the existing 'unitHasEnoughMovementForRoute' and add the following lines:

    //Should be no movement cost for a land unit to enter a water territory for transport,
    //or leave transport in water to enter a land territory
    if ((route.getStart().isWater() != route.getEnd().isWater()) && !ua.getIsSea() && !ua.getIsAir()) {
       left = left.add(BigDecimal.ONE);
    }
    

    The first two line are comments. Then check for isWater does not equal isWater (one zone has to be isWater and the other zone is not isWater) and if the unit attachments make the unit land only (not isAir and not isSea). If this is true then give the unit one movement to enter the or leave the water zone.

    I'm hoping this explains what I was thinking.

    Cheers...


  • Admin

    I'm just not really clear on what you're proposing, or what the problem is.

    If a zero movement unit is loaded onto a transport, wouldn't it need to be granted movement to be offloaded?

    Would there be a way to distinguish a unit that simply should not move vs one that could be transported?

    Which maps have zero unit movements, are there any that would need to have this rule be turned off? Which maps would stand to benefit?


  • Moderators Admin

    @LaFayette said in Zero movement cost to enter transports.:

    I'm just not really clear on what you're proposing, or what the problem is.

    If a zero movement unit is loaded onto a transport, wouldn't it need to be granted movement to be offloaded?

    No. Units should be able to offload regardless of their mobility value.

    Would there be a way to distinguish a unit that simply should not move vs one that could be transported?

    The one that simply should not move has no transport cost, as well as mobility 0, while the one that can be transported has transport cost of 0 or more (while possibly mobility 0).

    Which maps have zero unit movements, are there any that would need to have this rule be turned off? Which maps would stand to benefit?

    I think that movement 0 transportable land units should be loadable on sea transports (without special requirements). However, I also believe this would need an option for charging additional fuel cost for moving into a hostile territory (so that loading and offloading an armour into combat, for example, doesn't become fuel free for the armour (the armour is not just being offloaded on the beaches, but it is going to move within the land territory to make combat)). A feature for fuel cost to go in combat would be likely valuable on its own.

    A map upon which such feature may impact is @Hepps "Total World War". Beside this, I don't think that changing this behaviour (allowing mobility 0 units with transport cost to load on their own) is going to be much of a risk for anything.



  • @Cernel

    Thank you.

    Cheers...


  • Admin

    @Cernel

    No. Units should be able to offload regardless of their mobility value.

    This appears to be right, I just checked for movement point validation and there is none for the transported units. The only checks are on where the units are being offloaded and other checks around the transport itself and surrounding territories.

    The one that simply should not move has no transport cost, as well as mobility 0, while the one that can be transported has transport cost of 0 or more (while possibly mobility 0).

    Likely we'd want to set a very high transport cost rather than zero. Zero could mean infinite capacity.


  • Moderators Admin

    @LaFayette said in Zero movement cost to enter transports.:

    The one that simply should not move has no transport cost, as well as mobility 0, while the one that can be transported has transport cost of 0 or more (while possibly mobility 0).

    Likely we'd want to set a very high transport cost rather than zero. Zero could mean infinite capacity.

    As far as I know, transport cost 0 means that the unit can be transported at cost 0 (and I believe this is a correct behaviour).



  • @LaFayette said in Zero movement cost to enter transports.:

    This appears to be right, I just checked for movement point validation and there is none for the transported units. The only checks are on where the units are being offloaded and other checks around the transport itself and surrounding territories.

    Zero movement units can be unloaded so this is unneeded:

    <attachment name="unitAttachment" attachTo="germanTransport" javaClass="UnitAttachment" type="unitType">
       <option name="movement" value="2"/>
       <option name="attack" value="0"/>
       <option name="defense" value="1"/>
       <option name="transportCapacity" value="5"/>
       <option name="isSea" value="true"/>
       <!-- Below not needed to unload 0 movement units -->
       <option name="givesMovement" value="1:germanAntiAirGun"/>
       <option name="givesMovement" value="1:japaneseAntiAirGun"/>
       <option name="givesMovement" value="1:italianAntiAirGun"/>	  
       <option name="givesMovement" value="1:spanishAntiAirGun"/>
       <option name="givesMovement" value="1:swedishAntiAirGun"/>
       <option name="givesMovement" value="1:brazilianAntiAirGun"/>
       <option name="givesMovement" value="1:turkishAntiAirGun"/>
       <option name="givesMovement" value="1:Material"/>
       <!-- Above not needed to unload 0 movement units -->
       <option name="requiresUnits" value="germanDocks"/>
       <option name="canBeGivenByTerritoryTo" value="Germany"/>
    </attachment>
    

    But the reverse in not true so this is still needed:

    <attachment name="unitAttachment" attachTo="germanDocks" javaClass="UnitAttachment" type="unitType">
       <option name="isInfrastructure" value="true"/>
       <option name="canBeDamaged" value="true"/>
       <option name="maxDamage" value="12"/>
       <option name="maxOperationalDamage" value="8"/>
       <option name="canDieFromReachingMaxDamage" value="true"/>
       <option name="movement" value="0"/>
       <option name="attack" value="0"/>
       <option name="defense" value="0"/>
       <!-- Below is still needed to load 0 movement units -->
       <option name="givesMovement" value="1:germanAntiAirGun"/>
       <option name="givesMovement" value="1:japaneseAntiAirGun"/>
       <option name="givesMovement" value="1:italianAntiAirGun"/>
       <option name="givesMovement" value="1:spanishAntiAirGun"/>
       <option name="givesMovement" value="1:swedishAntiAirGun"/>
       <option name="givesMovement" value="1:brazilianAntiAirGun"/>
       <option name="givesMovement" value="1:turkishAntiAirGun"/>
       <option name="givesMovement" value="1:Material"/>
       <!-- Above still needed to load 0 movement units -->
       <option name="repairsUnits" value="vichyBattleship-damaged:germanBattleship-damaged:germanCarrier-damaged:russianBattleship-damaged:russianCarrier-damaged:italianBattleship-damaged:italianCarrier-damaged:britishBattleship-damaged:britishCarrier-damaged:japaneseBattleship-damaged:japaneseCarrier-damaged:americanBattleship-damaged:americanCarrier-damaged"/>
       <option name="isConstruction" value="true"/>
       <option name="constructionType" value="dProduction"/>
       <option name="constructionsPerTerrPerTypePerTurn" value="1"/>
       <option name="maxConstructionsPerTypePerTerr" value="1"/>
       <option name="consumesUnits" value="2:Material"/>
       <option name="requiresUnits" value="germanCombatEngineer"/>
       <option name="canOnlyBePlacedInTerritoryValuedAtX" value="2"/>
       <option name="whenCapturedChangesInto" value="any:any:false:Material:1"/>
    </attachment>
    

    All I'm saying is that both should not be needed. 0 movement units which have a transportCost > -1 should be allowed to load onto a transport without givesMovement.

    Cheers...


  • Admin

    @Cernel you stated:

    The one that simply should not move has no transport cost, as well as mobility 0, while the one that can be transported has transport cost of 0 or more (while possibly mobility 0).

    I raised the problem that would allow a transport to carry an infinite number of those units. That seems like a problem, so the rule of 'zero movement and zero transport' cost means you can load onto a transport.


  • Admin

    This is an odd rule to have, if a unit cannot move, then why should it be able to be moved by transport? Are we thinking of something like 'land transports' (EG: trains) that should be allowed to make a unit move? If so, are we not already in a realm where it's appropriate for bonus movement to be granted? I mean, isn't that exactly what we want?


  • Moderators Admin

    @LaFayette said in Zero movement cost to enter transports.:

    @Cernel you stated:

    The one that simply should not move has no transport cost, as well as mobility 0, while the one that can be transported has transport cost of 0 or more (while possibly mobility 0).

    I raised the problem that would allow a transport to carry an infinite number of those units. That seems like a problem, so the rule of 'zero movement and zero transport' cost means you can load onto a transport.

    As I said, I believe that a unit having transport cost 0 should be transportable in infinite numbers, without reducing the remaining capacity of the transport. This also means that a transport with capacity 0 should be able to transport an infinite number of units with transport cost 0.

    I also believe this is the current way the program behaves, which, I think, is good.

    So, yes, by allowing for mobility 0 units to load onto transports, the rest being the same as now, a "zero movement and zero transport cost" unit would be able to being loaded in infinite numbers onto any transport of capacity 0 or more.


  • Admin

    @Cernel said in Zero movement cost to enter transports.:

    As I said, I believe that a unit having transport cost 0 should be transportable in infinite numbers, without reducing the remaining capacity of the transport. This also means that a transport with capacity 0 should be able to transport an infinite number of units with transport cost 0.

    I agree, but I think that goes bad if transport cost and movement become related. The two should be completely independent attributes. Hence I do not agree that if a unit has zero movement, and zero transport cost, that it should magically be able to move onto transports. If a unit has zero movement, it has zero movement.

    Perhaps there is another property we can introduce here to help this. On the other hand, I would tend to think a unit providing another unit movement so it can be loaded on transport perhaps is the good way to do that.


  • Moderators Admin

    @Panther Do you think that a mobility 0 unit that can be loaded onto a transport can be actually loaded onto the transport or is the mobility 0 making this impossible unless something gives a mobility bonus to the unit?

    I know that all units that are transportable have mobility 1 or more in the basic games. So, for example, I'm saying how about if I change the infantry mobility to 0, rest the same.


  • Moderators Admin

    In any case, since it is disputable if movement 0 units should be able to load by themselves, and especially since in games using fuel costs this may be an unwanted way of moving units (also into combat) without using fuel, I strongly suggest updating the feature proposal with a property that determines whether a positive movement ability is needed for loading.


  • Admin

    Perhaps we can create an option for this kind of rule? Something like "canBeTransported". Maybe we'd want it to reference the units that could provide transportation, eg "canBeTransportedBy".

    This would allow for transport cost to be non-zero and vary between different 0 movement units on the same map. This would also allow for the movement attribute to be independent of this potential transportation flag.



  • <!-- A zero movement unit with the ability to be moved by transports -->
    <attachment name="unitAttachment" attachTo="Material" javaClass="UnitAttachment" type="unitType">
       <option name="movement" value="0"/> <!-- Has no movement -->
       <option name="attack" value="0"/>
       <option name="defense" value="0"/>
       <option name="transportCost" value="2"/> <!-- Cost of unit to be transported by isLandTransport Units, isAirTransportUnits, -->
       <!-- and isSea Units with a transportCapacity equal to or greater then 2 -->
       <option name="canBeDamaged" value="true"/>
       <option name="maxDamage" value="1"/>
       <option name="canDieFromReachingMaxDamage" value="true"/>
       <option name="isAAmovement" value="true"/>
       <option name="isLandTransportable" value="true"/> <!-- Can be transported by isLandTransport Units -->
       <option name="isInfrastructure" value="true"/>
       <option name="isAirTransportable" value="true"/> <!-- Can be transported by isAirTransport Units -->
       <option name="canBeGivenByTerritoryTo" value="Germany:Britain:Japan:Australia:Canada:DanubeAxis:Egypt:Finland:India:Manchuria:SouthAfrica:Thailand:VichyFrance:ExiledAllies"/>
       <option name="requiresUnits" value="germanFactory"/>
       <option name="requiresUnits" value="russianFactory"/>
       <option name="requiresUnits" value="japaneseFactory"/>
       <option name="requiresUnits" value="chineseFactory"/>
       <option name="requiresUnits" value="britishFactory"/>
       <option name="requiresUnits" value="italianFactory"/>
       <option name="requiresUnits" value="americanFactory"/>
       <option name="requiresUnits" value="spanishFactory"/>
       <option name="requiresUnits" value="swedishFactory"/>
       <option name="requiresUnits" value="turkishFactory"/>
       <option name="requiresUnits" value="brazilianFactory"/>
    </attachment>
    
    <!-- A zero movement unit with no ability to be transported -->
    <attachment name="unitAttachment" attachTo="germanFactory" javaClass="UnitAttachment" type="unitType">
       <option name="isInfrastructure" value="true"/>
       <option name="canBeDamaged" value="true"/>
       <option name="maxDamage" value="12"/>
       <option name="maxOperationalDamage" value="8"/>
       <option name="movement" value="0"/> <!-- Has no movement -->
       <option name="attack" value="0"/>
       <option name="defense" value="0"/>
       <option name="repairsUnits" value="germanHeavyTank-damaged:italianHeavyTank-damaged:japaneseHeavyTank-damaged"/>
       <option name="isConstruction" value="true"/>
       <option name="constructionType" value="fProduction"/>
       <option name="constructionsPerTerrPerTypePerTurn" value="1"/>
       <option name="maxConstructionsPerTypePerTerr" value="1"/>
       <option name="canDieFromReachingMaxDamage" value="true"/>
       <option name="consumesUnits" value="2:Material"/>
       <option name="requiresUnits" value="germanCombatEngineer"/>
       <option name="canOnlyBePlacedInTerritoryValuedAtX" value="2"/>
       <option name="whenCapturedChangesInto" value="any:any:false:Material:1"/>
    </attachment>
    

    The different 'Material' has 'transportCost', 'isLandTransportable' and 'isAirTransportable' while the 'germanFactory' does not.

    Having a 'transportCost' I think should allow that unit to be transportable. For the 'Material' to be transported by a isLandTransport or isAirTransport unit no additional changes need to be made. But for isSea transport, by a unit that has the transportCapacity, 'Material' can be transported, and unloaded, but can not be loaded without some additional help.

    I do think there are enough options already to distinguish between a '0 movement unit' that has movement abilities, and a '0 movement unit' that has no movement abilities.

    As to 'Fuel' cost for loading or unloading from an isSea transport, that I think should be a different topic for discussion. Also what to do about '0 transportCost' '0 transportCapacity' units should be it own topic. The topic here is about the loading of '0 movement' units onto a isSea transport.

    Cheers...


  • Admin

    Okay, so you're proposing that if a unit has any kind of a transport cost defined at all, then they should be transportable.

    That sounds simple enough and makes sense. If there is an option to define a transport cost, and so long as it's clear that 0 means infinite capacity, then it makes sense that that transport cost was defined because the unit should be transportable.

    @wc_sumpton are you able to determine which maps this could impact and if those maps would have to be updated? I believe you mentioned TWW, let me know if you could use help finding others.


  • Moderators Admin

    @Cernel said in Zero movement cost to enter transports.:

    @Panther Do you think that a mobility 0 unit that can be loaded onto a transport can be actually loaded onto the transport or is the mobility 0 making this impossible unless something gives a mobility bonus to the unit?

    I know that all units that are transportable have mobility 1 or more in the basic games. So, for example, I'm saying how about if I change the infantry mobility to 0, rest the same.

    The rules say that loading/offloading of a unit counts as the unit's entire move. Moving requires movement points. So I would conclude that a unit with "movement 0" can't move at all (unless - as you say - it receives a mobility bonus by whatever) . How would an infantry with "movement 0" physically move onto a transport?

    What we are talking about here is nothing else than moving a unit from a territory to a seazone and/or vice versa!

    I can't see how this could be allowed while movement between territories would be denied because of "movement 0"
    (again: unless - as you say - the unit receives a mobility bonus by whatever).



  • @LaFayette

    TWW is one. If there are others then I have not found them. Thank you for your help.

    @Panther thank you for commenting.

    Cheers...


Log in to reply