llSetText and HUD's

Ok, I'm making a hud that, among other things is an avatar scanner. When in a busy area with lots of avies, and the other data I'm printing as well, the output string I'm making goes above the 255 character string limit. So, I'm using two strings to store the data. The logic is working perfectly, as, when the first string approaches the limit, I'm moving to the secondary string, and putting the data there. I've used llOwnerSay to display the output, and it's working perfectly well, but, when I print it with llSetText, for some reason, it's chopping off after the first entry in the second string...

my output works fine in an llSay or llOwnerSay:

llOwnerSay (header + output + output2);

but when I use llSetText...

llSetText (header + output + output2);

the header prints, output prints, and the first partof output 2 prints, but not all of output2. Is there a total character limit to llSetText?

Ok, Nevermind...lol, I figured it out. Turns out, llSetText does have a 255 character limit, guess I'll have to maybe try 2 prims

Yes, you are correct on both accounts. So each prim in an object can display up to 255 characters.

Also, note that the newline character set '\n' accounts for 2 characters towards the 255 limit.

The only tricky part with using multiple prims, is to code it correctly, so you do not have any overlapping text between the displays, as well as lining up the displays so they seem as one, if their content is supposed to display that way.

Yeah, the initial plan was to line them up vertically, but the lines move down towards the prim as less avatars are detected. Leaving a big space in the list unless there's 16 avatars in the list. I had to settle with a side by side setup. I guess I could probably get away with adding "\n"'s to fill up the bottom 1/2 of the 2nd output string so it always has 8 lines to it.. hmm.. I also had thought about dynamically moving around the child prims based on the # of names in the 2 strings (Right now it's setup so that first 8 names go into the 1st output string, and anything over that (9-16), wind up in the 2nd string. If I were to add the "\n"s though, when there's one name on the list, it'll be way above the hud... hmm... another thought while writing this.... what I could do is send any output of 8 or less names to the lower prim, and if I go over, send it to the upper prim, and send the additional 9-16 detections to the lower prim. Honestly, as crazy as it's getting I think I might just go the XY text route instead.