thank you!! glad you're feeling inspired to make stuff too :)
june-tree
Creator of
Recent community posts
Quick question about brushes: seems like there's a global brush[] function to add custom brushes (and see a dictionary of them). Is there any way to (through scripting) change which brush is selected at the deck or card level? I know there's clicking on the Style>Brush menu, but I would prefer to do it with scripting (as the brushes I've made are more like stamps and are huge and overlap quite badly on that menu).
I only see the canvas-specific x.brush[] in terms of script control over brush selection... Is that it?
thanks! june
"They are unworthy. To make you feel unworthy."
shiragiku telling the truth!!!
"women-fucking perverts" is so funny to me. also fantastic wordplay as always. the homophobia and longing are intense and messy and painful and loving.
also i just love to see xm and zy again! I want the best for them (almost said I want things to be simple for them but remembered the "but I am not simple" bit in another one of your games (I forget which))
Ooh, thanks for finding the default event handler for new canvases (and everything else)! That's neat! (Still find it weird that the default on-creation is distinct from the default absent-script! Confusing design choice, imo!)
Yeah the default do-nothing script does nothing. I was talking about a truly blank script (with no event handlers at all, but maybe a comment present).
Just to be clear, my primary question with the above stuff was not so much "how does it work" but "i think this design choice is a tad hostile to discovery... is there a good reason for it, or could it be different?".
---
Again, I appreciate the pointers towards aspects in the code already, and I think it is quite cute that it's possible to make your own drawing UI. But, like before I was more pointing out "isn't it weird that the already lovely drawing UI that already exists is not by default available for canvases?"
Like, my question/critique was not as a user of decker wondering how best to interface with an already existent piece of software, it was as a person commenting on an in-constant-development project wondering about the design decisions and thinking some of them are rather confusing / a tad user-hostile and wondering if there was some really good reason they are that way. I do appreciate you finding the section of the documentation with the defaults though, thanks!
hi!! i have a few questions about canvases:
feels like the only way i can see using them is either:
1. creating a new one from a current selected bit of art i drew on the background, or
2. doing weird stuff with scripts (this is delightful and fun)
I would love to be able to draw on canvases, and I see that when you delete the "default" template for the script of a canvas, when in Interact mode, clicking and dragging becomes drawing! But only with a 1-pixel black line. And without erasing. So I have two questions:
1. Why is there this "hidden default" for canvas behavior? (And what even is it!) Also, if the default script featured whatever this hidden default is, then people could rather organically discover drawing on canvases and easily delete it for a "no-drawing" behavior. [A lot of my confusion comes from the Draggable deck which says that scribbling on is normal behavior for canvases... but having trouble replicating that in my own deck until the script was wiped]
2. Why can't we draw with all the lovely drawing tools we have on canvases? (Or will we be able to someday maybe?) I like having patterns and ovals and all sorts of great things, and I know "write on the background then create a new canvas from it" does technically work but... it feels weird and clunky to have a canvas unpaintable. Is there any way to make this possible? Or are canvases designed primarily for lil script-interactions?
Thanks!
June
ok glad the gray thing is gonna get changed but that was mostly a minor complaint tbh. most of my issue was being confused about how transparency functioned.
Is it just supposed to be puzzled out somehow that while the documentation is like "yep 1+47 colors/patterns!" and the palettes in the toolbar list 48 things... #47 can't be drawn by normal means, and to switch between drawing #0 and #32 you need to change something in the view menu (a menu labelled View because it changes how i view things, not what they are), and when that menu item is ticked there is zero intended indication on the palette that you're not drawing in a different color?
like idk much about UI, but maybe add a palette item for all the colors you can draw in?
like i'm sure you're both used to how this works and it all makes sense to you (and i understand it's a personal project, not trying to say you owe anyone anything) but it's confusing as heck for new folks!
(i will try the toolbars on the side too btw, i appreciate that tip!)
- i would love if right-click to erase were "discoverable" through the UI. Missed that part of the docs, and didn't see it in the "all about color" deck, so just never learned it. (i also skim-read a lot so this one might be on me!) Spent a while trying to work out transparency in other ways.
I assumed the "white" and "black" when color mode is on referred to patterns 32 and 47 but uh, i think they draw in pattern 0 and 1 instead! (Yeah, i just verified(???) by drawing, copy-pasting into a canvas, and reading off the pattern number directly using the listener. Unless doing the copy/paste alters the pattern somehow?)
- the view-menu item "transparency mask" changes how drawing works. This is kinda confusing for an item I'd assume would only change our view on things.
- calling pattern0 "transparent" and pattern32 "opaque white" feels misleading in the docs tbh, especially because I expect the "white" colors in both color-mode (expecting #32) and the normal mode (expecting #0) to draw either transparently or opaquely... but they don't (they both essentially erase (or draw transparency) unless transparency-mask is on, in which case they both draw opaquely.)
- the color of the "white" in the palette turns into gray when transparency mask is activated, implying drawing in this color draws "transparently". This is the exact reverse of the behavior though!
i feel like the following would be lovely:
- maybe keep pattern 0 and pattern 32 both visible in the palettes of color-mode and non-color-mode (indicating that 32 is always opaque white and 0 is always transparent somehow through an icon? idk. this "sometimes transparent sometimes not" behavior is mind boggling and causes the need for like a very vague "transparency" menu item for copying/moving imo)
- perhaps a tool item called "eraser" that reverses left/right click behavior? idk! just anything so that i don't need to read all the documentation before doodling
so i guess my question is: is this a bug? is this intended behavior? if it's intended, i feel it could be improved a bit
replicated it with a fresh copy by doing the following:
story.txt is
START
uhh
GOTO:CHAP12345 - asdf
###
CHAP12345
this will never print
###
delete all assets except blank, bg_title, bg_texture1. Deleted all audio files and video files from the folders as well.
assets.js is:
const IMGs = { BG_TITLE:"images/BG_TITLE.png", }; const VIDs = { }; const MUSIC = { }; const SPEAKERS = {
M: {name: "machine", colour: "#696969"}, E: {name: "engineer", colour: "#8b66ba"}, P: {name: "pilot", colour: "#e3a239"} };
I couldn't replicate it until i got rid of most of the assets, so I'm thinking that's the issue (and the debugger in firefox gave the consoler error
"Uncaught TypeError: track is null sfxPlayer http://localhost:8000/code/tags.js:697"
so i think maybe that's messing stuff up a bit? and it's bailing on the rest of the function??? idk)
found another bug i think?
GOTOs weren't working so i switched the order of the "drawDialogue(...)" and "if(goto!=null){...}" (to make drawDialogue after the goto check) blocks in the updateDialogue function, and now they work again.
idk the code so this miight have introduced a new bug or something? unsure! but now they work again and i'm happy
love this!! thank you this is so neat!!
a few bugs i've noticed:
1) POSY reset behaves differently than POS:x:reset:z (the former sets y position to 80 (which happens to be the default POSX i believe), the latter to roughly 350)
2) POS tags inside character speech take effect (even if it's a line like "E! - test POS:320:200:64")
3) resetting the third thingy of a pos tag seems not to work, can't do POS:RESET:RESET:RESET as far as i can tell
4) size takes a number rather than [number] as indicated in the guide, and does not seem to accept a RESET value.