search

mrkite / minutor

Mapping for Minecraft
http://seancode.com/minutor
BSD 2-Clause "Simplified" License
278 stars 52 forks source link

Minutor crash if 1.12.2 level.dat contains Data/DayTime #329

Closed terbin closed 2 years ago

terbin commented 2 years ago

Using Minutor 2.19.0 or the latest unofficial nightly build on Windows.

Minutor crashes if I open a Minecraft 1.12.2 level.dat that contains the Data/DayTime NBT data. I have attached a sample level.dat

level.dat.zip

EtlamGit commented 2 years ago

It works when the data type of Data/DayTime is Long and it crashes when it is Int.

When I look through my older test worlds, this element is always created as Long. Did you create that level.dat with some other tool or by hand?

EtlamGit commented 2 years ago

Even when I search the history of level.dat format, there is no point in time where this data field was an Int.

terbin commented 2 years ago

Thank you for checking this. I use Forge and a world download mot, not Vanilla for the client. I have several "world downloads" from an anarchy server by different people, which have it like this. Very strange. I can just remove the tag with NBTExplorer I recon.

terbin commented 2 years ago

@EtlamGit Forgot to mention that this is a new issue, introduced with Minutor 2.19.0. Minutor 2.18.0 opens these level.dats without issue

EtlamGit commented 2 years ago

Yes, we started to parse these values in level.dat to enable SlimeChunk and InhabitedChunkTime overlays.

I would suggest, that you convert this value to LongInt for your worlds (delete and recreate with same value). But I should also add some check code to prevent crashes here.

madmaxoft commented 2 years ago

On the other hand, why not make Minutor accept these even if they have the wrong datatype? It costs us nothing and makes life easier for the users.

EtlamGit commented 2 years ago

I'm doing exactly that at the moment ;-)

Kolcha commented 2 years ago

PR was merged, nightly builds are available, I'm also triggered build for nightly builds for Linux, so issue can be closed. P.S> GitHub has nice feature to close issues automatically when PR is merged, so no need to track issues separately

EtlamGit commented 2 years ago

Yes, normally they are closed automatically when you put a "fix #number" into the PullRequest text block. No idea why this did not happen here...