ID:903751
 
Resolved
Maptext did not forcibly wrap by breaking up a long word when it was too big for the given width.
BYOND Version:496
Operating System:Windows 7 Home Premium
Web Browser:Chrome 20.0.1132.57
Applies to:Dream Seeker
Status: Resolved (501.1214)

This issue has been resolved.
Descriptive Problem Summary:
Ok so when using maptext_width and maptext_height vars I noticed a where the maptext leaves its boundaries if a single word is big enough to do so. Also the underlining doesnt seem to work with maptext

Numbered Steps to Reproduce Problem:
1. Create a new project.
2. Create an object and set maptext_height to 64 and maptext_width to 96.
3. Set maptext to a really long word without any spaces
4. Add in the to my tags.

Code Snippet (if applicable) to Reproduce Problem:
obj
hud
icon='hud.dmi'
screen_loc = "1,1"
maptext_width = 96
maptext_height = 64
maptext="<b><u>TestTestTestTestTestTestTestTestTestTestTestTestTestTestTest</u></b>"
mob
proc
add_text(client/C)
var/obj/hud/O = new /obj/hud
O.screen_loc = "10,10"
C.screen += O


Expected Results:
For the word to stay in its boundaries and for the underlining to work

Actual Results:
The word leaves the boundaries and the underlining doesnt work like in this picture

Does the problem occur:
Every time? Or how often?Everytime
In other games?Dont know
In other user accounts?Yes
On other computers?Havent tested


Workarounds:
Not using long words in maptext or extending the boundaries. Not sure for the work around in the underlining


EDIT : Added in the underlining problem into this report
Although I know what you are getting at, I have to say.

You have a closing /b tag that doesn't have an opening tag.

A simple word wrap/cut would be nice.

Oh, and I'm not sure about how often but I've noticed underlining maptext is strange. It doesn't appear. Would you mind tacking that on to this instead of me having to make another report?
sorry for the second /b> closing tag but I just copied and pasted code into the browser and made changes to it so accidentally added the second /b>. Also I will edit the post and add in the underlining thing too.
As far as I can see the lack of underline and not breaking up the word are separate issues. The code doesn't appear to actually plan to break up the word, so that explains that, but the non-underlining I can't explain. This only happens in hardware mode. Strikethrough also doesn't work in hardware mode.
Are you planning to add some word breaking system for maptext in the future or you will leave it this way?

PS. Using
<i></i>
tags in maptext makes text unreadable instead of italic.
Also, to re-iterate from my bug report, on my platform in hardware mode I randomly get italic text and randomly get normal text. It is a failure to apply the font-style property.
Not sure if this is the right place to do this, but... Bump
BUMP.

The black box, is the bound of the obj.

obj/_ChatBox/_chatbox

icon = 'chatbox.dmi'
screen_loc = "WEST: 16, SOUTH + 1: 16"
maptext_height = 200
maptext_width = 240
layer = EFFECTS_LAYER


proc/update()

if(!usr.chatlist.len) return

var/full_message


var/start = usr.chatlist.len <= max_lines ? 1 : usr.chatlist.len - (max_lines + usr.chat_scroller)
var/end = usr.chatlist.len <= usr.chatlist.len - usr.chat_scroller ? usr.chatlist.len : usr.chatlist.len - usr.chat_scroller

world << text("[] || []", start, end)

for(var/i in start to end)

full_message += "\n [usr.chatlist[i]]"

src.maptext = full_message

Lummox JR resolved issue with message:
Maptext did not forcibly wrap by breaking up a long word when it was too big for the given width.
I'm regarding the strikethrough and underline issues as a separate matter. They'll need a different report.
This finally got fixed? :D YAYYYY
In response to Albro1
Albro1 wrote:
This finally got fixed? :D YAYYYY

WOO!!!
This... Actually addresses the last issue I had with maptext.

Gonna start using it soon-ish.
*dance* So many new possibilities.
I'm ready for the new version of BYOND to come out for this can be fixed!