# Convenience method to load a numbered world from the saves folder.
world1 = mclevel.loadWorldNumber(1);
# Find out which chunks are present
chunkPositions = world1.presentChunks
# presentChunks returns a list of tuples (xPos, zPos)
xPos, zPos = chunkPositions;
# retrieve an InfdevChunk object. getChunk is a special method;
# it will load the chunk from disk, decompress it, inflate the NBT structures, and unpack the data arrays for you.
aChunk = world1.getChunk(xPos, zPos)
### Access the data arrays of the chunk like so:
# Fire to Leaves.
aChunk.Blocks[aChunk.Blocks==world.materials.materialNamed("Fire")] = world.materials.materialNamed("Leaves")
That's a bug, and you have the right fix. That codepath is the one for copying directly from one infinite level to another without an intermediate buffer. The functionality isn't exposed anywhere in either program so it never gets used. You might notice it accesses the blocks one by one instead of doing a mass block copy via numpy. This is extraordinarily slow and my dread about rewriting it in numpy is why it's still in such bad shape.
I just have an idea to give, hopefully someone will run with it now that there's such a nice library. Make it dump the text off signs? It could just put the coordinates, and the 4 lines of text. I'd love to see all the fun sign text people have made on our server.
I hate it when clueless newbies post begging posts, thus flaunting how clueless and new they are, but:
>>> import mclevel
Traceback (most recent call last):
File "<pyshell#0>", line 1, in <module>
File "C:\Users\bbot\Downloads\pymclevel-20100920\mclevel.py", line 112, in <module>
File "C:\Users\bbot\Downloads\pymclevel-20100920\nbt.py", line 23, in <module>
from numpy import array, zeros, uint8, fromstring
File "C:\Python27\lib\site-packages\numpy\__init__.py", line 136, in <module>
File "C:\Python27\lib\site-packages\numpy\add_newdocs.py", line 9, in <module>
from numpy.lib import add_newdoc
File "C:\Python27\lib\site-packages\numpy\lib\__init__.py", line 4, in <module>
from type_check import *
File "C:\Python27\lib\site-packages\numpy\lib\type_check.py", line 8, in <module>
import numpy.core.numeric as _nx
File "C:\Python27\lib\site-packages\numpy\core\__init__.py", line 5, in <module>
ImportError: DLL load failed: The specified module could not be found.
What the hell is happening here? Installing numpy was an enormous pain in the ass, requiring a registry edit, since apparently python doesn't set registry keys right on 64-bit versions of windows? Previously numpy just refused to work at all, but after the registry edit, it didn't install correctly?
Edit: Nevermind, eventually found it, in TileEntities. Just have to construct a new NBT_Compound with the appropriate stuff to add a sign with a message. Thanks again!
(original post follows)
Hey, this is a great package btw - I'm enjoying playing around with it (writing a little converter to load maps from Eschalon into Minecraft). I did have a quick question, though - is there a way to get at (and set) the text on signs? I haven't yet found anything in the API which looks right. Perhaps it's just something I need to do with the block Data structure?
Oh, and I should mention I'm just using the Python API, not the CLI tool.
but was not at all looking forward to writing the lighting calculations
And even if you looked at MCInfdevLevel.generateLights, you might find it impenetrable without a little Numpy experience. That function took a lot of different tries to get right. In its current form it can relight as many chunks as you want without running out of memory, overflowing a stack, or entering an infinite loop, but at the cost of using a ton of extra CPU power relighting blocks that don't need it.
Major159: I had to add c:\python27\ to my PATH in order to get the regression tests to work. Windows is silly that way. The win32com is supposed to be an optional dependency, too, but maybe I messed that up.
I started tinkering with this tonight in hopes of using it to generate a new map. The example from the documentation doesn't quite work, though. Something about a conflict between sets and tuples and lists (oh my) but I haven't used sets very often so I don't know exactly what's wrong.
[email protected]:~/git/pymclevel$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mclevel
>>> world1 = mclevel.loadWorldNumber(1)
>>> chunkPositions = world1.allChunks
>>> xPos, zPos = chunkPositions
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'set' object does not support indexing
Hope that helps! If you do intend for this to be useful for generating maps, I would suggest making something like the demo script written by BagelMann in his JCraft tool found here: http://www.minecraftforum.net/viewtopic.php?f=1022&t=147476 -- that would be very, very handy for me and for others I imagine.
Sorry, it's not really obvious how you create a world. You can use MCInfdevOldLevel(filename, create=True) to do it:
def __init__(self, filename = None, create = False, random_seed=None, last_played=None):
Load an Alpha level from the given filename. It can point to either
a level.dat or a folder containing one. If create is True, it will
also create the world using the random_seed and last_played arguments.
If they are None, a random 64-bit seed will be selected for RandomSeed
and time.time() will be used for LastPlayed.
If you try to create an existing world, its level.dat will be replaced.
mathuin: Yes, I changed presentChunks to a set type instead of a list, but you should be able to create a list from it or another structure depending on what you need to do. The intro text didn't get updated after I did that. Look for a push with a bunch of new docs soon.