wthit56

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.

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~~~?!

If you have a generator that has been saved at least once, you can open its settings and choose to delete the generator. You then need to confirm. If you do, it says the generator has been deleted, and it will take you to the homepage.

But then if there are unsaved changes, it has that warning about leaving the page. But As the user has confirmed they want to delete the generator, saving doesn't even mean anything anymore anyway. If they cancel and stay on the page, they can continue to edit and even save.

When they save, though the save fails and the preview shows a warning like: (⊙.⊙) sorry, we cannot find a generator called curxte4k6u! and it never comes out of the saving state.

It's all a bit pointless and there's no point in ever staying. I'd say the expected behaviour is that after it's been deleted it shouldn't care if there are unsaved changes anymore, and just let the redirect to the homepage happen as expected--without that confirmation popup.

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.

(Pro tips can still come from non-pros, right? 👀)

I only started doing this recently, but it's a lot better for my stress levels 😂

I change the title to DEV ONLY so I know how safe it is to edit the functionality etc. I also have a banner in the HTML that shows if I'm not actually editing the original "real" version, which also reassures me.

Then I can break stuff, save to my hearts content (I have an itchy save-finger). And only copy it across to the real version when I'm happy it's safe. Just remember not to overwrite the $meta stuff if that's different in your dev copy. Though if you accidentally do that, the backups are very useful for quickly grabbing what you need to put back.

For the name, I call it the same, but with -dev- in there somewhere, and -4958734957 a load of random numbers at the end so it's super unlikely people could stumble across it.

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.