wthit56

https://perchance.org/46iutpmh9i#edit

The examples in the above generator page demonstrate the issue.

If in the HTML there's an onclick that updates itself and calls stopPropagation, it will update itself and stop propagation.

It seems if the HTML of the element in question was generated and injected by a [square block], then stopPropagation prevents the update from happening somehow?

...Actually, perhaps no updates work at all, if generated from a square block?! Wait, is this actually to do with the idea that it wasn't in the HTML from the start, so it doesn't think there was anything in that element to update?

Example: https://perchance.org/3o1sbun1w3#edit

Seems like what's returned at the end of the square brackets is somehow added, instead of setting what replaces the square brackets. Potentially, it's cleared, then the square brackets are processed, then the result of the square brackets is added?

Quite, quite odd. They work fine when used within the page. Just not when imported to another page. Quite frustrating to try to work around, and then find that even the fixes don't work when actually imported elsewhere.

Potentially some subtle bug with the proxies?

It should be untouched text. Only in JS does \t etc. are escaped. So \t becomes a tab character instead of just the text \t.

As seen here: https://perchance.org/slash-t-in-textarea-43534#edit

The <dialog> tag has a built-in backdrop that you can style to hide the page, etc. But that seems to not work on perchance for some reason. Any idea on how to get this to work, and what is blocking the functionality?

For example...

The creator of ai-furry-generator was frustrated by their generator now being shown on the page. It has this in the description: "whiteboard drawing with tldraw—powered by Stable Diffusion." Which is fine. (This is what https://lemmy.world/post/23131988 is about.)

But it matches the bad regex /white.*power/i

For now I've told them what to change so it'll show up again. But ideally, it wouldn't match something innocuous like this. Maybe check for only whitespace and dashes, or non-letters, something like that? I mean, some things are going to slip through either way--but personally I'd err on the side of letting good people have good things, rather than taking good things away from good people in case they're bad based on a too-inclusive regex. ;p

Might also be a good idea to console.log every generator that was skipped for showing on the page, with the reason why. So that there's an easy way to see the cause and fix it if it's an invalid match. Or ask the dev to fix that check so it's more correct... without needing to figure out the code itself.

(By the way this is wthit56. I changed my name to my usual online name, and the one I use in discord.)

https://perchance.org/json-stream-plugin

I've completed work on a plugin to help people make more complex things with AI text.

As always, the plugin page includes full documentation and example code. And I've also made a simple template setup you can use to get started.

Recently, I started playing with AI text--not the AI chat etc. but the plugin itself. I used my AI text demo to try different prompts, experiment with what's possible, etc.

I wanted to do things like have it generate more complex, structured output. Even if it's quite simple, any kind of structure is a bit of a struggle to convince it to generate. And if you do get it to generate the format you wanted, you've still got to parse it anyway to get the separate generated values out. The more structure, the harder it is to handle--especially for the average generator creator on perchance.

It's quite hard to get it to stick to a format you describe--because it's not seen many examples of that format. Unless you use a format it has seen before. I chose JSON, as I'm most familiar with it. Telling it to produce proper/valid JSON works pretty well. And showing it a JSON structure usually gets it to stick to it properly.

And you can have as complex a structure as you need fairly easily.

The next step was, creating a plugin/function that could handle that JSON coming out of the text AI, give you updates as it's built, and easy to use/access values of the generated JSON... to then use to show the user, hide different things, display in different ways any part of the JSON that's been generated.

This plugin took a while to put together. Perhaps there are bugs with it--just let me know. But it's very easy to use, with a number of features that make common uses like creating more HTML ready to take generated values and so on very easy to build out.

If you have ideas this plugin could be used for, I'd love to hear them in the comments of this post. And feel free to ask questions, or put forward ideas for new features you think could benefit people.

A button in the top toolbar that adds the generator to your "favourites" list. List is shown in a dropdown, or as icons in the topbar, or on a particular page, etc.

Could be used to collate a "most favourited generators" page.

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