baritone
baritone copied to clipboard
cabaletta
Added Litematica support
Added litematica support to 1.12.2 master.
Issues with this version:
- Some states (such as iron bars) are unrecognized
- In 1.12, the long array (
blockstates) isn't exposed by the libraries so parsing has to be done manually - Only reads in first region of the .litematic
#2338 Is a fully working implementation for modern versions of MC
If anyone has knowledge or cleaner solutions for any of these leave a comment so I can update it.
@ZacSharp I've been on and off about it. I haven't fixed any the original bugs enough to commit. I talked to masa and he believes it should be possible but in general the 1.12.2 port has had a lot of issues. I'll probably give it another try after the semester is over.
I'd like to express my interest here as well -- I have a lot of complex redstone that I need to place (running experimental 1.17.1 build) and this would make life much easier for me
I ported this up to 1.17 a while ago here, did the work translating mappings etc
https://raw.githubusercontent.com/sudofox/baritone-1.17/master/src/main/java/baritone/utils/schematic/format/defaults/LitematicaSchematic.java?token=GHSAT0AAAAAABKUY4TPGPDW7HIUI2M37YD2YQLEGKA
Unsure what needs to be done to push things forward
Issues with this version:
- Some states (such as iron bars) are unrecognized
- In 1.12, the long array (blockstates) isn't exposed by the libraries so parsing has to be done manually
- Only reads in first region of the .litematic
I't probably useable as is (never managed to get myself to have a look at it), but not ready for merging. The reason for the first point is unknown (as far as I know), the other two points have already been addressed in the discussion here.
Hey everyone looks like I should follow up here -
I wouldn't feel good merging it in with its current state - I would expect this will create GH issues than are closed.
I'm interested in pushing things forward for a 1.12 implementation with @sudofox but hit a wall with the mixins and have been working on other projects (@blankly-finance). I talked to Mesa a few months ago and there is no technical reason why this couldn't work.
If someone could tackle or give some pointers on the mixin for the long array that would be great.
For the mixin you probably want a simple mixin on NBTTagLongArray with an @Accessor for the data field. Since Baritone has the mixin classes in a separate source set you also need an interface for the accessor in the main source set and make the mixin class implement it. If you've got it right you can then safely cast the long array to the accessor interface and youse the mixin generated method to get the data. I think the easiest way to see how to do it is looking at the interfaces in baritone.utils.accessor and their implementations in baritone.launch.mixins.
Thanks for the mention Emerson. I should establish that my Java skills are quite hodgepodgey so I'll try to contribute as much as I can but otherwise I'll cheer you on from the sidelines 😅
I've had a look at it and I think you can copy the changes from https://github.com/ZacSharp/baritone/commit/0550fe362369d12e0aefe6ffb0b8f9190f2f7f69 as is. I also had a try at loading all regions of the schematic in https://github.com/ZacSharp/baritone/commit/3cf9e2f2580481350fcf1c4a1481164cde62b72d but that commit is not useable as is and comes with debug printouts and will likely (didn't try it) crash with map art mode enabled for any litematic that does completely fill its enclosing box volume.
I've invested some more time and used the approach from #3317 (patching the holes with air) to fix mapArtMode. You can find the changes at https://github.com/ZacSharp/baritone/commit/3661fea4f05755ebf285b883aabfe2abde34f76d and its parents in case you want to use them.
I also failed to reproduce the bug with iron bars not being loaded correctly, all 16 worked.
What's currently missing (both done on my branch but @EmersonDove hasn't done it here yet)
- Read all regions of the .litematic instead of just the first
- Get rid of the hacky string parsing
@leijurv I'd really like to know whether static schematics are allowed to have holes (i.e. behavior of getDirect is undefined at positions within the schematic bounds as it is the case for other schematics).
