Variable anchor for status bars, orbs, etc.

[doofus-01]

I'd like make it clear that the idea has not been dropped and it will be implemented whenever I can spare some hours for a proper implementation (most likely in late December). I marked the FR as postponed for now.

Well then, I stand corrected. My apologies and my thanks.

A decent solution might be to make the bars transparent excluding the unit.

In addition to what Xudo said, it also doesn't sound like it would be very easy to read (assuming I understand what you're proposing: make the bars semi-transparent where it overlaps the sprite?).

[ying]

A decent solution might be to make the bars transparent excluding the unit.

I thought “semi-transparent” but wrote “transparent” because the bar is somewhat transparent.

It does not solve the problem of HP bar over sword of swordsman.

If the problem is why the swordsman has a sword which confused the xp bar got commited to the the stable version in the first place, or more importantly why that bug hasnt been fixed, then, I agree that the “solution” does not solve the underlying problem. However, in my limited experience with Wesnoth, the official issue probably has to do with, “the best available swordsman sprite to commit to the master at that time”. Wesnoth doesn't like terms like “bugs” and “problems.” So, “fixes” and “solutions” are hard to find. Yet, I think the swordsman sprite bug should be fixed. The idea of making the hp bars semi-transparent excluding units may still significantly placate the issue of the placement of the bar for units that exceed the size of the hex.

In addition to what Xudo said, it also doesn't sound like it would be very easy to read

It seems like it would be easy to comprehend the hp and xp values based on being able to view the color and position of the hp and xp bar. Snow terrain could be bad. It seems that completely transparent bars are not the way to go.

(assuming I understand what you're proposing: make the bars semi-transparent where it overlaps the sprite?).

That is the proposition.

[iceiceice]

So actually, the bars already do have some alpha. They have 80% alpha, except for the unit that you have selected or are mousing over.

https://github.com/wesnoth/wesnoth/blob ... r.cpp#L309

I guess it's just not very noticeable.

Wesnoth doesn't like terms like “bugs” and “problems.” So, “fixes” and “solutions” are hard to find.

There might be some truth to this, I'm not sure. I think it might be that we just historically like "hacks" and "frequent releases" more than "systematically making everything work as it theoretically should". I don't know, you get what you pay for.

Try grepping through the source directory for the words "hack" and "HACK" some time.

Yet, I think the swordsman sprite bug should be fixed.

I think I actually agree with you on this -- if the sprite is designed such that the health bars are hard to read because of unfortunate sword placement, it's pretty reasonable to say it's a sprite design error. But in practical terms it might be less work to instate yet another hack like this health bar movement rather than redo all the animations for some core unit.

[Xudo]

Your arguments are very reasonable. Though, there is a "Allow to hide bars and orbs by WML. Default is "always show"." point in my list.
This option might be used in three ways:

• for creating destroyable scenery without hp and xp bar (which looks weird for gates and ships).
• for creating "stealthy" units. This will introduce gameplay problem "don't forget about this one" and add more style to various thugs, assasins and berserkers other stealthy units.
• for solving problem with really big creatures. Those sprites can not be just "redesigned" and "fixed". This is not "hack" and this does solve the problem of hp bar over some dragons face.

To prevent massive bug reports with content: "hp bar is missing", it can be designed like an ability of unit.
Ability tag can be named "[obscures]". It shares common keys and tags for every ability.
In addition, it have two additional ones:

• bar_alpha - alpha value of hp, xp bar and movement orb. Default is 80%
• bar_mouseover_alpha - alpha value of hp, xp bar and movement orb if unit is selected. Default is 100%
• unit_alpha - alpha value of unit itself. Default is 100%
• unit_mouseover_alpha - alpha value of unit if it is selected. Default is 100%

[iceiceice]

Though, there is a "Allow to hide bars and orbs by WML. Default is "always show"." point ihttp://forums.wesnoth.org/viewtopic.php?f=12&t=39570n my list.

Yeah, so I guess I'm questioning whether this is a good idea. If it isn't intuitive to the user that WML can do this then It may only cause interface confusion. Some things probably should not be configurable by WML, only by user preference. For instance, the feature in this thread. WML authors may also want to change the colors of the movement orbs themselves and override the user's choices but they shouldn't because (1) they will probably just confuse the user, (2) the user may have selected them a certain way because of colorblindness or a similar reason.

[*]for creating destroyable scenery without hp and xp bar (which looks weird for gates and ships).

Hmm so at least in my experience, most games do give these things health bars.

[*]for creating "stealthy" units. This will introduce gameplay problem "don't forget about this one" and add more style to various thugs, assasins and berserkers other stealthy units.

This problem seems serious to me but you seem not to think so. I think it was intended to use the ambush ability or similar for this -- "stealth" based on inducing interface confusion doesn't seem like a very fun feature.

[*]for solving problem with really big creatures. Those sprites can not be just "redesigned" and "fixed". This is not "hack" and this does solve the problem of hp bar over some dragons face.

Hack is not the best choice of words here, maybe "workaround" is more fair.

However, I think you forget that wesnoth is not realistic or "to scale" in any sense (WINR, HAPMA). The size of a creature is generally used to indicate its level compared to other units in its advancement path. If you have a unit that you thematically want to be "big" in your universe, just draw it to standard wesnoth proportions and explain its size in the description. If you look at current mainline sprites, the falcon sprite is about as big as the troll whelp sprite, but these units are surely not the same size in universe. It should never be necessary for any reason to make an egregiously oversized sprite, unless you are really doing things that are unintended, i.e. trying to hack together a multi-hex unit or something.

• bar_alpha - alpha value of hp, xp bar and movement orb. Default is 80%
• bar_mouseover_alpha - alpha value of hp, xp bar and movement orb if unit is selected. Default is 100%
• unit_alpha - alpha value of unit itself. Default is 100%
• unit_mouseover_alpha - alpha value of unit if it is selected. Default is 100%

Again I think if these things can be configured at all it should be in the preferences. There's also the "options are bad" theory -- if you overload the user with too many secret configuration options it just means that things are happening for reasons the user doesn't understand, and it's very tedious and irritating for them to change. (Here's a link to a relevant part of the GNOME guidelines for GUI design: https://developer.gnome.org/hig-book/3. ... er-control). In this theory if you are providing way too many options, really what it means is that you are trying to avoid figuring out how to make the system just work acceptably and automatically right out of the box, which is the actual hard part of gui design.

[doofus-01]

However, I think you forget that wesnoth is not realistic or "to scale" in any sense (WINR, HAPMA). The size of a creature is generally used to indicate its level compared to other units in its advancement path. If you have a unit that you thematically want to be "big" in your universe, just draw it to standard wesnoth proportions and explain its size in the description. If you look at current mainline sprites, the falcon sprite is about as big as the troll whelp sprite, but these units are surely not the same size in universe. It should never be necessary for any reason to make an egregiously oversized sprite, unless you are really doing things that are unintended, i.e. trying to hack together a multi-hex unit or something.

Or unless you are trying to draw a high level monster or something, as you even stated yourself...

[iceiceice]

No... there is not realistically any unit whose level is so high that it needs an oversized sprite.

L1: L2: L3: L4: L20: L100: L500:

What did you have in mind, this?

L20:

The above is just an illustration, but even if you really need to have enormously high level units like this for some reason, I know that you don't need to have height scale linearly with level... first of all it's not going to work because I know you aren't going to draw that many sprites. The point is only to use difference in size to show the *relative* difference in levels of units. You don't need Level 51 to look larger than Level 50 in the same way that Level 2 looks larger than Level 1, because 51 and 50 are not that different, but you probably want Level 100 to look larger than Level 50 in that way. Besides just being practical, what I'm trying to point out is that these are not photographs, but icons, so you might want to follow those kinds of conventions.

Second of all size is not the only visual cue at your disposal. It's easy to successfuly portray a high level unit without an oversized sprite:



You can give him fancier clothes, decorations, or illustrate his power with animations... there's so much more creative things you can do than just make him 150 x 150.

And although there are some oversized sprites in the repository, they are not prefered in mainline because they look bad...

[doofus-01]

What did you have in mind, this?

L20: Image

Why, that's exactly what I meant! Are you actively trying to block this, or are you just trying to come up with clever/condescending ways to shoot it down, or what?

Wesnoth is a pretty good engine, why are you trying to impose odd limitations? What is your role in this, exactly - is there any reason for this "debate"?

Look, I can't program this change in status bars, so my continued involvement in this is of limited value, but I'm happy to work with anyone who is wiling & able to continue it. If it's done in a way that makes changes optional, any change to the status bars should be innocuous. If the changes are not innocuous, I'd be happy to work (in whatever limited way that I can) with whoever is involved to make them innocuous-yet-effective.

[iceiceice]

What is your role in this, exactly - is there any reason for this "debate"?

well I was simply responding to ying's remarks, then xudo's. Then yours here:

Or unless you are trying to draw a high level monster or something, as you even stated yourself...

As I've said I'm not strictly opposed to the idea. I do think it's unnecessary, which is probably why it wasn't apparently requested before. But it's also convenient, which is a fine reason to attempt it, as I said also to ying above.

[zookeeper]

Yeah, the game doesn't handle huge bigger-than-hex sprites well, and never has. You get these kind of problems with bars, as well as layering problems with terrain (and other units). Everyone knew that when the sprite biggerization began, yet it was done anyway.

Just one of the reasons why I haven't wanted to have anything to do with sprites for a long time.

[doofus-01]

@iceiceice: All right. I guess we can just leave it at that.

Yeah, the game doesn't handle huge bigger-than-hex sprites well, and never has. You get these kind of problems with bars, as well as layering problems with terrain (and other units). Everyone knew that when the sprite biggerization began, yet it was done anyway.

Handling of "huge" sprites used to be flat-out broken (or non-existent), but it mostly works OK now. Sure, something silly and lazy like substituting firedragons for orc grunts will look like crap, but it can be done in sane and interesting (to some of us at least) ways that keep things from being awkward. As for layering problems with terrain and sprites, I've found that most problems can be overcome if you realize there is a problem. Layering in terrain-graphics seems a little ad-hoc at times, and the "base" parameter is something that still confuses me, but I think the tools are mostly there. Except for the status bars, there are no accessible tools for those.

[lipk]

Bump. I committed a change (again) that anchors bars and orbs to the sprite's topleft. Hopefully no more issues with zooming.

This commit does not add WML configurable anchor positions. If someone wants that really bad, it can be implemented easily by slight amendments to commit 6300d29 and the unit class.