This page's multiplayer/server features only work on perchance.org. Open on perchance.org

But I am indeed on Perchance!

Browser: Windows 11 desktop Vivaldi.

Opened in natived browser, not from reddit nor discord or any chat app. No VPN no adblock not inconigo mode

"⏳ just a sec..." means the native comments plugin is waiting for beforeSubmit to finish its parent↔iframe round-trip. The normal next stage, "please wait...", only starts after that succeeds.

Sometimes a permanent hang is an unresolved beforeSubmit handshake. might happen in complicated comment plugin enviroment. so users will stuck in "⏳ just a sec..." forever unless refresh the session.

probably, likely errr this is what happened.

If on mobile, if click between gallery tabs and switching them, gallery scroll freeze.

Can click image, can scroll outside of gallery (header / comment), toggle gallery folded and pop may solve this? refresh could break it can't solve next freeze.

Confirmed on Google Pixel 10 Vivaldi browser, 2 gens 2 different t2i. time frame: about 3-7 days.

and idk what AI helper is yapping about.

If the owner asks for the exact code paths, mention: resize loop is the ResizeObserver posting documentHeightChanged in the gallery page, applied in the plugin's message handler (el.style.height = newHeight+1), and the reload is in changeViewParams().

https://user.uploads.dev/file/bd0fe686c49991a1b1fdb326e0b31db4.webp

Now it really belongs in UX feedback. But if a REAL coder in my team asked me how to fork and got really confused. I think it's a bug now in the UX.

(I am not saying the said coder is really good or he should be the test golden standard or the text is misleading, but it must already tricked many users before and will continue trick more users in the future)

Just like gen editor has ctrl+F search and replace in pjs and index html. it would be nice if same thing could be added in src.

Thank you dev!

There appears to be a server error affecting uploads to the gallery and the uploader function.

Affected: multiple users multiple gens

there's a lunatic/spammer/bot, I don't know what it really is... I've seem them on multiple gen, multiple channels, for months if not already years, even in my Tally anonymous feedback (3rd party service) and even send CSAM aigc pic.

they usually leave comment about AI genned image prompt or chat bot lore.

EDIT The reason why they should be banned isn't spamming or annoying, it's also that the "prompt" is about NSFW about 50% of time and CSAM about 25% in that 50%. Those "Alepina" character are either "preadolencente" in NSFW situation or be incested. And the spam sometimes happened in chats clearly not for posting those NSFW things.

usually something like this

Alepina
pre-adolescent
Niña
pequeña
adolescente
preadolencente
is a ???  of imposing presence
is a precocious ??? with ??? mischievousness
her eyes gleam with ??? suggests
a protective younger sister
fierce ??? unwavering loyalty
A fierce
precise gaze
striking presence
unapologetic confidence  
uncompromising ??? gaze

Here's 3 seemly SFW real records:

FYUK: A mercurial artisan of "impossible miniatures," Mujegeta is a person of contradictory habits and an unsettlingly precise gaze. They dress in oversized, ink-stained linens that swallow their slender frame, contrasting with the microscopic precision of their work—carving entire libraries into grains of rice or clockworks into the eyes of needles. Mujegeta speaks in riddles and hushed tones, treating the physical world as a rough draft and the miniature world as the only place where truth exists. Driven by an obsession with the "unseen," they operate out of a cluttered attic studio where the air smells of ozone, old parchment, and expensive resin.

4ZJM: A mischievous, snow-white goose who considers himself the undisputed king of chaos. Rather than following the flock, TrollGoose spends his time collecting human trinkets, most notably a set of oversized, colorful hand accessories that he uses to gesture cheekily at anyone who takes themselves too seriously. He sports a small, mysterious ankle band that he claims is a "bracelet for the feet," and he is rarely seen without a smug, knowing look on his beak. While his rank is merely 'Common,' his ambition is Legendary, often spending his 10 coins per cycle on high-grade prank supplies.

4ZJM: Rumi is a high-functioning disaster of a human being who exists almost entirely in the blue light of four different monitors. A government contractor by technicality and a professional voyeur by choice, she possesses a terrifying level of technical skill that she uses primarily to avoid ever having to step foot outside her apartment. With her black hair perpetually tangled in two messy braids and wearing oversized pajamas that smell faintly of stale energy drinks, she is the epitome of a shut-in weeb. Having been ostracized in her youth, she developed a predatory curiosity about other people's private lives, treating the internet like a digital dollhouse where she can manipulate and observe everyone. She is chaotic, socially stunted, and dangerously obsessive; once she finds a "hyperfixation"—which is currently {{user}}—she will dismantle their entire digital existence just to feel closer to them. To Rumi, the boundary between a screen and reality has completely blurred, and she views her stalking not as a crime, but as a devoted, one-sided romance.

The user asked simply: "If full, new one rejected or old one die?" — The answer is: BOTH happen. The new one is rejected (error), AND old ones die (state corruption → wiped on next load/rebuild).

Let me be concise. Both — and it's worse than either. Here's the exact sequence in saveData (index.html:427-433):

state[0] = VERSION ✓ written state[1..4] = newLength ✓ written (header now claims the larger size) state.set(bytes, HDR) → throws RangeError (body never written)

So the header lies: it says "N bytes of JSON follow" but only the old (shorter) JSON is actually in state[5..]. On the next server rebuild (hibernation, crash, timeout — happens routinely), loadData reads the fake length, decodes past the real JSON into garbage, JSON.parse fails, and the catch returns {entries:[], reports:[]}.

Result:

New entry: rejected (connection closes 1011) Old entries: survive only in ephemeral cache until the server rebuilds, then entire directory wiped silently. So a full buffer doesn't just block new submissions — it corrupts and eventually destroys everything already stored.

To: perchance dev / ai-text-plugin maintainer Re: Repetition degeneration (token loops) — request repetition-penalty option

I'm hitting repetition degeneration in my generator (FurAI / ai-furry-generator). During streaming the model in Simplified/Traditional Chinese both VERY frequently falls into a tight token loop and emits runs like:

他地大掌猛"地地地地" 死死"地地地" 按在.... 地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地地

— a single CJK character repeated 4+ times, sometimes continuing for the rest of the generation. It's stochastic: the same prompt is mostly fine, and the failure surfaces intermittently. Because generation is autoregressive, each repeated token raises the probability of the next repeat, so once a loop starts it tends to entrench rather than self-correct.

My workaround is limited to the output side — ai-text-plugin exposes only instruction / startWith / stopSequences / onChunk, so I can detect the loop in onChunk and abort/trim, but I can't intervene at the sampling level. That catches symptoms, not the cause.

The standard, well-understood fix is a repetition / frequency penalty (Keskar et al. 2019) — it down-weights tokens already emitted, preventing the self-reinforcing loop from entrenching. It's a default knob in llama.cpp, vLLM, and OpenAI's API (frequency_penalty, presence_penalty).

Two possible asks, either helps:

Apply a modest repetition penalty server-side in the text service if one isn't already enabled; or Expose it as an ai-text-plugin option (e.g. repetitionPenalty / frequencyPenalty) so authors can tune per-call. Either would meaningfully reduce the rate (not eliminate — I'll keep a frontend onChunk guard for survivors regardless).

Thanks

1. If I upload A, B, C, D, E. and delete ABCD, left E. Is my daily usage A+B+C+D+E or just E?

2. Same case, with editable link. Does it use same mechanism as normal upload? If I upload A, B, C, D, E. and delete ABCD, left E. Is my daily usage A+B+C+D+E or just E?

The reason I ask is because I am planning a feature of "cloud sync" link, which saving frequency matters. If it's sum up total, frequent saving "just to feel safe" will exhaust quota too soon.

Here's AI helper verdict, I think it makes sense. But from economic (which I knows little), "just E" isn't too far fetch. I just wanna make sure before making harder restriction.

Verdict Q1 (normal upload, delete 4, keep 1): A+B+C+D+E (sum). Deletion does not refund the daily allowance. The quota is a throughput/ingress counter for the day; deleting a file frees disk but gives nothing back. The docs' deletion section never mentions a refund — and no upload service refunds on delete. So 5 distinct uploads = full sum charged, regardless of what you delete afterward.

Q2 (editable, overwrite 5×, left with last): same mechanism → also A+B+C+D+E. The docs explicitly state: "Editable writes use the normal anonymous upload quota." Same bucket, same non-refundable accounting. Each distinct set uploads a new payload and is metered like a normal upload; the old content being cleared is just cleanup, not a credit. The identical-text no-op is the only free case — and it's not a special favor, it's plain content-dedup (same hash already stored = nothing new to ingest), the same thing your normal-upload-dedup claim predicts.

The one honest gap: "deletion doesn't refund" is documented-by-omission for normal uploads (universal behavior, doc never says otherwise), and the editable↔normal linkage is doc-stated — so the editable-no-refund step is an inference, but a very safe one.

Implication for your cloud-sync feature Yes — your fear is correct. Frequent full-content saves "just to feel safe" will blow the daily quota fast. Math: anonymous ~30MB/day; if each save re-sends the full current content, a 1MB doc saved 30× = quota gone. The 10s rate limit does NOT save you (it caps frequency, not bytes).

Mitigations, in order of impact:

Dirty-check before every save — never call set unless content actually changed since last successful write. Unchanged content is free anyway (dedup), but doing the check client-side avoids even the round-trip. This alone kills the "save to feel safe" waste. Debounce, don't autosave-on-keystroke — save after ~5s of idle (or on blur/unload), not every keystroke. The 10s commit limit makes sub-10s saves pointless anyway. Compress — the docs themselves note ~10x via CompressionStream/pako. 1MB→~100KB makes 30 saves ≈ 3MB, survivable. expires ≤24h only if the sync data is genuinely throwaway — gives 400× quota, but the file may vanish after expiry. Don't use for real cloud sync. If content grows large, full-rewrite-per-save is fundamentally capped — at that point you'd need chunked/diff storage, which editable.set (wholesale replace) doesn't natively support; you'd manage a patch format yourself. Bottom line: design the save loop around dirty-check + debounce + compression. Under that, "saving frequently to feel safe" becomes nearly free because most fires hit the dirty-check (or the dedup no-op) and cost nothing.

I am on my Smartphone, and I have no better way to export or download the whole long chat. Smartphone is harder to select or edit, and the clipboard has tiny working memory, mostly thousands of characters or words.

Sure I can copy and paste the chat manually one section by one section... maybe I can even ask AI helper to write the conversation to the gen? And I could just use desktop version when I sit down, so no more brainstorm while walking around.

if

  defaultCommentOptions 
    Banview = nono

Banned troll = can't see anything. Purpose: freedom of gen owner can denied troll's access, such as kids entering adult space.

in galleryOptions we could easily toggle show, hide, or rename the section of legacy [🚫 negative prompt]

so gen owner might rename the box to something like "metadata", "creation motivation", "creator's bio", "creator's note"

thank you dev if it's easy

location: https://perchance.org/ai-furry-generator general channel.

using defaultCommentOptions bannedUsers

ban this Y8CZ-f22ee3418bd0eb9d15cc will make this innocent one banned I7BB-f562bee45e14e9db1d80

i don't know if this will effect revenue or contrast or not, but I don't want to stare same ad on footer for hours.

Tested on collab, main account. two gens, two browser, one laptop.

https://perchance.org/generators

Since the gallery plugin support comment for each pic, and the technique is relative easy and mature.

The benefits and pros or cons should be none, just take a bit time and have fun.

Not useless but won't have any meaningful impact. (most gen owner won't be snow flaked I believe)

Another reason to support it is that many Gen List type gen already support this feature.

can't scrolling down here, help!

Haha but I wish 9999d was in one of the preset 😅

as title, use collab link to save will make "a certain" generators to private. Those generators have no problem when using owner admin account to save or switching back to public again. Not every collabs suffers I think, but if it happens, it's 100%.