jabelar

I don't think you understood. Also, the world already had a random number generator so no real need to create a new one each tick. Next, you don't need to do anything with chunks. World is able to set blocks and get blocks directly from the world coordinates. So I think your code should simply be (assumes you have event parameter from WorldTickEvent handler method):

I believe that the saves are sort of triggered by setting the chunk's isModified field to true. So I think you're safe in terms of asynchronicity if you do your substitutions then set chunk to isModified at end -- it should then save the result of all your subs.

The math you're doing is extremely crazy. Why are you doing all that? That one hexadecimal number you're adding is probably like way outside the entire game, it wouldn't be close to the player. Why don't you just use the randX and randZ and add those to the player position. That's all you should need for random position near the player. If you insist on doing that crazy math, put a system console statement after every line that prints out the value calculated and check that it is what you expect.

It will return true for any class that extends World as well, like WorldClient. Why do you think only server-side?

Well, the getDrops() method is the one that determines the drops. Your code in that is a bit weird. First of all you get the drops from the super method. That will already have stuff in it. Is that what you want? Then you make a random where you check whether world is instanceof world -- that is a useless check since it is always true. Then you make yet another random with Math.random(). Lastly, the age needs to be greater than 7 otherwise the drops won't change.

I don't know the answers for sure, but you're generally thinking the right way about the debug but in modding you also have to figure out exactly what the heck Minecraft is doing. I think one issue is that Minecraft was sort of made to consider the 0, 0 (x, z) position to be the origin for generation. So it isn't quite like you generate the world and then place the player, but rather you generate the world from the player outwards. They add a bit of randomness, but only around that initial position as you can see with the Anyway, it still might be possible if you catch it at the right time. I think in the worst case you can handle the player tick which I think will be late enough that you could simply set the player position. Some of the things you should consider about the spawn points: - It gets saved in WorldInfo instance, which has methods to set and get the spawnX, spawnY, and spawnZ and I think these are world positions, not just in the chunk. - There is a getSpawnPoint() method in WorldProvider class, but I think that give point within the chunk. - There is a setSpawnLocation() method in the WorldServer class, that that is for point within a chunk. Also, in modding it is usually instructive to find something that works similar to what you want and figure out how Minecraft does it. So I'd look at beds and see how they manage changes to the spawn position. But again in worst case, handle the PlayerTickEvent instead and on the first tick (use boolean flag to prevent executing the code on all subsequent ticks) move the player. There might be a slight visual glitch, but at that point in the game the chunk loading isn't that pretty anyway.

Did you get any errors during the build?

Hopefully this isn't too much of a necropost but what do you mean by changing the main class? I have the same problem, not natives folder in the generated build folder He means in your Run Configuration. I don't know about other IDEs, but in Eclipse you can test your code by running it and for that there are Run Configurations where you specify some things about the project (in this case the main class) as well as class path, JRE, JVM arguments, Application Arguments.

What command did you use to setup your workspace? Did you use gradlew setupDecompWorkspace or setupDevWorkspace? You need to use the decomp workspace if you want the source available. If you do that, it should show up as a referenced library in your project with name forge-src

yeah, I think I responded to same/similar question on other thread. For some dumb reason, the getUnlocalizedName() is not symmetric with the setUnlocalizedName() because you'll get back the name with "item." prepended to your name. So I usually add a .substring(5) to the getUnlocalizedName() to get just the name.

Yeah, I know you can't get away without doing a binding for the render, but thought maybe the binding would still trigger something different if ResourceLocation was refreshed (same key or not). But looking through the code it like you said -- the binding should be same if ResourceLocation key is the same, whether or not the ResourceLocation is created freshly.

Sure, it looks like it handles avoiding the loading if the mapping is already present, but there is still a GL binding occurring repeatedly. Based on this thread, and the numerous hits about gl bind texture performance issues when I search for them, I suspect you do want to avoid binding the texture unnecessarily: https://www.opengl.org/discussion_boards/showthread.php/182629-glBindTexture-has-deferred-processing

The unlocalized name is the "glue" that helps associate everything -- blocks pick up their blockstate JSON based on this, and items pick up their model JSON based on that. Unlocalized names can be a bit funny depending on where you are using it. For .lang file purposes it will have "item." in front and ".name" at end. And if you're referencing something by unlocalized name you might need your "modid:" in front of that. However, if you use the getUnlocalizedName() method for the item, it will have the "item." in front of whatever you set. I find this annoying because I believe getter and setter methods should be symmetric. In other words if you set unlocalized to "myitemname" you would get "item.myitemname" back. So I often use substring(5) to strip that off the front. Anyway, best way to debug unlocalized name issues is to simply print out the string to the console before you try to use it. You'll get a sense of when it is a fully qualified name, just the simple name, or something in between.

In the OP's code at top of thread he's using the one big string, which I would assume needs parsing. It may not be the ResourceLocation itself but he's using that for binding the texture every time he renders as well. So that must do some sort of file access or at least cache access, right? Basically his code is binding a "new" (really repeating the old) texture every render tick.

What do you mean by not working? The items show up in game but have pink-black checkered model? Or they don't show up at all? Are you sure your item's unlocalized name matches? "Stone_Sledgehammer". Can you post code for the item as well as the code where you register the item (the item itself, not the item renderer)? Also, I think unlocalized names should be all lower case, so you might want to see if that helps. Otherwise, I can't see anything wrong -- you understand what is needed and it looks correct.

A lot of beginning programmers make the mistake of overusing the new instantiations on the fly. Don't keep creating the same thing over and over as it both affects perf (especially in the case where it includes file access) and also memory (as mentioned by Draco). If you've already got an instance, use it. If you know you need an instance over and over, make it a field for the class, or at least instantiate it outside the code that repeats.

There may be another way, but if you look at the alpha field in FontRenderer it is set by taking some of the bits from the color passed into the drawString() method. There isn't any other manipulation of the alpha field (which is private and doesn't have a setter method). So I think my suggestion should work -- create a color that includes the alpha.

I think you should set the color again right before the font render and change the alpha value passed into the color (the last parameter in the color 4f function)

It is important to always use all lower case for the modid as well as the unlocalized names. I think it has to do with file system compatibility. Also, in your example there is still a "yourItem" that you need to replace with the steel ingot item name.

I haven't done a lot of world gen stuff. I've done a lot of structures, but only as something that appears later in the game -- like is auto-built by an item. So I'm not sure how to control the order. But generally, in terms of being on top of the ground, you need to think through the logic of your code -- currently you just set a Y height for the starting point randomly. Obviously that could have some weird effects. So the Y should not be random. I know that after things are generated, there is a getHeightValue() method in the World class which gives you the position on the top of a x, y position. Putting this together, assuming your structure is generating after the ground, you would pick a random x and random z but then set y to be world.getHeightValue(x, z).

I'm not sure but in your renderTileEntityAt() method instead of creating new ResourceLocations each time, put them into a field during the constructor. ResourceLocation I expect does file access which would be an unnecessary perf hit. P.S. Are you an NVIDIA fan? (I am too.)

You just have to think through the math and logic to understand it. In this case there are two things wrong. In the for loop the number 10 represents how many structures will generate per chunk. So in this case you're getting 10 per chunk. There is randomness in the position but not in the generation so I think there will always be 10 per chunk. Next you need to consider the size of your structure. A chunk is only 16 x 16 (x and z) and it looks like your structure is around 35 x 35. So your structure can't even fit into one chunk! So you definitely don't want 10 per chunk... Instead what you need to do is to use a random chance of even calling the spawn so it is only called every several chunks. I'm not sure what the average biome size is, but I feel it is something like 20 chunks per side or something like that. So that means 400 chunks per biome and you want 4 structures per biome so you want a 1 percent chance of generation per chunk. So I would get rid of the for loop entirely -- you definitely don't want multiple per chunk. The spawn function should just be called if a rand.nextInt(100) < 1 (gives 1 percent chance). I hope you understand my points...

I think you also need to register the item renderer. In the init handling method of your client proxy, you need something like this: RenderItem renderItem = Minecraft.getMinecraft().getRenderItem(); renderItem.getItemModelMesher().register(yourItem, 0, new ModelResourceLocation("yourmodid:" + yourItem.getUnlocalizedName().substring(5), "inventory"));

I don't see a version of ray trace that does that, although the world ray trace function does have a flag for tracing through liquids. I think you'd need to create your own raytrace by copying the vanilla code for that method and modifying it to ignore blocks. It looks possible. The ray trace method basically just calls this function in World: So I would just copy that and go through it to make sure you understand it (I usually refactor/rename the fields so it is easier to read, as I learn what each field does) and then the modification necessary should be pretty obvious. The liquids flag is probably instructive as it performs a similar function (i.e. ignore liquid blocks).

At this point I think you should just do standard debug process. Trace the variables' behavior to ensure it is following your expectations. You can use debug mode of your IDE or just put a bunch of System.out.println() console statements. Also I want to point out that logically it is possible that the particles work and the models don't if there are multiple places where the block's state is updated. For example, during the random tick you directly read the is burning and act on it, so you know it will be good at that point. But maybe something else comes along and changes it before the renderer gets chance to start processing the model.