10 posts
Location
USA
Posted 19 June 2016 - 07:55 AM
screenshot of getting error, and showing they are same length
https://www.dropbox.....46.22.png?dl=0screenshot of the code being ran
https://www.dropbox.....51.00.png?dl=0-EDIT: added more printouts and wrote down the output. screenshot
https://www.dropbox.com/s/ay4gjufl3kalkn0/2016-06-19_03.34.44.png?dl=0anyone have any ideas on this one? im lost :/
Edited on 19 June 2016 - 07:19 AM
7083 posts
Location
Tasmania (AU)
Posted 19 June 2016 - 09:20 AM
By my count, you've got two more characters in "tt" (and the identical text you attempt to blit) than you do in blitb / blitc (a space, and \n).
Not that you can properly blit a line break anyway. That'll likely show up as a question mark instead.
10 posts
Location
USA
Posted 19 June 2016 - 09:23 AM
I think part of the issue is TL is reporting 8 when ran, yet its only 4 characters? I see what your saying about TT, still stuck :/
7083 posts
Location
Tasmania (AU)
Posted 19 June 2016 - 09:29 AM
Consider:
#("7" .. tl .. "7" .. ml) == #text + #message + 2
#("[" .. text .. "] " .. message .. "\n" == #text + #message + 4
All arguments you pass to term.blit() must be of the same length, hence the error.
Your later screenshot furthermore makes it look like you're using two characters for tc, when you should only be using one.
10 posts
Location
USA
Posted 19 June 2016 - 09:34 AM
changing TL to use one character instead of 2 gave same output. says 8 characters total even with it set a
text = "text"
tl = string.rep(c, #text) — reports 8 characters
7083 posts
Location
Tasmania (AU)
Posted 19 June 2016 - 09:37 AM
What's "c"? Check that you haven't made any typos within the script proper, and if you're still stuck,
pastebin the rest of the code and provide a link back here.
10 posts
Location
USA
Posted 19 June 2016 - 09:41 AM
http://pastebin.com/CwhasxD0thanks bomb for helping me with this, i know i must be just missing something obvious
7083 posts
Location
Tasmania (AU)
Posted 19 June 2016 - 10:02 AM
That's not all of it; you're calling log() from somewhere, and it's that call which is providing the invalid value for "c".
You also still need to correct your string constructions:
local tt = ("["..text.."] "..message) --# Because you can't perform line-breaks mid-blit
local blitc = ("7" ..tl.. "77"..ml) --# Extra "7" so's the lengths match
10 posts
Location
USA
Posted 19 June 2016 - 10:17 AM
im running it with simple test script
http://pastebin.com/mPxiY4y8ok, i see why its broke, just have to figure out how to fix it.
added printouts of it all and ran, screenshot here
https://www.dropbox.....14.15.png?dl=0blit uses the paint part of the color API and colors.whatever returns in decimal? … i think thats the issue, if I specify it with paint numbers, it works, if I use
for example, colors.yellow , then it returns 16 and breaks it
EDIT: solved that, now is there a better way to do this?
updated script link here:
http://pastebin.com/xcM7wfVEEdited on 19 June 2016 - 08:33 AM
7083 posts
Location
Tasmania (AU)
Posted 19 June 2016 - 10:45 AM
Well basically yeah; term.blit() wants one foreground / background character to represent each character within the text. You can't represent colours.yellow (the number 16) as "one character" without some sort of conversion.
I tend to use a lookup table for this sort of thing:
local colourChar = {}
for i = 1, 16 do colourChar[2 ^ (i - 1)] = string.sub("0123456789abcdef", i, i) end
liblogger.log("text","message",colourChar[colors.yellow])
10 posts
Location
USA
Posted 19 June 2016 - 10:57 AM
that works flawlessly, thank you very much. I was going crazy trying to figure this one out. that lookup table helps alot. thank you
