Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-NBT/MCA code cleanups #374

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

HoldYourWaffle
Copy link
Contributor

@HoldYourWaffle HoldYourWaffle commented Jul 30, 2022

As mentioned on Discord, these are my cleanups & refactors so far that have nothing to do with NBT or MCA.
The rest of my de-duplication effort depends on the discussed moving of most NBT/MCA logic to Querz/NBT, so I'll look into that next.

I'd strongly recommend reviewing this code per-commit.
I've rebased, split and rewritten the commit history countless times in an effort to make everything as review-friendly (and easy to revert) as possible, so I hope there's no weird leftovers remaining... :)

source = entities;
} else {
// MAINTAINER why not check poi data?
// MAINTAINER fail fast?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 3738e76

@@ -13,6 +14,7 @@ public boolean relocate(Point3i offset) {
}

private boolean relocateChunk(Chunk c, Point3i offset) {
// MAINTAINER why do we check if DataVersion exists, shouldn't that be a (fast-failing) irrecoverable corruption?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words: why is it okay to silently ignore this chunk and continue the relocation operation if DataVersion is missing?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is true. It could log a warning in case of failure to find the DataVersion tag, but only if the chunk has any data (c.getData() != null), otherwise it should just ignore that chunk.

} else if (entities != null && entities.getData() != null) {
source = entities;
} else {
// MAINTAINER why not check poi data?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, this should also check for the DataVersion in poi just in case.

@@ -82,11 +70,9 @@ jar {
'Class-Path': configurations.shadow.files.stream()
.filter($it -> !$it.name.startsWith('javafx')).collect{"lib/$it.name"}.join(' ')
)
exclude 'licenses/'
from 'LICENSE'
dependsOn minifyCss
dependsOn copyRuntimeLibs
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copyRuntimeLibs needs to be adjusted too, because it still references configurations.shadow.

Those libs are needed for the *-min.jar as well as for bundling with the Windows Installer.

@@ -21,7 +21,7 @@ protected Integer getNumber(ChunkData data) {
if (data.region() == null || data.region().getData() == null) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is going to be inconsistent with getDataVersion and i think it should be removed entirely.
It could use ValidationHelper.withDefault(data::getDataVersion, 0); if we don't want it to log a warning on failure to find a DataVersion, but i think it would make more sense if it logs the warning because it would imply a chunk corruption.

I also noticed that Region#getFilteredChunks does not check if a chunk is completely empty. There should be a check like this:

if (regionChunk == null && entitiesChunk == null && poiChunk == null) {
    continue;
}

This should stop all filters requiring a DataVersion from throwing an exception if a chunk is completely empty because they shouldn't even be executed.

};
ExposedByteArrayOutputStream baos = new ExposedByteArrayOutputStream();

// CHECK DataOutputStream wrapper unnecessary?
Copy link
Owner

@Querz Querz Aug 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both wrappers are unnecessary, because NBTWriter#write will wrap with a BufferedOutputStream and a DataOutputStream.
So this should look like this:

OutputStream nbtOut = switch (compressionType) {
	case GZIP, GZIP_EXT -> new GZIPOutputStream(baos);
	case ZLIB, ZLIB_EXT -> new DeflaterOutputStream(baos);
	case NONE, NONE_EXT -> baos;
};

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for both of the Chunk#load methods.

if (sourceVersion == 0) {
continue;
}
int sourceVersion = sourceChunk.getDataVersion();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This now will cancel the merging process of the entire file / all files if it throws the NoSuchElementException, as opposed to before where it simply ignored it.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this, we'll need to look into all other places where this might be an issue

return level;
}

// XXX what's going on with the colliding fixEntityUUID* methods? What do they actually do? How can they be named better?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixEntityUUIDsMerger handles entities on the root level, while fixEntityUUIDMerger is used to recursively change entity UUIDs for any passengers.

I guess they could be renamed to something like recalculateEntityUUID and recalculateEntityUUIDs to better describe what they do.


// XXX what's going on with the colliding fixEntityUUID* methods? What do they actually do? How can they be named better?
public static void fixEntityUUIDsMerger(CompoundTag root) {
// MAINTAINER shouldn't this be VersionController'ed?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but then we need to make sure that the root passed to this function is actually the root CompoundTag, and not already the Level tag in earlier versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants