太实用了

Update 1.3.5:
- the "pale background" bug has been fixed. It was a missing asset that was supposed to be present in the Roost, but currently isn't. Was a bit hard to track down because a duplicate of this asset exists in Shelves, so I wasn't reproducing it locally and not everyone was reporting the same issue. Should be all good now!

Thanks for posting that was going to talk about the same issue.

Sounds like an old bug, maybe unsubscribing and resubscribing might help. Steam has a habit of not properly updating DLL mods automatically.

the background of the codex is a very bright pale color on my install, any ideas why that would be the case?

Update 1.3.3:
- major rework, uses the new UI framework integrated into the Roost. The mod was rewritten from scratch
- support for subentries

Don't worry, I wrote a script to translate the description-related fields. If there are updates, I just need to run the script again.

Also, to discuss this further, please come talk to us on the cultist simulator fan discord. :)

You...tried translating it by hand? You know a lot of it is generated and might change a lot with each update, right?

Codex uses the same TMPro components for its UI so it should support all the fonts. Maybe it doesn't work. Codex is getting a big UI rework, we'll take a look at it. Thank you for your feedback!

I tried to translate "Mariner" into Chinese, but the Chinese font is missing in "Codex".

@Mensluguolo for the requirements:

Yes, you can check if an entry exists or has a specific mutation on it via the grandReqs property (Roost Machine specific, but Codex requires this mod to be enabled anyway). Example:

"grandReqs": {
"[*/codex : myentryid]" : 1
}

For more information, please consult the modding documentation written by the discord community, or even better, come talk to me in the #modding channel of the discord community server. :)

Hello @Mensluguolo :
For the persistCodex:
- legacies can define a "codex" property ("defaultcodex" by default).
- legacies can define a "persistCodex" property. When set to true, and you're playing this legacy, the game will save it in a file every time it saves.
- when starting a new game, Codex will look at the codex ID of the legacy, check if persistCodex is true, and if so will try to find the corresponding persisted codex file to load it.

So what persists is the exact state of the codex: elements and mutations. The "codex" is like an alternative table, saved in its own file, and displayed via a custom modal. Its "entries" are elements, and the mutated aspects via updateCodexEntries are mutations on these elements.

Couple of questions:
"persistCodex makes the codex persistent between different saves of legacies defining the same codex property value." - can you elaborate?
What exactly persists and between which runs?

Is there a way to check if you have a codex-entry unlocked as part of recipe requirements? something on the line of "I need to know X before I can do this"?

Update 1.3.1:
- fixes to the execution of codex properties in element xtriggers and recipe furthermores

Update 1.3.0:
- codex properties are now supported in The Roost Machine's xtrigger grand effects and the furthermore property

Update 1.2.1:
- duplication issues should now be solved (you can't unlock the same entry twice anymore)

Update 1.2.0:
- added two new properties on legacies: codex and persistCodex. persistCodex makes the codex persistent between different saves of legacies defining the same codex property value. The default value of codex is "defaultcodex" and the default value of the persistCodex property is false. (might become true soon, still undecided on that)

Update 1.1.0:
- added the three properties to Elements, executed when the element is first spawned
- added a new property to codex entry update objects for updateCodexEntries, "unlock", to automatically unlock an entry when updating it if it's not already unlocked