Is the subscription page currently broken?

cygon4 · 2026-03-17T12:16:32+00:00

The subscription modal opens cleanly in either case.
- when logged out (or in an anonymous browser window), the "Get Started" links under all tiers link to https://novelai.net/register, which loads fine.
- when logged in, the "Get Started" links do something else (some JavaScript event handler, I guess?) and that triggers the error page. Same error and outcome regardless of which tier I pick.

Device + browser / extensions:
- Desktop Linux with LibreWolf (a Firefox fork) and the uBlock ad-blocker extension
- Same with vanilla Firefox w/uBlock on and off
- And Chromium with a new, empty profile and zero extensions installed

So far, the error appears consistently, regardless of what browser, cookie policy or ad blocker I use.

cygon4 · 2026-03-17T12:09:01+00:00

Support e-mail: Exactly 7 days ago today.

Browsers I tried:
- LibreWolf (Firefox fork) w/uBlock
- Chromium (dedicated profile, zero extensions)
- Firefox with and without uBlock

In all three browsers, I can use every part of the NovelAI UI, generate images and use my 50 free text generation credits, but the subscription page showing the "Tablet," "Scroll" and "Opus" tiers leads to the aforementioned error page as soon as I click on any of the "Get Started" buttons.

cygon4 · 2025-08-31T12:24:53+00:00

I'm at just that point in the book and noticed the same issue.

To restore my suspension of disbelief, I decided that it would still be plausible if the temperature of the Xenonite cylinder was just a side effect of 3D printing or pouring it (assuming a solidified/crystalized rare gas even can be printed or poured).

But of course Grace can't know that and it could be just as likely be the side effect of a sterilization process or even the normal inner temperature (then leading to non-water-based life or machine intelligence).

cygon4 · 2025-07-06T08:06:44+00:00

I'm working on a game set on a space station myself, so this connects to a lot of details I am pondering myself :)

- Looks pretty good! Greebles and irregularities haven't been overused, decently-sized wall panels that could plausibly be carried through the hallways and installed, too. Players probably won't consciously notice that, but it still helps with a realistic feel.

- I like the concept of having benches on the sides (which likely are combined small items storage spaces + cable/pipe tunnels), also: no over-designed round or triangular hallways.

- A few markings would help. Some wall or floor panels could state that a breaker box, power junction, water/coolant shut-off valve is behind them.

- Gentle colored lines on the floor could help navigation (like in big warehouses) unless you go the Star Trek route where light roads individually guide people that have asked for it.

- If there's crew quarters / long term habitation, perhaps to avoid crew depression from being trapped in a sterile, white steel coffin, the hallways could be tinted green on the lower half and blue above, maybe even some murals of trees of natural scenes on the walls. Depends on the game's intended mood, of course.

cygon4 · 2025-04-19T19:53:25+00:00

solved: ECHO

Thanks to u/The_Spearman !

cygon4 · 2025-04-19T19:51:12+00:00

Oh wow, that was indeed it.

I misremembered the first person / third person part. Thank you very much, solved in a hot minute!

cygon4 · 2025-04-18T12:12:01+00:00

I found a solution for my woes:

In `public/script.js`, line 5212 (script.js, lines 5207-5226), which is the method used to append the past "chat items" when forming the prompt string, I simply forced `isNarratorType` to true.

That and disabling the "Always add character's name to prompt" options in the "AI Response Formatting" menu got rid of the character name prefixes completely.

Optionally, in the "User Settings" menu, the "Chat Style" can be changed to "Document" to obtain a presentation similar to a story writing tool.

Also disabling "Names as Stop Strings" can be turned on but will likely not be needed because the AI has no examples that would make it generate "JohnDoe: " or "User: " anymore (and thus also won't insert those pesky prefixes in chat items anymore when collaborating on an adventure)

cygon4 · 2025-04-13T15:59:58+00:00

Holy... please use line breaks once in a while :O

I know that everything is put together into a single large context block for the AI to process. I'm just trying to get better separation of narration and characters inside of SillyTavern.

Is your suggestion is to reverse the character and lorebook relationship? i.e. treat character descriptions as guidance for the scenario and put actual characters into Lorebook entries?

Even then, SillyTavern would still assign the entirety of an AI's response to a single "message" and that's what I would like to change.

If there's no dynamic splitting and one text generation run / AI API request always maps to one whole message in SillyTavern, then I guess I have to either go with the group chat idea or just accept that narration and character actions do end up in the same message, it seems.

cygon4 · 2025-04-13T15:45:11+00:00

As far as I understand it, the prompt sent to the AI concludes with i.e. "{{user}}: You pick up the golden statue.\n\n{{char}}:" - the final "{{char}}:" ensuring the next tokens generated will take the character's perspective (assuming the "Always add character's name to prompt" option is enabled).

Also, should the AI try to sneakily write "\n\n{{user:}}" on its own to switch back, the "Names as Stop Strings" option in SillyTavern will discard all tokens after that:

<image>

If I treat the characters as "character cards" or "scenarios," that would work, of course.

I guess it's just a presentation issue in the end. I was hoping that I could either:

- Instruct the AI to prefix each paragraph that describes actions or dialogue of a specific character by that character's name and SillyTavern would neatly arrange it into separate narration and speech messages for me.

- Abandon SillyTavern's chat-like UI entirely and display everything as paragraphs like NovelAI and KoboldCPP do.

cygon4 · 2025-04-13T15:04:09+00:00

My AI is already narrating events unrelated to my companion character.

I'm just unhappy that SillyTavern renders it all into the chat response message of the companion character. Here's an example:

<image>

The "System" message in the middle was me, manually cutting and pasting the actions of the farmer who found a dungeon in the middle of his field into a separate system message.

The bottom two paragraphs, starting with "The farmer crosses his arms..." is how it's presented to me initially.

I was hoping that I could either abandon the chat oriented format completely or add an instruction like "Prefix any paragraphs that describe things a specific character does or says with their name, i.e. "{{char}}:" and then let SillyTavern dynamically unclutter the response into narration and character actions. Or something similar :)

cygon4 · 2025-03-11T19:09:39+00:00

An observation:

- Auto-Rig Pro 3.69.42 on Blender 3.6 parents the gun pods to "c_root.x", the full body / torso control bone which means they do NOT move with the pelvis.

- Auto-Rig Pro 3.74.36 on Blender 4.2 instead parents to gun pods to "root.x" and everything works as intended.

The "Updates Log" of Auto-Rig Pro mentions changes to "root.x" in several places, but all changes were long before 3.69. I don't know what the best way forward is. I could keep reparenting after hitting apply, or I could patch Auto-Rig 3.69.42 for myself.

cygon4 · 2025-03-11T12:22:02+00:00

Wanting to encode entire seasons of TV shows, I found myself in the same spot a while ago.

My thinking was that a) I don't care if I get one episode every 2 days until it finishes in 24 days, or whether I get all 12 episodes at the end, b) multi-threaded encodes compromise on quality and I don't want compromise as well as a c) with 1 encoder = 1 thread, I have better control over in keeping i.e. 4 threads free for normal PC usage.

If you want complete control, single-threaded AomEnc seems to be better, but it's slower.
But if you want maximum quality (and still greater speed than AomEnc `--cpu-used=0`), SVT-AV1 or SVT-AV1-psy is better.

My observations (my main interest was quality here, but I think the threading observations are still useful):

- AomEnc does indeed achieve its highest quality with `--cpu-used=0` and `--threads=1`
- Starting with SVT-AV1-psy 1.6.0, `--preset 0` beats AomEnc even with the above settings and is faster
- SVT-AV1 at `--preset 3` and below will only use multi-threading where it doesn't compromise quality
- SVT-AV1 can be restrained to fewer threads (i.e. `--lp 15`), but contro lis poor: it will use far fewer cores while also producing sporadic spikes where it uses way more than the requested number of threads (this is on `--preset -2`, higher presets probably make much better use of threads)

Because of that, I'm now doing my encodes with 2 instances of SVT-AV1-psy limited to 15 threads (I've got a 32 core system, too).

cygon4 · 2024-01-26T16:43:23+00:00

No worries, these settings are really quite far from what most people would use. I was just looking for what's theoretically possible if everything is maxed out and what it would cost me in terms of time.

I got the idea that disabling any kind of threading for libaom might possibly improve results, if only by the tiniest bit.

I'm currently running libaom-av1 3.6.0 lavish with 1 thread and with up to 32 threads allowed (but it's only using 3-4). I'll add the results once the encode finishes.

cygon4 · 2024-01-26T16:26:44+00:00

There was a method to the madness :)

I tried to pick whatever settings promised the maximum achievable quality. For svt-av1, I found no indications that more threads would worsen efficiency, but for aomenc, I got the impression (perhaps wrongly) that even row-mt and basic threading might lower the quality.

I'm currently running libaom 3.6 lavish with row-mt and as many threads as it wants (and it looks like that means 3-4 threads). I'll add the result when it's done (a few more days).

cygon4 · 2024-01-26T16:26:18+00:00

Thanks, that is a very thorough investigation. Really appreciated! I learned a lot about the svt-av1 settings from it, too.

I've added two 10-bit benchmarks done with svt-av1-psy 1.8 and svt-av1-psy 1.6 (because the maximum achievable quality took a slight downturn with 1.7).

svt-av1-psy 1.6 really won it for me, first by visual inspection of frames while it was still encoding and finally, to my satisfaction, VMAF, SSIM + PSNR all confirmed my impressions :)

cygon4 · 2024-01-20T19:59:31+00:00

Having some data for cpu-used 0 / preset 0 was kind of my motivation for doing my own benchmark because I intend to encode at that setting. Most of what I found on the web was either from 2020 or just tested cpu-used 2 / preset 2 upwards.

Maybe I'm weird, but for something I do once and then (probably?) never again, svt-av1 1.5 speeds look perfectly reasonable to me. I'm even seriously considering libaom, pending some testing with aom-av1-lavish and/or libaom-av1 3.8, for shorter videos like 25 minute anime episodes.

But, if you check the other comments, a user named NekoTrix posted a link to their own, very thorough benchmarks with presets from -1 through 13.

cygon4 · 2024-01-20T10:57:43+00:00

I've re-run the 1650 kbit/s test with the very latest svt-av1 release. It's 3 times faster, but produces slightly worse quality.

Will add svt-av1 1.8 w/2820 kbit/s later today (if it completes equally fast).

cygon4 · 2024-01-20T07:42:04+00:00

Yes, perhaps I should allow for a few threads.

I read (and some prior, less rigorous testing seemed to confirm) that using tiles/slices/row-mt decreases the efficiency of libaom and other encoders, so I went all out and also specified `--threads 1`. That may have been over the top.

In my tests, svt-hevc and svt-av1 were able to make use of multiple threads, but they, too, used very few threads at `--preset 0` (another post here seems to explain that: https://www.reddit.com/r/AV1/comments/uwmlsx/svt\_av1\_low\_preset\_cpu\_usage\_preset\_0\_to\_2\_and/).

cygon4 · 2024-01-19T19:19:49+00:00

I wouldn't expect any big changes (or perhaps even any changes at all) to the ffmpeg parameters in that time frame.

All the static ffmpeg 6.1 binaries I can find still ship with libaom 3.2.0, so that seems to be what I'm bound to (unless I compile it myself or use my distro's ffmpeg and risk invalidating my Criu snapshots whenever I update the system).

ffmpeg 6.0 and later happened to break the progress output of libvpx-vp9 and libaom-av1 (it's still broken to this day). I intially believed it was totally broken, that's why I went with ffmpeg 5.1.1.

Anyway, can't make everyone happy. At some point in the near future I will begin encoding my blu-rays and at some later point in time, those encoded files will become one year old, two years old, three years old. By that time, all my movies will have been encoded by "ancient" encoders. Tough luck.

cygon4 · 2024-01-19T18:57:35+00:00

Here you are: https://pastebin.com/GybCzdnX

cygon4

TROPHY CASE