Abandon Penitence Textbox Overflows

[NeonPixels]

When abandoning a custom penitence that has a very long description, the textbox overflows. If possible, adding the scroll bar functionality would solve this.

[NeonPixels]

Investigating the code, the only difference I see between the ChoosePenitenceWidget and AbandonPenitenceWidget regarding the textbox is that the former has the following attribute:

[SerializeField]
private CustomScrollView penitenceScroll;

This is initialized when adding the description text to the textbox:

public void Option_SelectPE01()
{
    this.penitenceTitle.text = ScriptLocalization.UI_Penitences.PE01_NAME;
    this.penitenceInfoText.text = ScriptLocalization.UI_Penitences.PE01_INFO;
    this.penitenceScroll.NewContentSetted();
}

So if there is a way to add the attribute and initialize it when setting the AbandonPenitenceWidget description, it might work.

[NeonPixels]

Hmmm, looking more into it... First of all, we can't use patching to add properties to classes, so we can't add a CustomScrollView to the AbandonPenitenceWidget class, as far as I know.

Then the CustomScrollView needs to have its area defined on the Unity editor.

Not sure how to do a workaround for this.

[BrandenEK]

If we can fix that I would certainly like to have it in here. However, the CustomScrollView is almost certainly a component that was placed using the editor, so it will be very difficult to create a new one and add it to this UI element

[NeonPixels]

I will tinker with it eventually and see if I find a solution, but right now I think it is more of a "nice to have" feature, specially since it seems like it requires a lot of work for little gain.

Maybe a simpler fix in this case would be to trim the description text so it always fits on the textbox. The description will still be incomplete, but it won't look as ugly.

I'm going to do a couple tests to see how many characters fit in the box for the different languages and will report back.

[NeonPixels]

Made the following tests. The '.' character indicates 50 character blocks, and the ';' indicates 100 character blocks. Of course, the '.' and ';' need to be counted too. These are the results with the different character sets:

• Base font (Spanish, English, German, French, Portuguese):

• Chinese font:

• Russian font:

• Japanese font:

• Korean font:

[NeonPixels]

So I have tried cropping the text in the code and... It isn't as simple a fix as it seems. This is how it looks when cropping to 400 characters using the basic font:

The problems with this approach are the following:

• The fonts are not necessarily monospace, so a hard cap on the number of characters will not guarantee that the text is cut properly
• Asian fonts are much larger, so trimming the text to make them fit will excessively trim all other fonts, unless the code detects the language and applies a font-specific character limit.
• Newlines count as single characters, but add an entire line to the text (each line is approximately 35 characters long in the base font), and, worse yet, there is no easy way to know how many characters are already in the line before the newline. So unless the trimming code does some magic to manage newlines, the hard cap won't always work.

So the "simple" solution is not that simple after all.

[BrandenEK]

Can you try setting the height of the text field and possibly changing the overflow mode so that it cuts off the text automatically

[NeonPixels]

Will look into it!