Toggle Dark Mode

Procrastination Report №6

By Una Ada, August 16, 2025

This one doesn’t contain a single media review, actually. Maybe it could have. Maybe I forgot about something. Did I write anything this week? Absolutely… not. Unless you count this.

As I said, it’s a Minecraft era in my circle, which inevitably leads to me doing a certain amount of tech support and server administration. Would you believe me if I said this trend started all the way back in my sophomore year of high school, playing Tekkit and the like with my friends on public servers where I somehow ended up being given console access. Nowadays, given the way the community at large has developed, this results in a race between my dwindling desire to build dioramas for a barely impressed audience and an encroaching misanthropy wrought by the phrase “join our Discord server.”

See, when deciding on mods or modpacks to play, I stumbled across Beyond The Horizon (BTH), which happened to include not only a number of familiar mods my friends and I have previously enjoyed (Applied Energistics 2, Ars Nouveau, Create, Domum Ornamentum, Framed Blocks, Immersive Engineering, Iron’s Spells ’n Spellbooks, Mighty Mail, &c.) but also Tectonic to give wider spaces and more realistic mountain ranges paired with Distant Horizons (DH) to generate LOD models for terrain beyond the standard view distance. The latest version of the pack was released not long before we chose it, so it lacked a certain amount of testing and that really showed right out of the gate. There’s not much I like about AllTheMods’ myriad of versions, but they do at least do a decent amount of testing to ensure basic functionality before official releases. On top of that, however, a number of people had additional mods they really wanted to play with: Apotheosis, More Immersive Wires,1 Ottercraft, Shrink, and a handful of smaller additions not worth mentioning. Surprisingly, these additions weren’t the cause of many of the problems we faced.

The earliest game-breaking issue was a consistent inability to start the server at all, the debug report merely stating that a certain Create registry didn’t exist. This issue caused both Hermea and Emi to struggle for several hours before I decided to help, at which point the three of us struggled for several hours. See, we couldn’t recreate the problem outside of the hosted server for one. Plus, the problem evidently wasn’t actually caused by Create itself, which is not at all indicated in the logs. This turned out to be an issue with Create: Steam ’n’ Rails that was patched mere hours before we ran into the issue! In fact, I’m not even certain on that timeline, it could very well have been during the initial server installation.

Next, we had to deal with the typical server lag brought about with exploration, while the server is generating new chunks. This is compounded by both a number of additional terrain generation mods and DH having to render out the LOD model for each new chunk. The remedy for this is, of course, to pre-generate the entire map. We spent a long time tweaking settings to get this going, even temporarily upgrading the server at one point, but inevitably DH’s pre-generation procedure would slow down over time, eventually idling around two chunks-per-second out of the 512 chunk radius map we were generating. We mostly ended up cutting our losses on this one, shrinking the world border down to as far as we had generated after a couple days (around a 310 chunk radius).

Then there’s the problem that haunts me to this day. The “iron fences” added by Building But Better cause the server to crash. This one’s peculiar for a lot of reasons, actually. First off, nobody is building with them, they’re being generated as parts of some structure. That structure, oddly enough, is common enough that we’ve all seen a couple of them around already without crashing the server. On top of that, the most recent version of the mod, which we have, claims to fix this very issue. The only real solution at the moment is to simply avoid certain areas on the server, which is annoying to say the least. Whenever someone enters such an area, we have to have them log in and teleport them away before the area around them actually loads. I really wanted to just tell the server not to include that block when generating the structures, but there’s not really any easy way to do that! I assumed KubeJS scripting could, but as far as I can tell, and I can’t tell very far due to how incomplete their documentation is, it cannot. I do believe that the structure causing the issue is one BTH adds: \#bth_structures:tinkerer_house, so maybe there’s a way to block it from the kubejs/data/bth_structures/worldgen/structure scripts, but who knows! Sure wish KubeJS had real documentation.

There’s really no onboarding provided in-game for the fact that PvP is essentially disabled unless you opt into it. This has been really confusing as people like to punch each other and show off attacks, but nothing actually happens. The mod is PVP Flagging, by the way, it really ought to have like a join announcement or something to tell the player that they need to opt in.

There is another issue, not anything breaking and also not exclusive to this pack. FTB Essentials includes a /nickname command allowing you to set your own nickname in game, but this doesn’t seem to persist on rejoining the server. When trying to find fixes via similar issues, I stumbled across this old report about a compatibility issue with Chat Heads. Someone helpfully replied an explanation I believe to also be causing my issue, that player messages are being reconfigured as system messages by No Chat Reports which interferes with the Player.getDisplayName() call. Obviously, we can’t just remove No Chat Reports, that would be absurd.

A similar issue comes up with Minecraft’s built in team name tags, which I like to use on top of FTB Teams as it provides chat decorations. Evidently, there are some built in teams the pack uses for various things, such as marking players as AFK. I believe this is the ‘afk_display’ datapack loaded by KubeJS, so presumably it can be fixed simply by running /function afk_display:uninstall (this has to be done every time the server starts, there’s gotta be another way, right?). I believe the other teams are added by Incendium, but I don’t believe those affect players so it’ll probably be fine… not that I can figure out how to disable them anyway.

Once I got around to actually building train tracks, though, I found a client-side issue as well! They’re all lit weirdly! Specifically, I was using the Steam ’n’ Rails Spruce Train Track which renders as darker than spruce wood’s texture, which is odd. To make matters worse, when the tracks are rendered as an entity (like with curves and slopes), they’re even darker! I managed to fix the being even darker part by changing the settings on Flywheel (a rendering library packed with Create) via /flywheel backend flywheel:off rather than its default which seems to be irisflw:iris_instancing, at least in this pack. Of course, this made the entities of the spruce tracks look comparable to the vanilla spruce texture, but the block entity (I believe) form that shows with regular placement is still too dark. I tested every track and the only ones that do not have these issues are the default Create tracks with the andesite ties and the ones added for compatibility (trumpet, ashen, and azalea woods from Quark). The trumpet wood has that luxurious dark reddish texture that actually mixes very well with Create’s brass aesthetic, so I’ll just stick to that, I suppose.

I’ve had a lot of migraines lately, and I think the stress of vaguely wanting to play a game with my friends becoming an unending hell of a million amateur developers each believing they don’t need to write documentation if you can just ask them on Discord is contributing massively. That’s why I decided to just fuck off to the edge of the map and build in creative mode instead. I want trains and I want power lines, I don’t care to die a thousand times in an unlit cave after all this.

This weeks math problem actually comes from the Applied Energistics 2 mod in Minecraft. I was permitted to build a storage system with the mod using creative mode to skip the horrendous grind that comes with building an expansive network in survival, so I figured I would start out by maximizing the capabilities of the controller. What this maximization refers to specifically is to open up as many “channels” as possible on a single network, which is something of a geometry problem that requires a lot of context and has a lot of rules.

First, let’s describe the controller itself. This is described as the “routing hub of a ME Network,” essentially defining a network as only one is allowed per network and all channels are defined as paths to and from it. It can be built as a multi-block structure confined to a cube with side lengths of $7$ blocks. Each individual controller block must share at least one face with another to count as part of the same structure, it can have two adjacent blocks on one axis, after which all other axes are restricted to one adjacent block. Each open face then provides $32$ channels to the network.

Typical cables (ME Glass Cable, ME Covered Cable, and ME Smart Cable) can carry up to $8$ channels. Dense cables (ME Dense Covered Cable and ME Dense Smart Cable) can carry up to $32$ channels, four times the capacity of their normal counterparts. All cables by default are “fluix” cables, colored by their construction material, but can be dyed any of Minecraft’s 16 colors. Dyed cables do not connect to cables dyed a different color, but do connect to “fluix” cables. Connections between cables of the same color can also be blocked with the decorative subparts called cable anchors.

Channels are then paths between network devices and the controller. Per the documentation, routing of channels happens in three steps: through adjacent devices to the nearest normal cable, through normal cables to the nearest dense cable, then through dense cables to the controller. Each of these steps takes the shortest path and if that path is already taken, rather than rerouting via another path, they will be blocked from opening.

Point To Point (P2P) Tunnels are magical portals through the network, the eponymous “tunnel” is a single channel which will transfer items, fluids, redstone signals, power, light, and channels from one face to another. This means that we can transfer $32$ channels through the network as a single channel! We can use these as replacements to regular connections to our controller, such that each face of each block within its structure has one end of its own dedicated tunnel. These tunnels will then connect to their own subnetworks such that they do not require any channels from the main controller itself. Additionally, since they are subparts, we can increase the number of usable faces within the controller structure; where typically a cable with two to five adjacent controller blocks would still be limited to its maximum capacity of $8$ or $32$ channels, we can now convert those $64$ to $160$ channels into $2$ to $5$ channels. A notable restriction, however, is that the tunnel side of the P2P Tunnel can only attach to a normal cable.

Herein lies the optimization problem. How do we maximize the number of “usable” faces on a single controller. “Usable” meaning first that the controller blocks form a proper controller structure by the aforementioned rules and that it is possible to route channels from within the structure to outside it. Since each normal cable has a capacity of $8$ channels, they can only touch a maximum of $8$ faces before reaching a dense cable, at least $4$ of these normal cables then must connect to the dense cables to fill up their $32$ channel capacity, and dense cables cannot be placed directly adjacent to controller blocks.

My solution to this, which I do not believe to be absolutely optimal but was definitely realistically approachable, was to construct the controller structure as a second order discrete approximation of a three-dimensional Hilbert curve. This easily follows the rules of controller structures as each block then no more than $2$ adjacent blocks. It also leaves a significant amount of gaps through which cables can be routed. However, it appears that no empty block within the structure is adjacent to more than $3$ faces, which is why I believe it may not actually be optimal.

After playing on the server for about a week, we’d compiled quite a list of requests for additional mods. I vetoed a good number of these, especially ones that would require world generation due to the previously discussed pre-generation approach we took, but the list is still rather expansive:

I booted the pack up with all these mods just to run into a very obvious problem! Pantographs & Wires hasn’t been updated to Create 6.0.0. There were a bunch of changes to Create’s API with this update, so a lot of add-ons lack compatibility with it. It should be an easy fix, so I figure I might be able to pull it off myself. I actually haven’t messed with Minecraft modding since 2012, which is a bit of a problem. I was thinking maybe KubeJS has a way to alias classes, but I really don’t want to read through its source code or, god forbid, join a Discord server to figure that out. So, let’s figure out how to set up a Minecraft Forge mod development environment in 2025!

From the looks of it, I just need to install an IDE (I’m going with IntelliJ Idea Community Edition), fork the repo, clone that fork, then open the folder as a project. Gradle should handle the installation of all the dependencies… after a while. Oh! An error, it seems to be failing to load Flywheel which is… oh boy! First, I tried just nipping the Fabric version, which didn’t work. Next, I tried manually downloading the missing .jar files which got annoying as I needed to keep doing it. Finally, I decided to just follow the specifications provided on Create’s wiki.

What’s really messing with things, and this is why the original author hasn’t updated the mod, is that there’s no update 6 for Create on Fabric. This means that I have to somehow strip all the Fabric stuff out of the mod to get it to work… and that’s hard because it’s actually Fabric by default. Doing that got the IDE to finally start using the proper version of Create, so now let’s get patching!

First off, there’s some compat stuff for Sodium, which is Fabric exclusive,2 so I’ll yeet that. It also added a mixin for Sodium, so I’ll yeet that too… eventually remembering to strip it from the declaration of all the mixins that would be added… Then there’s a bunch of com.simibubi.create.foundation.utility. imports, which gets used quite a bit, that have to be renamed to net.createmod.catnip for some reason. There’s just a lot of stuff like that. Finally, there’s the important one where I need to rewrite the registration of the MovementBehaviour classes, which is a bit iffy but I pull it off. This is because the block registration .onRegister() callback function doesn’t actually pass in the registered block, but the instantiated block you pass into the BlockEntry call in the first place, which I had to simply hope would be fine! That looks like this now, hurray!

public static final BlockEntry<PantographBlock> PANTOGRAPH = 
PantographsAndWires.REGISTRATE.block("pantograph", PantographBlock::new)
  .initialProperties(() -> Blocks.IRON_BLOCK)
  .transform(TagGen.pickaxeOnly())
  .onRegister(ctx -> MovementBehaviour.REGISTRY.register(ctx, new PantographMovementBehaviour()))
  .onRegister(ctx -> MovingInteractionBehaviour.REGISTRY.register(ctx, new PantographInteractionBehaviour()))
  .register();

Testing the whole pack on single player is hard because it all takes so much RAM, but it’s not like I could get someone else to do it apparently. What’s even more annoying is that, with all the terrain generation mods, I can’t even just load a superflat world for testing. It took me an hour, including several failed attempts, to load into a single player world just to verify that it doesn’t crash on load at least.

I honestly haven’t been reading much other than keeping up with Witch School as usual. I supposed I did peruse an assortment of digital editions of self-published age-restricted one-shot manga, but none of those works really sparked a desire to discuss further… well, maybe one or two, but not right now. My FileBot license expired and I’m too lazy to renew it so I haven’t been keeping up with anime much this week either. What am I doing anymore…

Footnotes

  1. This one was my pick! I wanted Immersive Energistics, since we’d added that on our previous ATM10 server, but it isn’t compatible with MC 1.20.1. That turned out to be okay, since this mod actually adds more compatibility with more mods, rather than just wired for AE2’s ME cables. ↩︎

  2. Actually, Embeddium uses the Sodium libraries on Forge, so in a way it isn’t entirely Fabric exclusive. ↩︎