Better tooltips for banners and signs

[Xkeeper0]

Here is an implementation of the request in issue #8593.

• Adds tooltips to signs that are visible on hover.
  • Scrolling signs that have colored text use the text's color.
  • No entry signs show "No entry".
  • 3D landscape signs and other scrolling signs display their text.
• Changes some of the localization strings.
  • Addition of a new string for sign tooltips that resets the tooltip formatting.
  • Banner messages that ended with - - have had that trimmed.
    • STR_RIDE_ENTRANCE_NAME, STR_RIDE_ENTRANCE_CLOSED, STR_PARK_CLOSED, STR_NO_ENTRY ...
  • Those banners now use STR_BANNER_TEXT_FORMAT or STR_SCROLLING_SIGN_TEXT to provide the final - -.

One small issue is that new signs that have not been edited yet will show the text "Sign" instead of the default nearby-ride name, but the tile inspector does this as well.

---

[Gymnasiast]

The CI fails because of the formatting. Specifically, the following changes should be made: https://travis-ci.org/OpenRCT2/OpenRCT2/jobs/487190950

Formatting can be automatically done via the clang-format utility, or by git adding files, then doing git clang-format, followed by another git add.

[ZehMatt]

I do appreciate the banner text on hovering them but not a big fan of using the banner colors, I think it would be enough to know what the banner text is.

[Gymnasiast]

@ZehMatt That would require stripping formatting codes from the banner text. I don't think it's worth that. And personally, I do like the presence of the text colour.

[ZehMatt]

They are not too bad but when you hover over a banner with red text for like a short time during scroll/zoom you can potentially think that you just saw an error. When it comes to text I would a maximum have 3 colors that I use which is different when it comes to real world banners. How hard would it be to just skip color formatting for a specific string.

[Gymnasiast]

@ZehMatt Probably harder than you think. The banner text is saved in a stringid with the formatting code baked in. It requires copying and processing the string. All of this because of what I consider to be a cosmetic thing.

[ZehMatt]

I think that is not correct, the banner stores only the raw string id, Banner.Paint combines that string with another to the color.
See here: https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/openrct2/paint/tile_element/Paint.Banner.cpp#L101

[Ryder17z]

Either what @Gymnasiast said, or duplicate strings (one formatted, one not formatted) for each sign. Neither is really worth it I'd say.

[Gymnasiast]

@ZehMatt That's not what the code says. It always combines with string 1731, which is:

STR_1731    :{WHITE}{STRINGID} - - 

This combines the string-with-colour with the - -.

Since I have done more stuff with banners, I'm very sure it saves the colour formatting tag in the stringid itself.

[ZehMatt]

You are right, for some reason it always puts the final formatted string there rather than keeping string and colours as separate data. Well then it can't be helped I guess.

[jensj12]

As far as I know, this is the only map tooltip with 3 lines. Does it work properly with the bottom toolbar enabled (RCT1 style)?

[Xkeeper0]

Thank you for the feedback! I'm going to work on implementing the suggestions here and should have an update Soon™, hopefully.

---

As far as I know, this is the only map tooltip with 3 lines. Does it work properly with the bottom toolbar enabled (RCT1 style)?

I had checked it before submitting it (one of my roommates uses the bottom toolbar, thankfully) and it ... almost works. The text does fit (though it is a tight squeeze). But the expanded text uses tooltip formatting, which doesn't match the bottom toolbar. (It's also missing the outline...)

This seems to be because openrct2-ui/windows/MapTooltip.cpp:168 uses STR_MAP_TOOLTIP_STRINGID, but openrct2-ui/windows/GameBottomToolbar.cpp:721 handles drawing the tooltip itself using STR_STRINGID. I'm not sure if there's an easy way to say "reset to the default tooltip styling" in formatting without having to check against UITHEME_FLAG_USE_FULL_BOTTOM_TOOLBAR every time, though.

---

They are not too bad but when you hover over a banner with red text for like a short time during scroll/zoom you can potentially think that you just saw an error. When it comes to text I would a maximum have 3 colors that I use which is different when it comes to real world banners. How hard would it be to just skip color formatting for a specific string.

For normal tooltips, you have to hover over them for a short period of time before the tooltip displays. For the bottom toolbar, though, that is true.

---

The CI fails because of the formatting. Specifically, the following changes should be made: https://travis-ci.org/OpenRCT2/OpenRCT2/jobs/487190950

Formatting can be automatically done via the clang-format utility, or by git adding files, then doing git clang-format, followed by another git add.

I knew it had a good chance of failing the code format tool. At the time, I didn't have clang-format handy. I'm going to follow this advice and push out an update to fix the formatting :)

---

I did encounter an issue with some testing last night. Some rides, apparently most tracked ones, suffer an amusing bug in that when the ride is unnamed, the entry hut banner shows "(Ride Type) #", except instead of being the auto-incremented number, it's a rapidly-incrementing number related to the scrolling of the text. I suspect it's something I may have fouled up with openrct2/paint/tile_element/Paint.Entrance.cpp:169, but I'm not immediately sure how (nor why it only seems to break for certain ride types). The queue banners display the names as expected.

[janisozaur]

@Xkeeper0 thanks for your contributions, but it appears you have to rebase in order to resolve conflicts with translations.

[Xkeeper0]

@Xkeeper0 thanks for your contributions, but it appears you have to rebase in order to resolve conflicts with translations.

I used Github's web UI to resolve the conflict by adjusting the numbers I used.

[janisozaur]

@Gymnasiast is it ok now?

[AaronVanGeffen]

You accidentally stripped whitespace in the en-GB file.

[Xkeeper0]

You accidentally stripped whitespace in the en-GB file.

Can you clarify where the whitespace was stripped? Github's "See review" doesn't seem to show any comments or changes and when I checked with diff, I didn't see any unintentional whitespace deletions:

In this case, the change of - - after Closed, No entry etc. is "fixed" by recycling the generic banner formats STR_BANNER_TEXT_FORMAT or STR_SCROLLING_SIGN_TEXT, which include the spaces themselves.

Strings were changed intentionally

[AaronVanGeffen]

@Xkeeper0 Thanks for pointing that out, I missed that bit!