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.
Also, according to this: viewtopic.php?f=1036&t=330219, there is an NBT tag called "raining" in level.dat. Could you maybe make it possible to edit it with this library? Something like:
BetaWorld world = BetaWorld.Open("C:\\World1\\level.dat");
world.Level.Raining = 1; //??? it's an integer
world.Level.Save();
Yes, I noticed these new attributes (there are 4 of them) about a half hour ago when I was looking into your bug. They'll be added to the spec in the next release.
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.
Since Level is part of the INBTInterface, then with a few extra lines of code I think your tool should be able to support both Alpha and Beta worlds. Not that there's a big market for that support.
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:
using System;
using Substrate;
namespace Test
{
class 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;
world.Save();
}
}
}
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.
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.
http://code.google.com/p/substrate-mine ... loads/list
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
It causes me to spawn under the world, so I die. Am I doing something wrong? It seems to be reseting the player's position to 0,0,0. Help?
When I do:
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.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
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.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
I have built and ran the following program:
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.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
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.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
NBToolkit is also in the source repository and can serve as an example of some more advanced usage.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Yes, some of the work I've done in the last month was in preparation for supporting schematic files.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Also, Nether is actually dimension -1 :smile.gif:
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
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.]
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
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.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
ChunkManager cm = // some chunkmanager
ChunkRef cr = cm.GetChunkRef(10, 20);
ChunkRef cr2 = cm.CreateChunk(10, 21);
cr2.SetChunkRef(cr.GetChunkCopy());
The only problem is that CreateChunk will create a (blank) physical chunk that will just be discarded. I'll probably add something to ChunkManager.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate