One clear example how the AI behaves when it comes to purchase.
Germany can build 2 air units from start:
For the matter of simplicity, i only state the most important values (attack/defense/movement @ cost)
Aircraft A = 2/2/4 @ 9
Aircraft B = 3/3/4 @ 13
In this setup, the AI is purchasing only Aircraft A (dozens of test rounds)
If i either increase A to 10 or decrease B by 1, the AI will only purchase Aircraft B.
The first thing which irritates me is, that the cost difference between those units seems rather high in comparison to land or sea units in my game, but it was needed to get to the tipping point where the AI recognizes that one or the other air unit is best purchase.

Normally i would only up the cost by 2 PUs if a unit gets +1 att/def more. This works ok because the AI will purchase both more or less, but is never totally ignoring a purchase like with those air units i mentioned above.
A couple of land and sea units that AI is purchasing both and never ignore it are the following ones:
Light Tank = 2/2/2 @ 7
Med Tank = 3/3/2 @ 9
and
Destroyer = 2/2/2 @ 12
Cruiser = 3/3/2 @ 14
Those the AI is purchasing both more or less.

Do Air units have different AI purchase code/formula than land/sea units?

Thank you both.

The polygons represent places on the map.
Polygon map showing how it overlays the map.....

@wc_sumpton What a hero, fixed!! 3EFH.gif

How about "appurtenance"?

@beelee

I started a new topic for this discussion.

Cheers...

<property name="Selectable Zero Movement Units"
It seems that this only effects the player?
Example:

<attachment name="unitAttachment" attachTo="Mot.Inf" <option name="attack" value="1"/> <option name="defense" value="2"/> <option name="movement" value="2"/> <option name="canBlitz" value="true"/> <option name="transportCost" value="4"/> <option name="isLandTransport" value="true"/> <option name="createsResourcesList" value="-1:PUs"/>

With above isLandTransport unit, AI is able to pick up below isLandTransportable Unit and move it.

<attachment name="unitAttachment" attachTo="Infantry" <option name="attack" value="1"/> <option name="defense" value="2"/> <option name="movement" value="1"/> <option name="transportCost" value="2"/> <option name="isLandTransportable" value="true"/> <option name="createsResourcesList" value="-1:PUs"/>

But AI seems not be able to pick up following one:

<attachment name="unitAttachment" attachTo="FlaK88" <option name="attack" value="2"/> <option name="defense" value="2"/> <option name="movement" value="0"/> <option name="transportCost" value="3"/> <option name="isLandTransportable" value="true"/> <option name="typeAA" value="AA"/> <option name="attackAA" value="3"/> <option name="maxAAattacks" value="1"/> <option name="mayOverStackAA" value="true"/> <option name="isAAforFlyOverOnly" value="true"/> <option name="createsResourcesList" value="-1:PUs"/>

Seems its only for the player, and at least thats ok as long only the human player has units with movement=0.
But i have a unit which is for all players, so thats problematic as i like to have it at 0 movement while still being transportable by the AI.
Is there something i dont know?

@Zaroph said in Strange AI behaviour making an "impossible" movement over a canal while landing a unit:

Wasnt sure which category to use so posting it here.

https://forums.triplea-game.org/topic/1708/how-to-submit-a-bug-report

@Michael-Hoover You can't limit it directly. There are 2 workarounds.

You can limit the total number of units of the type available You could have the unit producible only at a specific facility with a limited production capacity

@TorpedoA Sorry, nevermind. I haven't tested it and remembered "canNotMoveDuringCombatMove" units would never attack, but, apparently, they do. In this case, I think there is not a clean way to have non-attacking units. However, this issue might be tracking the problem (which might be a regression):
https://github.com/triplea-game/triplea/issues/7167

@wc_sumpton
Nevermind
2.0 has a new XML option canRetreatOnStalemate. We can use that to explicitly allow conscripts an option to retreat on stalemate.

Moved to Map Making.

@TorpedoA yea it's that they'll give scramble ability to other planes now even if a normal AB isn't there.

isAirBase values: allows units with canScramble and requiresAirbaseToIntercept function from a territory with this unit

@LaFayette

I would give YAML a try, gives me a chance to learn something new. (Been trying JAVA, just can't seem to get this old head around it.😧 )

Cheers...

Hi @TorpedoA

If you wanna add as a separate map here is Frostion's guide:

https://docs.google.com/document/d/1FfF7N0srp9QG0_if5D-c1d1Aa1QTttdhxgm1GBh3pI4/edit

@DominicVenditti said in Editing an HML:

The XML file is named the exact same as the original code and its in the exact same place inthe directory as well. Anybody have any clue what I'm missing here? Thanks

You are supposed always to rename the game, when you modify it in any way, unless you intend to update the original, in which case you should upgrade the version number for it. Doing this will also assure you are looking at the right one.

@LaFayette said in Polygon grabber tool issues with islands inside a single territory:

The SZ name in territory is used as part of:

territory click detection relief image breaker center picker placement picker

That list is not fully exhaustive, it gets pretty complex to go down the tree of everything that uses that functionality and then everything that relies on that and so on.. It's a mess that the name of a territory is used at all to determine the territory type, in particular because it is not consistently done in that manner either.

Right, that is why I said "mapmaking utilities aside". So, once you have made the map, the only one of these points that matters is the "territory click detection" one, which is the only one I'm aware of, as well, if that comprises hovering the cursor to get information, as well.

There is a DTD, doc type definition that does enforce which XML entities and properties are allowed.

I was thinking you meant an XML property as opposed to a TripleA <property> tag. In XML, a property is typically a value after a tag, eg: <tag property=123>

When parsing in an enforcing mode the DTD defines which properties are valid and which are not.

Though you are right about property name values. An unrecognized one would go unused. EG: <property name='not-recognized'>

@wc_sumpton actually, adding the techTokens made my earlier approach work (in my first attach .xml file) so no need for triggers!

When a unit checks for repair facilities, it always selects the one where it can get the highest amount of repair, which is technically 0, in this case.

Assuming you are making or modifying a map, moved to Map Making.

If not:
https://forums.triplea-game.org/topic/1708/how-to-submit-a-bug-report