wthit56

Ideas for complete control over a curated gallery (behind a setting).

Only show people their own saved images in the public gallery. Other galleries can work as normal, but images they didn't add to the public gallery are hidden from the user.

The owner can see all images in the public gallery, nothing hidden there. But they can mark (and unmark) images as being part of the actually public facing gallery that everyone can see. Maybe just an extra button to toggle this is shown on the image if the owner is viewing it. (But also an always-visible icon or border colour or some indication as to whether it's already in the true-public view or not.)

So then you have a situation where the owner has full control over what everyone sees, but anyone can still add their own images to the public gallery. This is all smoke and mirrors, really, just filtering out images not owned, unless you're the owner of the generator itself. So it may not be too much server-side stuff to do.

Another take, perhaps even simpler (but more annoying to maintain for the owner): Have a property on the prompt/gallery call which contains a list of allowed images. Maybe one for blocked images too (which people have been requesting).

This could potentially be part of a separate call that just reminds the server what the settings are for this generator.

Or a property that can be set on the text_to_image function itself which is then taken into account for any images or galleries generated after that. Which would avoid having to send it every time a call is made. (I'm guessing the user block list etc. is currently sent on every call?)

Or ideally it would just be something stored on the server--which brings us back to the original idea if having an interface for it built in.

Could potentially use a separate generator for it though... like you pass in the id of a generator as a property on the gallery/image call. The server can then look that up without any extra AJAX stuff or message passing required at all, cached server-side until it's edited, etc. And a similar solution could be used for ban lists also. This method gives a lot of flexibility to the creator, and lower overhead on performance and network traffic. And it's even extensible with more "server-side data" options into the future. (Though I have no idea if this method would be better or worse from a dev standpoint.)

The advanced image plugin was in service of my advanced image generator. Which is now out! It has many features, but it's not focused on automatically adding opaque prompts you don't have control over. It's more about giving the user many tools to generate the prompts themselves.

All settings have (i) tooltips explaining what they do.

Your device's dark mode will work. Images automatically scale so they can be fully seen in the viewport.

Of special note, there's a "prompt only" setting which will just show you what prompts are generated.

And a "plain text" setting which makes the prompts not dynamic--you're just sending them direct to the image generator on the server.

Generator update thread on discord: https://discord.com/channels/970057744612724746/1276832370518921228

This line errors, if the iframe has been removed when there's a message received about it (completion I guess?):

464:   document.querySelector(`iframe.${privateIframeId}`).contentWindow.postMessage({type:"originNotify", frameId:privateIframeId}, serverOrigin);

I guess because you're always copying everything onto the window object?

So if you then call it yourself, because "you don't think it's been called automatically, because why would it? You haven't told it to do that"... it's actually being called twice.

Anything that's ever inside a tag with some attribute (eg. no-perchance) would not be evaluated whatsoever. This could be an easy way to allow creators to skip evaluation for entire sections of their page when they know they never want stuff in there evaluated. Also saves processing time looping through those elements (presumably), etc.

Or potentially, even provide a $ignoreHtmlSelector property (defaulting to [no-perchance] perhaps) to let the creator straight-up tell the engine what to ignore.

You could use the .closest(selector) on a node to figure out if it's in an ignored element. Or perhaps do a document.querySelectorAll(":not(" + $ignoreHtmlSelector + ")") to find only the elements you need to evaluate within and loop over those.

Link I’m guessing only the dev can answer this.

@[email protected]

I'm now coming up against the issue you thought I was having before. Where after a [code block] is processed it's evaluated. But if using a <script> tag to do things it won't be.

I don't want evaluation to happen. So I could escape perchance specials to work right when returned to a code block, but they won't be evaluated by scripts so they'll still be there on the page. Or I could not escape perchance specials to work right from scripts, but they will be evaluated by code blocks which I don't want. I just want plain text to always come out no matter what.

And there's (seemingly) no way of knowing if it's going to be evaluated at the end of a code block or not. And no way of just telling perchance "LEAVE THIS STRING ALOOOOOONE!!"

Is there anything I can do or is this just not possible in any way?

If not, I'd really super-duper like it if you could add a way. Even if it is as simple and "dumb" as setting a property on the object like .DONTEVALUATETHIS = true or something. I'd really appreciate it.

Or even something like if it has .evaluateItem = "..." it'll automatically use that instead? Maybe? I tried that in case, and it didn't work.

Honestly, I'm surprised this isn't an issue for all sorts of plugins. Though maybe it is assumed that everyone only ever calls anything from code blocks and not scripts. Or people just don't think about or have instances where the plugin returns HTML that includes specials that they want to stay plain text.

But as I'm doing my best to make my plugin bulletproof no matter how it's used... it's driving me insane 😅

So if you happen to have made changes to the code, even reloaded and partial-reloaded a bunch of times, none of that matters. Only the actual save. This is unexpected, as "duplicate" is sort of a "save as..." kind of function in my mind.

I recently was working on a bug, and duplicated the generator to narrow it down before reporting. But the bug didn't happen in the duplicate. Took a lot of testing to figure out why that was.

To return true if there's anything to evaluate in the object. Like for a string, if there's some valid {option|s} or [code blocks], that kinds of stuff.

I explored this here: https://perchance.org/481tgbwo1k#edit

I can't even guess as to what's happening with some of this. Most bizarre...

As seen here: https://perchance.org/ius2f4kd5y#edit

As seen here: https://perchance.org/ihmcs2z5nn#edit

__perchanceError() doesn't show on the page, or in the console. throw new Error() doesn't either.

Edit: Similar for in a <script> tag. The error does go to the console, but no perchance error shows up. So later if you call a function that wasn't created in that script tag because of that hidden error, you just get the error that the function isn't there--as if there was no problem with the script tag, but the function just isn't there, for no apparent reason.

Would be better if the script tag's error was also shown in the perchance error box so it doesn't lead to misleading reporting like this.