With FFXIV on Switch 2 now, I’ve been thinking more about how awkward chat can be when playing on console/handheld. The software/regular keyboard just isn't doing it for me.

I keep thinking it would be nice if I could just talk into my phone, quickly review/edit the text, then send it into chat somehow.

Like imagine being able to say things like "Say in chat/party/fc <your message>" or "Wave/Jump/Sit" etc.. Maybe even use chat to execute macros or other in game commands.

Curious how other console players feel or are handling this.

Do you actually use chat much on console, or mostly avoid it?

Is a keyboard good enough, or is it still annoying depending on where/how you play?

Will Yoshi-P ever give us real voice-to-text!?

Would phone voice-to-text with a preview/edit step feel useful, or too awkward?

If something like this existed, would you use it?

Anyway FFXIV on Switch 2 has been awesome otherwise, see you all in Eorzea! :D

Edit: thank you everyone who took the time to comment, greatly appreciated!

Hey everyone, I’ve been thinking about a problem with AI knowledge systems and was hoping to get somewhat of a sanity check from people actually building in this space.

From my understanding, most RAG setups seem tied to a particular app, vendor, or index. You often end up ingesting the same docs again for different agents or runtimes and and some basic questions can be difficult to answer consistently like:

- What version of this knowledge is the agent using?

- Where exactly did this information come from?

- Has the underlying source changed since it was last ingested?

- Can I move the same body of knowledge to another runtime without rebuilding it?

- Can multiple agents use the exact same knowledge?

The idea I’m exploring is something I'm calling a Durable Knowledge Base (DKB).

The basic concept:

- Compile source docs, code, or structured data into a portable, versioned knowledge artifact

- Preserve source paths, hashes, citations, and provenance

- Sign and publish releases through a registry

- Allow knowledge packages to be installed, updated, pinned, and removed

- Let agents search, find, and read the same knowledge base across different runtimes

- Keep the artifact retrieval-agnostic rather than baking one specific top-K/RAG strategy into the format

Basically, I'm wondering whether knowledge should have something closer to a package lifecycle, rather than every application maintaining another disconnected RAG index.

I'm also very aware that things like Azure AI Search, GCP, vector databases, MCP servers, Agent skills, etc. already cover pieces of this problem, sometimes extremely well.

So Im specifically not asking: "Can I build a better enterprise search engine here?"

I'm trying to figure out whether the portable knowledge artifact itself is useful.

Would this solve an actual problem for you? Or is this mostly reinventing existing search/RAG infrastructure with some packaging and provenance added on?

I would especially like to know:

- What do you currently do when multiple agents/apps need the same knowledge?

- Do versioning and provenance actually matter to you?

- Would you ever install someone else's curated knowledge package?

- What would this need to do that existing solutions don't before you woukd bother using it?

Feel free to poke some holes. I'm actually looking for reasons not to build this further before I sink more time into it.

Thank you.

Hey everyone, I’ve been thinking about a problem with AI knowledge systems and was hoping to get somewhat of a sanity check from people actually building in this space.

From my understanding, most RAG setups seem tied to a particular app, vendor, or index. You often end up ingesting the same docs again for different agents or runtimes and and some basic questions can be difficult to answer consistently like:

- What version of this knowledge is the agent using?

- Where exactly did this information come from?

- Has the underlying source changed since it was last ingested?

- Can I move the same body of knowledge to another runtime without rebuilding it?

- Can multiple agents use the exact same knowledge?

The idea I’m exploring is something I'm calling a Durable Knowledge Base (DKB).

The basic concept:

- Compile source docs, code, or structured data into a portable, versioned knowledge artifact

- Preserve source paths, hashes, citations, and provenance

- Sign and publish releases through a registry

- Allow knowledge packages to be installed, updated, pinned, and removed

- Let agents search, find, and read the same knowledge base across different runtimes

- Keep the artifact retrieval-agnostic rather than baking one specific top-K/RAG strategy into the format

Basically, I'm wondering whether knowledge should have something closer to a package lifecycle, rather than every application maintaining another disconnected RAG index.

I'm also very aware that things like Azure AI Search, GCP, vector databases, MCP servers, Agent skills, etc. already cover pieces of this problem, sometimes extremely well.

So Im specifically not asking: "Can I build a better enterprise search engine here?"

I'm trying to figure out whether the portable knowledge artifact itself is useful.

Would this solve an actual problem for you? Or is this mostly reinventing existing search/RAG infrastructure with some packaging and provenance added on?

I would especially like to know:

- What do you currently do when multiple agents/apps need the same knowledge?

- Do versioning and provenance actually matter to you?

- Would you ever install someone else's curated knowledge package?

- What would this need to do that existing solutions don't before you woukd bother using it?

Feel free to poke some holes. I'm actually looking for reasons not to build this further before I sink more time into it.

Thank you.

Hey everyone,

I just released Divine Logic v1.2.0.

Divine Logic is a Creation Kit logic framework made of pre-scripted, modular trigger boxes. The idea is simple: if you can drag, drop, configure, and connect objects in the Creation Kit, you can start building more interactive Skyrim mods without writing a custom Papyrus script for every mechanic.

You can use Divine Logic to build things like:

• moving platforms, doors, statues, and mechanisms
• in-game cutscenes and staged reveals
• puzzles, traps, counters, item checks, and state-based logic
• enemy waves, rewards, object spawning, and encounter controls
• cross-cell or persistent puzzle state using globals
• chained logic systems made from visible CK objects

Think of it like LEGO blocks for Skyrim gameplay logic: each box does one useful thing, and you build bigger mechanics by placing, configuring, and connecting them in the Creation Kit.

For context, here is the original v1.1 announcement.

Important note for existing v1.1 users

Divine Logic now uses a stable master filename:

DivineLogic.esm

Previous versions used:

DivineLogic_v1.1.esm

I changed this because versioned master filenames create a bad long-term problem. If every release had a different master name, every dependent plugin would keep needing a new master dependency. Starting with v1.2.0, the framework master is just DivineLogic.esm, which should make future updates cleaner.

If you are starting a new project, just load DivineLogic.esm as a master.

If you already made an .esp that depends on DivineLogic_v1.1.esm, you will need to update that plugin so it points to DivineLogic.esm instead.

Back up your plugin before editing masters.

Updating an existing plugin with Wrye Bash

1. Install Divine Logic v1.2.0 so DivineLogic.esm exists in your Data folder.
2. Back up the plugin that depends on DivineLogic_v1.1.esm.
3. Open Wrye Bash.
4. Select your dependent .esp in the Mods tab.
5. In the plugin details, find the Masters list.
6. Allow editing on the Masters list if needed.
7. Select DivineLogic_v1.1.esm.
8. Use Change To....
9. Choose DivineLogic.esm.
10. Save the plugin.
11. Open the plugin in the Creation Kit and verify that your Divine Logic references still resolve correctly.

Only replace the old Divine Logic master with the new Divine Logic master. Do not swap in an unrelated file.

Wrye Bash docs: Advanced Readme

What is new in v1.2.0?

• Stable master filename: DivineLogic.esm replaces the old versioned master filename.
• API filename resolution update: the API now looks for the stable Divine Logic plugin name.
• Better marker chain behavior: DivineSpawner and DivineWarper marker chains now support repeating single-marker setups and looping multi-marker sequences.
• Keyword refs now behave in expected order: DivineRef01 through DivineRef09 are read numerically, which makes sequential activation easier to reason about.
• Cutscene startup improvements: the cutscene creator has better startup handling for first-person camera setup and blackout behavior.
• Animator relay behavior improvement: DivineAnimator now performs its animation/variable/look-at work before relaying activation.
• Expanded documentation: the docs now explain Creation Kit trigger creation, prebuilt marker forms, linked-reference wiring, marker chains, the API, performance guidance, and box properties.

What boxes are included?

Divine Logic includes boxes for activation, actor value modification, animation, comparison logic, inventory transfer, cutscenes, deletion, enabling/disabling, Havok force, global variables, markers, messages, sound/music, player control, scaling, spawning, translation, and warping.

The full documentation has every box property, every marker property, API usage, examples, compatibility notes, and performance guidance.

Links

• Nexus page
• Full documentation
• Discord

If you have questions, want help wiring something up, or want to show what you are building, join the Discord and head to #skyrim_divine-logic.

Happy Modding!

Hey everyone,

A while back I posted about Divine Logic, a framework I was building to help Skyrim mod authors add gameplay logic without having to write code.

Divine Logic v1.1 is now officially released on Nexus.

Nexus:

https://www.nexusmods.com/skyrimspecialedition/mods/185730

Divine Logic is a set of pre-scripted, modular, trigger boxes that allow Skyrim modders to add complex logic to their creations without needing to use the Papyrus scripting language.

If you understand how to drag, drop, and connect objects within the Creation Kit, you will now be able to make objects and characters move, add in-game cut-scenes, make interesting puzzles, and much more!

The requirement to know and use the Papyrus scripting language is a pretty large barrier to entry for many would-be creators. Divine logic offers an alternative to Papyrus scripting and potentially opens the floodgates on mod creation.

v1.1 also includes an API for advanced mod authors who want to query and activate Divine Logic signalers from their own scripts.

This is a modder's resource, so it is primarily intended for people creating Skyrim mods. Source scripts and complete documentation are included.

If you have questions, want to show what you're building, or would like to see examples, I'll be hanging out in the Discord:

https://discord.gg/jTXqGnNJ8r

Head to the #skyrim_divine-logic channel.

Thanks to everyone who followed the project, tested things, or encouraged me to finish it. I'm excited to finally get this out and see what people build with it!