"createsUnitsList" Placement Logic



  • I've been experimenting with certain unit properties for a project of mine, and I have a sea unit with this unitAttachment option:

    <option name="createsUnitsList" value="1:some_unit"/>

    The unit created is a land unit, and is placed in a land territory connected to the sea zone where the creating unit is. There are 5 different land territories that connect to the sea zone, but the land unit is always produced in the same territory. I am interested to know what logic determines where this unit is placed. Does anyone else have any experience with this or knowledge of how this logic works?


  • Admin

    @theredbaron Nope. Honestly, if you asked if you could set that on a sea unit to produce land units then I would have guessed it wouldn't work at all 🙂

    I assume if there are no adjacent land units then it doesn't produce any? I think the selection of land territory is probably either 1. random (but consistent) or 2. (based on ordering of land territories in the XML). I can eventually look at the code when I have some time to shed more light on it.

    Can you describe your use case in a bit more detail on what type of sea unit and land unit we are dealing with and in your mind the ideal behavior. I also wonder if any other map has implemented this and if not then we could consider tweaking it.



  • @redrum I just tested it out, and you are correct, with no adjacent land territory, no land unit is produced (and there is also no console output).

    As for my use case, there are several. The primary use case I had in mind was offshore oil drilling, which was historically begun in 1946, which would work for some WWII-era scenarios. My drill platform was creating oil units that could then be used to produce other units. Another use case I had thought of was an Age of Discovery-era "explorer ship" that offloaded "outposts" to territories it came into contact with.

    I'd like to note that the behavior is the same if the unit with "createsUnitsList" is a land unit and the created unit is a sea unit. This setup (which I should have mentioned) has infinitely more use cases, from shipyards to land-based minelayers.

    My ideal behavior would be allowing the user to choose, just like with regular placement. Any other option would not be worth the effort to code, IMO, as it would still be random and unhelpful from the user's viewpoint.


  • Admin

    @theredbaron
    Interesting. I would also guess it's either based on the sequencial parsing order of the involved land territoryAttachments as placed in the xml, or maybe an alphanumerical order. Also I wonder if placing the related conditions and triggers in different sequences within the AttachmenList would affect it.

    Post back if you figure it out.



  • @General_Zod My guess is that it is based on the order of the territories in the XML, as that is how it has been so far in my tests.

    0_1523829961672_shipbuilder_example.png

    In this example using POS2, I had a "shipbuilder" (the unit with the naval base icon that creates transports) in Sardinia and Greece at the end of Italy's turn, two territories that each touch two sea zones. The shipbuilder in Sardinia had the option of creating a transport in 13 Sea Zone or 14 Sea Zone. It picked 13 Sea Zone presumably based on the order in the territory definitions. This mostly arbitrary decision puts the new transport placed by Sardinia's shipbuilder in harm's way (in an enemy-controlled sea zone). The transport placed by Greece's shipbuilder follows suit, choosing 14 Sea Zone over 15B Sea Zone.


  • Admin

    @theredbaron Yeah, my gut says the property was never really fully flushed out for creating land from sea or sea from land and the way it works was an after thought. Probably to make it really usable, we'd need to add an option to allow the user to select which territory to place the units. Could be a good feature request.


  • Admin

    One other thing to consider would be if this projected placement would be allowed to be done into enemy held territories, or if it was only into neutral and friendly. If it was to work for age of exploration outposts being placed from ships, then I guess it should not be limited to friendly territories. 🤔



  • @Frostion That would follow the same logic as being able to have a AOT-style mortar producing bombardments in a contested territory. That's part of the beauty and flexibility of "createsUnitsList."


  • Admin

    @theredbaron Yes, in AoT it is nice that the mortars and missile launchers (MLRSs) can generate their ammo in contested territories / unresolved battles. I don't hope this changes 😁


  • Admin

    So I took a quick look at the actual code and it does the following:

    1. land adding unit to sea - adds sea units to random adjacent sea territory
    2. sea adding unit to land - adds land units to random adjacent land territory owned by the current player

    If none are found then it doesn't place the units. Both appear to be completely random in selection of the territory and could change each round but all units generated from a given territory are then placed in the same adjacent territory for that round (doesn't split them up if placing multiple).

    Code logic is here in case anyone wants to check it out: https://github.com/triplea-game/triplea/blob/master/game-core/src/main/java/games/strategy/triplea/delegate/EndTurnDelegate.java#L110



  • @redrum That's interesting to know. Random I think is better than based on the ordering in the XML, though still not ideal. So I'd say the takeaway is that using this feature is playable, if not perfect. To you and the other devs, I won't push this too hard as there isn't currently a map that uses this. Once I have (or anyone else has) a map in the later stages of development that uses a system like this, we can ask for a more nuanced placement system to be implemented. Thanks for the info.


  • Admin

    @theredbaron Yep, that's the general approach I like to take as otherwise I end up spending time making changes that might never get used 🙂 But it should be relatively easy to replace the existing logic with something a bit less random.