More is not always better and I really see no good reasons to split between different kind of information, being them relationships, statistics, or whatever. Just an option for not giving any information that it is not given for the Neutral (null) player (thus comprising not being in the politics panel and in the players tab) should be good enough.

This doesn't even need to be an option, by the way; it may be related to the player having no phases assigned (which would be consistent with the player being, thus, alike to the Neutral one).

Also multiple options, side by side, would give pointless possibilities. For example, I don't think you'd ever want to hide any information about a player while offering it as selectable, do you?

At most, the levels are going to be 3:
1- Players you want to select and have info.
2- Players you don't want to select, but still want to have info.
3- Players you don't want to select nor have info (like the Neutral player in NWO etc.).

I still wonder if number 2 is even much of an item. What's the problem about assigning those players to the AI (maybe even to Nothing) and leaving them selectable, even if you are not supposed to ever select them. Telling a player it is supposed to be not selectable is already done by having it defaulting to an AI, isn't it?

Then, we could add no options at all, but I still believe the "isHidden" option should be renamed into something more consistent and definite.

@Captain-Crunch i know it is 🙂 still remember how inept it was before @redrum came around. 🙂

@redrum I tried the latest pre-release and it seems to work now 😊 Great Work!

And I realize that not all errors will be able to properly get reported one at a time, like the second one i listed. Something might accidentally end up in a comment or something because of the first error.

I use notepad++, but often there are enough things that are just one letter off, or just different at the end of a name (Romania vs. Romanians) that i just tend to keep typing. Or it isn't showing up in the auto complete because i got the second letter wrong, ... Or ... I might just be lazy sometimes! 🤷🏼♂

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