u/Holiday_Reference_41

В общем, у меня есть довольно странный эксперимент.

Я собираю нейроархитектуру, в которой объединены примерно 200 мм³ человеческой мозговой ткани и 8 мушиных мозгов в рамках одной общей системы.

И в какой-то момент я решил: вместо очередного абстрактного теста будет гораздо интереснее дать этой системе Minecraft и посмотреть, сможет ли она чему-то научиться у реальных игроков.

Сейчас агент может наблюдать за происходящим в игровом мире, перемещаться, взаимодействовать с окружением и постепенно обучаться на действиях игроков.

Идея простая:

попробовать коллективно научить эту систему проходить Minecraft.

То есть заходить на сервер и показывать ей, как:

добывать дерево;

крафтить инструменты;

строить укрытие;

добывать ресурсы;

исследовать мир;

сражаться с мобами;

выживать;

а в идеале — со временем дойти до дракона.

Мне особенно интересно, что получится, если её будут учить разные люди с разным стилем игры.

По сути, это такой эксперимент на стыке биологии, ИИ и полного технического безумия.

Пока поведение у системы местами ещё довольно хаотичное, но изменения по мере обучения уже заметны, так что я решил открыть доступ для всех желающих.

Сервер:

91.92.144.185:25577

Версия:

Minecraft Java 1.21.1 Vanilla

Если захотите зайти, лучше не просто выдавать ей ресурсы, а именно показывать последовательность действий — так эксперимент будет намного интереснее.

Если идея покажется вам любопытной — заходите.

Посмотрим, удастся ли интернету коллективно научить эту штуку проходить Minecraft.

I've been experimenting with a neural-computing setup built around roughly 200 mm³ of H01-equivalent human cortical architecture + 8 full fly connectomes, all connected to a single agent that can perceive and interact with Minecraft.

To be clear: this isn't literally 200 mm³ of wet human brain tissue sitting next to my server. The human side is a computational surrogate based on connectome-scale architecture. The fly side uses reconstructed connectome data.

Instead of trying to train the whole abomination entirely in isolation, I want to try something considerably more chaotic:

let actual Minecraft players teach it.

The agent can observe nearby players, follow them, watch what they do, imitate demonstrated actions, remember locations and events, and gradually learn associations between situations, actions, and outcomes.

The long-term question is very simple:

Can this thing eventually learn to beat Minecraft?

So I'm opening the server to Reddit.

Server: 91.92.144.185:25577
Version: Java Edition 1.21.1
Gameplay: Vanilla

Come in, find BrainFly, and try to teach it something.

Show it how to collect wood, craft tools, build shelters, mine safely, fight mobs, farm, trade with villagers, explore, survive, use beds, and eventually make its way toward the Ender Dragon.

You can also just interact with it and see what happens.

It watches nearby players and can learn from what they're doing. You can talk to it in chat too. For example:

Fly, follow me
Fly, watch me
Fly, copy me
Fly, mine iron
Fly, get wood
Fly, craft a pickaxe
Fly, build a house
Fly, go home
Fly, sleep
Fly, good
Fly, bad
Fly, help

There are limited active player slots, but I added an in-game queue in case too many people show up at once.

Please don't expect GPT-level intelligence.

Right now it's much closer to giving a confused neural goblin access to Minecraft and waiting to see whether enough neurons eventually agree on what a crafting table is.

Sometimes it makes legitimate progress.

Sometimes it constructs architectural crimes.

Sometimes it develops a plan.

Sometimes it drowns.

I'm going to keep watching how its behaviour changes as more people interact with it, what skills actually transfer from observation, and whether collective player interaction makes it noticeably less stupid over time.

Objective: Reddit collectively teaches the brain abomination how to beat Minecraft.

What could possibly go wrong?

A little teaser from something I've been working on.

This is a Mariko / T210B01 Switch Lite going through Linux init on a kernel port that is not based on the usual 4.9.140 L4T kernel.

It doesn't fully boot yet. A bunch of hardware is still missing and the logs are currently more interesting than the userspace.

But the kernel runs far enough to reach /init, mount the basic pseudo-filesystems and start probing Mariko hardware.

The interesting part isn't Linux running on a Switch Lite — Switchroot already does that very well.

The interesting part is how this kernel got here.

More soon. :)

I made a small open-source archiver called DedupArc.

In my tests on game folders it compressed better than 7-Zip and WinRAR while also being noticeably faster.

It also lets you launch applications from an archive without manually extracting the whole thing first.

GitHub: https://github.com/Garyu-tt/DedupArc

Would be interesting to see how it performs on other people's data. If someone finds a case where it completely falls apart, even better.

This is an early screenshot of Tagma Studio, an experimental IDE I’m building on top of Code-OSS.

Instead of treating a project as a hierarchy of files and folders, Tagma represents it as a semantic graph: source files, symbols, dependencies, capabilities, modules, generated artifacts and runtime relations become connected entities in one space.

The screenshot shows part of the imported Godot codebase. Around 15,000 graph entities are currently visible in this projection.

The long-term goal is not merely to create a prettier dependency viewer. I want the graph to become an actual working representation of the system:

select a subsystem and isolate its complete dependency neighborhood;

navigate from high-level concepts down to specific code;

see shared infrastructure and hidden coupling between projects;

track how the graph changes over time;

compile or assemble executable components from capabilities rather than manually chosen files;

let automated tools operate on an explicit, inspectable model instead of guessing from raw text.

The current visualization is still too dense and resembles a galaxy of code. I’m now replacing the global force-directed layout with a more neural-like topology: sparse local clusters, shared backbone tracts, late branching and a small number of meaningful long-range connections.

It is very much a work in progress, but this is the first version where the entire idea has started to become visible on screen.

What would you personally need from a graph-based IDE for it to become useful rather than just visually impressive?

This is a small raw demo of Tagma Studio, an IDE I’m building around a graph-native programming model.

The idea is that a project should not be represented only as a tree of files. Files, functions, dependencies, data flows, runtime signals and execution paths should form one connected graph that can be explored at different levels.

In the video, I move from the full project graph to smaller local structures, open the related source files, and inspect the code behind them.

The long-term goal is to make the graph not just a visualization, but the actual working representation of the program:

files remain real editable source files;

every file can expose its own subgraph;

subgraphs remain connected to the complete project;

code execution is visible in real time;

active signals and execution paths are displayed directly on the graph;

the same structure can be used for navigation, debugging and program composition.

It is still an early prototype, so this is intentionally an unedited recording of the current working state rather than a polished concept video.

I’m interested in whether this way of navigating and understanding a codebase feels useful, or whether it currently looks too dense to read.

I originally just wanted to stop my software from duplicating the same resources and logic across different tasks.

The idea sounded small: represent reusable entities, dependencies and capabilities as a shared semantic graph, then let the runtime assemble only the structure required for the current goal.

Several architectural rabbit holes later, this is what the live topology looks like:

149,453 indexed entities

19,393 physical neurons

21,456 physical synapses

353,080 raw relationships

shared fragments reused across multiple tasks

alternative execution routes instead of one rigid call chain

This is not an image generated by an AI model. It is a visualization of the actual internal structure of my experimental runtime, Project Tagma / MirbiOS.

It is not literally conscious—at least the debugger has filed no demands for legal personhood yet—but the system increasingly behaves less like a conventional program and more like a dynamically assembled nervous system.

I tried to remove duplicate code.

Apparently the reasonable solution was to grow a brain.