Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
I like that the issue with maptext overflowing was fixed and it now wraps correctly, but I am still left with a dilemma when trying to create an on-screen chat box. Unless I use a monospace font, there is no way for me to tell if a message overflowed onto another line, and therefore if I want to display X amount of lines to the user (In this case, 17), it will bug up when trying to do so because it overflowed to another line and I can't tell.

I'm making this request simply because I would like some way to be able to tell if a line of text (I have them all separated with <br> tags) goes onto a second or even third line in accordance with the font used and the maptext_width.

I'm not sure how possible it is, but it would be very helpful.
Yeah, we're going to need to come up with a way that we want this to work or it will probably be stamped as no-go.

Maybe we should be given the equivalent to the output control with maptext, which would automatically "scroll up" to handle the overflow...

I personally like the idea of having the ability to just strictly use monospace fonts with a graphical font system (instead of developers hacking together screen object systems controlled by the server). Its very annoying that we still don't have something as basic as this. One of the first things you learn to program when making a game with opengl is how to make the client draw text on the screen using little textured quads that have bitmaps of letters on them. I don't understand why the seeker client doesn't have this functionality.

Assuming you really love TTF fonts for some reason (even though you can't predict how they will look on different machines, and you can't measure them at all), I would say you need to think of a clever way to handle the overflow. Without that suggestion, I don't see this feature request having any momentum.
In response to FIREking
I was just using simple Times New Roman 9pt. I'm not super experienced with fonts and stuff so I don't really have any experience with this to be able to give a good, fortified suggestion. I'm hoping someone like yourself with experience can come up with something.

I do like the "scroll up" ability, quite a bit. So long as it could work when using <text align='top'>, it should provide a workable system to create a chatbox with.
This is what I use for the time being.

client/var/tmp/Lines = list()


var/text = ""
var/lines=27//decided on max lines
var/max_character_width = 42
var/actual_lines=length(Lines)//neccessary for count back

while(lines>0 && actual_lines>0)//checks for both
var/v = Lines[actual_lines]//grabs the last line from a list of text entries
lines -= round(lentext(v)/max_character_width)+1//this checks how long a single text entry over the max width
actual_lines--//sub actual lines
if(lines>=0) text = "[v]\n[text]"//arranges lines into a single text line in reverse order
//if lines is less than zero don't show the line, this prevents really long (wrapped over) lines from thinking it can display it's second half and just ignores the whole line.

Update_Maptext("<font align='top'>[text]</font>", "Chat")//update portion

It's not perfect but it handles maptext-overlapping across multiple lines sort of well. It doesn't identify < br >/line breaks though (yet).

My system uses a list (Lines) of text entries, if one entry is too long the display portion does some-extra leg work.

Sort of forgot about < br > tags, but one would just have to figure out a way to count how many were in the given "line" and add that number to
lines -= round(lentext(v)/max_character_width)+1//this checks how long a single text entry over the max width

Update: Butchered FA's split text proc to make this:

proc/CountStrings(haystack, needle)

var/pos = findtext(haystack, needle)
var/start = 1
var/needlelen = length(needle)

if(pos) count++

while(pos > 0)
start = pos + needlelen
pos = findtext(haystack, needle, start)
if(pos) count++

return count

lines -= round(lentext(v)/max_character_width)+1+CountStrings(v,"<br>")

I'm half asleep and molesting split-text that way just kind of pop'ed in my head, there's probably cleaner alternatives my insomniac brain didn't see.
Yeah, it's be nice if we could get some way of telling how long (in pixels) map_text is.

At the moment, the only way of doing this is using some kind of list to keep track of the length of each character used, then looping through each character in the string you're using and adding up the length of it. Then you'd need to find the closest space to the point you want the string to cut off and split it in two.
At the moment, the only way of doing this is using some kind of list to keep track of the length of each character used.

There's another way, but it involves browsers. Basically you pop the text into a hidden div via javascript through the browser with a limited width, and check the height of the div after the contents have updated.

Though, of course, this is somewhat inelegant.
I've been running the chat text through DMIFonts getlines() proc, after setting up a DMIFont the style and size of my maptext, then breaking that up into a list with Forum_Accounts split proc to count the lines, and displaying sections of the chat text list on demand.
Bump, just to hopefully get some attention to this by Tom or Lummox.
Bump, still could use some sort of way to control the overflow of maptext and make it scroll-able.