RSSAmplifier

redstrate's Blog · Aug 4, 2026

Kodama Progress Report 2 - Dreams

0
Sign in to vote or save

redstrate · redstrate.com

Posted on
Tags: FFXIV Reverse Engineering
Syndicated to: Mastodon logo

The project survives into another progress report! This one is going to be a short and sweet, partly because I’m torn between a few other projects and because working on Kodama isn’t easy. Let’s dive into this month’s changes anyway 🙂

If you don’t know what Kodama is, it’s a FFXIV 1.23b server emulator. While it’s currently limited in functionality compared to other projects, we aim to be easy to setup and understand.

Spawning Actors #

Like most games, the world is made up of various and varied actors like players, enemies and objects. As you may have suspected if you saw Project Meteor, the lack of client-side information is a huge problem. We have their individual models and text data, but lack important details to re-create the world as it once was. What we have is whatever Project Meteor put together, a few public packet captures and online video footage. Basically in fewer words: if we want to have enemies in public fields we’ll need to place them there manually. And it’s not just enemies: this applies to literally every interactable object and NPC!

This poses an interesting problem for server emulators: how do we describe where these actors are placed? In Kawari (a server emulator for FFXIV ARR) I was tackling the same problem there: a way to manually place enemies as that information was stripped out of the retail client. And so I adapted that system to this scenario:

{
    "actors": [
        {
            "label": "Bed",
            "position": {
                "x": 155.97,
                "y": 0.0,
                "z": 165.14
            },
            "rotation": -1.65,
            "class": 1200379
        },
        {
            "label": "Exit",
            "position": {
                "x": 159.98,
                "y": 0.02,
                "z": 151.9
            },
            "rotation": 0.0,
            "class": 1200335
        },
        {
            "label": "Unending Journey",
            "position": {
                "x": 159.84,
                "y": 0.7,
                "z": 167.17
            },
            "rotation": -0.2,
            "class": 1080120
        }
    ]
}

Here is a example drop-in for one of the inns, but this isn’t new or groundbreaking. Project Meteor had this same information, it’s just kept in SQL instead. I wanted something easier to consume from a human and tool point-of-view.

Let’s break down the format further as it reveals some interesting technical details and oddities with the 1.x actor system! Labels are arbitrary and not read, they’re present to make the entries easier to maintain. Position and rotation are also arbitrary, as you’d expect actors could be placed anywhere. The most important bit of detail is the “class”. That’s a unique number corresponding to a Lua class. Every object and NPC has one, and roughly corresponds to a Lua script on the client alongside appearance information and their display name.

The disconnect here is that we aren’t privy to the mapping between actor classes and Lua class names. For example, our inn bed has an actor class of 1200379 but Kodama somehow has to know that it’s the /Chara/Npc/Object/ObjectBed script. This is not only useful for the server, but we also pass this path to the client to initialize the object’s behavior. That means we have to maintain a manual look-up table to do this, fortunately Project Meteor started a lot of that work already.

This is just foundational work as we can’t spawn functional objects or NPCs yet. The client is very finicky, and the event interaction system is super complex!

Leveling up #

Kodama now persists classjob EXP, so I added a !exp command to give yourself more EXP - because a legitimate method isn’t implemented yet. When adding the needed amount of EXP to level, you’re now automatically leveled up too!

However there’s an additional system bolted onto leveling up: FXIV 1.x and even early ARR had a skill point allotment system (before ripping it out in Stormblood.) Basically the player could manually move points between stats like STR, VIT and so on. If you watched any online videos of 1.0 this is the UI used to interact with it:

But if you take a look at a 1.23b client, you’ll notice it actually looks much different:

What gives? Well, it turns out that in 1.20 they modified the system (as described in the patch notes.) So there’s a lot of information online that’s actually talking about the old system, which definitely didn’t make research easier.

Project Meteor didn’t implement this system (because it’s not super important) but I couldn’t help myself, it was an easy afternoon project! You’ll get the retail-accurate number of points each level (starting at 10) and can only allot the allowed maximum for that level. Keep in mind that the stats don’t matter yet - as there’s no combat - and the base stats are still at a fixed number.

Teleporting #

Kodama now implements the Teleport and Return command, but they do not place you next to Aetherytes right now. It’s more like a dressed up !teri command with built-in destinations. Unlike Project Meteor, we do keep track of the Anima used, but there’s a few limitations:

  • Anima does not regenerate nor are any of the legitimate ways to replenish it implemented. You can use the !anima command to set it right now.
  • Not having the required Anima does not prevent you from teleporting yet.
  • The Anima cost is fixed and does not change under the circumstances you would expect it to.

More new debug commands were added to bridge the gap in in-game functionality: !unlock_aetheryte, !favor_aetheryte and !homepoint are needed to make the Teleport command functional for new characters.

Tooling #

Between working on Kodama and Umbra, I’ve been creating a new FFXIV toolset for 1.x specifically. It’s called Atma and if you’re familiar at all with my Novus software then it’s pretty much identical! I have created an Excel and Map Editor (they’re not editors yet FYI) and they’ve been super invaluable tools already:

They’re still super early in development of course! There’s no pre-built binaries yet and the map editor makes everything look like Nier: Automata but they do work.

Launcher #

One thing I was missing while playing FFXIV 1.x on Linux was changing the options. When using the out-of-game options tool, it actually couldn’t save anything and crashed immediately. Which is annoying because the game defaults to a middling set of options and a tiny resolution! I spent some time reverse-engineering the config format, and then integrated these options into Umbra itself:

This also exposed a screenshot directory option ala Astra (under General options.) This feature hasn’t been released yet, but you can try it from a GitHub Actions build.

Smaller things #

I fixed the SpecialEventWork packet, which is basically 1.x’s “festivals”. Right now it cannot be customized from the config file, and it’s hardcoded to expose the Bomb Dance emote ala Project Meteor.

When waking up in an inn, a non-quest dream is now determined randomly.


Kodama is open source and we regularly accept contributions big and small ♥️ If you are stuck on something, or are unsure if it’s in scope for Kodama don’t hesitate to open an issue or join our chatroom (it’s currently shared with Kawari.)

Share on Mastodon!

See Also #

Read the original on redstrate.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.