Updated object sizes under "Enabled Mods Wrapper"

@marder @Stan
Instead of trying something with additional mouse hover tooltips, I added the proposed text but made the room for it larger to fit. The window resolution is 1024x768. I'm not sure if the result can still be considered "nice" (admittedly, I have some doubts), but I just wanted to ask you for your thoughts. Should this be discussed in the forum, too (so others can also share their ideas)? I would create a new thread. Under "Game Development & Technical Discussion"? I know that this is of very low prio and likely of minor interest, so please regard this also as an exercise for me to learn. Thanks for your patience and your time. ;) And have a nice weekend! :)

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Inlines. I'm not sure (yet) how to fix the hotkey stuff.
Also an artist might want to create a nicer icon.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Some more inconsistencies.

In D4267#181475, @bb wrote:

However if a unit is attacking a target which becomes miraged by another entity (i.e. its mirage) then the unit will keep attacking the parent (i.e. the original target). This will probably be very hard to fix.

Yeah, I meant this, sorry. ^^

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Fixing indents, fixing the default warning text and storing the position in a variable.

I suppose we should set the "center" default to the ModernInput, so that all input fields can benefit.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Add m_TextVAlign.

Was thinking about upgrades but D2652.

A few of the descriptions end with a period. IMO all of them should.

Another solution would be to #ifdef the usages of freetype. Up to you;

However when the mirage is unmiraged the order is still the parent (which is bad),

I don't think so: when a mirage is unmiraged there is an onEntityRenamed message send, which will change the order in unitAI, so the order should be set correctly in that route. However if a unit is attacking a target which becomes miraged by another entity (i.e. its mirage) then the unit will keep attacking the parent (i.e. the original target). This will probably be very hard to fix.

Okay so as @wraitii said build fails on macos because path is

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

In D4108#181466, @Stan wrote:

Forgot the build-osx-libs.sh file :)

Thanks!

Forgot the build-osx-libs.sh file :)
Need to update the dockerfile too

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Uses @s0600204 and @wraitii patches.

Fixed in rP25851

Successful build - Chance fights ever on the side of the prudent.

My concern has been fixed.

Successful build - Chance fights ever on the side of the prudent.

My concern has been lifted.

const

The problem was fixed in changeset rP25912.

I'd say that clicking the minimap wouldn't flare, but move. One can flare by using the hotkey/button.
(Also, calling it a minimap is quite strange. ^^ )

Tests run correctly, don't see a significant slowdown. Reads correct and complete.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Add general comment to the function.

Btw reference file for stk is here https://github.com/supertuxkart/stk-code/blob/master/data/supertuxkart.desktop

Committed in rP25905.

Patch looks okay, compiles and seems like a move in the right direction.

In D3424#181342, @bb wrote:

Now I am not so sure if doing this on the cart houses is good gameplay wise (it renders the up pretty useless if one first loses pop to get a little more, s one won;t need to have more houses to start).

For what it's worth, this was intended to make upgrade less good, as it's currently very efficient since it takes no builder (something that e.g. Nescio didn't like in the Tower case IIRC). Giving a temporary debuf allows balancing the cost in resources & build time vs the ultimate bonus. Whether the current balance is good is quite debatable.

In D3424#181342, @bb wrote:

I would more see a usecase in towers losing there arrows during upgrade.

That perhaps sounds more like #5889? (Upgrading state so one cannot be in the attacking state.)

For the fun of it we could add GenericName=Real-Time Strategy Game too

Sounds like a great addition. Now I am not so sure if doing this on the cart houses is good gameplay wise (it renders the up pretty useless if one first loses pop to get a little more, s one won;t need to have more houses to start). I would more see a usecase in towers losing there arrows during upgrade.

grepping playernameText.caption (case insensitive) yields no more instances

I kinda like the approach of a 3rd-party positioning class. I had some reserves about overcomplicating layout logic, but it doesn't seem bad here.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

@Kate do you want to work further on this patch? Otherwise I could commandeer and do the JavaScript part.

In D4266#181310, @Stan wrote:

points more toward a will to get A23 back than an actual need for those animals.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Don't align the history filter

In D4266#181310, @Stan wrote:

Maybe they were removed due to a lack of animation? The link in the summary points more toward a will to get A23 back than an actual need for those animals.

Sorry the comment was two down from the original link. I fixed it in the summary now.

Maybe they were removed due to a lack of animation? The link in the summary points more toward a will to get A23 back than an actual need for those animals.

In D4086#181288, @Feldfeld wrote:

I see, it indeed makes sense. Well you can do as you want, the current snow distribution works and it's true that my suggestion could turn out weird in the end.

Thanks :) Yes I agree that the snow distribution is subotimal, the problem is the the new snow textures don't blend well with other textures, therefore it is hard to reach a natural looking result either way. But I can try the ways you proposed.
It should be noted however, that the current distribution is at least semi realistic. When the first snow falls, the forest floor is usually not covered, as the snow fall on the trees and melts there with the next sunshine.
In spring it is the other way round: snow stars to melt on open ground as the sun shines on it, but the snow that has fallen over the course of the winter inside the forest is covered in shade and survives longer.