Leaderboard

i don't understand much of minecrafts chunk generation code, i implemented my own version. If you want to learn about manipulating noise in general you could dive into the subject of computer graphics, try the chapter about generative design from https://thebookofshaders.com/ .

you write your blocks into the chunkprimer after you have copied it to the chunk, you call setBlocksInChunkIsland to late. Put it directly after "this.setBlocksInChunk ..." or after "this.biomesForGeneration = ..." if you want to manipulate the biomes. Edit: I am not shure if the world object has the biome information you need at this point, use biomesForGeneration instead, you have to calculate the coordinates manually since biomesForGeneration is an one dimensional array. Edit 2: Also you should not check for the right biome and instead just update the biome information when a block is set. [...] primer.setBlockState(k2, l2+upperScale, i3, iblockstate); if(iblockstate != Blocks.AIR.getDefaultState()) { this.biomesForGeneration[k2 + i3 * 16] = KCore.instance.FloatingIslands; //i am not shure about the coordinates it could be i3 + k2*16 instead } [...]

Ok, but it would still be possible to find out at which positions the biomes need to be changed.

If there are no floating stones then you probably don't want to change the biome there, i don't see the problem.

This is not a forge issue, it is a user issue caused by ignorance. Use the Forge installer. All you have done so far is phone the doctor and tell them "it hurts". Now you need to provide actual information. As for the fact that you don't have the forge jar:

I am no expert on this, but i would propose to get rid of the if(biome == KCore.instance.FloatingIslands) line. Floating islands will be created everywhere but there shouldn't be any chunk problems with chunk borders. If you really need to have a floating island biome at these positions then let the setBlocksInChunkIsland method return something telling you if there was at least one non-air block set, so you can fix the biome.

As you know, for any given block, only states returned by getStateFromMeta(int) are stored to disk. Additional states returned by getValidStates() are not. Your best bet would be to see what properties in the set of states returned by iterating through metadata 0-15 never change (and do change in getValidsStates()). All 16 states returned for the dirt block from getStateFromMeta for instance will be snowy=false, as that is not stored. This will not be true in 1.13, where blocks will not be limited to 16 (storable) states. Presumably every possible state will be stored. I'm not getting the pushback here. His mod deals with stored world data files, and the integers are still heavily used in the anvil files. This will change of course, but is totally applicable for a program that runs without even having Minecraft (with its nice int to blockstate mapping) running. If you're going to deal with savefiles, there's going to be some numbers involved. Of course things will get more complex in 1.13! Which will of course include the numbers to blockstate mappings in the savefiles, but those are not yet in 1.12 and below, so again I really don't get the pushback against using the numbers. You simply have to when dealing with (generating, editing) savefiles without Minecraft running.

?