-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-Offloaded Units Are Unpredictably Removed Before Same-Named Offloaded Ones (2.5.22294) #8855
Comments
I've created a PR to fix the issue where it was grabbing non-amphibious units first. But if the units have a marine bonus, they will be grabbed last. As for making it possible to select the units, I don't think triplea has graphics to indicate amphibious units vs non-amphibious units. So the dialog would show the exact same unit images. Someone needs to create a graphic to indicate the difference and then the select dialog can be shown. |
Thanks @trevan !
Have a second prompt, immediately after confirming the first, visually identical to the prompt we already have for selecting casualties, but asking you how many are the offloaded units please. This needs no graphic. For example, I attack with 2 spearmen, 1 irregular, 2 phalangite and 1 warelephant by land and 2 spearmen and 2 phalangite by sea. I get 9 hits on me. I have a first prompt that makes me remove 6 units amongst 4 spearmen, 1 irregular, 4 phalangite, 1 warelephant undamaged and 1 warelephant damaged (this is simply the prompt that we already have). If I take 1 warelephant undamaged (meaning the free hit which the warelephant absorbs and will repair), 4 spearmen, 1 irregular and 3 phalangite, I immediately get a second prompt asking me to select how many are the offloaded units for all types above, except that the spearmen, the irregular and the warelephant undamaged are fixed at 2, 0 and 0, respectively (I took the max so I must take the max of the offloaded too), while the phalangite is set at 2 but I can lower it down to 1, if I want. On the second prompt, there should be
If the max is equal to the min for all types, then the second prompt is not shown (obviously). The second prompt should also never be shown for games that have both no partial non-sea-borne retreat and no units with "marine" bonus for which the aforementioned min and max are differing (so be sure you never see this second prompt if you play Classic, Revised or World At War (the marines of World At War are marines in name only), for example, except only if you are playing the 3rd Edition of Classic (having actual marines)). I believe it would be better if, when you are on the second prompt, you can roll back to the first and reselect the units to remove, especially so long as there is no indication on the first prompt to enumerate the offloaded units per type. Of course, actually showing the unit separated all the time, with some graphic indication, may be a good feature request, hopefully not to be done in a way that will feel out of place for pre-modern games (like 270BC Wars). |
By the way, sometimes you want to take non-offloaded units of the same type first even when having no positive marine bonus for the type. This is related to using the partial retreat so to leave some units to finish the battle without exposing too many to a counter. However, this very rarely happens in practice (usually you indeed rather take offloaded first when having no positive marine bonuses). |
This seems similar to other problems where unit stacks are incorrectly grouped together for the purpose of casualty selection. Airplanes and differing remaining units is another example. For this case, a unit being offloaded could be graphically represented with a composite image, a "super-script" transport icon drawn behind the unit image could indicate the unit is being offloaded. |
Following on to the previous comment, in the vein of coding is never "simple" - what happens for maps where there is no standard transport unit and for maps that have multiple transports? Perhaps it's okay to break up the selection group to be 1:1 to the offloading transport (for example in WaW there are 4 boats that can transport, there are 3 different infantry types, hence there could be a combination of 15 unit groups just for infantry casualty selection). This also makes auto-selection interesting as well as selecting between any of these units is a valid choice. If we force manual selection because now there are multiple categories, it will be a step in the wrong direction. |
This would be useless. Under any rule I'm aware of the distinction is merely between offloaded and non-offloaded once the battle has started until it is over. Since you can never retreat offloaded land units, it is completely pointless to know what sea unit offloaded them. As far as "World At War" goes (as well as Revised), it is always useless to distinguish between offloaded and non-offloaded units, since if 1 unit is offloaded no land unit can retreat. This problem is completely irrelevant to this game. |
Side note, in the intended rules of non-LHTR Revised and the (non-1940) Europe and Pacific you can also call off landings, which is a sort of sea-borne retreat for the units which you plotted to be offloaded after a successful naval battle, but this rule has never been implemented in TripleA and would be still irrelevant for the battle because calling off landings can be done only before the battle starts (which is weird especially when you end up with air units obliged to make 1 round of combat while the offloaded units have been called off). In any case, when you call off landings, which you would do immediately before starting the land battle in the territory, you have to call off all units being offloaded into the same territory from any zone where you made a battle (you cannot call off landings from ships which were not involved in any sea battle), so there would be still not much point in showing what is offloading what. |
I would agree and am also concerned about the impact this would have on auto-selection of casualties. Having a 1:1 is perhaps a naive solution but resolves a number of questions. I don't know what the best answer is here. If we don't do a 1:1, there are a number of questions to answer:
|
Just to make sure: in the proposed solution I gave there is no need visually to distinguish offloaded and non-offloaded. For example, if you have 3 infantries of which 2 are offloaded and 1 armour and have to remove 2 casualties. You have a first prompt (which is simply the prompt that already exists, nothing being changed about this) where you take either 2 infantries or 1 infantry and 1 armour as casualties and a second prompt where you have to decide how many are the offloaded ones. Assuming you took 2 infantries in the first prompt, in the second prompt you have a minimum of 1 and a maximum of 2 for the infantries, while the armour is fixed at 0. Other than this, the two prompts would look the same. |
Just to be clear, this can only happen if the property |
I don't like the two layer casualty selection, nor that it is solved by being very wordy. If we ever translate TripleA, this will be more work, it could also be confusing whether the offloaded or non-loaded units are the ones being selected. Stopping a player to carefully read a sentence is very disruptive to game flow. There are other cases where unit groups should be distinguished (EG: movement), I think we need a solution that fits with that. |
If by "this" in "this can only happen" you mean "retreating the surviving non-offloaded units in a battle where one or more of the units which were in the battle at the start of the battle have been offloaded", correct, and "World At War" doesn't have that property true and doesn't offer the choice in the game options, either. So this problem is not affecting "World At War" in any ways. |
The behavior of the retreat menu and how units group IMO should not depend on a XML property or any other game rule. I was presuming that was out of the question. To another extent, it's moot because any map that is not "impacted", could easily have a variant where the given property is flipped. |
A correctly working behaviour is always preferable to a wrongly working one, no matter if arguably more user friendly, which is the current condition. So my suggestion is initially implementing my proposal, which is at least better than the current situation, then playtest it some and open a feature request for a better system. On the upside, this will be completely irrelevant to all players on older (pre-v3) games (which mostly means Revised and World At War), so it will need to be faced by the more "evoluted" part of the community (playing on more recent and complex rules sets), while the rest should not even notice anything different. |
My "solution" can be also integrated by a tick box on the first prompt displaying a sentence like "always select offloaded units first for the same type". When the box is ticked, the second prompt is not given. I think this should really eliminate any concern about my solution being too confusing for the average user. If you really want, this tick box can be ticked as default, though I would have it non-ticked as default. In this case, only if the user himself/herself untick the box, he/she will ever see the second prompt. |
I suggest a universal transport icon if you go down that route, especially
if the unit engaged in the transport is irrelevant at the point of display.
Thomas
…On Sun, Feb 14, 2021 at 3:00 PM Dan Van Atta ***@***.***> wrote:
This would be useless. Under any rule I'm aware of the distinction is
merely between offloaded and non-offloaded
I would agree and am also concerned about the impact this would have on
auto-selection of casualties.
Having a 1:1 is perhaps a naive solution but resolves a number of
questions. I don't know what the best answer is here. If we don't do a 1:1,
there are a number of questions to answer:
- If we are using a 'transport' icon, then how is the engine to know
which one to use?
- If there are multiple transports, how does it pick?
- If always using the same transport icon, regardless of actual
transport, then how to decide which one that should be?
- Or do we use a universal transport icon to represent this in any
game?
- Or does the game randomly select a transport unit to be the
representative transport? If randomly selecting, do we create an XML value
to create an explicit default? Is there something simpler than updating
every known XML and teaching every map maker what and when to use this new
attribute?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8855 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABB5HALZI7N3UBJZGCNHC53S7BIY5ANCNFSM4XTOACCA>
.
--
Thomas Leavitt
Internet enabled since 1990
|
I'm as sure about it as I can be: in every rules set there is no "engagement with any transport" at this point. The offloaded units have already left the transport and "don't remember" what has offloaded them. They only know that they have their backs to the shoreline, nowhere to retreat to and no ship coming back to the shoreline to pick them up until the next round. The universal transport icon likely cannot be good for an ancient, world war 2 and any science-fiction maps at the same time. |
Except there is that memory, right? Offloaded marines have a boost in attack power. I agree it would be difficult to have a good universal offload icon. As a suggestion towards that though, we could create an overridable default that is era specific. Overall there are a lot of options to choose from with different pros/cons. |
They do (if the marine value is set greater than zero), and that is also unrelated to the transport, so no exception. Also in this case, they "don't remember" what has offloaded them, just that they have been offloaded. It would be realistic if you could get different bonuses per ship (for example, better offence if you are being offloaded by an attack ship rather than by a common troop ship), but I believe there is no such a feature. |
Make the icon symbolic. If the unit being transported is super-imposed on
it, then it could be something as simple as a line or an arrow underneath.
Or an L shape... here's some half-assed attempt. It could even say,
"transported" underneath.
…On Sun, Feb 14, 2021 at 4:13 PM Dan Van Atta ***@***.***> wrote:
The offloaded units have already left the transport and "don't remember"
what has offloaded them
Except there is that memory, right? Offloaded marines have a boost in
attack power.
I agree it would be difficult to have a good universal offload icon. As a
suggestion towards that though, we could create an overridable default that
is era specific. Overall there are a lot of options to choose from with
different pros/cons.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8855 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABB5HAP7YKZ44TYW3HXJWQTS7BRKZANCNFSM4XTOACCA>
.
--
Thomas Leavitt
Internet enabled since 1990
|
The units actually do remember who transported them. It isn't visible in the UI anywhere but the engine has that information. |
I was actually talking from an intended rules stand-point. If the program keeps in mind what offloaded what in a land zone after I click to start the battle in the land zone, I'm as sure as I can be the program is keeping useless information (which could be substituted by simply tracking for every unit whether or not the unit has been offloaded). But I suppose it is good to keep in case in the future TripleA will get some feature using that information. |
Let's foucs in on the exact problem and the options that we want to pursue. Recapping: to resolve this issue properly we need to be able to update the casualty selection such that a player can choose whether a disembarking unit or non-embarked unit are chosen as casualties (EG: 2 marines, one is offloaded, the other is attacking from land). Options:
Constraints:
Unless a developer actively volunteers to solve this, rather than continuing the conversation I suggest we let this issue remain the problem backlog |
If someone is willing to create a default image and make it look good, I'd be willing to do one of the options where the existing casualty selection dialog is updated. |
@trevan it would be cool to see this fixed. Probably moving to forums would be appropriate to get more feedback and the actual images. Perhaps when that thread is open, link to it here and we can close this conversation in favor of the new thread. Having a default image per era could even still be quite tricky. I don't think it's wise either to require each map to come up with something as well (maybe for new maps this works well, but that puts us on the hook to do something for 100 some maps that are not actively maintained). Personally I think the easist & most scalable is the default image to be chosen from existing transport images. It seems like it would be straight forward to add an XML option to designate which unit should be used as the default (otherwise choose the unit that has the largest transport capacity to be representative). This would mean that units such as paratroopers could potentially have an image of a boat next to them when they are actually paratroops. This also maybe is the best counter-argument to a default image, say we draw some sort of water or beach icon and the unit is a paratroop instead of a marine. That makes me think the ideal solution is really a unique graphic to show the power-up. Backfilling that is not a good option. But we could see if we could auto-generate such an image somehow. We can leave the door open to allowing for a custom variant of the image, though we should be cautious about that. With that said, we could do a treatment where we do a hue or saturation shift of the unit, give them a sort of glow perhaps to indicate they are different. |
Forgot to mention, a second constraint, I think we should also design and solve the differing movement points scenario as well. We won't necessarily have to implement that now, but at least design it so that we can be sure that our differing attack value solution works well with a potential differing movement solution. |
Paratroopers are simply non-offloaded units (there is nothing in the rules forbidding them to retreat, so they must retreat if retreating): once the AA fire phase is over, there is no difference between paratroopers and all other non-offloaded units. |
Doing it someway is better than nothing, but, if not having a double prompt, my preference would be entirely splitting the prompt into two sections, one above for non-offloaded units and one below for offloaded units. You would head both sections with the titles of "non-offloaded" and "offloaded", respectively, removing the need for any per-image marker. |
There may also be a toggle called "always select offloaded units first for the same type" which, when ticked, collapses the two sections into one, undistinguishing offloaded and non-offloaded, and making you take out offloaded first (also in case the offloaded are stronger for positive marine bonuses). You can untick it any moment to go back to the two sections layout, the program automatically assigning as much as it can to the offloaded part and the rest to the other. |
On a further thought, I think my "offloaded" term might be not very good because, whilst game-wise land and air transport units are never offloaded (you just move them together, so there is no offload movement or action like you have with ships), realistically offloading would indifferently refer to getting a load off anything, be it a ship, an aeroplane, a lorry or maybe even a mule (not sure about the mule). So maybe changing my suggested name to "sea-borne" (instead of offloaded or unloaded). In any case, please don't use the term amphibious! Although being an original definition, that is a complete misnomer of a misnomer because, militarily, that would be a sea unit which can move itself on land (which is not supported by TripleA) and scientifically it would be not even that (a duck can move and live both on water and on land, yet it is not an amphibious). I guess me using the term "offloaded" might be what made @DanVanAtta think I was comprising air (and land?) transported units too (which I have not been). I can see people easily thinking that paratroopers are "offloaded" units (and maybe they would be right to do so: I'm not sure about the original definition). Also, we cannot assume that TripleA MUST be good at representing every setting. I would certainly hope so, but I'm still seeing the term "fire" used in the battle descriptions every time ancient armies are hacking at each other... |
All TripleA 2 released versions (up to the current 2.5), including the initial 2.0.20123 release, have the problem documented at this issue. It is quite amazing noone reported it until the opening of this issue. I've my "270BC Wars" game which is badly affected by this issue, and I don't want to downgrade it to a 1.9 release, and I like to document in the game notes all issues or try to. Is there any hope that TripleA 2.6 will be released soon, like before the month's end? If I will have to release my new version before TripleA 2.6 comes out, can I be exactly informed about what is the behaviour of TripleA 2.5 on this matter? Does it always take non-offloaded first, amongst units having the same name, or not necessarily always? (I guess asking mostly @trevan.) Practically, I need a confirmation so that then I write in the notes to be aware that non-offloaded units are always taken first. |
@Cernelius , I tested out 2.1 and it didn't have this issue. I used the "World War II Global 1940 2nd Edition" map. I removed the russian sea units next to the baltic states and then did an amphibious assault with 2 german infantry and a regular land assault with 2 germany infantry. I also added 3 more russian infantry to the battle. The russians killed 3 german infantry and I was given the chance to retreat. So the offloaded units were removed first before in 2.1. |
I tested what you say in "World War II Global 1940 2nd Edition" using TripleA 2.1.20365. All default options but "Low Luck" enabled. I confirm what you say (except for the fact that, having used Low Luck, the Russians killed 2 german infantry units only, being the offloaded ones). I also tested what I said
and I can tell that I received the retreat prompt both when only 2 infantry units were left and when only 1 infantry unit was left. So, it is good that at least I have a released version of TripleA to fall back, releasing a new version of my map stating in the notes of its game to use that version of TripleA instead of the current 2.5. If it is easy for a developer to know it, I would like to be told what is exactly the version since this problem existed. Anyways, not a big deal: I can simply test all released versions since 2.1, I suppose. Can I be fairly sure that if a version happens to take offloaded units first, this is what it would always do? Now I guess I should try it a number of times, to try to test it was not just a coincidence that the offloaded units were taken first (is it possible that taking offloaded or non-offloaded might be random)? @trevan Going back on productive items, whilst I'm unconfortable with the idea of adding anything directly into any unit image to tell the unit is offloaded (and would prefer the program doing it by visualizing sets of offloaded and non-offloaded units when offering casualties selection), I surely much prefer having this feature actually working properly any way. If you are determined actually to fix this issue properly as long as someone gives you the graphic you need and also to gather more opinions, I suggest you open a topic in the forum (I think there are very good chances a map-maker will provide you with the image you need). |
Good input. Let's be sure we design this right. I do not want it to be a per-map graphic or else we may see a lot more of those "missing unit image" tickets. Secondly the burden to create maps is very high already, anything to make it easier and more automatic is a sure win. Third, whatever we do should be reasonably consistent across all rule sets so we can implement it relatively cleanly (and not do more sub-optimal designs like use 'isInfantry' to mean multiple different things with changing behavior under different rule sets). |
Negative: 2.1 does have this issue. I believe there is the issue in all releases since the first 2.0 release, and, what is worse, it appears to be random or else neither always present nor always absent. Using TripleA 2.1.20365, I tested my case
and I can say that, after 1 offending infantry is removed, sometimes you get the prompt to retreat and sometimes you don't. My best guess, at this point, is that the program selects one of the three infantries randomly. If this would be the case, you should be prompted to retreat after losing 1 infantry 2/3 of the times and not prompted 1/3 of the time (since one of the three infantries is non-offloaded and only its survival gives the ability to retreat). You need to keep testing this case again and again until you get no prompt to retreat (the battle proceeding automatically). It might take several tries to obtain it. So I believe all TripleA 2 released versions (up to the current 2.5), including the initial 2.0.20123 release, have the problem documented at this issue. What is even worse is that they appear not always having this issue, so you don't even have the certainty of a behaviour. I think this renders very important to release a new TripleA version having this issue at least tempered by the program always following the same pattern (which I understand currently is always taking offloaded first amongst same-named units but always taking non-offloaded first in case the units have a positive "marine" ability). Of course, this is still against the rules (since you should be able to select every unit specifically, so deciding whether you are taking an offloaded or a non-offloaded one for the same type) and has the major issue that I guess any non-developer user has no way really to know what the program is going to do. |
I would assume the same issue is in 1.9, then. I'm not seeing any thing obvious in the code between 1.9 and 2.0 that would trigger this. |
I did this test case in 1.9 but with a modified order. I first moved the infantry unit from Poland and then I moved the 2 infantry units from Finland. With that change, the infantry unit from Poland was removed first and I could never retreat. |
Are you saying that you believe that you would have been able to retreat if you sent the offloaded units first? I can scarcely believe that the order you made movements can possibly have any influence. On my latest tests on 2.5.22294 the (non-offloaded) infantry from Poland was always removed first, no matter if sent before or after the two from Finland. It seems to me that there is something causing the program to take either offloaded or non-offloaded first, but I cannot figure what it is. I doubt it is just random. Anyways, having a correct behaviour for a new release would be likely a better investment of time than all this investigating on how the hell current and past releases actually work, even though I'm still certainly curious about that if only to be able to document it for my game if I'll release it before 2.6 is out. |
I'm saying that this bug has been around for a long time. It isn't new in 2.0. It existed in 1.x as well. The change I made in 2.6 (which was never released) made this bug more pronounced as it always forced non-offloaded units to be taken first. The change I just made (still in 2.6) forces offloaded units to be taken first unless they have a marine bonus. |
I suppose I never realized that the offloaded versus non-offloaded TripleA selection was such a mess... I always assumed that there was the (wrong but intended) general behaviour of always taking offloaded first for same-named ones (even though, as usual, I've never seen any documentation giving any information on the matter to any user). It seems that back then when moving from v2 to v3 the new rules of partial retreat have been added to the program in a very sloppy way and I've no idea if any consideration was even given to anything at all back then when marines were added for Classic. |
If this issues is not getting properly fixed by the next release, is there any idea on how to document the chosen behaviour? I mean, I will know that, barring problems, what is going to happen is that same-named offloaded units will be removed preferentially to non-offloaded ones if the marine bonus is absent or either equal to or lesser than 0, or else the non-offloaded units will be removed preferentially, but how to give this information to every user? Adding it to the "Movement/Selection Help" information? |
How can the problem be recreated?
Start a game of which the rules set allows retreating non-offloaded units (all basic ones from v3 onwards), make a battle in which there are offloaded and non-offloaded units of the same type and observe that, once only a combination of units which is the set or a sub-set of all offloaded units remain, you will not be prompted to retreat any longer.
For example, start "World War II v3 1941", send in "Baltic States" 2 infantry units from Finland and 1 infantry unit from Poland, and witness how you will have no prompt once only 2 or less infantry units remain offending (enable "Low Luck" to be sure to observe the behaviour).
Do you have any ideas for an expected fix?
I believe the intended rules in every case it matters (also in case you cannot retreat any land units, yet offloaded units are differentiated due to marine bonuses) are that the player can individually choose to remove an offloaded or a non-offloaded unit for every hit (I'm assuming no multiple hit points units are present, to keep the explanation more concise and since all land units have only 1 hit point each in every basic game.).
For example, if I send 2 offloaded infantries and 1 non-offloaded infantry in a battle and receive 2 hits on the first round of combat, I should be allowed to do only one of the following.
(If the game is v3, taking the second option is idiotic, because you deprive yourself of the ability to retreat and are otherwise in the same condition as taking the first option, yet this is exactly what the program forces you to do.)
Attach a Save Game
I believe this is easy enough to reproduce that doing so should take less time than downloading and loading any save-game (especially if you have to unzip the save-game).
Is there anything else we should know?
I'm almost sure in the past offloaded units were always removed before non-offloaded units of the same type, which is just as wrong a behaviour, but at least I believe it is usually preferable if there are no marine bonuses in the game. I think removing non-offloaded units before offloaded ones of the same type is a very bad behaviour and likely the greatest problem which I'm aware the program has.
I think this problem should have the highest priority amongst all problems currently in existence for the release. It is a huge problem for my "270BC Wars" game too.
CC: @panther2 @trevan
The text was updated successfully, but these errors were encountered: