Feat/litematic support

[KevinDaGame]

What type of PR is this? (check all applicable)

• Feature
• Refactor
• Bug Fix
• Optimization
• Documentation Update

Description

close #232

• Implement litematic support. Thanks @SandroHc!
• Refactor stencil/schematic system to support litematica and any future formats.
• Removed check for .schem files. In the future, we might want to keep a list with supported formats (preferably directly from schematic4J)
• Added Unittests! the VoxelSchematicLoader has 100% test coverage
• DataFolderSchematicReader can't be properly tested due to it's dependency on the file system
• In the future we could add any number of schematic readers, such as one over the network (who knows?)

QA Instructions, Screenshots, Recordings

The following schematics can be used for testing:
schematics.zip

Added/updated tests?

• Yes
• No, and this is why: please replace this line with details on why tests
  have not been included
• I need help with writing tests
• Not needed

[optional] What gif best describes this PR or how it makes you feel?

[Lennart99]

I think it is better to use new File(baseDirectory, file); or simular.

[KevinDaGame]

I disagree. Until now we have used the file handler everywhere. Making a file directly would require getting the full path to the plugin root, which is extra work

[Lennart99]

you don't https://github.com/KevinDaGame/VoxelSniper-Reimagined/blob/master/VoxelSniperCore/src/main/java/com/github/kevindagame/util/Messages.java#L383C92-L383C92

[Lennart99]

Also I am not sure if using '/' is platform dependent or not..

[KevinDaGame]

you don't https://github.com/KevinDaGame/VoxelSniper-Reimagined/blob/master/VoxelSniperCore/src/main/java/com/github/kevindagame/util/Messages.java#L383C92-L383C92

That's more an issue on that part. I prefer to leave this file logic to the main file handler. It might be a good idea to refactor this in other places

[Lennart99]

Maybe this would be a nice option, we could add/change a method in filehandler File getDataFile(String... path), which could take all path 'parts', without having to concatenate the strings, which I think is not the way it is meant to be done in Java (could be wrong here, but most examples either use File or Paths).

    default File getDataFile(String... path) {
        File f = getDataFolder();
        for (String p : path) {
            f = new File(f, p);
        }
        return f;
    }

[KevinDaGame]

INFO: Why don't you like the way I'm using it? I'd like to stay away from the File constructor wherever possible, to prevent divergence later on.

[KevinDaGame]

I do think though that the way we access the filehandler isn't nice. Perhabs this could be solved using dependency injection

[Lennart99]

I will approve the PR, since the same issue was already present before I think, but we should indeed look into improving this.
I feel like we should, if we want to be able to change the implementation, supply every part of the path to the filehandler separately, so that it can traverse the filesystem in whatever way it needs to.

[SandroHc]

In the future, we might want to keep a list with supported formats (preferably directly from schematic4J)

That can already be done like this:

Set<String> supportedExtensions = new HashSet<>();
for (SchematicFormat format : SchematicFormat.values()) {
	supportedExtensions.add(format.fileExtension);
}

// Or as a one-liner:
Set<String> supportedExtensions = Arrays.stream(SchematicFormat.values())
    .map(f -> f.fileExtension)
    .collect(Collectors.toSet());