ID:1288335
 
Redundant
Applies to:DM Language
Status: Redundant

This feature has already been implemented, or is already achievable with existing methods.
Just requesting that we get a forced line break when there are too many consecutive characters that extend beyond the maptext_width boundary without a space (or other line break character).

Also sorta asking for an efficient workaround while we wait for this to become a feature.
I want to second this.

Because maptext currently doesn't force a line break, my current chat system that uses maptext tokenizes all chat text and splits large tokens in order to force the line break to keep the displayed text within the maptext boundaries.

It works well, but it's kind of slow and I would prefer it if this behavior was built-in (because I'd assume it'd be faster).
Would it make sense to always respect the boundaries and auto-break?
I think it makes sense, but I'm unsure if FIREking or other developers would agree. I feel like there are some cases where not auto-breaking large strings is ideal, but none of these cases come to mind right now.
If it auto-breaks, would it respect HTML/CSS stuff that would cause hyphenation? Auto-breaking without hyphenation would seem weird.


Ideally; maptext should work just like the output (probably with limited styling options, cause, of graphics-related stuff).
Maybe there could be some sort of text macro the enable this behavior? Either way it would be nice to have.
Hell, or even a maptext_wrap boolean variable, something (anything) to force it or not would be pretty epic. Having to manually calculate out a bunch of crap just to make the maptext look half decent is tedious (usually worth it though).

When Tom and I were first talking about maptext I didn't expect it to be so open-ended but I also expected it to be a little more user-friendly, as it was originally billed as a 'quick and easy way to display some text on the screen', having to write up some complicated stuffs to have that text look OK is a whole 'nother story.

Absolutely support the optional usage of this feature.
IMO the main issue with maptext is that it is all rendered on the client so the server can't really anticipate what's there (it'd be nice if we had the font knowledge etc. server side to do this). But I'm sure we can come up with something for this.
Was this ever added?
According to id:903751
yes
this should probably be merged over there
LordAndrew resolved issue (Redundant)