2.6 Overflow units should use the width of the unit & not the width in map.properties

[TheDog-GH]

I view this as a problem, but it could also be a feature request.

The overflow of units is governed by these map.properties units.width=96 units.height=68

. units.width=60 units.height=54

It would be really good if the overflow would just use the width of the units displayed, Possibly like the task bar units, although Im unsure.

In 1941 Global Command Decision the biggest unit width is 98px and the biggest hight is 66px, the smallest unit is 54x54px

@frigoref maybe one for you?

[Cernelius]

As usual, this matter is disputable because these two widths are supposed to be the same, although TripleA does not enforce this limitation.

[WCSumpton]

As usual, this matter is disputable because these two widths are supposed to be the same, although TripleA does not enforce this limitation.

I am not sure I understand what you mean by this. TripleA uses place.txt to define the placement of images. And even here it tries to center the image in the given space. There is no defined space for overflow units. The system uses the information in map.properties to create an area to contain the image. If all images are the same, then there is no problem. In GCD they are not the same, and overflow images tend to look strung out. Using the image width would make for a more compact line.

This would only be a visual effect, and would have no effect in game play.

As @TheDog-GH has asked me to look into this, I have developed a process.

Cheers...

[Cernelius]

As usual, this matter is disputable because these two widths are supposed to be the same, although TripleA does not enforce this limitation.

I am not sure I understand what you mean by this.

You are supposed to have your units images having the dimensions specified in the properties of the map, so the "width of the unit" should always equal the "the width in map.properties" for every unit, making what requested at this issue substantially irrelevant.

TripleA uses place.txt to define the placement of images.

Yes.

And even here it tries to center the image in the given space.

No, it does not: it just draws each them from a corner of the image itself according to fixed coordinates. I would partially agree, however, if you are talking about the program generating the "place.txt" file.

There is no defined space for overflow units.

No, there is: if I recall correctly, it is drawn from the last coordinates for the zone in the "place.txt", and you can also specify in which direction the overflow shall go.

The system uses the information in map.properties to create an area to contain the image.

Yes.

If all images are the same, then there is no problem.

As I said, them all ought to be the same by them all having the dimensions specified in the properties of the map.

In GCD they are not the same,

Then, the map-maker either has done something which he or she has been told not to do or did not read the documentation in full. This all, of course, according to my own interpretation of the aforementioned documentation.

and overflow images tend to look strung out. Using the image width would make for a more compact line.

Sure.

This would only be a visual effect, and would have no effect in game play.

I disagree, but I guess that by "in game play" you mean "on the rules as enforced by the program" or "on what you can and cannot do beside display-only-related limitations", with which I would agree. For example, a shorter over-flow line may make you able to click on a unit which would be otherwise hidden by the over-flowing units (not to mention the fact that overflow-lines which are too long can even go outside of the view itself for maps which do not wrap on the X axis, this not being relevant to this map).

As @TheDog-GH has asked me to look into this, I have developed a process.

Good luck.

Cheers...

Cheers.

[frigoref]

This was already discussed in issue 12447 (2.6 Combat Move units with a double click - units are truncated & ...). There is not general solution on how the scaling should occur (would depend on the way the images are created), so I think it is fair to leave it to the map maker to create same size unit images according to the map specific file map.properties (values for unit.height and unit.width). It is possible to have "smaller images" by just making more of the image transparent, so scaling to adjust the different images can be done "outside" of the triplea code base. Maybe it should be enforced in the map making process in the future to avoid similar issues being opened here.