sleeves

octatonic is a command line mod manager I wrote in early 2025. It's seen a lot of iteration, multiple redesigns and language changes, and a handful of modest releases. It's now in a pre-release state for 1.0.0, which is the least polished yet most promising version yet. If it wasn't obvious from my word choice, this isn't the most feature-complete, stable, or fast mod manager- at least not yet. However, I believe the best method of development is to make something work, then make it good, then make it fast. In this spirit, I've spent the past month or so hastily slamming spaghetti together in an attempt to get a working build. That part is done. Now I'm going to step back, untangle this mess, and form it into something easy and enjoyable to maintain. That's a lot of ranting about my process, but what about design? How is this tool different from others? De-coupled Allows for easier multi-installation use Doesn't interfere with other tools Setup is just a symlink Offline-first Uses a local store of files Reduces disk usage and increases speed Automatically links mods to profiles as needed Supports loose files View modinfo, profile data, etc. Install profiles or mods from greater filesystem Compliant Uses XDG desktop specification, environment variables, and command options Convention-respecting man pages planned - I hand-wrote them for octatonic 0.x and will likely do so for this version FOSS Licensed under GPL 3 (a popular copyleft license) Does not rely on proprietary software Hosted on sourcehut along with my other projects Anyway, I'd love to hear any thoughts or feedback. Contributing is also very welcome, though I'd recommend waiting until the codebase is more legible. Thanks for reading :-]

How heated this discussion has already gotten shows why we require manual control of what we see, not that based on quality estimates from community reports. The reality is that everyone has differing wants and needs for a filter, so any single-purpose solution will leave many unhappy.

I think adding more variations of sounds- especially for stepping on and breaking blocks- would help a lot with the perceived silence. Many present sounds are easily tuned out because they're so consistent.

I think this could be balanced by treating small animals like a hot crucible. If you carry them without gloves, they regularly bite you, dealing a little damage and escaping your grip. As mentioned, chickens would probably be a little safer. On the opposite end, wolf pups should probably deal extra damage.

This could also be tied into in-world transformation, or even farming. Temperature regulation sure has a lot of potential.

I still wish we could just manually hide mods. I don't want to see closed source mods either, so I'm planning a tool to browse the database with a custom blacklist.

A teleporation mod using xylophones (or marimbas, but marimport doesn't quite roll off the tongue) Players would craft a xylophone and two soft mallets. Each xylophone has a link mode and a travel mode. In link mode, the melody played becomes the address of the xylophone. In travel mode, the melody played will decide where to send the player. Think of it like a stargate but with a little jingle rather than a sequence of glyphs. The idea popped into my head after seeing the traveling bells mod, though it's also inspired by a xylophone spellbook of sorts I made in another game.

Which is why it's a mod in the first place.

I like to avoid closed source mods wherever possible, but doing so requires going to the mods' pages and checking their licenses (if any) on their source repositories. To avoid this, we could have an optional license field in the modinfo spec which contains an SPDX identifier, or ARR (all rights reserved) by default. I'm not sure how this would be best represented on the database, though, given different versions of the same mod could have different licenses. Perhaps the license would display under each changelog?

Agreed, and doubly so for mods. No one's trying to devise a lore-friendly reason why rust creatures have impressive tailoring skills with the drifter tuxedo mod; why should we be any stricter with tech mods?

In my opinion it should be up to the creators to indicate their own LLM use, preferably via a simple checkbox or the like. Failing that, a number of user reports would flag it for moderator review, leading to a warning or penalty if clear evidence was given in the reports. For instance, I could report a mod for unmarked LLM use and include a link to a commit made by an agent.

All these points (on both sides) are outweighed by one simple thing: it's a mod. The whole point of modifications is to change the game, hence their name.

True, but that's also the case for the other block game; space mods either included general automation or expected you to run such a mod as well.

You may be referring to the old prototype for ships, where a mini-dimension of sorts was created via command and subjected to physics simulation. I don't have a link for this unfortunately, but I believe it was somewhere in the official discord server.

The fun part is automating such processes as you go.

There's actually a library mod to create additional dimensions: https://mods.vintagestory.at/manifold At least for me, it would be depth and moddability. VS already has detailed systems in place for metallurgy, regional climate, modifiable vehicles, and so on. While space may not be particularly fitting thematically (unless traversed via portal), it would certainly be compelling mechanically. Heck, there have been multiple mods to add gas simulation to the game, so we could even have proper oxygen limitations. As for the modding part, the game's data-driven nature and emphasis on easy compatibility between mods would make for a much more appreciable implementation than in any other game I know of.

True. My thought would be that any mod author can submit a respective mod, then each contributor chooses whether it meets their criteria. The service would act as an escrow, only refunding if the contributor's rejection is valid (corresponds to an unmet condition). Once again, though, very overcomplicated.

That may be a problem, but I don't think it's a primary one. Most distaste for LLM usage comes down to two factors: quality and ethics. The former has a lot to do with the actual technology, and whether or not it will get significantly better, which is itself a debate. The latter has to do with the resource usage and arguable plagiarism inherent to these models. In the latter case, we're not afraid of it; we're boycotting it. Personally, I think we could very well design a sentient machine some day- humans are just machines made of flesh, after all- but what we have now is barely even on the path to that objective. All that being said, people need to stop slinging insults at those who disagree with them. As OP said, they were clearly labeling their mods, so it's counter-productive for anyone uninterested in generated code to go complaining in the comments or what have you. Hopefully that issue will lessen when filters are added.

Alternatively, a mod bounty program where anyone can contribute to the bounty pools would be interesting. For instance, if I were to submit a $20 bounty for a wheelbarrow mod, someone else could add $15 to that prize. Whoever implements the described mod would get $35. Of course, you'd need to account for differing opinions on how the mod is made, but I think most such issues could be resolved by requiring conditions along with a contribution. If someone adds $5 with the condition that the wheelbarrows need an animated model, they're allowed to refuse payment for the completed mod should it miss that feature. (This whole thing is probably overcomplicated - it's just an amusing thought I had some time ago :-p)

Agreed. I'd say, generally, that updates should contain two major features at most.

I would recommend doing any cinematics in-game using commands and mod tools, if nothing else. I personally tend to discount any game using out-of-engine renders for significant portions of a trailer. Besides, doing that stuff in-game ultimately results in better tooling, as I know you all experienced first-hand when implementing fake players for the 2022 feature trailer(?). In any case, this is all very exciting!

Furthermore, hot items should probably be restricted to the hotbar (play on words unintended).

It would be cool if we had an alternate control to merely touch our tongue to the food, and if it deals damage, to take a small fraction of said damage a couple hours later. It's not perfectly realistic, but close enough to feel immersive, and it would still require memorizing (or recording) the results for later use.

I think the problem with procedural food is that runs are long. In a roguelike where you're starting over constantly, having to re-discover everything is fun and engaging. If I've been playing a world for hundreds of hours then I already discovered every food effect a long time ago, and now it's just back to usual. Something like the novelty mod (as mentioned in this thread) is cool, but having a separate meter feels a little overcomplicated to me. I have a multi-part idea for a similar mechanic though: Remove current meal bonus Eating more food at once restores more hunger Eating the same ingredients too often reduces maximum hunger This would penalize spam-eating, yet make it necessary when maintaining a narrow diet, all without adding new status bars or random values.

A nice compromise, I think, would be to restore limbs on respawn but apply a penalty depending on which ones were regrown. For instance, mining speed could be reduced for each arm lost, and movement speed for each leg. This could be explained as a limitation of the technology or even confused muscle memory. Moreover, it would incentivize using the mentioned prosthetics, as they would assumedly be about as effective as the originals. The problem with this approach is that a player could simply die twice in a row to disperse the regrowth penalty too, so perhaps it should be on a timer or something rather than resetting on the next death.