Feature Request: to help players on the purchase screen with maxBuiltPerPlayer errors

[TheDog-GH]

When a xml has maxBuiltPerPlayer it can frustrating for the player when they inadvertently try to purchase more than maxBuiltPerPlayer allows because it resets all their purchases.

One solution would be show how many can be bought, as in the image below;

So a maximum of 2 Wizards and 3 Sorcerers can be can be purchased, the rest are unlimited, to the PU available.
If the red numbers were 0 then, 0 can be purchased.

The discussion is here
https://forums.triplea-game.org/topic/2752/maxbuiltperplayer-error-resets-purchase-ui-was-how-to-limit-the-number-of-units-purchased?_=1621065805932

[butterw]

I have hardcoded some strings in ProductionPanel.java Rule.getPanelComponent() to see where best to display per player unitType counts. IMO the best solution would be improve the max button so that it takes into account maxBuiltPerPlayer (allowedBuild = maxBuilt - currentlyBuilt).

[butterw]

I hacked the ProductionPanel to display currentlyBuilt (at the end of the tooltip) and added allowedBuild = maxBuilt - currentlyBuilt in the label. currentlyBuilt is not that simple to calculate.

[beelee1]

so count:4 is how many are already built ? Even that would be a Huge upgrade. I mentioned this a few years ago, because as we all know, it totally blows when you gotta purchase everything all over again.

[butterw]

Yes and the max button is also working, which means the values should now never be reset.

If maxBuiltPerPlayer isn't used, it would be possible to display the count in the label in place of allowedBuild.
The most difficult part is calculating currentlyBuilt , because the result isn't available directly.

I'm also going to display the max factory production capacity (if applicable).

[Cernelius]

I've no idea how something like "Max Built Allowed" can fit in a tool-tip for users.

Something like that seems like some sort of technical jargon-based information understandable only to persons that already know exactly what "Built" means in the context.

Personally, I would have no idea (or at least no level of certainty) about what it actually means. Some possible interpretations:

• It means that I can purchase at most that many of those units per phase (regardless of how many I already owned at the start of the phase).
• It means that I can purchase at most that many of those units per game (regardless of how many I already owned at the start of it).
• It means that I can own at any given time at most that many of those units (so I can currently purchase those units in any number up to the number equal to the specified number minus the sum of the same units I own on the map and the same units I hold in inventory (typically for having purchased them on a previous round but not placed yet)) (and, in this case, I would also be wondering if the game is already giving me the final number (by already subtracting what I already have) in such tool-tip information or requiring me to count out what I already have on the map myself).
• It means that only up to that number of those units can be purchased across all players during the whole game (For example, in V1 you are supposed to be able to purchase factory units only up to a given number accounting every purchased factory, so any player who buys the latest available factory makes itself and every other player unable to buy any factory for the rest of the game.).

On top of that, I think something like "Built" leaves also unclear whether we are talking of purchasing or placing or both.

[butterw]

The Pos2 description is quite clear, it's not strictly a piece-limit, it just impacts what can can be bought in the produce panel based on the current unit count.

maxBuiltPerPlayer UnitAttachment option
values: is the number of this unit that can be BUILT by a player. If they have fewer than this number they can build more, if they have more than this number they can not build more [this does not cause excess ones to disappear, and the player can still capture more and more of them if they are capturable].

From my testing this is a good option well supported by the engine/AI which puts a hard limit on overstacking. I can see 2 reasons why it isn't currently used much:

• the current frustrating UI.
• the lack of a "Player Production Per Unit Restricted " property to make it an optionnal rule in maps.

[Cernelius]

The Pos2 description is quite clear, it's not strictly a piece-limit, it just impacts what can can be bought in the produce panel based on the current unit count.

maxBuiltPerPlayer UnitAttachment option
values: is the number of this unit that can be BUILT by a player. If they have fewer than this number they can build more, if they have more than this number they can not build more [this does not cause excess ones to disappear, and the player can still capture more and more of them if they are capturable].

In my opinion, the statement "the number of this unit that can be BUILT by a player", assuming "the number" means "the maximum number", "built" means "purchased" and the simple present implies that we are meaning "per phase", actually means that I can purchase at most that many of those units per phase regardless of how many I already owned at the start of the phase. The subsequent statement "If they have fewer than this number they can build more, if they have more than this number they can not build more" is arguably clear enough, but it says nothing about what happens when they have no more and no less than this number (meaning that the "if they have more than this number" part should have been formulated as "if they have this number or more").

On the assumption that the current behaviour is correct, I would say that

is the number of this unit that can be BUILT by a player. If they have fewer than this number they can build more, if they have more than this number they can not build more [this does not cause excess ones to disappear, and the player can still capture more and more of them if they are capturable].

may be better explained as

the number of these units at which or above which no more of them can be purchased by a player if each of the units is owned or purchased by the player.

---

However, the main point I was making is that I believe that the current "Max Built Allowed" description in the automatic tooltips gives scarce information to the casual user and likely is fully understandable only if you exactly know what option this description is referencing and how the option behaves.

[butterw]

• current unit count has been appended to the end of the Production tooltip (which makes the info easy to scan). It has been suggested this info can be useful to plan production.
• the aaGun doesn't have a maxBuilt rule and hence no limit is displayed in the label
• infantry was maxed out using the max button.
• production capacity is displayed in the label at the bottom (if applicable).

My hack moves some previously existing code used for output validation into the ProductionPanel.
This works, but does causes the count values to be calculated twice every time the Produce dialog is displayed, which is undesirable. It should be possible to move the calculation to the PurchasePanel and calculate it there only once per player turn.
To achieve this may require better knowledge of the code and Java.
Getting from gamePlayer+gameData to unitTypes seems a bit troublesome and you would also need to pass the calculated IntegerMap values into the ProductionPanel.

[beelee1]

Can you use "Built" instead of "count" for clarity ? Or is that something that's named in the code that you're using ? Wouldn't be practical to change ?

Nice work 👍

[butterw]

"Count" is just a placeholder, but "Built" isn't clearer in my opinion.
Would "Currently owned" in the tooltip be satisfactory ?

To be clear, the count will only show in the tooltip for the Produce Dialog. showing it in all tooltips would require a different approach.

[beelee1]

Since "Built' is used right above it, I'd go with
"Currently Built" but either would be fine.

Yea, having it in the purchase screen only is plenty. It's where you're doing the actual purchasing, so not needed elsewhere imo. Probably best to save as much space as possible when you can.

[DanVanAtta]

Some thoughts/responses:

• the built terminology could use work as it is a bit confusing. Does built include units that are captured or otherwise granted? I would then lean to something like "(3 of 5 Owned)". I would be tempted to see what that text looks like underneath the unit image rather than an alternative UI treatment.
• the UI controls should prevent invalid selections, the max arrow should then only allow a max build. A similar constraint ought to be applied for PU constraint and if we can, production constraints as well.

[butterw]

the built terminology could use work as it is a bit confusing. Does built include units that are captured or otherwise granted? I would then lean to something like "(3 of 5 Owned)". I would be tempted to see what that text looks like underneath the unit image rather than an alternative UI treatment.

• maxBuilt is only tested in the Production dialog, so it doesn't apply to captures or triggers. It does currently apply to bid, though this could be changed.
• "Max owned units" or "Piece-limit" would be better descriptions than "max Built Allowed" used in (the code) and the tooltip , however they do not convey that this limitation is directly linked to production and the current number of units.
• maxBuiltPerPlayer is not currently used in most maps. In such a case my proposal is that the UI stays the same as currently, with the addition of the production capacity limitation and a "Currently Owned" count for each unit type (appended to the production tooltip).
• Replacing "max Built Allowed: 32" with "Currently Owned: 26 of 32" in the tooltip could work, but might be complex to implement. Unless this info directly appears in the UI, players will also likely be confused if in one map the UI prevents them from buying more units of one type despite having the required PUs.

the UI controls should prevent invalid selections, the max arrow should then only allow a max build. A similar constraint ought to be applied for PU constraint and if we can, production constraints as well.

This is currently working in my v2.5 code, but doing the calculation in the production panel rule forces a number of recounts instead of a single count per human player turn.
In the case of factory limited production the current check allows to buy more units than can be placed (after warning), but I'm not sure if there is a case where this actually makes sense ?

[Cernelius]

• maxBuilt is only tested in the Production dialog, so it doesn't apply to captures or triggers. It does currently apply to bid, though this could be changed.

Since the option is not making you impossible to have more (as you can have a game starting with more units than the maximum), I tend to think that bidding should not be effected. However, I can see good reasons also for effecting the bid. I guess better not changing current behaviours when the matter is very questionable.
I agree triggers should not care.

• "Max owned units" or "Piece-limit" would be better descriptions than "max Built Allowed" used in (the code) and the tooltip , however they do not convey that this limitation is directly linked to production and the current number of units.

"Max Built Allowed" is a terrible and literally wrong description, so it can be easily improved. Not sure what is a very good description if it is wanted to keep it short, though.

• maxBuiltPerPlayer is not currently used in most maps. In such a case my proposal is that the UI stays the same as currently, with the addition of the production capacity limitation and a "Currently Owned" count for each unit type (appended to the production tooltip).

Yeah. I'm not a big fan of piece limits myself. I think I've never used this option so far. Nevertheless, it is always good to improve options if they are available.

• Replacing "max Built Allowed: 32" with "Currently Owned: 26 of 32" in the tooltip could work, but might be complex to implement. Unless this info directly appears in the UI, players will also likely be confused if in one map the UI prevents them from buying more units of one type despite having the required PUs.

I would rather change

"max Built Allowed: 32"

to

"max units number per player on purchase: 32"

It is a bit long, but it gives full information. Still, it is far from clear, but I don't know how to make it clear without making it very long.

If you want to make it shorter, you can change the behaviour as to have the units destroyed if captured beyond the maximum (For example, if I'm at 30 and I capture 5 in a battle, I actually capture 2, whereas 3 are destroyed.). If you do that, the tooltip can be shortened to:

"max units number per player: 32"

(I would still keep the starting setup and triggers able to exceed the limit)

In the case of factory limited production the current check allows to buy more units than can be placed (after warning), but I'm not sure if there is a case where this actually makes sense ?

It never makes any sense in any basic game. In non-basic games, it may make sense in some cases like mobile factories or placement in newly taken territories. The current program behaviour is correct for v1 and v2 (where you can freely over-purchase and, in theory, nobody would even give you a warning), but it is kinda silly because you practically never want to over-purchase (unless you lost your mind). Beside basic games, the allowance is basically a hack to let the players do what they want because the program fails to support a number of features it offers (and in 270BC I've just removed the warning completely because it was easily wrong because of the legionaires able to place forts only). v3 and v4+ have different over-purchase systems which are mostly (for v3) or completely (for v4+) not supported: this is a long story which has been beaten dead a number of times and better suited for a new issue, though I think there may be one or more still open on the subject.

It's to some extent part of the usual story on whether or not TripleA should offer you making choices you can make but you would never make. We recently met it in the case of removing non-offloaded marines when you cannot retreat or removing bombers with more movement left instead of removing the ones with less movement left (both things which you can do but you should never do).

So the general question is if TripleA should make you able to perform idiot moves by giving you prompts that serve nothing but to delay the game and allowing you to missclick on something you would never rationally click on. For v1 and v2, the current answer is "yes it should".

[butterw]

• OK. The mod doesn't aim to change current game behaviour, it's just an UI improvement.
• Instead of "Max Built Allowed" I would suggest "Max Owned after Purchase" in the tooltip. Changes to the general unit tooltip can be handled in a separate issue.
• Production capacity really means Factory limited production capacity here, which doesn't at all cover all possible production and placement rules. I think the safest is just warn on overpurchase like currently. Further improvements should be considered in future versions though.

[Cernelius]

• Instead of "Max Built Allowed" I would suggest "Max Owned after Purchase" in the tooltip. Changes to the general unit tooltip can be handled in a separate issue.

If you want to keep it short, I would rather go with:

"Max Owned per Player when Purchased"

which would be short for "Max Owned per Player when one or more are Purchased".

This literally means that, when they are not purchased, this limit doesn't matter and, when they are purchased, there is the limit. I think it is due to specify "per Player", because, if you just say "Max Owned", I would understand you are accounting all owned units (that is, all units in the game except the ones owned by the "Neutral" player, which is a pseudo-player for non-owned units and territories). Also, literally, "after purchase" means just that, so it would apply also 20 rounds after the purchase phase (meaning that, in your formulation, it should rather be "immediately after purchase" or "as soon as purchased", instead of "after purchase").

I suppose that units retained in inventory (usually because of having been purchased yet not placed) are counted too. Right?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If there is something that can be done to resolve this issue, please add a comment indicating what that would be and this issue will be re-opened. If there are multiple items that can be completed independently, we encourage you to use the "reference in new issue" option next to any outstanding comment so that we may divide and conquer.

[andrewthree]

I would like to see something done on this. maxBuiltPerPlayer can be very useful in games where you don't want generic units but want to have a historical order of battle, for example, where units are specific to each player and there is only one of each "type" allowed to exist at any given time. 1st Army, 2nd Army, 9th Army, 3rd Army, for example, and you spent money on upkeep and rebuilding units that were destroyed. Technically, maxBuiltPerPlayer makes all this possible, but it is so hard to use as to be practically impossible. One of two things needs to be done:

1. Make it so that it will not allow you to even try to purchase more units than allowed (as it is now, you can try to purchase one more than allowed, then you get the error message). It should be greyed out if you are already at the limit.

2. Would it be difficult to simply have something with each unit on the purchase screen showing number of units already on the board, then a slash, then maximum number allowed for this player? 0/1 or 1/1, or 3/5, or whatever it is.

[TheDog-GH]

andrewthree, check this out, if you have not seen it already;
https://forums.triplea-game.org/topic/2798/achievable-improvements-to-the-triplea-user-interface/48?page=3
and the following post, by me on how to use it.

Im still using it today.

[asvitkine]

@butterw

Do you have your code available for any of your prototype changes?

[WCSumpton]

All I could find

Don't know if it will help any.

Cheers...

[butterw]

My old computer died shortly afterwards and I haven't looked into triplea since. But I probably still have any unreleased code on a hard drive.

…

On Mon, 10 Jul 2023, 13:12 asvitkine, ***@***.***> wrote: @butterw <https://github.com/butterw> Do you have your code available for any of your prototype changes? — Reply to this email directly, view it on GitHub <#9231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADD2U5EKM7HSZ6MLK3SAOTXPPPQNANCNFSM445VNSDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[TheDog-GH]

@butterw
Please could you look into uploading what you have, it would be a great help.
Thanks in advance!

[asvitkine]

The latest 2.6 now keeps the purchase selections after the error is shown. So closing this per that behavior.
We can file another issue to track further improvement ideas (like UI changes).