Minecraft Forums

I got more bugs.

Sheep/other creatures spin in circles when standing on fence posts. Sheep/other creatures can still jump onto fence posts. If you can't jump onto them, mobs shouldn't either.

The new biome id in f3 sometimes shows the wrong biome type in SMP until you log off and back on to the server. Unsure about SSP.

I have a screenshot but it isn't uploaded. It was consistantly showing a taiga biome as a jungle in one specific area and upon restart it changed back to taiga.

Another issue is that the biome id defines an ocean by how deep a body of water is and not by how large it is. There are small bodies of water labelled as ocean.

Unsure if it's a bug or not. But sl while I assume to be sunlight doesn't change as long as the sky is exposed to you. Depth doesn't matter. Hmm it probably isn't a bug, but really does sunlight retain its brightness indefinitely down a small hole?

Quote from DocGratis

OK so say you built an new generation software that could generate new biomes (A) and basically had the previous biome code (B ).

So every time it went to generate a new chunk it would use biome A. But how would it know when to blend the code for B?
The current system doesn't read the loaded chunk, it just makes new chunks when needed.
So everytime a new chunk was needed it would have to see if the last chunk was B biome. And if it was it would try to blend.

My thoughts were that upon game join, the map would have data indicating when it was created, and that would initiate the check . The check could be done in many ways. I think I would try mapping out the terrain of the new terrain gen without showing the terrain as loaded with the new terrain and if biome B of terrain gen B doesn't match what it would be if it were biome A, then adjust to smooth the terrain. It would keep in mind the height ranges of each level in the border generation.

After it has been written to file, the game shouldn't care about what gen it is when it has to load it, because the terrain doesn't need to be generated. Only new chunks require generation procedures.

But if you were deep inside of A biome it would be wasting time checking chunks to see if they were old.

If old chunks surround an area too small to mesh, it will generate old gen terrain or attempt to erode the area to fit. You can't really expect miracles in this situation.

And what if some of these chunks were from C or D biome code?

I hadn't really considered multiple gens. My thought is that it would mesh according to the terrain heights along the border and according to the biome somewhat. This would be present in multiple gens.

Your suggestion about having it check all the borders would be done when? On conversion?
So you load an old map.. it spends a LONG time going all the way around your world, building a smooth transition (I would think this would take say twice as long as Anvil conversion took.. and people are having issues doing that conversion.

Nope. I would make it happen during the new chunk loading process. It would be as if the chunks were taking an excessive time to generate.

And then if you don't walk to a particular boarder (say the north side of the map), and then a new new biome system comes out.. what will it assume the north edge of your map looks like? Biome A? A blend of A&B?

Good question. It all depends. This mesh would be fully dynamic. It would go through several checks that will ultimately tell whether it will mesh an incomplete biome, or map out the rest of the biome with the proper gen.

It is easy for humans to fill in the gaps, it is not so easy to build a software model that does it for you..

I realize that, but it isn't impossible to get a mesh within a decent margin of error. Minecraft's chunk system provides a good basis to make it happen. Imagine an unloaded chunk, surrounded by loaded chunks. Each chunk side is completely flat, only the block heights matter. I would implement some way to determine which side(s) the chunk would be meshing from and take the opposite border heights and then check whether the mesh can mesh at 16 blocks, if not go to 32 blocks. I would probably check so many blocks outward. I'm a little unsure about how it would handle a loaded chunk x number of blocks out, but I imagine in that case I would just have it use gen A. If it can't mesh then it will just generate the first detected gen. It will create a chunk border, but that's because there was nothing the mesh could do to fix it. But anyways my point is as long as I have two points of reference the points in between can be adjusted. It maybe not look pretty, but the larger the mesh, the easier it is to create realistic terrain.

Oh and yes I plan to tamper with the generator when the API comes out. I want to at least get this idea started with simple block meshes, and then include unloaded(as in blocks aren't visible in game) seed gen arrays, and work from there.

It's not a sign of Secret Friday updates, it's a sign of the release containing game-affecting bugs that people wouldn't live with for an entire update.

Take note that patches are almost always bug fixes, or small changes. I don't see the big deal really and you shouldn't either.

Well it is by no means impossible to fix. I will go as far to say it isn't really that hard to fix the issue as it's only smoothing. It wouldn't be hard to find the height values of biome A and the going to be generated biome B biome height values. (Biome height A will always be the same when produced in algorithm A and the same goes for biome B in algorithm B. Once you have these two values along with the biome types you create a proper terrain mesh over the border until, biome A terrain height and biome B terrain height at chunk edge is smooth. It would take recalculating, which would make the transition very performance intensive, but after the initial application the result should be even.

This would work for most small generations. The extreme generations are unfortunately harder to code. The transition for any biome to biome would probably need particular seed elements. For example, if the old biome terrain would make an extreme mountain biome with algorithm A, then it would need to render that biome using algorithm A until algorithm B which is less extreme terrain can take over. It would then have to check all of the biome borders. A seed check for algorithm B can efficiently bring up biome types. The biome types don't need to form in order for identification since seeds form identically. A terrain edge is mapped around the border and then the game attempts to recalculate transitioning without the need to write those chunks to file, and the entire chunk border that would touch the transition biome would be sent to an array(list). Game will then attempt to calculate a block mesh that can match up with the height properties of the border within a margin of error. Algorithm A will take priority over algorithm B, and the transition mesh made by algorithm C will take priority over algorithm B. Any values that are too extreme will be eroded to fit.

The method of erosion can be simple or complex. It all depends on the degree of detail of the transition.


This probably could not fix 100 percent of cases, but every bit counts. It doesn't need to be as complicated as my idea above. It's just how I would attempt to tackle it. I would give algorithm A priority, and then use a separate algorithm to calculate a match and anything that cannot be matched I would erode to look like it matched.

They could also add a transitional biome, that would form between two types of biomes during a transition. Basically it would form according to average height 1 and average height 2, and them form to make the difference.

Only slight performance iissues here and there. Nothing unplayable. Allocate more memory to the game if you're having issues.

My thoughts. Nether worlds aren't coded to update to anvil from older maps or are bugged so that they don't convert. That means your old Nether is still there, it just isn't compatible with your anvil map. Remember that Minecraft keeps your old formatted worlds.

Jeb most certainly has his hands full with 1.2. So many interesting bugs. It reminds me of Beta, but in a good way.


Anyways It's most certainly going to be the API update, but that doesn't mean that we wont receive weekly AI tweaks and new features along the way. The end goal will just be the API. I just hope Jeb will decide to fix the major bugs in 1.2. If he does oit the Notch way and makes people wait until 1.3 to get a stable game, then people are going to RAGE.

I wouldn't build near the 256th level if I were you. That's the only game breaking bug I know of. Make sure you back up older world's though. There's some issues with older worlds.

You know the consequences of updating. If you didn't backup your map like it was suggested on the main page, then it's your own fault.

I have a bug to report.

http://puu.sh/j44m


If you move up where the lava slants a certain way you can see clear through the lava and I even found a place to stand in the lava. The second thing is that grass doesn't go away when lava flows over it. Not even after some time has passed will it ever turn back into dirt. The lava doesn't affect it.


Also in certain spots in the lava, the lava sound will turn into continuous sound. I don't really know why.

There's a difference between a nerf and a bug. If they don't spawn at all, then it's obviously a bug.

I don't think it even matters really. An easy to handle mechanic wouldn't make the game worse, only add depth. You could say that the extra depth is unnecessary and it probably is. That's a valid argument.

There isn't a lot of point to it... It could make your food go down faster when you're thirsty, and when you're really dehydrated you can't sprint and the FOV starts to change. It would have some nice dehydration effects.

Those effects wouldn't be hard to remedy. either find some water source blocks, or drink a bottle or two. Drinking would only restore so much, while submerging yourself would restore gradually like health regen.

Why does it have to be super challenging to restore it?

._.

Besides two buckets take up two inventory slots. Water is everywhere, it would never be a challenge to restore thirst. They shouldn't try to make it difficult if they ever added it.

I thought that thirst could be restored when floating in 2 blocks of water.


Really I wouldn't mind this if Jeb allowed the idea above as an alternative to drinking.