Convert Minecraft server world files into MCserver world files.

[rs2k]

Converter works. It too the mcr file and created a valid and working pak file, Now I need to change it to do that to all files in a directory and place the output into another directory. I've only tested this in linux.

http://code.google.com/p/mc-server/source/detail?r=34

[rs2k]

The converter appears to be working now. It takes all mcr files in the directory region and converts them to pak files in the directory world. I'm running a full test but converting an entire map now. I'll upload the new code when it's done.

It takes about 20 seconds per 1024 chunks (region) to convert. It's over 15 times faster than the PHP code.

The converter has a memory leak I need to find. Probably just something I forgot to delete.

---

It seems to work. One chunk out of about 73,000 caused an error message, but it may have just been a corruption mcr file.

Come check it out the converted map at omencraft.com (default port).


The code's still messy and I need to fix the memory leak and convert entities over, but at least it works now.
http://code.google.com/p/mc-server/source/detail?r=36

[rs2k]

Destroying a block seems to lock up the server. I'm not sure if it's the map or something else causing the problem yet. I'm running the newest version of MCServer.

---

Ahha: It looks like it's going through and doing something to the pak files:

"cFileFormatUpdate will loop through old files and convert them to new files"

I'll let it finish instead of restarting it. lol.

---

What ever it's doing, it's eating a ton of RAM while doing it. up to 21% RAM until it completed when it dropped down to 14.4% system RAM. It looks like there's a memory leak.

The process lasted about 10 minutes. When it finished I was able to destroy blocks like normal. Server's back up and running like normal.

[FakeTruth]

Well that's strange. All it does is convert the player data in /world/player from binary to Json. While it's doing that the server isn't even running so you shouldn't be able to connect.

Converting 1166 players to the new format took like 5 seconds here.

[rs2k]

Well that's strange. All it does is convert the player data in /world/player from binary to Json. While it's doing that the server isn't even running so you shouldn't be able to connect.

Converting 1166 players to the new format took like 5 seconds here.

I'm not sure if that's what's doing it, it's just a guess. Something definitely caused a large memory leak. The part of code it was happening at is here:

cChunkMap::cChunkLayer* cChunkMap::LoadLayer(int a_LayerX, int a_LayerZ )

I added LOG("Source File: %s", SourceFile ); to the code to see if this was the line, it was:

Code:

short NumChunks = 0;
                if( fread( &NumChunks, sizeof(NumChunks), 1, f) != 1 ) { LOGERROR("ERROR 3 READING FROM FILE %s", SourceFile); fclose(f); return false; }
                LOG("Num chunks: %i", NumChunks );
                LOG("Source File: %s", SourceFile );

It took several seconds per pak file. Whatever it did hasn't happened since the one time. It seems like it was converting or reorganizing something.

[FakeTruth]

I have no clue

[rs2k]

It looks like the compressed chunk size in the chunk headers changed. MCServer seems to have uncompressed and re-compressed every pak file. The uncompressed size has stayed the same though. Every file is slightly large because of the compression size change. The denotch map converter must be compressing them in a format MCServer can read but doesn't like.

---

I'm using the -lz option when I compile using g++. It looks like it's using "/lib/libz.so.1.2.3.3" and it looks like you're using zlib-1.2.5

[FakeTruth]

That still doesn't make sense. There is no code that makes it loop over pak files and recompress them.

[rs2k]

I'm cleaning up the code now and making it compatible with windows. I'm applying the new bits of information I've learned about c++ lately.

memcpy is so much faster than a for loop. lol.

---

The program is now 20 times faster. It only takes about 1 second per region as opposed to a little over 20 before and over 300 for the PHP converter.


C++ works much better when you use it correctly.


There's still a memory leak. I think it's because I can't delete the NBTData object in between regions. Every time I try I either get a segfault or this:


Any ideas?
[/code]

Code:

*** glibc detected *** ./denotch: double free or corruption (!prev): 0x0000000000c5d580 ***
======= Backtrace: =========
/lib/libc.so.6(+0x775b6)[0x7fc6902d25b6]
/lib/libc.so.6(cfree+0x73)[0x7fc6902d8e83]
./denotch[0x409f07]
./denotch[0x405e3e]
./denotch[0x403669]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7fc690279c4d]
./denotch[0x401fc9]
======= Memory map: ========
00400000-00421000 r-xp 00000000 08:11 14                                 /media/ssd/mc-server/mc-server/converter/denotch
00620000-00621000 r--p 00020000 08:11 14                                 /media/ssd/mc-server/mc-server/converter/denotch
00621000-00622000 rw-p 00021000 08:11 14                                 /media/ssd/mc-server/mc-server/converter/denotch
00c54000-00cb2000 rw-p 00000000 00:00 0                                  [heap]
7fc688000000-7fc688021000 rw-p 00000000 00:00 0
7fc688021000-7fc68c000000 ---p 00000000 00:00 0
7fc68fd5a000-7fc69025b000 rw-p 00000000 00:00 0
7fc69025b000-7fc6903d5000 r-xp 00000000 fb:00 44433761                   /lib/libc-2.11.1.so
7fc6903d5000-7fc6905d4000 ---p 0017a000 fb:00 44433761                   /lib/libc-2.11.1.so
7fc6905d4000-7fc6905d8000 r--p 00179000 fb:00 44433761                   /lib/libc-2.11.1.so
7fc6905d8000-7fc6905d9000 rw-p 0017d000 fb:00 44433761                   /lib/libc-2.11.1.so
7fc6905d9000-7fc6905de000 rw-p 00000000 00:00 0
7fc6905de000-7fc6905f4000 r-xp 00000000 fb:00 44433463                   /lib/libgcc_s.so.1
7fc6905f4000-7fc6907f3000 ---p 00016000 fb:00 44433463                   /lib/libgcc_s.so.1
7fc6907f3000-7fc6907f4000 r--p 00015000 fb:00 44433463                   /lib/libgcc_s.so.1
7fc6907f4000-7fc6907f5000 rw-p 00016000 fb:00 44433463                   /lib/libgcc_s.so.1
7fc6907f5000-7fc690877000 r-xp 00000000 fb:00 44433768                   /lib/libm-2.11.1.so
7fc690877000-7fc690a76000 ---p 00082000 fb:00 44433768                   /lib/libm-2.11.1.so
7fc690a76000-7fc690a77000 r--p 00081000 fb:00 44433768                   /lib/libm-2.11.1.so
7fc690a77000-7fc690a78000 rw-p 00082000 fb:00 44433768                   /lib/libm-2.11.1.so
7fc690a78000-7fc690b6e000 r-xp 00000000 fb:00 45745677                   /usr/lib/libstdc++.so.6.0.13
7fc690b6e000-7fc690d6e000 ---p 000f6000 fb:00 45745677                   /usr/lib/libstdc++.so.6.0.13
7fc690d6e000-7fc690d75000 r--p 000f6000 fb:00 45745677                   /usr/lib/libstdc++.so.6.0.13
7fc690d75000-7fc690d77000 rw-p 000fd000 fb:00 45745677                   /usr/lib/libstdc++.so.6.0.13
7fc690d77000-7fc690d8c000 rw-p 00000000 00:00 0
7fc690d8c000-7fc690da2000 r-xp 00000000 fb:00 44433644                   /lib/libz.so.1.2.3.3
7fc690da2000-7fc690fa1000 ---p 00016000 fb:00 44433644                   /lib/libz.so.1.2.3.3
7fc690fa1000-7fc690fa2000 r--p 00015000 fb:00 44433644                   /lib/libz.so.1.2.3.3
7fc690fa2000-7fc690fa3000 rw-p 00016000 fb:00 44433644                   /lib/libz.so.1.2.3.3
7fc690fa3000-7fc690fc3000 r-xp 00000000 fb:00 44433481                   /lib/ld-2.11.1.so
7fc6910b4000-7fc6911b9000 rw-p 00000000 00:00 0
7fc6911be000-7fc6911c2000 rw-p 00000000 00:00 0
7fc6911c2000-7fc6911c3000 r--p 0001f000 fb:00 44433481                   /lib/ld-2.11.1.so
7fc6911c3000-7fc6911c4000 rw-p 00020000 fb:00 44433481                   /lib/ld-2.11.1.so
7fc6911c4000-7fc6911c5000 rw-p 00000000 00:00 0
7fff9fc2d000-7fff9fc42000 rw-p 00000000 00:00 0                          [stack]
7fff9fde0000-7fff9fde1000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted

[FakeTruth]

Yeah there's probably something wrong in the NBTData destructor. I'll look into it.