ccufcc
also I think, I could be wrong, but there's a slow tagging bot slowly scanning gens???
so even without meaningful risky updates, some gens flip to private days even week later????
this sounds too sus to be true so might not be the real mechanism but I think there's a delay tagging there...?
i think the "sticky" part isn't really strong, ta least 50/50%, fix code works!
also collab link (usually no one use) has high(not always, but per-gen bound????) rate make a gen 100% auto-private.
- Don't use collab link to edit
- Check if you use NSFW words in code
- Someone just made this guide I am not sure if this type of manual is allowed but I won't bother even ask because to ban it is also weird but I think there's some kind of restriction of this kind info but anyway... https://perchance.org/perchance-banhammers-explained
tldr:
- the bug: has admin hash = no [load more] button
- cause: mod deleted(hidden) some comments, so comment count never reach 200, no [load more]
- fix: might be as above
Proof complete. Here's the full evidence chain — the reason is the 6 hidden posts, and I can show each link.
- Same channel, same moment, one variable. Fresh cache-busted fetch of Submit's message list, two ways:
with the admin hash → 194 messages without the hash → 200 messages Same newest message, same instant, reproducible. The only thing that changed is whether the 6 hidden posts are in the list.
-
The 6 posts are identifiable — and they're not deleted, they're excluded. The 200-msg list contains exactly 6 that the 194-msg list omits (publicId 518f2597... ×4: "Ale Pina is a pre-adolescent girl…", "Leo is an eighteen-year-old…", "Elena is a firebrand…", plus the SUBMISSION_column spam and "is there any mod that can help me"). They still exist in the DB (the public feed shows them) — the hashed/mod feed is the one that drops them. So: hashed feed = most-recent-200 − 6 hidden = 194.
-
The plugin's own code turns 194 into "no button". In the embed: maxMessagesPerPage = 200 (line 2457); if(messageDataArr.length < maxMessagesPerPage) noMoreMessages = true (line 2536); button only rendered when !noMoreMessages && length >= 200 (line 2564). I ran that exact condition on the real arrays: 194 → no button, 200 → button.
-
You can run the reversible A/B yourself in 10 seconds. Comment line 284 back in (hash on) → reload → Submit loses "load more". Comment it out → reload → it returns. You've already seen both states. The switch is literally whether those 6 posts are counted.
-
Corroboration: General & 18+ General show the button with the hash because their recent-200 contain zero hidden posts (200 ≥ 200). Submit/Feedback sit under the line.
So the hash isn't the cause by itself — it's what makes the server exclude those 6 posts, dropping 200→194, below the plugin's hard 200 threshold. Fix: mods delete the 6 (or ~6 new posts arrive) and the button returns with the hash intact.
Here are 3 fixes for the comments-plugin dev. All reference the embed source (I saved the full embed page to scratch/comments-embed.html for line numbers).
-
Ask the server "are there older messages?", don't infer it from the page count (root-cause fix) The button and noMoreMessages are computed purely from how many messages got embedded: if(messageDataArr.length < maxMessagesPerPage) noMoreMessages = true; (line 2536) and the button only renders when messageDataArr.length >= 200 (line 2564). But when adminPasswordHash is in the query, the server excludes hidden/flagged messages before embedding, so a channel with 329 real messages ships only 194 → button never renders. Fix: have the server include an authoritative flag in the embedded data (e.g. hasMoreMessages, or a total count) computed from the full pre-exclusion message list, and gate the button + noMoreCommentsBeforeThis on that flag instead of length >= 200.
-
Make the exclusion count-preserving: embed "most recent 200 non-hidden", not "most recent 200 minus hidden" (smallest, surgical fix) The hashed feed is currently: take newest 200 → drop hidden ones → 194. Change the server query to WHERE hidden=0 ORDER BY time DESC LIMIT 200 so the array always reaches 200 whenever 200 non-hidden messages exist. Then the existing client logic (button at length >= 200) works unchanged for both hashed and un-hashed feeds.
-
The same flaw exists in the load-more API path AND the availability signal is DOM-based (needed for the button to survive partial pages)
loadMoreMessages also sets noMoreMessages = true when a fetched page has <200 items (line 2671) — so even with the button shown, one short page kills it. Use the same server hasMore flag there. noMoreCommentsBeforeThis is computed via a DOM hack: if(!#loadMoreMessagesBtn || offsetHeight===0) noMoreCommentsBeforeThis = true; (line 2492) — this reports "no more messages" whenever the container is hidden or zero-height (exactly the announcement ticker case). Compute it from server data, not geometry. Host-side, ctx.loadMoreButton only activates when opts.onLoad is set (imports/comments-plugin/main.pjs:344) — hosts who don't pass onLoad can never get a button even when older messages exist. Want this written up as a ready-to-paste bug report file? Meanwhile, the immediate workaround on your side: delete the 6 hidden messages via admin (or ~6 new posts will push them out of the window) and the button returns with the hash intact.
Perchance has vision (i2t), ref image (i2i) is dead code, last time checked few days ago
If on mobile, if click between gallery tabs and switching them, gallery scroll freeze.
if
required improvements => suggested improvements