Skip to content

Conversation

@github-actions
Copy link
Contributor

Description

While waiting/hoping for the issue listed here to be resolved, I had an idea of how to implement it via an extension.

By default, due to how Yarn's clipped text works, word wrap will only happen after the maximum width is hit. This means there are partial words typed out before they jump to the next line, which is jarring and unprofessional for dialogue.

This extension will allow someone to define a "maximum characters before wrapping" then use the full Dialogue Line to calculate where all linebreaks should be for full words. It then does some math and substrings to build out the proper output expression, using the Clipped Line to keep the typing effect. The events support up to a maximum of 8 lines, and should not be used with trigger once otherwise they cannot behave like the standard ClippedText expression.

This has been tested and works with BBText, Bitmap Text, and regular Text objects.

How to use the extension

  1. Set up your text object with your desired font and text site.
  2. Add the text object to the scene, sized to the desired width.
  3. Add an example/placeholder text.
  4. Manually count the number of characters before the line wraps, or copy the placeholder text from before the wrap into a character counter. This is your maximum line characters.
  5. Set up yarn dialogue events as described in the wiki and the existing examples.
  6. Instead of setting your text object's text to the normal DialogueTree::ClippedText(), set it to EnhancedYarnWrap::ClippedText()

Checklist

  • I've followed all of the best practices.
  • I confirm that this extension can be integrated to this GitHub repository, distributed and MIT licensed.
  • I am aware that the extension may be updated by anyone, and do not need my explicit consent to do so.

Example file

YarnWrap.zip

Extension file

EnhancedYarnWrap.json.zip


Extension by @Silver-Streak

You can update the extension on this "Pull Request" by commenting the update command: in the comment field, type !update, then drag and drop a zip file with your extension file in the commenting field, like how you initially submitted the extension. It should look like this:

!update [MyExtension.zip](https://github.com/GDevelopApp/GDevelop-extensions/files/12709661/MyExtension.zip)

It can take a few seconds for the file to fully upload and show as the above. Once it is like shown above, click "Comment" and let the bot do the rest!

@github-actions github-actions bot added the ✨ New extension A new extension label Jan 13, 2026
@github-actions github-actions bot requested a review from a team as a code owner January 13, 2026 03:09
@D8H
Copy link
Contributor

D8H commented Jan 13, 2026

Thank you for submitting an extension.

Does this extension only work for monospaced fonts?

Have you checked how the auto-typing extension work around this?
https://wiki.gdevelop.io/gdevelop5/extensions/auto-typing/

@Silver-Streak
Copy link
Contributor

Silver-Streak commented Jan 13, 2026

Thank you for submitting an extension.

Does this extension only work for monospaced fonts?

Have you checked how the auto-typing extension work around this? https://wiki.gdevelop.io/gdevelop5/extensions/auto-typing/

From my testing it should work for any font, albeit the dev will need to manually find what they want the safest character count to be (i.e. they should set it to wrap at the least amount of characters that are reasonable to avoid lines that get wrapped too late)

Unfortunately, the auto-typing extension in question didn't seem to work for Yarn dialogue line based text at all, and also still had instances where some characters were typed on line 1 before wrapping the word into like 2, so visually it would jump between the lines.

I tried to debug that before I went too far into building something new, but it looked like it had to do foundationally with the way the formulas were set up (best guess was that it was only checking one character ahead rather than finding the latest start/stop of a word?)

Since I explicitly wanted something to address needs around Yarn dialogue text (i.e. could work explicitly within normal Yarn dialogue event setup without needing anything extra done so it could be drop in-place), it didn't make sense to further try to debug that visual behavior on the other extension.

@D8H
Copy link
Contributor

D8H commented Jan 13, 2026

Unfortunately, the auto-typing extension in question didn't seem to work for Yarn dialogue line based text at all, and also still had instances where some characters were typed on line 1 before wrapping the word into like 2, so visually it would jump between the lines.

The auto-typing behavior writes 1 word ahead and if the text object height changes, it reverts it (before it get displayed) and put a line break instead.

Just to make sure, you tried the auto-typing behavior without Yarn own auto-typing, right? Because using 2 auto-typing at once will only add up the bugs from both of them.

Do you still have the test project reproducing issues with the auto-typing extension?

From my testing it should work for any font, albeit the dev will need to manually find what they want the safest character count to be

The issue is that "i" is smaller than "m" unless the font is monospaced, so some lines will be too short.

@Silver-Streak
Copy link
Contributor

Just to make sure, you tried the auto-typing behavior without Yarn own auto-typing, right? Because using 2 auto-typing at once will only add up the bugs from both of them.

Correct, I was testing using just regular text thrown into a text object, and also tried via setting the object to the LineText expression for Yarn rather than Clipped text, which had a lot of complexity to work at all compared to just using normal Yarn events. At that point I stopped investigating as my goal was to integrate this into existing Yarn event workflows rather than replace them.

I don't have the example project anymore because I quickly gave up on it after the initial investigation, but I'll see if I can reproduce it later this week if desired, although that wouldn't replace this being a separate extension for the above reason.

The issue is that "i" is smaller than "m" unless the font is monospaced, so some lines will be too small.

Yes, this should still work fine so long as the dev finds the right character minimum count for wrapping, some lines will be shorter but only by a few characters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

✨ New extension A new extension

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants