Rioku Labs: dev log

Spoiler: What's Hiding in Hostile Encounters

Fri, 23 Oct 2026 00:00:00 GMT

Spoilers and unfinished content from the game files.

Release: Data Center v0.9.0

Thu, 22 Oct 2026 00:00:00 GMT

Data Center is on the Steam Workshop. It's our first mod, it's version 0.9, and you can subscribe to it right now.

If you missed the last post, that's the one about why anyone would want a server room on their ship. This one's about what's actually in the box.

At a glance

73 blocks: server racks, rack servers, overhead cable trays and the room around them.
Six of the servers are the game's own automation blocks in rack form, so your timers, event controllers, LCDs, batteries and control panels can live in a rack.
No other mods needed. Scripts are optional.
Free and open source under the GPL.

Known issues

It's a 0.9 for a reason. These are the ones we know about:

Front + Rear Doors racks open both sets of doors together.
Rack doors don't block you when they're closed. The aisle containment doors do.
Two contained 1.5 m aisles can't share a row; make one of them 1.0 m.
On a 24U rack, the rack label only fits on the back.
Rack PDU strips will stand on any upward face. To seat one in a rack, aim at the plinth top in the rear corner.

If you hit something else, open an issue on GitHub with the log lines that mention [DataCenter].

Racks and servers

There are six racks: 24U and 42U, each as an open frame, with split front doors, or with doors front and back. Place a rack, aim at the back of an empty slot and the server seats itself in it. A 42U takes eight servers, a 24U takes four, and the UPS takes two slots on its own.

The Timer, Event Controller, Status Display, UPS and KVM Console work exactly like the vanilla blocks they're built on, same terminal and all. Compute, Storage, Network Switch and the Blanking Panel don't do anything, but a half-empty rack looks sad, and nobody wants that.

Cable trays

38 tray pieces in four cable densities, from an empty basket to completely stuffed. Reducers step a run down one density at a time, and a Drop hangs over a rack and pours its cables in from above. The basket stays silver and the cables take whatever paint you use, so color-coding your runs is on you. Finally, cable management without a bag of zip ties.

The room around it

Raised floor tiles to stand everything on, an in-row cooler whose fans spin up when it has power (it cools absolutely nothing, but it's very convincing), a PDU cabinet, power strips for the backs of the racks, and sliding containment doors and roof panels for 1.0, 1.5 and 2.0 m aisles. The signs and rack labels are LCDs, so type whatever you like on them and paint the frames red for hot aisles and blue for cold ones.

Building it, and breaking it

Every block builds the way vanilla blocks do: a see-through cage until it's 30 % done, then the frame, with lamps, screens and cables going in last. Shoot one and you get the game's damaged look, sparks, smoke and fire, and when a section breaks off you see a solid inside with torn wiring instead of an empty box.

Scripts, if you want them

Everything above works without scripts. If you launch the game with -loadScripts, you also get a smoother KVM drawer that waits for the rack doors to open before it comes out, and a Programmable server that actually runs your code. Saves are identical either way, so you can switch back and forth. Keen, the offer from last time still stands.

What's next

0.9 means close, not done. Block names, costs and PCU can still change before 1.0, so keep that in mind before you build something enormous. After that it depends a lot on what people build and what they ask for. Ideas for new rack servers are very welcome in the GitHub Discussions.

Get it

Go build something we didn't think of.

*The pictures and clips in this post are renders of the mod's own models, not in-game screenshots.*

What do you actually do with a server rack in Space Engineers 2?

Thu, 22 Oct 2026 00:00:00 GMT

I showed the site to a few coworkers this week and one of them asked what you actually do with servers in the game. They don't play Space Engineers, so fair enough. A server rack in a space game does sound a bit random.

The quick answer is that they run your ship. The longer answer is that they're built for role play, which is half of why I play sandbox games in the first place.

Your ship already has a brain

Space Engineers has a few blocks that make your builds run themselves. Timer blocks fire off a list of actions after a delay, like closing the hangar doors, turning the lights on and starting the engines. Event controllers wait for something to happen, say a door opening or a tank running low, and kick those actions off for you. The first game also has the programmable block, which runs C# you write yourself. People have done ridiculous things with it. Someone built Minecraft in one.

In a normal build, though, all of that lives in a few blocks bolted to whatever wall had space. Your ship's brain is somewhere behind the cockpit and you never think about it again.

So we put it in a rack

Every working server in Data Center is one of the game's own blocks in a rack-server body. The Timer server is a timer, the Event Controller server is an event controller, the Status Display is an LCD, the UPS is a battery and the KVM Console is a control panel. Same settings, same terminal, so whatever you already know how to set up still works. The Programmable server is the one exception for now: SE2 doesn't run scripts by default yet, so it only runs your code if you launch the game with -loadScripts. (Keen, if you're reading this: official mod scripts and in-game scripting whenever you're ready. No pressure. Okay, a little pressure. I really want to see how far this engine can be pushed.)

The servers slide into racks, the racks have doors that swing open, and when you switch the KVM on, its drawer slides out and the screen flips up. None of that makes your timer any smarter. It just turns your ship's brain into a place you can walk up to.

Why there's a whole room

If I was going to make racks and servers anyway, I figured why not do the room too. So there are raised floor tiles, hot and cold aisle containment with real doors, cable trays that run overhead and drop into the racks, and an in-row cooler whose fans spin up when it gets power. It doesn't cool anything, since SE2 has no heat, but it's very good at looking busy.

I don't expect everyone to use all of that. How much detail you put into a build is a personal thing. Some people will tuck two half racks behind the bridge and call it done, and that's a perfectly good use of the mod. Some people will build the whole hall. I spent eight years working in data centers, so you can probably guess which one I am.

Built for role play

I've always enjoyed a bit of role play in sandbox games like this, and that's really what Data Center is for.

Picture your mining ship with a little server closet off the main corridor, the status display telling you what the ship's up to before you even reach the cockpit. Or a station with its data core sealed behind aisle doors. In multiplayer everybody knows where that room is, which makes it the first thing you defend and the first thing the other side comes looking for.

And when you come home after a long trip and a screen in the rack says CORE ONLINE, it doesn't do a single thing for your ship's performance. It just feels right.

I really admire the people who take this seriously. The Sigma Draconis folks are a great example: a community that modded and tweaked the first Space Engineers until it plays like a certain sci-fi universe with some very good drives. That's real dedication, and it's the kind of thing that makes me want to build more. Data Center is a small first step in that direction.

This wasn't possible in SE1

What Data Center does today couldn't have been done in the first game. SE2's unified grid lets small, detailed parts sit right alongside the big ones, which is how a server can be one slot in a rack instead of a whole block of its own, and how a room can have floor tiles, cable trays and door frames that line up.

And the game is still in alpha. With what I think Keen has planned, we could end up with 10x, maybe 100x the realism we have now. Imagine what a dedicated team of server builders and modders could do with that: whole role-play universes where the ships, the stations and the rooms inside them all feel like they actually work.

Ideas we can't stop thinking about

None of this is planned, so don't hold us to it. It's just the kind of thing we talk about way too much.

Say Keen adds a full currency system someday. I'd bet they will, and if they don't, some mod author probably will. Now picture a crypto mining server. It slides into your rack, it makes you money, and it eats power like nothing else on the ship. If you've ever wanted to explain to your faction why the lights keep going out, this is your chance.

Or hacking. Red team servers on one side, blue team servers on the other, and the fight happens over the network instead of with guns. A red team parks a ship full of attack servers outside your station and goes after the data core remotely, while your blue team's racks try to keep them out. Suddenly that room behind the aisle doors matters a lot more. Give it a month and someone would be running capture the flag on a dedicated server. DEF CON in space, and the Wi-Fi still wouldn't be safe.

That's really what I mean by all this. A game like Space Engineers is what you make of it. Keen does a great job giving us so much cool stuff, but they know and we know that modding is what this game is built for. We're a community, and an awesome one at that. What we love about the team at Keen is that they understand that desire, because it's exactly the same one they have.

We'd love to hear what you'd put in a rack, or what you'd build around one. There's no Discord yet, so for now the place for that is Data Center's Discussions on GitHub. The code's there too, under the GPL, if you're curious how a timer block ends up in a rack.

Yes, we use AI to build our mods

Wed, 21 Oct 2026 00:00:00 GMT

Plain version first. A lot of what Rioku Labs makes is built with an AI coding assistant, mostly Claude Code. That covers the mod scripts, the test suites, the tools we use to build and package mods, and this website. The block models are generated by code in Blender, and a lot of that code gets written the same way.

I'm saying it because modding communities care about this, and they're right to. People have strong feelings about AI in games, and a lot of those feelings were earned. I'd rather you hear it from me in a post than work it out yourself and wonder what else I left out.

Where I'm coming from

My day job is in software development, so I've watched AI coding tools arrive from pretty close up. I've seen the bad side first hand. Code that looks finished and isn't. Pull requests nobody can explain, because nobody really wrote them. Tests that pass because they don't actually test anything. Confident answers that are just wrong. When people call it slop, I know exactly what they mean, and I've had to clean some of it up.

I've also seen the other side. Developers who stopped losing their afternoons to boilerplate and glue code and got to spend them on the hard problems instead. People getting productive in a new language or framework in a week instead of a month. Small teams shipping things that used to need big ones. Same tools, very different results.

The difference, every time I've seen it, is the person using it. AI is a tool. Used responsibly, it does what it's told, and really that's all it can do. If you don't know what you're asking for, or you don't check what comes back, you get slop. If you do, you get a lot more done than you ever could on your own.

What I can't do

I'm not going to lie: I don't know the first thing about 3D modelling. I've never been good at frontend work either. I've always been a backend and infrastructure guy, and before my current job I spent eight years working in data centers. That's where my strengths are, and none of them have much to do with making things look good.

So without help, Data Center would have stayed an idea. I knew exactly what I wanted and had no way to build it. Modelling, materials, UVs, animation, the game's block definitions, and a website that doesn't look like it's from 2004 are each things people spend years getting good at.

What I can do

What eight years on a data center floor does give you is a very clear picture of what one should look like. That's where the mod came from, and it's why there's so much focus on getting the details right.

Racks come in standard heights, so ours are 42U and 24U. Hot and cold aisles get closed off with doors and roof panels so the air goes where it's supposed to. Perforated floor tiles go where the cold air needs to come up, not wherever they fit. Rack power strips run off two separate feeds so one failure doesn't take a rack down, and our A and B strips sit in opposite rear corners because that's how you'd actually wire it. Cable trays hang above the racks and drop into the cable managers, not into the middle of the rack. And a KVM drawer slides all the way out and stops before the screen lifts, because that's how they work.

None of that is taste in the artistic sense. It's knowing what's right. That turns out to be exactly what a tool that does what it's told needs from whoever is telling it. It can write a generator for a perforated floor tile without breaking a sweat. It has no idea where that tile belongs until somebody tells it.

How we actually use it

In practice the assistant writes the code and I decide what the code should make. Every block starts as a description of the real thing: what it is, what each part does, how it should behave in the game. The assistant turns that into models, definitions and scripts, and then I look at the renders.

That last part is most of the job. Nothing gets accepted because a test went green. Models get rendered from several angles, moving parts get rendered as video, and a lot of what I send back is some version of "no, that's not how that works."

When I catch the same kind of mistake twice, it becomes a written rule the assistant has to follow from then on. Every visible part on a block needs a real job. Parts have to physically touch whatever they're attached to. A broken block shows a solid inside with torn wiring, never an empty box. Those rules live next to the code, and where they can be checked by a test they are, so each new block starts from everything the last one taught us.

There are lines it doesn't cross, either. We don't copy other people's mods or code, whoever or whatever is doing the typing, and we only reuse code where its licence allows it. Data Center's source is public under the GPL, so you can read all of it and judge it for yourself.

Where it still gets it wrong

Left alone, the assistant will happily make something that passes every test and still looks wrong. Our first KVM motion was technically fine and looked like a glitch. The first go at broken interiors modelled pipes, pumps and control boards, used up nearly the whole triangle budget, and still looked hollow. An early model had clamps floating off their mounts and pins that weren't in their holes.

Every one of those got caught by a person looking at a render and going, no, that's not right. I don't really count that as the tool failing. It did what it was told. What it was told just wasn't specific enough yet, and fixing that is my job.

Why there's a dev log at all

Posts like this one start as AI drafts too, and I'll be honest about why: I'm not good at writing like this. Explaining what I built and why, in a way that's actually enjoyable to read, is its own skill, and it's one I want to get better at. So I tell the assistant what I want to say, it writes a draft, and then I rewrite it until it sounds like me. Every round of that teaches me a bit more about saying what I mean. If a draft says something that isn't true, it doesn't go up.

Why bother writing at all, then? Because what matters most to me is pretty simple. I want people to have cool stuff to play with in the games we love. That's the whole point of Rioku Labs, and the mods are only half of it.

I love reading dev logs. Keen Software House's dev blogs have been a big one for me over the years. The sneak peeks of what's coming, the technical details of how something actually works under the hood, the problems they ran into on the way there. I'd read those and come away wanting to build something myself, and eventually I did. They're a big part of why these mods exist.

So this dev log is me trying to keep that chain going. I want to share what I'm learning as I learn it, including the parts that went wrong. I want to show you what we're working on before it's finished, rough edges and all. And if I'm lucky, a post here gives the next person the push to stop sitting on their idea and start building it, the same way those blogs did for me.

If any of this changes how you feel about our mods, that's fair, and I'd rather you made that call with the full picture. But I'll say this much. Without these tools there would be no Data Center. There'd just be a guy who used to work in data centers, with a lot of opinions about cable trays and no way to build any of them.

PS: If my old boss is reading this, I spent so much time trying to make the cable management look right (including using velcro, not zip ties!) only in the off chance you ever install this mod you could feel proud ;)

o7
- DM