Unit Tooltip Improvements & Poll

[General_Zod]

Terrain bonuses and penalties should be listed somewhere too, even if they can be mimicked by fighting units support figures.

[Hepps]

@general_zod What about

A/D/M 1/2/1
Transport cost 2
etc.
etc.
etc.

The Idea here being that if we can standardize the basic combat and movement descriptors (which are essentially basic defining perimeters) it will free up 2 lines within the tool tip display.

Since most basic games have only these elements... it would mean that the tool tip would be quite small and concise, while also reducing the space needed for games with more features/attachments.

[Hepps]

@general_zod Really like your terminology for the support mechanisms.

[General_Zod]

@hepps

Yes, the first line contains the common figures. This will be present for most fighting units. I think that's a nice place to save space in a revamped tooltip.

@general_zod What about

A/D/M 1/2/1
Transport cost 2
etc.
etc.
etc.

[redrum]

Thoughts on format of "number then label/description" (Frostion example) vs "label/description then number" (Zod example)?

[Hepps]

@redrum I would say the format itself is pretty arbitrary... whether it be # <-> description or description<-> #

Really what it comes down to is having consistency of all rows.

[Hepps]

@hepps Took a look at this again...

I think Zods example is clearer.

Descriptor---> number

[redrum]

Well here is a start. Still need to go through and standardize AA and support descriptions but did most of the core stuff and easy stuff.

LME

TWW

[Hepps]

@redrum Already looks much better. I like how the bold punctuates certain important pieces of info. so much more understandable now.

[Hepps]

@hepps Suggestion... bearing in mind I have no idea if it is possible...

[Cernel]

@redrum I would not put the movement value together with the combat values, as it is really something different, especially not setting it apart by a slash. Also, I think the initials only it is too much of a cut. And, minor note, not bolding the slash.

So, instead of this:
A/D/M: 2/3/1

I would do:
Att/Def: 2/3
Mov: 1

or:
2/3 Att/Def
1 Mov

Having the number before the description, especially if all or most numbers would be, now, at the start of the line, makes it easier to read, as they would all be sort on the same column; so, once you know where you are reading, it should make it faster reading.

On the other hand, the transport cost can stay in the same line as the movement, as they are conceptually related, and belong to the same phases; so it could be:
2/3 Att/Def
1 Mov, 2 TC

Side note, while "Transporting Capacity" is a fine naming, I don't like "Transporting Cost", as I would not have "Cost" used for anything else but the purchase cost. So, if possible, I would change the "Cost" in "Transporting Cost" to something else. For example, "Transporting Encumbrance", if that feels ok for an English speaker (also, if they start with a different letter, they wouldn't both be "TC", when written short).

[alkexr]

@redrum I agree with @Cernel that movement should not be grouped together with Att/Def values. Properties that I would put in the same line / same general area: type (land, sea, air), movement, fuel cost; and all transport related properties (transport/carrier cost/capacity, land transportability, air transportability etc.)

[Hepps]

@cernel said in Unit Tooltip Suggestions (Pre-Release Feedback):

@redrum I would not put the movement value together with the combat values, as it is really something different, especially not setting it apart by a slash. Also, I think the initials only it is too much of a cut. And, minor note, not bolding the slash.

So, instead of this:
A/D/M: 2/3/1

I would do:
Att/Def: 2/3
Mov: 1

or:
2/3 Att/Def
1 Mov

Having the number before the description, especially if all or most numbers would be, now, at the start of the line, makes it easier to read, as they would all be sort on the same column; so, once you know where you are reading, it should make it faster reading.

I really think that since so many other things in the tool tip will need to have the definition first followed by a value or defining parameter or colon delimited list, it would far more beneficial to keep things consistent... Descriptor---> value or definition. I really can't see a comprehension issue nor is it any clearer. In fact, it feels kind of backwards to me. If you think about anything in your life you read or do it is always the qualifying thing first followed by the definition or parameter...

Name: John Doe
Rank: Sergent Major
Age: 24

To me it seems to enable comprehension. Since the value is useless until you know what it is for. By placing the definition first it enables our minds to interpret the information in a way our brains are wired to do it. A/D/M 1/2/1 reads logically and I don't have to read backwards to understand.... I simply read the line as though it was in sentence form... Attack/Defense/Movement (are respectively) one/two/one.

I also don't really get the column benefit since you are not reading a vertical column of information. The vertical axis is not of any value unless there is some binding factor that makes them significant to be in a column. Which is not a factor here... we are reading lines of information. The vertical axis has no impact on our ability to comprehend the data.

As far as separating the movement... sounds fine. I was simply suggesting a method to conserve space for the basic info that is present for any non-infrastructure unit. But it would make sense to group movement with things like fuel consumption (for games where it is present).

[Cernel]

@hepps For definitions, like being land or sea, yes. But the numerical values you would say "I have 1 of this, 2 of that...".
Anyways, it can go either ways I suppose. As I said, main reason is that this way all the values are at start of the lines; so you don't have to go search for them so much.
If at the end, which I wouldn't suggest, maybe something like:

Att/Def......2/3
Mov.............1
Something...4

(not necessarily with points)

[redrum]

Yeah, agree with shortening to Placement Requirements and trying to list Placement Restrictions values. I'll take a look at both of those. Good input.

For now, A/D/M will stay together since its displayed like that in other areas (at least purchase screen). We can have a separate thread to discuss updating all of those to a different format.

I'm open to "label: value" or "value label" though my vote is label first (appears @Hepps and @General_Zod would prefer that as well). We can create a poll in this thread if there is enough debate on that.

While I can see not loving Transporting Cost, I'd say Transporting Encumbrance is definitely worse. Maybe something like Transporting Weight?

It would be way to difficult to try to align numbers to the right as some of the properties are much longer than others. Idea is to use bold to make the values easier to read.

[Cernel]

@redrum I hoped you or somebody would have come up with something for that, as "Transporting Cost" is bad also because it rather makes me think something I have to pay to get on the ships, like a fuel cost specifically for that.
How does "Transporting Load" sound?
How does it sound not having Transporting, but just "Capacity" and "Load", or maybe "Encumbrance" sounds ok on its own?
If not cutting, how about "Carrying" instead of "Transporting"?
"Carrying Burden"?
There must be a good word in English for that.
Personally, I'd advise against using "Size" or "Volume", since that is a dimensional thing, while here the limit is usually weight, in case somebody suggests that. Still, I wouldn't use "Weight" or "Mass", either, as too basic.

[Cernel]

@redrum In that case, I at least advise Att/Def/Mov, instead of just A/D/M.

Edit: And, anyways, using the slash as separation doesn't seem correct here, so, even in that case, instead of:

Att/Def/Mov: 1/2/1
or
1/2/1 Att/Def/Mov

I would prefer:
Att: 1, Def: 2, Mov: 1
or
1 Att, 2 Def, 3 Mov

Also, I like and have really no problems with the current:

1 Attack, 2 Defense, 3 Movement

[redrum]

@hepps Placement Restrictions is a list of territories not territory effects so unless its very short (4 or less) then the values won't be displayed. As you definitely don't want a list of 100+ territories like it is in TWW. You'd need to have a new unit property based on territory effects.

    <attachment name="unitAttachment" attachTo="germanMarine" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="movement" value="1"/>
      <option name="attack" value="2"/>
      <option name="defense" value="3"/>
      <option name="transportCost" value="2"/>
      <option name="isLandTransportable" value="true"/>
      <option name="canBeGivenByTerritoryTo" value="Germany"/>
      <option name="requiresUnits" value="germanBarracks"/>
      <option name="unitPlacementOnlyAllowedIn" value="Ontario:Quebec:Northern Central US:Chicago:Detroit:Eastern US:New York:Northeastern US:Washington:Eastern US:Southeastern US:Southern US:Florida Peninsula:Northern Mexico:Northwestern US:Western US:San Francisco:Los Angeles:British Columbia:Alaska:Hawaiian Islands:Eastern Mexico:Panama:Columbia:Venezuela:Rio de Janeiro:Argentina:Chile:Cape Town:Western South Africa:Eastern South Africa:Algeria:Tripolitania:Cairo:Turkey:Western Turkey:Ireland:Scotland:Central Britain:Southern Britain:London:Northern Spain:Western France:Northern France:Vichy France:Low Countries:Northern Germany:Denmark:Eastern Germany:Poland:Leningrad:Eastern Finland:Finland:Northern Finland:Northern Sweden:Sweden:Southern Sweden:Norway:Central Norway:Archangel:Northern Italy:Rome:Sardinia:Sicily:Southern Italy:Northern Yugoslavia:Southern Yugoslavia:Greece:Bulgaria:Romania:Eastern Ukraine:Caucasus:Southern Caucasus:Astrakhan:Western Kazahk:Northern Saudi Arabia:Southern Saudi Arabia:Bombay:Western Madras:Calcutta:Rangoon:Malay:Southern Thailand:Thailand:Saigon:French Indochina:Kwangtung:Hong Kong:Shanghai:Shantung:Peking:Manchuria:Korea:Eastern Manchuria:Vladivostok:Soviet Far East:Hokkaido:Japan:Tokyo:Kyushu Shikoku:Luzon:Phillippines:Brunei:Borneo:Sumatra:Java:Celebes:Dutch East Indies:Dutch New Guinea:Caroline Islands:Wake Island:Southwestern Australia:Southern Australia:Queensland:New South Wales:New Zealand"/>
    </attachment>

[Hepps]

@redrum The thing about placement restrictions is I didn't look to see what can be imposed as a restriction.

Off the top of my head it can be the: PU value of a territory, a terrain, Original ownership of a territory.

I have never really looked at it all that closely to see what else this can be used with, so I don't know how hard it will be.

[Cernel]

@redrum Of course, having a possibly infinite list is not acceptable. Having no list at all is not a solution. Setting some arbitrary cap over which you don't get the list is lame, and not a solution, either, once you hit it.

In any case of listing, meaning something affecting a series of specific items, the info needs to be on the targets themselves, as this is the only viable and effective solution.

If a unit can be placed in a number of territories, you should find in the territory tab that such a unit is allowed there, while the unit itself should have just the info that cannot be placed but in territories that specifically allow it. I would keep the info about what territories only in case the territory is only 1, but still giving the info in the territory too.

If a unit can support a number of units, you should find in those units tooltips that those units can be supported by this unit, while the unit itself should have just the info that it can support some units. I would keep the info about what units only in case the unit is only 1, but still giving the info in the supportable unit too.