@Ondis The reason I redesigned as a square was based on the example @LaFayette had posted... with some infantry units not really centered... the circles looked very off center... where-as using the square I thought it would look more centered as well as the square would work well for some of the larger unit images like the BB or CA

@LaFayette Well, that was really more on the side of the user, as it would be the one adjusting the right bar wideness, but I've no idea if it is an easy thing to do or not. For example, the optimal size of the buttons is probably not the same if you are on a full hd or on a ultra hd, but of course there are many more items that go the same way, so I guess it's consistent. What the mapmaker would gain is the ability of setting a minimap dependent right bar wideness independently. Minor note, I would actually distribute the buttons this way, left to right: Previous-Next-Skip-Sleep-Alert.

The unit scroller updates are now live with unit counts and follows the mouse cursor. I'm curious if there is consensus that we probably will not need to use the battle calculator quite as much. @Hepps really the issue is more confusing rendering than forgotton units. Once folks have play-tested the updated unit scroller, I'd be curious if there are more ideas for making it clear which units are in which territories. AT some point it'll come down to updating/fixing maps, before we get to that point, I'm wondering if there is more that we can reasonably do. There might be some overlap here with the 'highlight territory' on mouse enter idea. Having all units highlight when you hover over a territory should really help this too.

I like the idea @ubernaut , could be units only, territory only, or both. The units getting a 'roll-over' highlight makes a lot of sense. Very similar to how when you hover over buttons or anything clickable, it usually shimmers. To boot, we already have the unit highlight ability readily coded up, likely that would be a far easier than outlining the territory.

so is there a Git request for a quick save? wow abuse more thats like my 7th or 8th post he deleted cuz the truth (my sig) hurts

@tinfoil666 I was thinking we could do territory highlights of territories eligible for placement (you can demo the 'territory highlight' by doing a find territory, it will outline the territory in white). We could potentially turn the territory highlight on for all eligible territories, then when the territory/factory is exhausted, turn it off. I wonder if combining that with grayed out factories would make it even more clear. I like the territory + factory visual change. If there were only 1 implemented, I would pick factories, but on maps where the factories are 'invisible' (such as the 'build anywhere' maps), then you would need to highlight the territory for this to work. Until your response, I forgot that the factories are not always visible. [edit] Don't forget that the 'eligible territories' should include sea zones adjacent to factories with builds left. Ideally, the sea zone highlights should cease once you have placed your last sea unit.

@LaFayette Really hope this is fixed to how 13066 works. It is quite annoying when testing and one has multiple saves.

@Cernel There are rare occasions when it makes sense to declare war on true neutrals. Mostly late in the game in order to move through a specific area. But its probably done in less than 5% of games if I had to guess.

@Cernel said in Sea Units starting in hostile seazones: oping that a developer takes interest, which may be influenced by the map's popularity. An example is World At War, that had an unsupported way of handling canal movement (even requiring the use of edit mode in all multiple canal cases!), documented in notes, then @redrum supported it at the engine level. Going further back, New World Order had edit based rules for adding bunkers to the map, that were changed to be supported (even, though, in this case, not in the same way). Ok, thanks you very much for the answers and the information. I will think about it.

@Frostion Side note, for the tooltips on map, I would find more useful getting the info about the unit value (usually, cost), so I'm really not seeing why we are getting told who is the owner and not what is the value of that unit, from someone that would have neither of them.

This topic seems to be devolving into a discussion about units that can submerge verses creating a mechanism where a unit MUST submerge.

I'm trying to keep the aliaser trolls on this forum to a minimum

@Cernel There are all kinds of issues one could argue are either right or wrong as they stand. I think I would prefer if the mechanics being established did not interfere with existing established rules, but rather worked consistently with them. Then, looking down the road as how to circumvent those (perceived) deficiencies as a matter of an addition to the code as a separate idea.

@LaFayette Here was some feedback on the unit scroller in the pre-release: https://forums.triplea-game.org/topic/105/ai-development-discussion-and-feedback/204 Oh, with the UI, when you are doing combat moves ... if you want to say move a Tank and then you change your mind and want to click "Undo Move" well that whole area used to be big but its now blocked by those fast buttons below and I tried the only 3 resolutions on my comp that I can and the Combat area is always so small I can barely scroll to the "Undo Move" button and its much slower than when it was a whole big nice area to click on so my question is can I click off those fast button things below the Combat window so I can see the Combat window better since I don't even use those Fast buttons things I've never seen before

@Frostion Here are some examples: Attack Suicide Support Unit Can provide support for the first round of battle and then suicides. It would act as just a regular unit with no attack/defense values on defense (wouldn't suicide). <attachment name="unitAttachment" attachTo="suicideSupportUnit" javaClass="UnitAttachment" type="unitType"> <option name="movement" value="1"/> <option name="attack" value="0"/> <option name="defense" value="0"/> <option name="isSuicideOnAttack" value="true"/> </attachment> <attachment name="supportAttachmentSuicideSupportUnit" attachTo="suicideSupportUnit" javaClass="UnitSupportAttachment" type="unitType"> <option name="unitType" value="infantry"/> <option name="faction" value="allied"/> <option name="side" value="offence"/> <option name="dice" value="strength"/> <option name="bonus" value="1"/> <option name="number" value="10"/> <option name="bonusType" value="magic"/> </attachment> Iron War Nuke with Updated Properties Suicide on attack unit which fires during first strike but can't attack other nukes. <attachment name="unitAttachment" attachTo="Nuclear-Bomb" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="attack" value="5"/> <option name="attackRolls" value="10"/> <option name="movement" value="6"/> <option name="fuelFlatCost" value="Fuel" count="3"/> <option name="carrierCost" value="2"/> <option name="isAir" value="true"/> <option name="canAirBattle" value="true"/> <option name="airAttack" value="0"/> <option name="airDefense" value="0"/> <option name="isSuicideOnAttack" value="true"/> <option name="isFirstStrike" value="true"/> <option name="canNotTarget" value="Nuclear-Bomb"/> <option name="isStrategicBomber" value="true"/> <option name="bombingMaxDieSides" value="10"/> </attachment> POS2 XML PR: https://github.com/triplea-maps/the_pact_of_steel/pull/42

@beelee I totally agree with this as the immediate concern when finishing up a turn is generally where the least mobile units need to go. Great suggestion!

@wc_sumpton I meant if the matter was needing two different kind of support/units to get supported, it seems more logical doing it directly rather than 0.5 + 0.5 and ignoring if only one 0.5. Also that would allow for support or nothing when it is a +2 or more. But I have to say several times I wished for something like this, especially when you have land transported units.

@lenzls You could cache the results and/or compute them in the background on game launch. Overall though, I'd stick to the rule of thumb: "working, clean, fast - in that order". I think we need to eventually have bigger updates to make game data broken up and store the history data as delta's and independent of the immutable data such as base game rules and map options. That would give many benefits, a compability for a custom save-game format that does not rely on serialization, smaller save games, and much faster game clone operations which cause many delays. Hence, IMO it might be okay to just cache the results and let it be somewhat slow until we can get those deeper changes in place. Grant it, if there is a way to cleanly make the rendering fast, then it would be very difficult to wait or object to that.

@redrum Seems like a good place to start. Very interesting... I had always wondered what impact the 256 x 256 had other than when the map itself was being rendered. I hadn't realized it affected unit placement as well.