Download Tricksy Foxes 4.1 on Modrinth. Supports 1.20.1–1.20.2 Fabric. Published on May 4, 2025. 1 downloads.
Update for the Tricksy Foxes mod!
Version 4.1 fixes a critical bug that prevented the combat nodes from working (a bug that somehow was entirely unreported for the past year!), adds a couple new search-type nodes to make farming automation easier, and adds a server config option to disabled Prescient Candle logging to reduce server performance impacts.
Download Wheelchairs 2.5 on Modrinth. Supports 1.20.1–1.20.3 Fabric. Published on Sep 1, 2024. 0 downloads.
For all the Wheelchairs enjoyers that prefer a more populous/developed/familiar/etc. modded environment, release 2.5 is now available for Minecraft version 1.20.2 on Fabric.
This version naturally includes a few bug fixes as well as the new content in the main 2.5 release version, like service vests and the AAC speech tablet!
Download Various Types 0.6 on Modrinth. Supports 1.20.6 Fabric. Published on Aug 30, 2024. 0 downloads.
New Various Types beta version, with many new toys!
Added new abilities (as per convention, if the description has [square brackets] around something, it's configurable):
Berserk grants you substantial HP and damage buffs, but temporarily slows and weakens you afterwards
Mindless and Omniscient both prevent you from picking up XP, but Mindless prevents you from using crafting menus whereas Omniscient treats you as always having 9999 levels
Quake emits a shockwave where you land
Thunderstep allows you to teleport between any two visible surface positions via bolts of lightning
Bad Breath spawns a lingering cloud of poison at your feet
Flameproof reduces fire damage by 50%
Webweaver prevents cobwebs from slowing you down
Herbivore prevents you from eating any non-vegetarian food
Fleeced trades your hunger with white wool
Gelatinous now adds 15% resistance to physical damage, and makes you translucent
Regeneration now converts applicable damage into nonlethal damage
Animated avatars in the character creator or sheet display screens can now strike some poses for an indefinite length of time
Download Wheelchairs 2.5 on Modrinth. Supports 1.20.4–1.20.5 Fabric. Published on Aug 27, 2024. 0 downloads.
Wheelchairs release 2.5 is now available for Fabric 1.20.4, featuring service vests for your animals that ensure they survive your adventures unscathed and the speech tablet, a fully-functional ingame AAC device with 97 discrete phrases that can be used individually or as part of more complex messages!
During Minecraft version 1.12.2 there was a mod called Kidnap.
It mainly dealt in adding ways to hinder other players (as one might expect from the name) in terms of how they could move around, what they could interact with, and to an extent even how they were able to use ingame chat. But for game balance, and in a stroke of genius game design, everything you could do to someone else, they could oppose, even without specialised tools. They could struggle out of being tied up, they could pick the locks on their manacles, so on and so forth. This meant that despite the mod giving you ample ways to debilitate your fellow Steve, they always had some way to respond to it.
Additionally, you could counter-act their escape efforts by checking up on their restraints regularly, which created a kind of emergent mind-game mechanic as abductees tried to outwit their captors and escape (or just wait for them to log off). The captor in turn had to stick around to ensure their prey didn't disappear from under their nose. The restraints were also very rarely absolute, even gagged you could type gibberish into chat.
If you haven't yet spotted the problem here, well... Kidnap was a BDSM fetish mod, and it did NOTHING to hide that fact. The basic rope binding was straight-up fetish knots, there was a variety of ball gags to use, there was even blatant slave/domme mechanics you could enact on your captives.
Mojang quite swiftly caught wind of this, and in a move unheard of before or since they stepped in and forced the one-man mod team for Kidnap to pull it offline in very short order. Almost overnight the mod became vaporware, nowadays even the wiki is barely visible on Archive.org, and it took me a good while even to identify the screen name of the author. From what I gather, Mojang were so intimidating that they deleted the source and basically quit modding altogether after that.
There's basically nowhere to find Kidnap in a downloadable form, though there are copies floating around outside the anglosphere and foreign language mod showcases for it still pop up on YouTube occasionally. As they say, nothing ever quite leaves the Internet.
At time of writing Minecraft is marching towards version 1.21, and in the intervening time absolutely no mod has ever come close to replicating the game design elegance that Kidnap did. For a lot of projects, it continues to be a tough question of how to impede players without utterly spoiling their play experience. Most of the time it's either done with status effects that can't be meaningfully opposed or by keeping the stats low or just giving up all pretense and hosing the unfortunate recipient.
But in a kind of Streisand Effect, Mojang stepping in to squash one brilliant mod with a proud and upfront adult thematic did more for it than the author likely ever could: It created a legend.
In Various Types, the properties being applied to each player are determined by a central character sheet object. This object is responsible for determining their current creature types, abilities, and other useful information. It also serves as the repository for the things that change those values, such as their selected species and currently-applied templates.
Initially, this was all hard-coded, so that adding a new value necessitated directly changing the character sheet object and updating all of the modifying elements to account for it. Whilst this was simple enough when there were relatively few values, such as when there was only 3 of them, it quickly became a headache as the amount of information and modifying factors increased during development.
Time for a new approach.
Enter the twin registries of ISheetElement and SheetModule. The simplest descriptions of which are the parts of a character sheet you write in (the modules) and the parts that many digital character sheets automatically calculate for you (the elements).
ISheetElements are the individual modifiable values stored in the character sheet. This can be a singular value like the the player's home dimension or volume of nonlethal damage, or it can be more complex like their current abilities. Each element defines what other elements must be calculated before they are, such as types before abilities since types themselves convey abilities, as well as when modules are applied during their recalculation process (for efficiency this "build order" is calculated after initial registration and stored for later usage, rather than calculated each time a sheet rebuilds). Elements can be stored in persistent data (such as activated abilities that require long-term information storage) but most are simply recalculated from scratch as needed.
Modules receive each element as it is recalculated, in a specific ascending integer order. They are the things that change the values, such as species or custom abilities. Modules always initialise blank.
Each character sheet always has a copy of every entry in both registries, even if a new entry was added inbetween times the sheet was loaded into memory. When the character sheet is rebuilt, usually due to a change in one or more of its modules, it recalculates each element in build order, applying the changes of each module as it goes.
New modules can be registered to expand the variety of modifying factors and new elements can be registered to expand what information the character sheet tracks.
This revised approach, though certainly overkill for a character sheet existing with only a small handful of components or with no intentions for future expansion, allows the character sheets to be expanded endlessly by third-party add-ons as well as to hold whatever feature creep inevitably demands.
Changing to this approach early on greatly simplified making changes to the character sheet structure during development, such as implementing custom types and abilities, separating abilities into passive and activated abilities, as well as adding new mechanics such as implementing nonlethal damage as a new tracked value per player.
This essentially makes Various Types into not only a powerful and versatile mod in itself, but the quintessential utility for implementing virtually any game mechanic that necessitates per-player data tracking.
Expand your gameplay customisation to the absolute limit!
There's a new/old character mod on the block!
Various Types is a rebirth of the Various Oddities types system and implements a datapack-driven per-player gameplay customisation infrastructure that is endlessly customisable and easy to use both by developers, server admins, and players.
As of today you can check out its first alpha version in Fabric 1.20.6, but don't be mistaken in thinking "alpha" means its buggy or crash-happy or that big chunks are incomplete.
The only thing this version is lacking in is default content. The infrastructure, from the character creator that lets you pick a species and any number of templates, complete with a preview screen of what you'll be like ingame, as well as the character sheet screen that lets you even look at other players' characters, to a fully-fleshed out wiki detailing how to use the commands and how all the different components work, is already here!
Download Wheelchairs 2.0 on Modrinth. Supports 1.20.4–1.20.5 Fabric. Published on Jul 14, 2024. 0 downloads.
In addition to the changes of previous beta versions, this release version includes:
Added the Placer wheelchair upgrade! This upgrade adds its own discrete inventory slot, which only accepts blocks. Roughly every 1/4 second, while the wheelchair is on solid ground, the upgrade will attempt to place a block from its inventory beneath the wheelchair. Ideal for bridging! Applied with a dispenser.
Added the Handles wheelchair upgrade! When a wheelchair with this upgrade is right-clicked, if it is already being ridden, it will bind to the player much like a walker does. This allows a wheelchair to be moved by someone other than the user, though the user can use the Untie button in the inventory to sever this binding and prevent a new one for 3 seconds. Applied with iron bars.
Added the wheeled stool! This item is not well-suited to exploration but ideal if you just want to rest your feet for a moment at home.
Added translation for all sounds, as well as a sound event when drawing from a cane sword
Added metal wheels in copper, iron, gold, and netherite forms
Added copper cane handle
Added walker crafting recipe
Ostensibly resolved the "phantom walker" bug that would result when the game crashed or was force-closed. I've already fixed this one like three times so I'm not definitively saying it's gone, but I'm like... 98% sure...
Download Wheelchairs 1.6 on Modrinth. Supports 1.20.4–1.20.5 Fabric. Published on Jun 5, 2024. 0 downloads.
Wheelchairs is now available in 1.6 beta form, which includes the previously-teased crutches and canes! For more information on either, check the mod wiki!
Fully-customisable assistive devices, for roleplay or disability representation purposes!
If you're a disabled Minecraft player or just someone looking to roleplay a disabled character ingame, the Wheelchairs mod's first full release version is worth looking into!
Dead by Daylight has more than its fair share of "witch" type characters as-is between Hag, Artist, and Nurse, but prompted by chat earlier today I thought I'd give a shot to adapting my own OC, the Witch (or witch!Lying), to the context of a video game full of murderous psychopaths that constantly terrorise and torture hapless civilians.
Let's start with the core concept:
A chase Killer with a ranged debuff attack and a connection to the crows that inhabit the Entity's realm.
And with that, the outline of the Witch's lore:
Living in a cabin in the woods on the outskirts of town was just fine for the Witch, giving them just enough privacy to practise their eldritch magics, construct little charms and talismans to forgotten gods, and especially to terrorise the villagers who dared step just a little too far beyond the treeline.
But eventually, probably after one too many spooks, or maybe the child that was chased into the river last winter by ravens, or possibly the whole family that went mad after finding their house picked clean by the same three-eyed birds mocking them all the while, the townsfolk got nervous enough to dare.
Despite a harrying amount of ravens cackling at them as they made their way, they laid siege to the cabin and set it ablaze. And as the Witch gave one last hearty cackle to terrorise their revolting victims, the Entity stepped in to claim them.
Now in the Fog, the Witch is surrounded by crackling flames and watchful black birds, and charged with one solemn duty: Make them fear
First, the ability:
Cursed Flame
The Witch can toss a small fireball which flies on an unerring trajectory unaffected by gravity (ie. always in a straight line). If hit by the fireball, healthy survivors become injured, and injured survivors are afflicted with Deep Wound. Has a short wind-up and uses charges, similar to the Nurse's Blink, which need time to recover once expended.
A number of add-ons apply status effects to survivors struck by the fireball, including the usual Blindness, Mangled, and Exhausted.
Eldritch Wings
The Witch is old friends with malevolent black birds, and the Fog is full of them. Like the Dredge, they can teleport to undisturbed crows around the map, with their appearance being heralded by small flames that crescendo as they arrive.
Additionally, they can teleport to just shortly behind a visible survivor within their terror radius, appearing in a flurry of black feathers, though this puts the ability on a considerably-longer cooldown compared to the crows.
Second, the perks:
Sinking Sensation: Survivors within your terror radius have any Exhaustion effects slowed by 12/16/20% (eg. the Exhaustion caused by Blood Echo would last 50-54 seconds instead of 45 seconds if spent entirely within your terror radius).
Three-Eyed Ravens: Survivors who startle crows within your terror radius have their aura revealed for 6/8/10 seconds. This could be likened to Spies From The Shadows, but the dependence on terror radius makes it more variable, such as being worthless for most stealth killers.
Omen of Doom: After hooking a survivor, a random injured or healthy survivor hears your terror radius approaching for the next 6/8/10 seconds. You still emit a terror radius as normal. Any effects applied by your terror radius (eg. Coulrophobia, Overwhelming Presence) also affect the haunted survivor.
The general playstyle is to use surveillance-type perks to monitor the map and teleport between generators using the crows, then when in a chase using the teleport to quickly catch up to a fleeing survivor in a similar fashion to the Singularity's Overclock mechanic.
Their fireball serves to give them ranged potential, but it can't down a survivor by itself (unlike most ranged killers so far) so they still need to get close, such as by using the teleport at the cost of needing to really stick the landing on the subsequent hit or else risk a more protracted chase. Debuff add-ons would give it some hefty versatility as well.
In the long history of Minecraft, there is a handful of recurring game design elements that have appeared quite prominently amongst the various mods made for the game. Ore multiplication, item transportation, automated crafting, etc.
Of particular note at this time is that third one: crafting, because as of Java Edition version 1.20.3, the developers at Mojang have added the Crafter. After 12 years since formal release version 1.0, the unmodified version of Minecraft may soon have its own solution for automated crafting.
In terms of its design, the Crafter is a fresh entry in a troublingly-long series of changes made to the game that introduce a solution to a problem that obviates all others. It has exceedingly few drawbacks and occupies only a single space in the cubic grid, rendering any attempts to address the challenge of auto-crafting irrelevant if they don't somehow occupy an even smaller footprint. Its user interface is unique, in that slots can be toggled on or off, preventing them from receiving items whilst still contributing to the composition of crafting recipes. It even spits out the crafted product when triggered, either into the open world to be collected by the player or into an adjacent inventory, including other Crafters.
How then do mod developers compete? How can they reclaim some ground in what has historically been one of the high notes of virtually any mod with a solution?
Well frankly, they can't. Like the Shulker Box and the Elytra, the Crafter is a solution that renders the problem trivial, so the modders need to do something more creative with the solution in a way that complements rather than attempts to exceed it.
For the purposes of the Tricksy Foxes project, there are two blocks that attempt this: The Work Table and the Clockwork Friar.
The Work Table (planned only days before the Crafter's announcement) serves as a mid-point in the evolution from Crafting Table to Crafter. It has an inventory, it can still be used for crafting, and if triggered can craft its inventory according to a matching recipe. It does not have toggleable slots nor can it dispense its product into an inventory, but it can serve very well as a crafting table with built-in storage or a simple compacter (a form of recipe common in modded and unmodded gameplay). Relative to the Crafter, it's also quite cheap, requiring only humble wood to create.
The Clockwork Friar is almost a step beyond the Crafter, but comes with its own drawbacks in comparison. A programmable automaton, the Friar similarly has an inventory like the Work Table, but can only hold up to 9 items at the most. This informs it of the recipe it is to process and, when triggered, it siphons the ingredients from neighbouring inventories directly instead of needing them piped in. It can also be triggered with a simple interaction, with no inherent need for complex wiring. However, it is twice the size of the Crafter and Work Table, like the Crafter cannot be used for everyday crafting, and like the Work Table cannot deposit its product.
Ultimately, neither of these blocks seeks to directly compete with the Crafter, but rather to serve as useful tools in their own specific use-cases. In the context of Tricksy Foxes, a mod based around automation using behaviour trees, they serve as a means to easily enable the foxes to craft items, an action that would be overwhelmingly complex if it were performed solely inside of the behaviour tree implementation itself.
It can roughly be said that a behaviour tree is only as useful as the sum of its available conditions and actions, to that end when building a behaviour tree system for the purposes of automation it becomes important to consider what actions the player takes most frequently to identify what nodes will be necessary.
Virtually all sandbox games for example include a degree of inventory management. This is to say, not only picking items up from somewhere in the world but also moving them intelligently into a container for long-term storage. Useful conditions in these contexts include the exact type of item that a given item represents (such as a set of wooden planks or a valuable ore), and whether a given container is appropriate to receive it (either because it has been designated as such by the player or because it already contains some amount of the same item).
In Minecraft, the majority of automation falls into this category, a task which is typically addressed through the usage of a great many hopper blocks, which both pick up items that land on top of themselves and transfer them to other containers or hoppers in a predictable and linear fashion. It is then up to the player to properly engineer only the intended items to arrive in the intended containers.
A behaviour tree approach is quite valuable in this context, as it enables a singular agent to take the place of possibly dozens or even hundreds of ticking tile entities with considerably less engineering needed on the part of the player. Instead, they only need to walk through the steps they themselves would take to perform the same task.
Automation seldom ends here, however. There may be occasions where specific player-taken actions are needed, often specifically relating to certain items held in hand. This might range from applying a food item to multiple livestock to initiate breeding, to mining resources (both in the wild and in controlled environments), to attacking hostile agents in the pursuit of certain rewards (aka "drops", after the tendency of such items to "drop" once the entity is slain).
These tasks may be simplistically reduced to repeating them endlessly (in the understanding that the desired context will just happen to occur whilst the loop continues) or performed more conservatively (such as waiting until a sheep's wool has regrown before trying to shear it). This presents a quandary in terms of efficiency: The eternal loop approach will inevitably require fewer behaviour tree nodes, whereas the efficient approach will inevitably require more, hence the efficient tree has higher computing costs. This poses a problem when attempting to maintain a low-impact system, which is difficult to overcome without providing very low-impact and often hyper-specific conditions.
However, despite this challenge, it can be foreseen that the end result remains less severe on a server's resources than the equivalent in a large mechanical system as well as providing opportunities for players to continue playing the game. This is to say that as many of these more complex automation tasks require the player to undertake them, either by writ of how interactions are performed or by their complexity, it becomes increasingly necessary for the player themselves to perform them. This can range from mindless repetition of the same action for hours on end or, even less palatably, from automating the player's control inputs directly (such as by an external auto-clicking application).
But in all this there is an overarching question: Is it fun?
By alleviating the need for large complex systems, reducing much of them down to only a handful at most of behaviour tree-driven programmed agents, are we eliminating part of what the player finds enjoyable in the first place?
Surely the end product is less time-consuming and less prone to error in the event of malfunction or mistake during construction, and for many players the engineering is indeed the entertaining activity. However, there is skill and puzzle to the design of an efficient behaviour tree as well, which can be construed as being different but similar to the original approach.
A brief demonstration of one use-case for editable behaviour trees for the purposes of sandbox automation, featuring a fox.
The tree used in this demonstration is 15 nodes in total, which is relatively small. It primarily consists of only two behaviours: retrieving up to 8 fuel whenever its hands are empty and the lamp is on, and cycling through the furnaces giving them 1 fuel each. Otherwise, it waits at its initial position.
The lamp itself only serves as an indicator that enough fuel is present to retrieve, which ensures the fox distributes it evenly. Beyond that, the fox's behaviour tree is entirely responsible for the automation demonstrated.
In this particular implementation, the number of furnaces is entirely arbitrary and the tree can handle as many furnaces as the fox can hold fuel. The only thing that would need to be changed is the contents of the Furnace Array variable, the tree would handle everything else.
Without the fox, this particular automation problem would necessitate dozens of ticking tile entities (in the form of hoppers) and significantly-complex wiring dependent upon discrete knowledge of the game engine.
Kerbal Space Program was once afflicted by a bug the fans dubbed the "Deep Space Kraken", whereby if you travelled far enough from the origin of the game's coordinate system, floating point rounding errors would cause your spacecraft's components to become misaligned and/or clip into each other, resulting in the craft falling apart or exploding for no obvious reason.
The bug was later fixed by defining the active spacecraft itself as the origin of the game's coordinate system. In effect, the spacecraft no longer moves; instead, the spacecraft remains stationary and the entire universe moves around it. Owing to how relativity works, to the player this is indistinguishable from the spacecraft moving about within a fixed coordinate system, and it ensures that the body of the craft and its components will always be modelled with maximal precision.
While elegant, this solution introduced a new problem: it was now possible, by doing certain stupid tricks with relativistic velocities, to introduce floating point rounding errors to everything except the active spacecraft. In extreme cases, this could result in the destruction of the entire observable universe.
Some might call this one of those situations where the solution proves to be worse than the problem. I call it a perfect expression of what Kerbal Space Program is truly about.