Hi. My brother and I have our own multiplayer world that we play on a server hosted on his computer.
He got a blue screen to do with a driver error (he's uninstalling and reinstalling drivers right now) and now when he starts the server it does the whole [SEVERE] java.lang exception thingy.
Here's the world. I'm not sure if there's anything you can do, but if you can, thanks.
I really hope you can help. We've spent hours on this place. He made an awesome mountain keep, I made a sweet bridge extending through the trees and a giant, huge hall as well. It feels like an old school fairytale fantasy world.
Hi. My brother and I have our own multiplayer world that we play on a server hosted on his computer.
He got a blue screen to do with a driver error (he's uninstalling and reinstalling drivers right now) and now when he starts the server it does the whole [SEVERE] java.lang exception thingy.
Here's the world. I'm not sure if there's anything you can do, but if you can, thanks.
I really hope you can help. We've spent hours on this place. He made an awesome mountain keep, I made a sweet bridge extending through the trees and a giant, huge hall as well. It feels like an old school fairytale fantasy world.
Do you have a backup? If you have a backup, no matter how old, I can fix it.
Hello, I'm having a problem with one of my save files.
Whenever I enter a certain chunk my character seems to be freezing.
I have tried removing blocks under me, but my character just keeps floating in mid-air.
Dropped items keep floating.
Also, mobs also seem to have this problem too.
I don't know how long this has been around since I never go to that part of the map, but i hope you can help me fix it.
It's a late Infdev save: http://www.mediafire.com/?ink15q3irfc9ec5
This problem occurs at the coordinates:
X:-112
Y:65
Z-218
I hope you can help me,
Thanks in advance.
I fixed it. Chunks don't regenerate properly, so do some reading in the first and second posts in this thread about why that happens so you can avoid it in the future. There is nothing that can be done about it now.
Yeah - but stupidly, I also had them in my saves folder...dur! I kept meaning to move them to my removable hard drive, but never got around to it. If I can get ZileFile to work...I'll see about an upload.
Thanks again!
I think I fixed it. I went into the region folders and renamed them all to what they were supposed to be, and restored a backed up level.dat. Do you have any mods installed? My game crashed in a manner that would make me suspect a mod. Other than that, it seems to be fine.
I personally think you are epically lucky to have your save recovered. This is by far the furthest I have ever seen one get and still come back. If you really did delete it and all of the backups and it was totally gone, then wow. just wow. store those backups somewhere safe from now on k? thx =)
I think I fixed it. I went into the region folders and renamed them all to what they were supposed to be, and restored a backed up level.dat. Do you have any mods installed? My game crashed in a manner that would make me suspect a mod. Other than that, it seems to be fine.
Oh man you are a genius! I use the Mixcraft HD texture pack and probably had MrMessiahs BetterLight & BetterGrass and minimap installed.
Quote from apocalypse_r »
I personally think you are epically lucky to have your save recovered. This is by far the furthest I have ever seen one get and still come back. If you really did delete it and all of the backups and it was totally gone, then wow. just wow. store those backups somewhere safe from now on k? thx =)
Holy crap - you are making me feel that luck! But I guess that it is also a good advert for Recuva - I'll definitiely be recommending that as my undelete tool of choice! My backup saves will be on USB, on my portable HD and maybe on my gmail account from now on!
I add here the .png of my corrupted world (done with cartograph). I circled in red the buggy zone (near the big plateform) :
I thank you in advance for your very helpfull work.
Working on it now. MAN is mcedit pissed. I don't know what happened to this world, but MCedit does NOT like it. I should be able to fix it though.
edit - OK, I think I've fixed it. I removed the corrupted chunks with mcedit. theres a big square hole in the map, but it will regenerate when you go close to it.
I think I need to call upon your genius once again - in both my modded and now in vanilla Minecraft, the world you fixed for me crashes Minecraft after a few seconds of play time. I don't get any debug output ot error messages. I wonder if there is a problem chunk somewhere that causes a crash when it loads / updates?
I also notice that running MCEdit on World4 doesn't seem to show my world?
Thanks again for your awesome help!
Edit
There is definitely some corruption, I don't know if it is recoverable.
The red circles show obvious chunk errors (I think the strip to the left is all I can see in MCEdit). The blue circles show what seems to be some missing data - structures chopped off halfway through. I wonder if this is the part that is crashing?
firstworld.zip is the first world I mentioned, the one I fiddled with. I think it has both a newly generated MCregion world and the old pre-1.3 world. secondworld.zip is the unmodified one.
Just to be a bit more specific, when I say "fiddling" I mean I deleted a few of the most recently modified chunks to see if it would work, and instead of loading and converting the map it just generated a new one, so I restored the chunks I deleted (recycle bin ftw)
Not sure why the chunk reverted itself, but it probably got borked when the power failed and was regenerated the next time the server tried to load it. I can't fix the chunk, you will have to rebuild over it.
The good news is that between all of the copies of the world you sent me, there was exactly one working metadata backup, and I was able to fix the world from that, and it should load properly again.
Also, the two worlds you gave me were radically different, as though one was an old backup of the other. I was under the impression that survival2 was a copy of the world that you saved immediately prior to fiddling with it.
Here is my save file, I don't exactly know what's wrong, but I hope you can fix it. The first problem I encountered was that one chunk was completely reversed to it's original state, when there wasn't a building. I got that fixed, but when I entered again, after the manual fix, I found that one chunk had copied itself to another chunk, which gives a structural error. On top of that, if I enter certain chunks, including the one I was standing on, I'm not able to move, at all. I got difficulty set on normal, so mobs were spawning, and they couldn't move either. I hope you can be of service somehow. Thanks in advance. :smile.gif: http://www.mediafire.com/?f7cpwoyrobsabvg
In future, don't go copying chunks, it breaks things. Just use mcedit to restore broken areas instead. I found and removed the corrupt chunk (this is why you were unable to move) and cloned an unbroken side of the palace over the missing areas.
I think I need to call upon your genius once again - in both my modded and now in vanilla Minecraft, the world you fixed for me crashes Minecraft after a few seconds of play time. I don't get any debug output ot error messages. I wonder if there is a problem chunk somewhere that causes a crash when it loads / updates?
I also notice that running MCEdit on World4 doesn't seem to show my world?
Thanks again for your awesome help!
Edit
There is definitely some corruption, I don't know if it is recoverable.
The red circles show obvious chunk errors (I think the strip to the left is all I can see in MCEdit). The blue circles show what seems to be some missing data - structures chopped off halfway through. I wonder if this is the part that is crashing?
mcedit is, apparently, very lazy, and has case sensitive file recognition - most of the salvaged chunks had uppercase extensions, and mcedit didn't read them. don't ask me, I didn't write it.
it appears that some of the region files are corrupted. I would venture to say that this is why the game crashes when we try to load the level. I will break out my strongest juju and try to repair them. It might take me a day or two. Several of them seem to have bogus entries in their sector tables, and mcedit won't even open the map if they are there (I have to rename them so mcedit doesn't see them, this is why I suspect minecraft is crashing because of the bad regions)
however, some of what you are seeing is more or less normal - for no particular reason, disconnected chunks will sometimes be generated. The holes in the map will (or at least should) fill in when you go close enough to them for minecraft to try to load them.
Hey, just wondering if you finished packing yet and got a chance to look at my world file >_>
I'm really sorry, I would have, but just as I was about to, the forum rudely decided to go stop working for hours and I decided to call it a night. I have class soon, I get out in 4 hours, and I'll do yours then.
I have also made progress on that program I promised (the one that can do these sorts of things automatically). I spent about 20 minutes yesterday night porting zlib to c++ (it's written in c so its been easy as cake), and have started brainstorming features for it as well as disassembling region files and reading the documentation so I know how they work. It's been fun. Kyudos is very lucky that chunks internally store their position. His/her region files were deleted and the chunk index was overwritten, but I should be able to use the program I'm writing to analyze the damaged files and rebuild the chunk index from the mostly still existing chunk data.
Tech dump - region files store chunks in sectors. The first 2 sectors are metadata - the first being the position and size of each chunk, in sectors, the second being a 4 byte timestamp of when the chunk was last modified. all subsequent sectors are chunks. a sector has a size of 0x1000 bytes (4096 bytes, or 4kB). an 8kB region file contains no chunks. one of Kuydos' region files has had the first 3 sectors overwritten. Most of the chunks seem to be intact, but unordered.
That program sounds cool. To be honest, before I found this thread I was seriously considering writing such a utility myself, software being my job too :smile.gif:. However, you sound so far ahead of me, you'd no doubt be finished your version before I even get my head around the file format.
But if there is anything I can do to help, just let me know.
Wow. Mojang should pay you for this or something, I mean really - fixing all these worlds out of the goodness in your heart is quite noble of you. Also, I'm surprised this hasn't been stickied.
Rollback Post to RevisionRollBack
Quote from Ultra-Orange »
Quote from Direwolf20 »
#37) Ores tend to spawn in packs
If you take one out you better be ready to take on its angry cousins!
Took out an over head coal node once and was snuffed by a gang of Gravel seeking revenge!
That program sounds cool. To be honest, before I found this thread I was seriously considering writing such a utility myself, software being my job too :smile.gif:. However, you sound so far ahead of me, you'd no doubt be finished your version before I even get my head around the file format.
But if there is anything I can do to help, just let me know.
brainstorm common problems that the program can target. I already have a big list, but I think most of the items address issues that apply to pre 1.3 saves (most of which still apply, but now the region system adds a whole new layer of things that could go wrong). I'm writing it in C++, just so you know. I just finished some fun work writing an nbt reader/writer, that will hopefully be fully operational tomorrow. at that point, it will be able to read level.dat and perform the most basic of sanity checking. if you feel like writing some pseudocode for high level error checking and corruption detection, be my guest.
Quote from GnomeSag »
Thanks, take your time. I understand you're busy. :]
you have no idea.
Quote from Amphouse »
Wow. Mojang should pay you for this or something
Lol I wish
I mean really - fixing all these worlds out of the goodness in your heart is quite noble of you. Also, I'm surprised this hasn't been stickied.
Inorite. sticky would be useful. but they'd move it to the support section, and I think we can all agree that it's better off here, away from 50000 posts in broken english by users with 2 posts, all of whom have exactly the same problem. Also, I applied to be a mod here, but no response. would I make a good mod?
Quote from p0rtalplayer »
Just wanted to remind you to look at the saves I posted, in case you forgot. Thanks :wink.gif:
I fixed yours, its up there about 10 posts or so ^^
Hi. My brother and I have our own multiplayer world that we play on a server hosted on his computer.
He got a blue screen to do with a driver error (he's uninstalling and reinstalling drivers right now) and now when he starts the server it does the whole [SEVERE] java.lang exception thingy.
Here's the world. I'm not sure if there's anything you can do, but if you can, thanks.
I really hope you can help. We've spent hours on this place. He made an awesome mountain keep, I made a sweet bridge extending through the trees and a giant, huge hall as well. It feels like an old school fairytale fantasy world.
Do you have a backup? If you have a backup, no matter how old, I can fix it.
Unfortunately, no. And that lev_old.dat thing or whatever didn't work either.
Some thoughts, which may or may not line up with what your were thinking...
Name
Every Project needs a name right? I would’ve called this the CHUNk Diagnostic and Emergency Repair tool – or CHUNDER. But that is probably more a reflection of my sense of humour than anything else.
Errors
When it comes to the source of errors, the utility needs to be agnostic as far as possible – there are simply too many potential sources of error for it to be enmeshed with any of them. However, I see chunk errors falling into three broad categories:
[*:19ewptrf]Data Missing
Chunk data or meta-data is missing. Given the NBT format, a fault tolerant NBT reader/writer should easily be able to determine if this is the case. It is obviously important that the utility be able to read and interpret what is present, independent of what isn’t.
[*:19ewptrf]Data Invalid/Corrupt
We know what should be in each field of a NBT file, so it is relatively straightforward to determine if the data present is feasible. Given that we also know what block and item IDs are in use, you can sanity check the map data.
[*:19ewptrf]Data Incorrect
This might be the most common type of error, I don’t know, but is probably also the most difficult to fix automatically. Imagine a case where some block data gets blanked (filled with 0x00). This amounts to filling that area with air, and while you might be able to see this easily in a map editor, you couldn’t determine that it was wrong automatically. The same applies to chunk translations (data rotated, flipped or mirrored). These would have to be fixed manually, if at all.
Repairs
What to do about the errors…
[*:19ewptrf]Data Missing
The obvious thing to do is to regenerate / replace the missing information. So if it is chunk location that is missing, it can be gleaned from the file system (old format) or the metadata of neighbouring records (new format). If world data is missing you could offer replacement in a number of different ways – depending on how involved you want to get:
[*:19ewptrf]Carte Blanche
Replace the whole chunk with something like flat, earth-topped stone. I don’t see this as a popular option to be honest – but people might want it if data is missing in the middle of their structures.
[*:19ewptrf]Infilling
Fill “holes” by infilling from the edges – might result in vast swathes of uniformity though.
[*:19ewptrf]Copy missing data from a neighbouring chunk
This offers a reasonable compromise – giving you a similar distribution of blocks to the surrounding area, but is most suitable for rebuilding missing terrain. It would make weird things happen in built areas.
[*:19ewptrf]Regeneration
I guess this would be the ‘holy grail’. Integration/re-implementation of Minecraft’s terrain generation into the repair utility would allow any chunk to be regenerated and returned to its pristine unmodified state. This might also allow you to gauge the amount of changes a chunk has undergone (via comparison with the ‘original’ chunk). In turn, that could inform your decision on how to repair. For example, if what remains of a damaged chunk is identical to the original, it is probably safe to replace with the original (depending on how much is missing of course!). However, if it is significantly different, the intimation is that the player has been building there (or you have a combination of missing and corrupt data – ugh!)
[*:19ewptrf]Data Invalid/Corrupt
For corrupt location and block data, pretty much the same replacement options exist, see above. Corrupt block sub data (e.g. stair orientation) could be repaired, but with no way to determine “correctness” unless you want to go to extremes. Using the stair case, for example, you might be able to come up with a “best guess” to fix the orientation by aligning it with neighbouring stair blocks, but that’s a lot of extra processing, and each block type would have to be processed differently.
[*:19ewptrf]Data Incorrect
I think these are the sorts of things falling into the “we can’t fix / don’t want to fix” category. What I’m about to suggest is probably way beyond the scope of this utility, but could be done.
Essentially it amounts to offering a way to manually inspect and correct chunks in various ways and probably steals some functionality from things like MCEdit. Say for instance you could see an overhead view of a chunk in context – say the centre of a 5x5 grid of chunks. You could then offer manual translations (rotate, flip, mirror), copying of another chunk, carte blanche replacement or insertion of the original chunk.
The utility might also address issues on a ‘world’ level. It might offer to remove orphan chunks (a chunk with no neighbouring chunks is probably not part of the ‘game world’, though is not necessarily a problem either). If you had the terrain generation integration, the ability to regenerate unmodified or barely modified chunks would also be handy – so you could update your world with new content without have to explore outside your existing boundaries.
He got a blue screen to do with a driver error (he's uninstalling and reinstalling drivers right now) and now when he starts the server it does the whole [SEVERE] java.lang exception thingy.
Here's the world. I'm not sure if there's anything you can do, but if you can, thanks.
http://www.mediafire.com/?kwl9022b9vvh9vv
I really hope you can help. We've spent hours on this place. He made an awesome mountain keep, I made a sweet bridge extending through the trees and a giant, huge hall as well. It feels like an old school fairytale fantasy world.
Do you have a backup? If you have a backup, no matter how old, I can fix it.
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
I fixed it. Chunks don't regenerate properly, so do some reading in the first and second posts in this thread about why that happens so you can avoid it in the future. There is nothing that can be done about it now.
m33p1.zip
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
I think I fixed it. I went into the region folders and renamed them all to what they were supposed to be, and restored a backed up level.dat. Do you have any mods installed? My game crashed in a manner that would make me suspect a mod. Other than that, it seems to be fine.
edit - forgot link
Kyudos4.zip
I personally think you are epically lucky to have your save recovered. This is by far the furthest I have ever seen one get and still come back. If you really did delete it and all of the backups and it was totally gone, then wow. just wow. store those backups somewhere safe from now on k? thx =)
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Oh man you are a genius! I use the Mixcraft HD texture pack and probably had MrMessiahs BetterLight & BetterGrass and minimap installed.
Holy crap - you are making me feel that luck! But I guess that it is also a good advert for Recuva - I'll definitiely be recommending that as my undelete tool of choice! My backup saves will be on USB, on my portable HD and maybe on my gmail account from now on!
Working on it now. MAN is mcedit pissed. I don't know what happened to this world, but MCedit does NOT like it. I should be able to fix it though.
edit - OK, I think I've fixed it. I removed the corrupted chunks with mcedit. theres a big square hole in the map, but it will regenerate when you go close to it.
DarthSoulXworld.zip
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
I also notice that running MCEdit on World4 doesn't seem to show my world?
Thanks again for your awesome help!
Edit
There is definitely some corruption, I don't know if it is recoverable.
See this Cartograph image:
http://www.mediafire.com/i/?p5m9tkbiacwcatp
The red circles show obvious chunk errors (I think the strip to the left is all I can see in MCEdit). The blue circles show what seems to be some missing data - structures chopped off halfway through. I wonder if this is the part that is crashing?
Not sure why the chunk reverted itself, but it probably got borked when the power failed and was regenerated the next time the server tried to load it. I can't fix the chunk, you will have to rebuild over it.
The good news is that between all of the copies of the world you sent me, there was exactly one working metadata backup, and I was able to fix the world from that, and it should load properly again.
Also, the two worlds you gave me were radically different, as though one was an old backup of the other. I was under the impression that survival2 was a copy of the world that you saved immediately prior to fiddling with it.
survival.zip
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
In future, don't go copying chunks, it breaks things. Just use mcedit to restore broken areas instead. I found and removed the corrupt chunk (this is why you were unable to move) and cloned an unbroken side of the palace over the missing areas.
minecrafterII3.zip
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
mcedit is, apparently, very lazy, and has case sensitive file recognition - most of the salvaged chunks had uppercase extensions, and mcedit didn't read them. don't ask me, I didn't write it.
it appears that some of the region files are corrupted. I would venture to say that this is why the game crashes when we try to load the level. I will break out my strongest juju and try to repair them. It might take me a day or two. Several of them seem to have bogus entries in their sector tables, and mcedit won't even open the map if they are there (I have to rename them so mcedit doesn't see them, this is why I suspect minecraft is crashing because of the bad regions)
however, some of what you are seeing is more or less normal - for no particular reason, disconnected chunks will sometimes be generated. The holes in the map will (or at least should) fill in when you go close enough to them for minecraft to try to load them.
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Hey, just wondering if you finished packing yet and got a chance to look at my world file >_>
I'm really sorry, I would have, but just as I was about to, the forum rudely decided to go stop working for hours and I decided to call it a night. I have class soon, I get out in 4 hours, and I'll do yours then.
I have also made progress on that program I promised (the one that can do these sorts of things automatically). I spent about 20 minutes yesterday night porting zlib to c++ (it's written in c so its been easy as cake), and have started brainstorming features for it as well as disassembling region files and reading the documentation so I know how they work. It's been fun. Kyudos is very lucky that chunks internally store their position. His/her region files were deleted and the chunk index was overwritten, but I should be able to use the program I'm writing to analyze the damaged files and rebuild the chunk index from the mostly still existing chunk data.
Tech dump - region files store chunks in sectors. The first 2 sectors are metadata - the first being the position and size of each chunk, in sectors, the second being a 4 byte timestamp of when the chunk was last modified. all subsequent sectors are chunks. a sector has a size of 0x1000 bytes (4096 bytes, or 4kB). an 8kB region file contains no chunks. one of Kuydos' region files has had the first 3 sectors overwritten. Most of the chunks seem to be intact, but unordered.
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
But if there is anything I can do to help, just let me know.
brainstorm common problems that the program can target. I already have a big list, but I think most of the items address issues that apply to pre 1.3 saves (most of which still apply, but now the region system adds a whole new layer of things that could go wrong). I'm writing it in C++, just so you know. I just finished some fun work writing an nbt reader/writer, that will hopefully be fully operational tomorrow. at that point, it will be able to read level.dat and perform the most basic of sanity checking. if you feel like writing some pseudocode for high level error checking and corruption detection, be my guest.
you have no idea.
Lol I wish
Inorite. sticky would be useful. but they'd move it to the support section, and I think we can all agree that it's better off here, away from 50000 posts in broken english by users with 2 posts, all of whom have exactly the same problem. Also, I applied to be a mod here, but no response. would I make a good mod?
I fixed yours, its up there about 10 posts or so ^^
[FAQ] Extremely Common Problems
[OFFICIAL] Dragon Cave Thread
Unfortunately, no. And that lev_old.dat thing or whatever didn't work either.
Does that mean we're boned?
Name
Every Project needs a name right? I would’ve called this the CHUNk Diagnostic and Emergency Repair tool – or CHUNDER. But that is probably more a reflection of my sense of humour than anything else.
Errors
When it comes to the source of errors, the utility needs to be agnostic as far as possible – there are simply too many potential sources of error for it to be enmeshed with any of them. However, I see chunk errors falling into three broad categories:
[*:19ewptrf]Data Missing
Chunk data or meta-data is missing. Given the NBT format, a fault tolerant NBT reader/writer should easily be able to determine if this is the case. It is obviously important that the utility be able to read and interpret what is present, independent of what isn’t.
[*:19ewptrf]Data Invalid/Corrupt
We know what should be in each field of a NBT file, so it is relatively straightforward to determine if the data present is feasible. Given that we also know what block and item IDs are in use, you can sanity check the map data.
[*:19ewptrf]Data Incorrect
This might be the most common type of error, I don’t know, but is probably also the most difficult to fix automatically. Imagine a case where some block data gets blanked (filled with 0x00). This amounts to filling that area with air, and while you might be able to see this easily in a map editor, you couldn’t determine that it was wrong automatically. The same applies to chunk translations (data rotated, flipped or mirrored). These would have to be fixed manually, if at all.
Repairs
What to do about the errors…
[*:19ewptrf]Data Missing
The obvious thing to do is to regenerate / replace the missing information. So if it is chunk location that is missing, it can be gleaned from the file system (old format) or the metadata of neighbouring records (new format). If world data is missing you could offer replacement in a number of different ways – depending on how involved you want to get:
[*:19ewptrf]Carte Blanche
[*:19ewptrf]Data Invalid/CorruptReplace the whole chunk with something like flat, earth-topped stone. I don’t see this as a popular option to be honest – but people might want it if data is missing in the middle of their structures.
[*:19ewptrf]Infilling
Fill “holes” by infilling from the edges – might result in vast swathes of uniformity though.
[*:19ewptrf]Copy missing data from a neighbouring chunk
This offers a reasonable compromise – giving you a similar distribution of blocks to the surrounding area, but is most suitable for rebuilding missing terrain. It would make weird things happen in built areas.
[*:19ewptrf]Regeneration
I guess this would be the ‘holy grail’. Integration/re-implementation of Minecraft’s terrain generation into the repair utility would allow any chunk to be regenerated and returned to its pristine unmodified state. This might also allow you to gauge the amount of changes a chunk has undergone (via comparison with the ‘original’ chunk). In turn, that could inform your decision on how to repair. For example, if what remains of a damaged chunk is identical to the original, it is probably safe to replace with the original (depending on how much is missing of course!). However, if it is significantly different, the intimation is that the player has been building there (or you have a combination of missing and corrupt data – ugh!)
For corrupt location and block data, pretty much the same replacement options exist, see above. Corrupt block sub data (e.g. stair orientation) could be repaired, but with no way to determine “correctness” unless you want to go to extremes. Using the stair case, for example, you might be able to come up with a “best guess” to fix the orientation by aligning it with neighbouring stair blocks, but that’s a lot of extra processing, and each block type would have to be processed differently.
[*:19ewptrf]Data Incorrect
I think these are the sorts of things falling into the “we can’t fix / don’t want to fix” category. What I’m about to suggest is probably way beyond the scope of this utility, but could be done.
Essentially it amounts to offering a way to manually inspect and correct chunks in various ways and probably steals some functionality from things like MCEdit. Say for instance you could see an overhead view of a chunk in context – say the centre of a 5x5 grid of chunks. You could then offer manual translations (rotate, flip, mirror), copying of another chunk, carte blanche replacement or insertion of the original chunk.
The utility might also address issues on a ‘world’ level. It might offer to remove orphan chunks (a chunk with no neighbouring chunks is probably not part of the ‘game world’, though is not necessarily a problem either). If you had the terrain generation integration, the ability to regenerate unmodified or barely modified chunks would also be handy – so you could update your world with new content without have to explore outside your existing boundaries.