I think this option would be much better if it would offer a numerical value at which the unit suicides, with a boolean for determining if this value is influenced by supports (and maybe splitting the options between attack and defence and between regular attack and AA ones).

The current behaviour would be a subset, where you set such value equal to the attack/defence value (so that it suicides only when it hits).

This way, the regular suicide option would become redundant too (and could be deprecated or refactored as a shortcut for generating such option with value equal to the dice sides), as it could be covered by the above option, setting the value equal to the dice sides.

Moreover, I understand this would fully cover this feature request, as well:
https://forums.triplea-game.org/topic/1579/suicide-munitions-unit-with-support

And I also understand it would allow supporting suicide units (for example, for representing ammunition consumption).

Practically, instead of having:

<attachment name="unitAttachment" attachTo="germanNavalMine" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="attack" value="0"/> <option name="defense" value="0"/> <option name="isSea" value="true"/> <option name="isSub" value="true"/> <option name="isAAforCombatOnly" value="true"/> <option name="mayOverStackAA" value="true"/> <option name="typeAA" value="navalmine"/> <option name="targetsAA" value="Battleship:Cruiser:Destroyer:Submarine:Transport"/> <option name="maxAAattacks" value="1"/> <option name="maxRoundsAA" value="1"/> <option name="movement" value="0"/> <option name="attackAA" value="2"/> <option name="damageableAA" value="true"/> <option name="canInvadeOnlyFrom" value="none"/> <option name="isSuicideOnHit" value="true"/> </attachment>

you would have:

<attachment name="unitAttachment" attachTo="germanNavalMine" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="attack" value="0"/> <option name="defense" value="0"/> <option name="isSea" value="true"/> <option name="isSub" value="true"/> <option name="isAAforCombatOnly" value="true"/> <option name="mayOverStackAA" value="true"/> <option name="typeAA" value="navalmine"/> <option name="targetsAA" value="Battleship:Cruiser:Destroyer:Submarine:Transport"/> <option name="maxAAattacks" value="1"/> <option name="maxRoundsAA" value="1"/> <option name="movement" value="0"/> <option name="attackAA" value="2"/> <option name="damageableAA" value="true"/> <option name="canInvadeOnlyFrom" value="none"/> <option name="isSuicideOnRolling" value="2"/> </attachment>

@Cernel Yes I believe the sorting of units based on either attack or defense of the units whether they are the attacker/defender.

@Frostion Siege-Towers usually have a battering ram at their base, integrated in the tower and protected by it.

@Cernel also that's a pretty standard chat feature almost everything has that.

@redrum
1. Yep.
2. Yep.

You're good at this! 🙂

Cheers...

Mod status would be tied to account and not username. If someone wants to change their account name, they can create a new account. I'm not sure why we should make it so difficult and say "no, you have to re-register with that same email but a new account name". Is that just not convoluted? We can certainly discourage mods from changing their names, or changing often. I'm not sure if it's worth the complexity of special casing it into the code when we can keep the same name by convention. Given the game allows multiple logins, no limit on how many accounts, no validation of email, no password requirement even, it doesn't seem like relieving the requirement of creating a new account if/when a person wants to change their username is a huge deal necessarily. I really view it as a convenience so you don't have to register multiple accounts. Arguably we want that particularly when stats could become tied to a user.

@redrum yup forgot we still had that kicking around 🙂

@LaFayette oki doki

@ff03k64 It is a work-in-progress map. I have had a little pause in developing it, but I think that I am about ready to begin working on it again. I have not released a playable beta version yet, but it will come out eventually.

Look for it in the maps and mods category. 😉

Thanks for the quick thoughts/feedback.

We'd have to work out some issues for the blank map. It could be that we start off with an empty map that can be loaded, or there is a quick wizard process that gets a map maker to that point. TBD exactly, main idea though is that the tools would be moved to in-game rather than be completely external.

Glad the idea of map configuration hosting sounds good. Implicit to that idea, is that the entire map would be stored on the server, in DB!! No more github manipulation or uploads. Hence the asset split is particularly useful. If the UI tools are good, then map makers will have a UI to select their assets by image and it will be written into the configuration properly without anyone dealing with IDs. Part of the goal would be to decrease the manual file editing. I suspect a fallback to file system will almost always be there to support offline map making.

I was thinking that the potential new map database could write out to a github repository and check in the contents, largely to serve as a backup. That's a detail for now that is less important compared to the other main ideas.

really like both of these ideas. 🙂 i also think even further simplifying the battle window by only showing the currently active odds groups could make the whole thing much more visually appealing and less cluttered.

here's another random thought, if we are taking a deep dive on the battle window another thing that might be interesting is an enhanced low luck view. Since so many people play with LL and the predictability often leads to much more precise odds calculations that must be made in real-time in tight/large battles there could be some added value to be had there.

Wow, looking at that help menu, it suffers from a common developer problem where trying to solve one thing "people don't know about this" feature, the information is plastered in the wrong places. Most of those ctrl hotkeys can be seen by simply opening the menus and looking there. The 'turn off map artwork' is the same, just a restatement of menu options. The extra details about that do not belong here.

This is a bit of a UX issue, overloads unnecessary information on a user and out of context. The problem that creates is it detracts from the rest of the information that is present here.

Anyways, that is a digression. For now flags/highlight has a new home with the unit scroller for better or worse.

Further progress I would agree needs a bigger vision. For that we should know what more controls we are going to need and then work to create mock-ups of how they could be arranged. Follow up is in this thread: https://forums.triplea-game.org/topic/1525/ui-mockups-needed-unbury-the-controls

Ctrl+Z (hide right hand panel) is only a hotkey, it could use a UI icon.

I like Low Luck for battling the AI or online matches but with the board game I just use dice

everyone has their own preferences and its nice to have options.

Haha, I guess my terminology is backwards, sorry.

i think to remove randomness in this game is like poker with an ordered deck. Sure the hands will be very orderly but by taking the randomness out of it you are really taking a fundamental aspect of game out of the picture. Part of your strategy should be to allow for things to go against you imo.

That being said i do understand why people like LL and a version of it the effect of it were always even would be interesting to try at least.

also, this over rolling of 1's and 2's, this is the first ive heard of that. here is 14 round 6 sided game stats as well as a 28 round 12 sider stats they look pretty good to me. 😛

Screen Shot 2019-07-06 at 6.55.48 AM.png Screen Shot 2019-07-06 at 6.56.17 AM.png

@redrum right well the attacker never gets to choose the casualties so i was just using that as a comparison. if the defender should always be able to choose the best scramble returns it really wouldn't be any worse than that.

@redrum yeah that would be awesome