Describe your suggestion

There's already a fork of Baritone on gitlab (I think) that is made to be used as a fabric mod. So some of the work is done already, you can look at that repo and see how they did things, and then add a gradle task to build a jar for Fabric.

Settings

If applicable, what settings/customizability should be offered to tweak the functionality of your suggestion.
Jars built for fabric should ideally include settings for using Litematica's API classes rather than the Schematica classes from 1.12. That way we can use it in 1.15.2 and don't have to worry about Litematica no longer having those classes. (Which seems increasingly likely since it's apparently being rewritten from scratch.)

Context

Litematica for newer versions only supports Fabric right now. There's no good way to load Baritone and Fabric together right now, because Fabric no longer supports loading via LaunchWrapper/LegacyLaunch. They use Knot, their own thing now.

Final checklist

• I know how to properly use check boxes
• I have not used any OwO's or UwU's in this issue.

1. The official devs of baritone will never touch fabric, "not going to be using fabric like the other retards who are" and "Fabric is incomplete, incompatible, and all around a piece of shit" @ZeroMemes <3

2. The fabric fork of Baritone is very clearly stated by both sides not a part of Baritone, in terms of support and issues.

3. Why dont you just create and issue on the Fabritone git to ask for built in Litematica support???

In that case I really think these changes should be merged with Baritone proper. They seem really helpful.

1. That's not an issue with the idea itself. Besides, it's getting improved constantly and it's been a while since they said that.

2. I know. I'm saying that it's a good spot to start for making Fabric support part of baritone itself

3. I didn't think of that. I will go do that. Although part of the reason is that I think this should be an official feature.

I know that Fabric it is getting improved, matter of fact Im one of the people working on the Fabritone fork together with two other guys, but tbh i do not see a reason to make a fabric support part of baritone official, as that part is already handled by the Fabritone fork when it comes to automatic mappings and such. Just use Fabritone instead? After all, changes made there that becomes popular and good for baritone in general will be mapped over and merged with the official branch.

Aditionally @chexo3 the rewritten Fabritone ports are actually more of less exactly in-sync with this repository's 1.15.x Forge branch except mainly Toasts and customizable autotooling, and other branches only on the repo. Either way, the schematic-type support remains the same on both Fabritone and Baritone, and in fact fabritone never even touched the Schematic code except for basic remapping, and as far as prior test went, it's schematics are recognized in both baritone and fabritone just fine, just it gets confused from other issues with build present in both.

As said, Fabritone's main only differences are as follows:

1. Toast Support and the ability to swap between normal chat logging or toasts for some areas
2. Making AutoTool Customizable
3. And ofc Fabric Support

Besides that, each of the features developed within fabritone have their own branch, so if leijurv or another dev chooses, all that would be needed is to cherry-pick the relative branch and remap as needed, but in relation to this issue: Fabritone does nothing different with schematics then what Baritone already officially does

29.08.2020
still the same problem

It's not a problem.

Fabritone does nothing different with schematics then what Baritone already officially does

Legit, can we just lock this already xD

The same points ive said in here are still valid, only difference now is that I took ops advice and made prs for the autotool and toasts, so now:

There is 0 difference besides remapping that makes Fabritone different from Baritone

Anyone who wishes to argue on this, bring up a diff between the projects and ill happily discuss.

It's not a problem.

So, the #schematica command is just broken as it was designed? We do not have the "schematica" mod for 1.15, do we?

This website lets you convert nbt to schematic https://cubical.xyz
Originally posted by @Dominikaaaa in #750 (comment)

Also, this site does not properly convert .nbt files to .schematic, it just replaces magma blocks with stone.

Also, this site does not properly convert .nbt files to .schematic, it just replaces magma blocks with stone.

user error

@leijurv petition to lock this

@leijurv Seconded here, let this page to rest already senpai

@leijurv please I'm so tired of getting notifications about this. Wait a minute, I can just close the thread... oh wait that's been done already. Will attempt to lock it.

You can disable notifications but it doesn't stop idiotspeople from continuing to comment on it, just like #1851

You can disable notifications but it doesn't stop idiotspeople from continuing to comment on it, just like #1851

Do you count as an idiot too for commenting here?

We're combating against people who keep reviving older issues like this. If it's closed, it means there was a damned good reason that it was closed

Closed issues typically are not locked unless people keep reviving them or spam. This falls into the first category hence why we're involved now to get leijurv to lock this down.

Fabric support is unrelated to the Litematica schematic format.