Search

Currently it's quite fiddly, making sure all the keys/names arrays are up to date so it still functions as expected.

If it used a set and delete handler it could handle all that internally. Or if there was some special methods we could use like .addValue() and it would figure out what kind of value it is--property, node, function--and handle it correctly.

Of course, I'm working on a plugin now to handle this for people. 😜

There's a lot of stuff that becomes real fiddly to do because they are not iterable... that would be real easy to do if they were iterable. I believe there's a proxy "trap" for iterating over properties somewhere in there.

As we have ignorePerchanceErrors() and clearPerchanceErrors(), seems fair to have this function too, for public use.

Would be useful to be able to see the images just in the page so we don't accidentally delete the wrong one, stuff like that. I know we can click on the link, but this would just be a nice feature to make it easier.

I feel like it would make sense for perchance to use the image set in the perchance way, if there is one.

As in, console.clear().

This would clear the console on every partial/full reload. I put this in myself, but there are times I've put it in the wrong place and then spend like an hour trying to figure out why code isn't running, then I move the clear, and there was an error in the logs the whole time. ...Er, I mean, that could happen to someone... else.

An option that's just built-in for those that know the console exists (may not be that many of us creating on perchance I grant you) would be useful. And avoid problems like that. I mean, problems for other people. 👀

Just adding quick line of code that allows you to write something like (model:::1) , (model:::2) and (model:::3) to override the keywords would be so helpful.

Things work really well overall but it's frustrating to , for example, run a anime prompt only to have it switch out to the furry SD model because perchance detects the word "dragon" in the prompt etc.

For context: Perchance uses 3 SD models that run depending on keywords in the prompt. I want to be able override this feature.

Dear Perchance Dev,

I recently noticed that a new option to report a user has been added. Thank you very much for that addition. So, VioneT and I believe it would a great idea to report a generator as well. There are quite a number of generators just promoting hatred and discrimination.

VioneT suggested that there should be a "report button upon opening the 'edit' even if you aren't the owner of that generator."

And below is an example of why a generator must be reported.

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.)

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.

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.

At the moment there's a lot of "clutter" in what is logged; it seems to all just use console.log which counts under the "info" category. And means anything the creator logs for their own "real" debugging is much harder to see--especially with more complex generators with many imports and nested imports.

If debug was used instead, the creator could choose to see all those things by turning on the "verbose" category in their dev tools. Or leave it off, and see the "info" channel with their own logs very easy to see and much more useful.

It's always funny when I get a perchance error in the red box that's some obscure problem internally. It's like "here's some common mistakes," but the mistake is actually not the user's fault and they're not making any mistakes--the perchance engine is 😅

Main thing is... the error message will mean absolutely nothing to most creators, and just look real scary. (I'm able to figure things out to some degree because I'm a web dev.)

It would be good to either catch problems early and handle them without erroring, just logging a warning perhaps.

Or maybe throw up more useful/readable messages, careful to mark it as an internal perchance issue--so then average creators can report that issue, and more advanced "hacky" users like me know it's because they're poking around with the internals.

Or you could have it just marked as an "internal error" and have an expandable <details> panel with the real error inside. Again, so advanced users can figure things out, but average users aren't like AWHAAAAAAAAAA~~~?!

For what I'm building I don't particularly fancy the full gallery--for reasons. But I wouldn't mind a button users can click to open the overlay version. I think I may be able to replicate that looking through the text-to-image plugin... maybe. But it would be great to just have that as an option. Like, the normal way of producing the gallery, but add overlay=true to have it show the overlay instead.

Also, some "official" way of closing the overlay--perhaps something as part of the returned value when asking for an overlay? Perhaps even a property on the imported text-to-image-plugin I could call to close any open gallery overlays.

And an easy way of finding the outermost overlay container div (it's all just styles right now, so I've got a somewhat brittle css selector to query based on the iframe's src). Perhaps include a useful id or attribute. I've got something working fine, but would be a good feature to have in place as part of this.

Edit: Oh also, I feel like Escape should close the gallery overlay. And perhaps there should be a clear button to close it.

Might be useful. Could potentially be used to trigger retrying the generation, maybe with stronger (nsfw) negative prompt, something like that. Or just hiding that generation entirely.

So if you just want to adjust it, you don't have to type it all in or copy-paste.

I'm not too studied-up on CORS, but I know what it's there for. Currently there's a number of things that are not possible to do because our generator is on a different subdomain than other generators or iframes, etc. etc. and even the top-level page we're actually on.

With that allowed (I think CORS can allow this), there's a lot more customisation we can do of things like t2i image iframes and gallery iframes, reading/changing the top-level url, etc. Maybe that's something you don't want to allow, but I for one have wanted to do these things for completely benign legit reasons multiple times.

Currently, as far as I've figured out, in the HTML we can have {import:...} and it will be accessed. So we can use that to actually run code immediately. Using it this way means it won't be included in the lists for when it's imported into other generators, but we can still use it in that specific page.

But we can't use {import:...}.property or {import:...}(args).

In the lists, we can have imported={import:...} and it will load in but not be accessed. To trigger the access, we have to use [imported] someplace that is accessed--in the HTML, or perhaps $output depending on the situation, something like that. Which is counter-intuitive, as the code we're writing to import it in the first place is literally an assignment (by how it looks at least).

But if it's in the list at all, it's now part of the dependencies included when importing it into another generator. Which, if we're only importing it into the list to be able to call in the HTML, is not explicitly intended by the creator. As this kind of assignment doesn't actually access the imported thing, at least it's not going to actively do anything. But ideally it just would not be required.

On the other hand, it would be useful to be able to simply say {import:...} and have it import, even without a name to store it under. It's clear what the creator wants, from that code. And it works exactly as expected in the HTML panel. On the other-other hand there's no way to call an imported function or access an imported property from just the HTML so it needs to be part of the dependencies of the plugin itself.

> If my plugins were actually used by anyone (LOL) this would have been a pretty big issue when I recently made a typo (and got stuck being unable to fix it for a time) in a not-required-at-all import that had to be there purely for the plugin's page to use.

> If I could've just imported it and used it all within the HTML panel, it wouldn't have been so urgent, because the error would not have affected any users of the plugin--only my own page presenting it.

The main thing here is, they work differently--seemingly (from the outside from an average creator's point of view) for no real reason. So learning how import works correctly is made more difficult. And learning how it works just for lists or just for HTML is easy... but of course trying to use that knowledge in the other panel leads to confusion and frustration because actually there are different unforeseeable rules there.

Could well be that for backwards-compatibility some of this could not be changed. But perhaps things could be expanded to allow for more features to be cross-compatible, and more expected/very common features to "just work."

While testing it can be frustrating having to "clear cache and hard reload" from time to time just to see the changes I've made in other generators. A "no-cache" option would be great, in whatever form that takes.

It seems there is no way to have scripts run after everything else. Normally I'd use window.onload or similar things, but all that's been and gone by the time any script is run anyway. So I tried defer. Normally defer means that script will run after non-defer scripts. That would be useful, but the defer attribute isn't heeded by the engine, currently.

https://perchance.org/085unhhfqe#edit

For now I'm going to try using a [code block] just to have it run later. But obviously that won't be sufficient for all situations. So it still would be useful to have some callback or addEventListener thingy to use to run code after perchance has done everything it does.