Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Three Eyes Software

460
Posts
8
Topics
592
Followers
A member registered Sep 07, 2024 · View creator page →

Creator of

Recent community posts

Are you using the QAT version?

Someone created an unofficial Discord here a while ago: https://discord.gg/RJeV2qu28J

There is no official Discord though, and I am not present on that server.

It's only for the demo now, but a much better model that only requires 8 GB of VRAM has been added since then.

If you're on Windows, open a command prompt in the game's folder, then run:

Silverpine.exe > log.txt 2>&1

It will create a log.txt file in the same folder. Reproduce the bug, then upload the log somewhere like Pastebin.

If you're on Linux, open a terminal in the game's folder, then run:

./Silverpine.x86_64

It will directly output to the terminal.

They're currently not valid variables, but they should be, since %SEX% still is.

There will be support for Gemma 4 31B, which is currently not used in generating the actual dialog, and GLM-5.1 in 1.7.3. 
Maybe there's something confusing about your custom characters specifically. Make sure not to add any instructions addressing the LLM to your character descriptions.
Nemo is ancient and no longer sufficient for the current harness.

Eventually, yes.

I've uploaded a patch. Thanks for the report.

Version 1.7.2 adds Gemma 4 12B to the model lineup. It doesn't use the backend's --fit feature, which might be the problem here, if your detected/confirmed VRAM amount is 16+ GB. Hope that fixes it.

(2 edits)

You can manually download the model from any source and put it in the KoboldCPP folder, then create a .seal file of the same name, which is just a JSON with two fields inside. The size field must be the same number as the byte size of the .gguf file, as shown here.

The quantization level of the downloaded model should be Q4_K_M. The .gguf file must be named the same as its alias in the game. For Gemma-4-Sparse, the actual model is Gemma 4 26B-A4B.

Edit: I made a mistake here. The "url" field has to be "https://huggingface.co/bartowski/google_gemma-4-26B-A4B-it-GGUF/resolve/main/google_gemma-4-26B-A4B-it-Q4_K_M.gguf?download=true" for Gemma-4-Sparse, or the game will force you to redownload it from that source.

Edit: As of version 1.7.2, you can now use "N/A" like in the picture to skip the version check.

This has been fixed a while ago. Are you on the newest version?

This is just a guess, but make sure your KoboldCPP version is back to 1.111.1.
The OpenRouter key has to have credits on it, and sometimes extra characters slip in while pasting into the API key field, so try quick setup if you haven't already.

Gemma 4 is much more stable, knowledgeable, and RP oriented than Qwen 3.5. You will notice that it's a sparse model with less active parameters, but it more than makes up for it by being "in its element".

I wasn't really able to reproduce this issue, so my attempt at fixing it was a shot in the dark. It's certainly something very strange if you have objects not sticking to their normal grid positions.
This is inside the zone of persistence around Orson's cabin, not wilderness, so I can't easily retroactively fix it for old saves. The shape of it makes me think it's not related to what I've changed. Was this already present the first time you went to the cabin on this save? Does it occur on fresh 1.7.1 saves?

I've also experienced weird memory errors working with Qwen 3.5, though I'm not sure if it's an issue with KoboldCPP or the hardware itself.
Try Gemma-4-Sparse, it's a better model in most aspects anyway.

Which model are you using?

A logical next step would be having something that lets you create plots and premade buildings, but I'm not 100% sure about the specifics yet.

It's not impossible, but back in Nemo days it was very beneficial to have the AI take the first turn. It might be different now with Gemma 4.

Feel free to post it here, but don't create a thread for it.

It's a process that requires querying the LLM. Does talking to NPCs work? Disable all custom NPC definitions so you can test this. What are your system specs and which model are you using?

This is a model issue, so there's nothing that can be done about it without destroying performance through extra API calls that check for and correct it.

(3 edits)

There simply isn't enough context window/intelligence/performance for these kind of elaborate systems with the local models that can run on the average person's machine. I have some ideas for an alternative to dynamic mode which queries the custom NPC's AI every in-game hour to let it choose from the list of possible routines in real time, taking into account everything that it has access to in dialog, but I have doubts about Gemma-4-Sparse, aka 26B-A4B, being able to handle this in a coherent way.

NPCs can change their daily routine in a very limited way if you plan a meeting at X location in Y hours/days, and them not being able to follow you outside the town perimeter has been solved with version 1.6.0.

This is planned for a minor update.

I'm working on improving this for Gemma 4 specifically using its currently unused thinking mode. Models with low active parameter count struggle with this task the way it's currently set up. Qwen 3.5 seems to do fine. I have not extensively tested it with the dense Gemma 4 or DeepSeek, but if it's a problem with those too, please let me know.

Knowledge doesn't see %SPECIES% as a variable, so write out the actual species.

The NPC has to be mentioned or present for their public knowledge to be accessible. I will investigate having "lesser" custom player character description fragments as a feature though.

Will investigate.

The AI can change its mind about invoking some NPC actions, and in most cases it results in better accuracy.

The log shows that it fails during text completion too. This is some sort of mystery OS/driver/backend issue, since the only thing the game does differently between sending requests to Qwen and sending requests to Gemma is that it launches the backend with SWA enabled on Gemma.

You could try letting the game load the model, then killing the hidden Kobold process after it's done loading the model, and run this command in the StreamingAssets folder to "switch out" the backend process for one without SWA:

./koboldcpp-linux --model "Gemma-4-Sparse.gguf" --usevulkan --gpulayers -1 --quiet --multiuser 100 --contextsize 4096 --skiplauncher --port 5003 --nofastforward

If SWA isn't what causes the problem, I'm out of ideas. It's difficult for me to debug what's happening here because I don't have an AMD system to reproduce the bug with, if that's even the cause.

This has been fixed now. Thanks for the report.

(1 edit)

I've uploaded a patch that should fix it. Now I'm also curious where you got the log in your original post from, seeing as logging should be disabled and there is no user-facing way to copy errors that happen during dialog.

Add diffuse to the first one, delete the second one, or copy the contents of the first one into the second one.

Modifying default NPCs doesn't change their schedules. Dynamic mode is only available for fully custom NPCs.

The game prefers textures of which the name contains "diffuse", "albedo", or "color", and refuses textures with "specular", "metal", "normal", "smooth", or "emission".

Import the model into Blender and check if the actual color texture somehow violates this rule.


The model itself is working completely fine. This seems to be a problem related to KoboldCPP's tokencount API. I'm sort of at a loss why this would be happening with specifically Gemma 4 series models.

The changelog for koboldcpp-1.112.2 says "Fix for /api/extra/tokencount". I see that you've manually updated to 1.113, but for sanity, try it again with 1.112.2 specifically. If this doesn't fix the issue I will add a fallback that simply guesses the token count if the API fails.

Your link requires a login. Use Pastebin or just post it here.

It's a bit difficult to explain what the faction value actually does because it influences a lot of little things internally, and should simply be "Silverpine" if the NPC lives in Silverpine, "Capital" if the NPC is an offscreen visitor from the capital like Mirel, and "Other" if they live in the wilderness. It has no influence on anything that is clearly visible to the player.

The custom NPC's daily routine in dynamic mode is solely influenced by the private character description, knowledge, and possible routines you have set up. The AI will try to infer a daily routine from those things.  For example, if you have a custom NPC that has just two possible routines, "visit_tavern_in_silverpine" and "stay_in_capital", and a knowledge entry that says "%NAME% visits Silverpine every Tuesday.", the AI will most likely set up a daily routine that results in the NPC visiting the tavern every Tuesday.

Custom NPCs being able to move in with the player like Mirel will come in a minor update. You can currently have 8 custom NPCs enabled at the same time.

I'm not willing to moderate this (which is also why I just purged all those posts in the other thread), so someone will have to make a third-party place for it.

There's a log file at ~/.config/unity3d/Three Eyes Software/Silverpine/Kobold.log now.