cc-mek-scada: a SCADA architecture for Mekanism reactors in ComputerCraft
Configurable ComputerCraft SCADA system for multi-reactor control of Mekanism fission reactors with a GUI, automatic safety features, waste processing control, and more! Please be sure to take a look at the Wiki tab, this project has lots of docs!
At a glance
- What is it?
- cc-mek-scada applies industrial control vocabulary to a Minecraft mod setup, with coordinator, supervisor, RTU and PLC applications running on ComputerCraft computers, and the interesting engineering is in how it fits a full control system into one megabyte of space.
- Who is it for?
- cc-mek-scada is the right project for a Minecraft player running Mekanism reactors who wants real instrumentation, a terminal based HMI and safety interlocks rather than a pile of redstone, and for anyone who wants to read a serious control architecture written in Lua. It is the wrong tool for industrial control of anything that is not a ComputerCraft computer, and the wrong dependency for a production system of any kind.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Lua, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A control system, in a game
cc-mek-scada is a configurable ComputerCraft SCADA system for multi-reactor control of Mekanism fission reactors, with a graphical interface, automatic safety features and waste processing control. The primary language is Lua, the licence is MIT, and the project lives inside Minecraft, on computers provided by the CC: Tweaked mod.
The framing is deliberately borrowed from industry. The readme links the Wikipedia article on SCADA and recommends reading it to understand the concepts, and then it uses the vocabulary throughout. A Supervisory Computer gathers data and controls the process. A Coordinating Computer acts as the human machine interface, where the user requests high level processing operations. An RTU is a Remote Terminal Unit. A PLC is a Programmable Logic Controller.
That naming is the point of the project as much as the reactor control is. Someone who has read about industrial automation can look at the code and recognise the roles, and the components in the repository are named after them: coordinator, supervisor, rtu, reactor-plc, plus shared pieces such as scada-common, graphics, lockbox, and a pocket application for handheld access.
The subject is a game mod, but the problem being solved is a real one. Mekanism fission reactors produce heat, consume fuel, and generate waste, and controlling several of them at once with vanilla redstone is genuinely difficult. A computer that can read sensor values, decide, and drive actuators is exactly the tool the situation calls for, which is why the project exists at all.
Nine components, each with its own version
The released component versions section is the first thing an installer needs, and it shows how the system is put together.
There is an installer, and then core libraries or components: Bootloader, Common, Comms, Graphics and Lockbox. Then there are the main applications: Reactor PLC, RTU, Supervisor, Coordinator and Pocket. Each has its own version, and the stated reason is that this allows individual component updates to be managed by the installation script.
That design decision has consequences. It means an upgrade of one component does not force you to reinstall the whole set, and it means the set of versions on a given computer can be mixed. It also means there is a coordination problem, because the applications and the libraries have to agree on the wire format between them, and the Comms component is the piece that carries that traffic.
The version information is published as JSON files on the project's GitHub pages, one per component, which is a lightweight way to let the installer check what is current before it runs. The readme shows a badge for each component that resolves to one of those files.
The remaining applications map onto the SCADA roles. The Coordinator Server is the top of the hierarchy and there can only be one. The Supervisor is the supervisory computer for a facility, and there is currently one per facility system. The RTU is the field level. The Reactor PLC is the part that actually talks to a reactor. The Pocket is the handheld access point.
The coordinator, the supervisor and the RTU
The ComputerCraft architecture section describes the three levels in enough detail to show that the mapping is deliberate.
The Coordinator Server is unique, and it acts as a hybrid of levels 3 and 4 in the distributed control diagram the readme includes. In addition to viewing status and controlling processes with advanced monitors, it can host access for one or more Pocket computers. So the coordinator is both the place where the process is supervised and the place where a human interface connects.
The Supervisory Computers sit below it, and there should be one per facility system, which currently means only one. The readme is explicit about the future: multiple supervisors would provide the capability of coordinating between multiple facilities, such as a fission facility and a fusion facility. So the hierarchy is designed for a scale that has not been reached yet, and that is a fact worth knowing before you try to model a multi-facility layout.
The RTUs are the bottom level, and the readme describes them as effectively basic connections between a device and the SCADA system with no internal logic providing the system with I/O capabilities. The interesting detail is how they are modelled in the game: a single Advanced Computer can represent multiple RTUs, since the author models an RTU as the wired modems connected to that computer rather than the computer itself.
That is a modelling decision with practical consequences. If one computer stands in for several field devices, then a fault in that computer takes out all of them, and the redundancy has to live in the number of Advanced Computers rather than in the number of RTU objects.
Installing it on a ComputerCraft computer
The installation section offers three routes, and they cover the cases that matter in the game.
On a networked computer, the installer script is fetched with wget.
* `wget https://raw.githubusercontent.com/MikaylaFischler/cc-mek-scada/main/ccmsi.lua`
* `pastebin get sqUN6VUb ccmsi.lua`The second form uses pastebin, which is useful when the raw GitHub host is blocked but pastebin is not, and the third route is for a computer where HTTP is disabled entirely, using release bundles linked from the wiki page on alternative installation strategies.
The requirement list is short and worth reading before anything else. The mod requirements are CC: Tweaked and Mekanism v10.1 or newer, and the readme explains why the version floor is what it is: v10.1 is required due to the complete support of CC: Tweaked added in Mekanism v10.1. Without that version, the reactors do not expose what the system needs to control.
Two mods are recommended rather than required. Advanced Peripherals adds the capability to detect environmental radiation levels, and Immersive Engineering provides bundled redstone, though the readme notes that any mod containing bundled redstone will do. That second one is the more important of the pair, since bundled redstone is how a ComputerCraft computer drives the reactor's components in the first place.
Why the code on your computer is not the code in the repository
The installed software section is a short paragraph that explains a surprising detail, and it is the part of the readme that tells you most about how the project is engineered.
The software installed on your ComputerCraft computers will not appear perfectly identical to the source on GitHub, because the deployment system first minifies the code, removing leading whitespace, most comments and blank lines, before publishing it to GitHub pages, where the installation script pulls the source from. The readme gives the reason: the installed applications are now nearly filling all the available space on a 1 MB ComputerCraft computer.
So the minification is not a build optimisation for its own sake, it is a hard constraint. A ComputerCraft computer has a megabyte to work with, and the set of applications, libraries and the bootloader together come close to filling it. Stripping comments and blank lines is what makes the bundle fit, and it is why the repository source is more readable than anything running in game.
The mechanism is specific. The file build/gen_minified.py is responsible for the minification, and GitHub Actions runs that and publishes the builds using the .github/workflows/deploy.yml workflow. Two build streams exist, one for the main branch and one for the devel branch, published under the builds/main and builds/devel paths on the project pages.
The installation manifests live alongside them, at the manifests/main and manifests/devel paths, as install_manifest.json files, and those are what the installer consults to work out which component versions to fetch.
Where cc-mek-scada is the wrong tool
Four limits, and the first one is the one to state plainly.
This controls a game mod, not industrial equipment. Every term in the project is borrowed from industrial automation, and none of it runs a real reactor. If you are evaluating it for a physical control problem, it is not a tool for that, and the safety features it implements are the safety features of a Minecraft server.
The second is the dependency floor. The system needs CC: Tweaked and Mekanism v10.1 or newer, and it wants bundled redstone from another mod to drive the reactors at all. That is a hard constraint on the mod set of a pack, and on a server where other players want different mods, the pack has to be arranged around it.
The third is the stage of the project. The recent releases are all beta, with v1.10.10-beta described as the final pre-release update, and the contributing section says the author started the project as a challenge and is hoping to keep contributions to a minimum for now, being more open once it is out of beta. An invitation to reach out by Discord or email rather than an open pull request process is a signal about how the code will evolve.
The fourth is a practical one about scale. There is exactly one coordinator and currently one supervisor, and the RTU model concentrates multiple field connections onto one Advanced Computer. A build with a handful of reactors is what the architecture was designed for, and the readme itself points at multiple supervisors and multiple facilities as future work rather than current capability.
Licence, releases and where the documentation lives
The licence is MIT, with a LICENSE file at the root of the repository, so the code can be used, modified and redistributed with the notice kept. This is not legal advice, and the licences of the mods it depends on are separate questions.
The release history shows an active pre-release line. Version 1.10.8-beta was published on 2026-07-05 as a beta hotfix, 1.10.9-beta on 2026-07-09 as another beta hotfix, and 1.10.10-beta on 2026-08-04 as the final pre-release update. The last push to the default branch was on 2026-10-18, and the repository is not archived, so work is landing even though the tagged versions have not moved since August.
The beta suffixes in the tag names are worth taking seriously. A hotfix tagged as a beta is a beta that is fixing something, and the contributing section says the remaining challenges are ones the author wants to solve before opening up. That combination, active commits plus a closed contribution process, describes a project in its final stretch rather than a stable release.
The documentation is the significant part of the project, and the readme says so directly, asking readers to take a look at the Wiki tab because the project has a lot of documentation. The wiki page on alternative installation strategies is the one the readme links for the offline install route, and the YouTube channel is the video home for the project. The Discord server is where the community is.
For anyone adopting this, the readme itself is the shortest document in the set, which is another way of saying that the wiki is where the real answers are.
Editorial conclusion
cc-mek-scada is the right project for a Minecraft player running Mekanism reactors who wants real instrumentation, a terminal based HMI and safety interlocks rather than a pile of redstone, and for anyone who wants to read a serious control architecture written in Lua. It is the wrong tool for industrial control of anything that is not a ComputerCraft computer, and the wrong dependency for a production system of any kind. Before adopting, read the wiki pages the readme points at, check that the Mekanism version on your instance is 10.1 or newer, and look at the beta release notes, since the 1.10 line is still marked as a pre-release.
Frequently asked questions
What is cc-mek-scada?
It is a configurable ComputerCraft SCADA system for multi-reactor control of Mekanism fission reactors, with a graphical interface, automatic safety features and waste processing control, written in Lua. It implements the SCADA concept inside Minecraft and uses the industrial vocabulary throughout, with coordinator, supervisor, RTU and PLC roles.
What do I need to install cc-mek-scada?
CC: Tweaked and Mekanism v10.1 or newer are required, the latter because Mekanism v10.1 added complete CC: Tweaked support. Advanced Peripherals is recommended for radiation level detection and Immersive Engineering is recommended for bundled redstone, though any mod providing bundled redstone will do.
How do I install cc-mek-scada on a ComputerCraft computer?
Either fetch the installer with wget from the raw GitHub URL or get it from pastebin, or, when HTTP is disabled, use the release bundles linked from the wiki page on alternative installation strategies. The installation script then pulls the component versions listed in the install manifests from GitHub pages.
Why does the code installed on my computer differ from the GitHub source?
The deployment system minifies the code, removing leading whitespace, most comments and blank lines, before publishing it to GitHub pages, because the installed applications nearly fill all the available space on a 1 MB ComputerCraft computer. The file build/gen_minified.py does the work, run by GitHub Actions through the deploy workflow.
Is cc-mek-scada still in beta?
The recent releases are all beta, with v1.10.10-beta published as the final pre-release update on 2026-08-04, although the last push to the default branch was on 2026-10-18. The contributing section says the author will be more open to contributions once the project is out of beta.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/mikaylafischler-cc-mek-scada)Was this useful?