Art pad 2.3 worksn't


to answer everyone’s first question, yes, i have been able to access the forum the whole time! ha ha. i just wanted to lurk until i read everything i missed, but now that i’m down to the last 10% of unread topics with 90% of unread plays, i’m gonna cut that short a little. just don’t expect me to post to any topics that have hundreds of unread posts in the past two months. [2]

wow, not that often you go offtopic before even establishing what the topic is, sheesh.

yes, i want to update my humble art pad to version 2.3! this version is going to be focused on using the “create a clone” block to cut down on excess editor objects! [3] my regular followers are probably already aware i burned a whole afternoon on cutting down the 73 editor objects that version 2.2 has, to only six! and it mostly works [4]!

here is version 2.3 beta:

and here is the current version 2.2 [5]:

the 73 objects of version 2.2 are divvied up in the clone indices of 2.3 beta as follows:


2.3 clone index 2.2 equivalent
1 “plain pen”
2-6 “wide pen” [6]
7-28 “isnbn pen” [7]

the isnbn pen is broken: the “when ipad is tapped, go to finger” rule doesn’t seem to be affecting it, even though all clones are running it. all pens also lag, but snowdust found a fix for this!

“color squares”:
…ah, y’know what? there’s 32 clones. the first one functions as the 2.2 object “square 1”. i’m sure you can figure out the rest.

anyway, this one has major issues! it’s my primary concern, & i’ll go over it in more detail later.

“save files”:

2.3 clone index 2.2 equivalent
1 “save file 1 – save”
2 “save file 1 – load”
3 “save file 1 – color”
4 “save file 2 – save”
5 “save file 2 – load”
6 “save file 2 – color”
7 “save file 3 – save”
8 “save file 3 – load”
9 “save file 3 – color”
10 “save file 4 – save”
11 “save file 4 – load”
12 “save file 4 – color”

as mentioned earlier, version 2.3 has three other editor objects, but they all work fine.

in order for someone smarter than me to figure out the problem, i’d probably have to explain how i encode color variables on my art pad to strings [8]. for example, i’ll use the hsb color [120, 100, 55], which is objectively the best color. the encoded color starts with a comma [9], expresses the hue in 3 characters [10], and then the saturation & brightness with 2 each. the way this is possible [11] is by subtracting 1 from the integer value before it’s encoded. s = 100 becomes “99”, b = 55 becomes “54”, s = 5 becomes “04”, and b = 0 becomes “-1”. the hsb color mentioned earlier is “,1209954” as a string.

anyway, the “color squares” object starts by generating its 32 clones, then setting the original object’s object variable “color data” to every color on my art pad as a string, sequentially. [12] then, the 32 clones are ordered to assume their familiar grid formation [13], and then extract color variables from the original object’s “color data”, to their own. clone 1, for example, sets its “color data” to the first color string on page 2, followed by the first color string on page 3 [14]. each clone, when tapped, is supposed to set the three variables tracking the active color’s hsb to characters 1-4 of the color [h], characters 4-6 plus 1 [s], and 6-8 plus 1 [b].

well, uh, that’s what’s supposed to happen. in the actual art pad, clones 1-16 all output hsb [0, 1, 1] [15], clones 18, 19, and 20 all have hyphens in their outputted saturation values [16], clones 17 and 21-32 are all reading colors, but they’re all wrong, and none of the outputs change when the page is changed from 2 to 3 [17].

on top of all that, the save files are also not working right! they’re set up in a very similar manner to the color squares: an original object with color data set to four consecutive encoded blacks [18], where the “load” buttons decode the color variables & set the active color to the saved colors, and the “save” buttons overwrite the saved color by encoding the active color to a string. more detail in this subnote: [19] in practice, however, not only do the colors not save right, [20] but the save files’s color squares don’t even display the incorrectly saved colors!

bottom line, art pad 2.3 worksn’t. [21] help would be appreciated.

  1. degug ↩︎

  2. i’m still reading those! ↩︎

  3. while this is the main focus, there are a couple of other changes i’d like to add in version 2.3 that are not in the beta ↩︎

  4. better than i expected ↩︎

  5. the editor features of which will be repeatedly referenced to as i explain the issues with 2.3 beta ↩︎

  6. requires multiple clones to function properly ↩︎

  7. requires multiple clones to function properly ↩︎

  8. oh goigly! oh boy! ↩︎

  9. to ensure it always stays a string ↩︎

  10. “120” ↩︎

  11. when they can both be 100 ↩︎

  12. pages 2 and 3 are separated by a line break ↩︎

  13. which, thankfully, they do correctly ↩︎

  14. “,0009999,0156494” in this case ↩︎

  15. meaning they are all somehow reading “,0000000” in the original color data ↩︎

  16. there are all grayscale colors in the intended result, which is encoded as “,000-1xx”, where xx is the brightness value. this may have something to do with it ↩︎

  17. completely defeating the purpose of a page ↩︎

  18. “,000-1-1,000-1-1,000-1-1,000-1-1” ↩︎

  19. basically, i accounted for all four save files at once. when “save” is tapped, it first checks which save file it’s saving to based on clone index & the ceiling function. it then sets the saved color data to: every saved color in every previous save file, unchanged, then the active color, encoded, then every saved color in every following save file unchanged. the active color is converted to a string as: “,”, then “hue” as a string with the “join” block, then a “0” if saturation is between 1 and 10, “00” through “09”, then “saturation” minus 1 as a string, then that whole same thing with brightness. ↩︎

  20. i can’t seem to find any rhyme or reason to the incorrectly saved colors, but maybe i’m missing something ↩︎

  21. never gonna give you up! ha!! get rickrolled ↩︎


i am completely unable to save any colors at all?

The color squares is a timing issue, original object color data isn’t set until after most of the clones have already checked it, though both page 1 and 2 seem to have the same colors, is that expected?


from my experience this is not the case – the rectangles intended to display the saved colors are incapable of doing so, while a color is saved internally [even though it’s wrong], which can be accessed with the “load” button

no [1]

  1. the game starts on page 2, page 1 is the page with the save files ↩︎


tapping save then load doesn’t change the color at all and I can’t get a pop up to show when i try to save a color

It looks like it is reading the saturation as the hue for page three (unless I’m doing the math wrong) (I got it is reading index 13 which is the begining of the saturation of the second color in the screenshot above) so I’m not sure why they both look the same, they should be totally different…


oh no

wait if that’s clone 2’s “color data” then it should be outputting the hue as “,02”. that 9 at the beginning should not be there


i thought that at first too but it looks like it looks for page 2 hue starting at index 2 which would be correct for that



that should not be happening

two wrongs made a right for once



i finally managed to get 2.3 to have different colors on pages 2 & 3! the change was made by making the original “color squares” object set its preset color data before creating its clones. this barely noticeable change caused every color square on page 2 to output hsb [9, 100, 100] which is “,0099999” and every color square on page 3 to output hsb [209, 100, 100] which is “,2099999”.


e: nevermind the pages don’t change anymorebut it’s a lot closer


@Petrichor please help me this art pad is almost working as intended

synopsis of errors:

  • the far left column of color squares seems to be shifted up one, removing the bright red square, from 2.2, and treating the bottom left square as though its h-value has a comma in it [this is because pages 2 & 3 are separated by a line break, which would be accounted for if the left column were reading correctly]
  • page 3 is displaying slightly darker versions [brightness lowered by 7] of the page 2 colors, instead of the page 3 colors
  • the save files are somehow even more broken, even though i did nothing to them
  • the grayscale colors are all incorrectly displaying as black
  • incorrect colors [brightness all slightly off]:
    • [120, 100, 60] should be [120, 100, 55]
    • [150, 95, 95] should be [150, 95, 100]
    • [300, 100, 80] should be [300, 100, 75]
    • [300, 35, 95] should be [300, 35, 100]
    • [0, 0, -8] should be [0, 0, 0]
    • [0, 0, 32] should be [0, 0, 35]
    • [0, 0, 95] should be [0, 0, 100]
    • [35, 50, 70] should be [35, 50, 64]
    • [30, 100, 94] should be [30, 100, 100]
    • [35, 50, 60] should be [35, 50, 52]
    • [35, 50, 32] should be [35, 50, 40]
    • [240, 10, 90] should be [240, 10, 85]
    • [335, 60, 95] should be [335, 60, 100]
    • all other colors are correct [if misplaced]

geez 2.3 does as 2.3 pleases


60 … should be … 55
-8 … should be … 0
80 … should be … 75


how does this even happen lol

i am not sure if this is the cause of the issue, but the order of clones seems to be starting from the second column, then third, then fourth, then first for each row, so the top left square seems to actually be clone index 4. Is that intended?

Also, your math to get the color data seems confusing, and it also seems to return nonsensical values. I am not quite sure what the correct behavior is supposed to be, may you explain in a bit more detail what you are trying to accomplish, specifically why you chose the specific values and formulas you did?

Also, I’m not sure what the color data for after the first page should be, you join something based on its length at the end of it?

And looking at it some more, I don’t understand how it is getting the correct color at all…

Could you give some examples for expected values of self color data for the clones?


i have zero clue :skull:

that’s probably it, but i don’t know what in my code is causing that. each clone’s y-value is based on the ceiling function of its clone index divided by 4, so the top left one should be clone 1…

okay, so basically, an encoded color is eight characters long, [1] so the first page of colors in the original object’s color data, which is the 32 colors in order followed by a line break, is 32 * 8 + 1 = 257 characters long. the clones’s process is to find each color is by finding the first color in the original object’s color data, setting its own color data to that, then searching for the next color, and appending it to the color data. [2] it does this by setting its color data to the original data at character index (clone index * 8) - 1 to (clone index * 8) + 7, getting the entire eight-character color. since the clone’s color data is always 8 times longer than the number of pages it’s checked, it then does the following: set its color data to: join (self color data) with ((characters in (original object color data) between (what i just said at the end of the previous sentence + ((length(self color data)/8) * 257))) [3] the expected result is exactly the same as version 2.2, with the one expected difference, of course, being that the title says “2.3 beta” instead of “2.2”. the color values themselves also come from this version directly, although i believe most of them are over five years old now.

yes. the intended result can also be found in 2.2

basically what’s in each color square’s preset color data in 2.2. the one difference is that the second color [the one intended to appear in page 3] does not have a comma before it, while the first one does. in 2.3, both colors should have commas before them.

  1. the comma & seven digits: e.g., “,1209954” ↩︎

  2. i also run this process another eight times, so i can easily add more pages in the future, but this should theoretically not affect the result as those characters shouldn’t be checked by anything ↩︎

  3. i.e., shift forward by the number of already checked pages times the character length of one page ↩︎


Why ceiling?

I thought that the first color started at index 0 in the original data? When I changed that to characters_at((clone_index-1)*8, to: clone_index*8) it got correct-seeming data so I’m confused as to why you are skipping all but the last character of the first color

I’m still confused about why you add this to self color data, it never seems to actually be used?

So an expected total self color data would be something like

black   white   ??



i used ceiling as opposed to floor to prevent the thing that is happening right now to happen [so clearly i didn’t do a very good job] basically, clone 1 does ceiling(1/4) which is 1, clone 2 does ceiling(2/4) which is 1, same for 3 & 4, and those are the ones that become the top row of the color squares. if i used floor instead, 1, 2, and 3 would output 0 while 4 outputted 1, which would shift the row containing multiple of 4 clone indexes, down 1. however this actually happened & i have no clue why

oh yeah it does start at 0… uh oops! oh no i will fix it

theoretically it should be used in the page 3 colors but the page 3 colors do not seem to do that

correct except the 514. where did you get that


thats the weird length thing that gets added after every page except 1


but that’s what the second color is isn’t it?


no i meant every page after 2, not 1

so it ends up as first color, second color, length, third color if it would exist, length, etc.


wait the length itself gets added?? i thought the length was just used to find the correct character index in the original color data


No, that’s just the clone index times 8 minus one (did you mean clone index minus one times eight?) which isn’t actually correct at all, it would be the first color repeated for every page


(clone index/8)-1

well that would explain this


wait why? Are you sure?