As promised, this version will break compatibility with most existing applications. The Chunk/ChunkRef objects have been reconfigured to contain separate BlockCollection and EntityCollection objects, which will make it easier to extend a common interface to other map types such as classic or mcschematic. Fixing existing applications should be relatively easy, most changes will be of the following form:
chunk.GetBlockID(x, y, z) -> chunk.Blocks.GetID(x, y, z)
All block-specific operations are now accessible via the Blocks property of chunks, and entity-specific operations are accessible via the Entities property.
There have also been other bugfixes including the bugs mentioned above, and some more lighting fixes, although I'm sure some new bugs have also slipped in. The caching back-end for chunks has also been updated.
Have you verified the values of x, y, and z? Have you verified where the spawn is being placed in MCEdit, or the values of the level.dat file in NBTedit? I don't disbelieve you, but it might be possible that my tool is doing everything correctly and Minecraft doesn't like the particular values you're feeding it and defaults to weird behavior.
I get the intended behavior of spawning ~5 blocks above a flat surface. In this instance, I am not creating a player. Are you creating or setting a player? If you are, you also need to set the player's position. Creating a new player object (as opposed to using Level's SetDefaultPlayer) will initialize the player's location at 0,0,0, which actually places them below the map.
Please post or PM me the full source code you are using, so that I can get to the bottom of your problem.
FlatMap is my "create world" example, and it works correctly for me. If you are deriving from that example, I need to see exactly how you are deriving from it to determine why world creation might be failing.
That is not a complete program. That will not compile. What is spawnX/Y/Z and where do they come from? I really must insist that you give me the actual program that you compiled and ran, or there is no way I will be able to account for any subtle behavior causing your failure.
I have built and ran the following program:
static void Main (string args)
BetaWorld world = BetaWorld.Create("F:\\minecraft\\test2");
int x = 20;
int y = 65;
int z = 20;
world.Level.SpawnX = x;
world.Level.SpawnZ = z;
world.Level.SpawnY = y;
Running the code produced a region folder and a level.dat file in test2. The level.dat contains 9 entries, and excludes a player entry. I assume from what you have described earlier, that you are not seeing a level.dat file being generated. I assume you were not expecting a bunch of default chunks to be generated like when you create a new Minecraft world, but if that is what you were expecting, then this library will not do that.
Please run the code snippet, and see if it creates what I just described. If it does, then please give me a complete, compilable program demonstrating that a level.dat is not being created.
All the examples do not exist yet. If you check the repository, I believe 5 of them are up now.
The separate lighting steps are important. The RebuildLight functions of the relighting API are only valid on an unlit chunk, or a chunk that is already correctly lit, but hasn't had new light sources calculated in yet. I also can't just reset the light in the same chunk that you're rebuilding the light on, because relighting a chunk also affects its 8 adjacent neighbors. The UpdateLight functions similarly require an already correctly lit map, and are used to add OR remove an individual light source. By default these functions are called automatically when you change blocks, but you may wish to disable that behavior if you plan on changing lots of light sources, at which point rebuilding the lighting for the entire chunk is more effective. There are additional lighting functions you'll see used in NBToolkit for stitching light between two chunks, which you need if you only relight a subset of chunks.
Efficiently relighting maps without potentially loading all of the chunks into memory is a tricky problem.
Thank you. I'll look into these. Are you planning to add support for schematic files? That'd be very helpful for all kinds of programs.
About my sinus world gen, while landscape looks nice at first glance, it repeats itself quite quickly... but I have ideas to improve that too. Still need to figure those caves out, too :wink.gif:
Yes, some of the work I've done in the last month was in preparation for supporting schematic files.
I always assumed -1 was a funny joke for an underworld.
Could you send me the region file which caused the exception? An out-of-bounds exception probably means I'm violating some other assumptions and it's easier to debug an actual example.
Lighting is still not perfect, I've discovered other areas where light fails to recalculate properly, especially with a large number of light sources like a lava pool. [EDIT: or not. I just wasted an hour tracking down lighting bugs only to realize relight.exe was being artificially constrained to a 20x20 chunk area. Fu.]
This is a relatively minor release that fixes a bunch of lighting bugs. Lighting is so goddamn tricky. I've also added weather attributes to the level object from beta 1.5. If I promised anything else for this release, it's not included, it'll have to wait until the next one.
@aXu, try this build before following up with the region file I requested.
Players don't have their own spawn point by default (it's set by beds, after all). The code requires you to set all of the spawn parameters (X, Y, Z) for it to save. I probably won't change this behavior because player objects in general are not bound to any particular level file.