jabelar

Yeah. What I ended up doing was to actually have my Y index increment over each tick, rather than loop through all Y in one tick. That kind of spreads the lag. I previously made it only do one dimension at a time per tick (i.e. both the Y and Z loops were incremented over ticks rather than within a tick) but at that point the total time to make the structure gets pretty long -- a 20 diameter sphere would take 400 ticks = 20 seconds. Which was too long, but the good thing was there was no lag at all. So it seems to be a balance.

I used to think that, but I've been doing a lot with structure generation lately and found that with very simple code (just loop through an array and place bocks indicated) it can create perceptible lag on structures of any decent size. I actually changed my code to only do one layer per tick in order to improve this. I think a sphere the size he's showing could actually show a bit of lag. Generally though that won't be too noticeable if it happens during chunk generation because players are used to some lag from that, but if you generate the structure in response to player action (like using a tool), it can be noticeable. Anyway, I was surprised that it could lag, but I think the thing is that the volume of a structure gets large very fast -- a sphere as large as shown in the OP's picture has 5000 blocks! And I think the block placement requires fair bit of processing as well as client server sync notification. Just giving my observation...

Like Eternaldoom said, this affects the Rendering, this means if i set the Y-Bounds to 2.0F u will get a block that is 2 blocks high and seems to be bugged when you still using normal textures. Are you guys sure about that? If you follow the code the only relationship to rendering seems to be that if you have a side that has width 0 it won't render the side, and the selection box (the thin black box when your mouse goes over a block) will be affected though, but that is sort of the point because it shows you where you can hit the block. Also, I thought the original question above was to enable colliding with the block. In that case you should be making the bounds smaller, not larger. Why are you trying to make the bounds 2.0 high? Anyway, if you want a more flexible way of controlling the collision box, @Override the getSelectedBoundingBoxFromPool() and possibly the addCollisionBoxesToList() methods. The latter is interesting because you can do things like change the collision box depending on the entity type (because entity is passes as parameter). These definitely do NOT affect rendering.

What do you mean by "bounce off"? You mean it is blocking you like other normal blocks do? Or is it behaving differently?

I'm not certain of the timing of the burning processing versus the damage from fire. For example, I think while you could extinguish the flame with LivingUpdateEvent, I suspect that other code will run that will detect the light and set it on fire again and then process the damage. Again, I'm not sure, but I think the LivingUpdateEvent will fire before other onUpdate() code is run, so in this case the extinguishing may get undone. It may be more controlled if you process both the RenderLiving event (to make sure it doesn't display as on fire) and also the LivingHurtEvent (to make sure it doesn't take damage from fire). As long as you don't see fire, and it doesn't take damage from fire, I think that counts as not being on fire...

Yes, but that is already decided as the metadata index. That is why you use an array-- you register an icon for each growth stage. No reason to use bit shifting to figure it out. If you've extended the metadata so that other bits are used, then maybe you'd want to mask the metadata first. Other than that, metadata gives the icon directly. General rule of thumb is that the simpler code is, the less chance for bugs.

You can just make a public static boolean field in your mod's main class, called something like structureAlreadySpawned. Initialize it to false, and then whenever you call your generate function check the value and only proceed if false. Set it to true once the random chance happens and you spawn it. Make sure to save and load the field in your world save data.

Why is your getIcon() method so weird? And you really didn't look at my tutorial which has this all correct already. I think you should just need this: public IIcon getIcon(int side, int metadata) { return this.iconArray[metadata]; }

With structures, i tend to build them in multiple passes. First I do blocks with no metadata, then I do the blocks with metadata (and yes you need to get that right if you want your beds and doors and stuff right and facing right direction), then I do some special blocks ("decorations") that attach to other blocks (for example trip wires, because if you place them before the floor blocks beneath them they will end up as entity items instead of trip wire), then I place any items that I want inside any tile entities.

I have a tutorial for custom crops. The growth stage is controlled by the block metadata. There are some functions with names like func_149853_b() that actually increment the growth stage. For displaying the growth stage it uses the getIcon() method. Of course you need to registerIcons() previously. I prefer to put my icons in an array and then index them based on the metadata value. Anyway, look at my tutorial and see if that helps. It explains a bunch of this stuff.

The best thing to do is to trace the code execution to figure out what it is doing. You can either make most of the AI custom and add System.out.println() console statements to give information about the exeuction, or you can run Eclipse in debug mode. But basically you need to watch the functions and see if the shouldExecute() method is being called for each AI and if it is not being called then figure out why (i.e. usually another AI with lower priority already running) or if it is being called but returning false figure out why (print out the conditions for the shouldExecute() and figure out why they are false. Basically, when code does something you don't expect and review of the source doesn't give any obvious ideas then next step is to trace the operation of the code while it is running to see why it is doing what it is doing.

I have a custom mob and I like to make the collision map match the model size so in this case a good size would be 1.5F. I mean for the custom entity I use setSize(1.5F, 1.0F). This makes the width/depth of the collision box to be bigger (and this can be confirmed by pressing F3+B during game to see the bounding box). Anyway, the problem is that when the mob attacks it now goes around and around the player really fast, and just keeps going around and around. Note this is in a flat area of the world, so isn't a matter of having trouble navigating around blocks. Basically the pathfinding seems to never quite get where it wants to go (the player attack target) and so keeps moving the entity. I can of course use size 1.0F but it isn't really what I want. 2.0F seems to work better but also not what I want. I'd like to get 1.5F (and other fractional sizes) to work. Anyway, I looked into the navigator and path finding code briefly but couldn't see any obvious reason it would have trouble with it, although there is some math floor operations and such going on. Anyone else experience this before?

A stack of "blocks" is really a ItemStack of ItemBlock. Because ItemBlock extends Item you can use the setMaxStackSize() method. So if you make your own custom ItemBlock you can change the stack size. However, the maximum in the game seems to be 64. If you try to make it larger, then weird things will happen. There are other threads on making stack larger than 64 and while it is probably possible it is a huge amount of work because you have to change all the inventories, the way inventories display, etc. to custom.

What's going wrong -- are you getting errors in console indicating it can't find the sounds? You probably need to check that you're using the new JSON sound mapping method. I have a tutorial on this here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-organizing-and.html

I explain the mutex and priorities a bit in my tutorial here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-custom-entity-ai.html

Well, you've given them both the same priority. I'm not sure but I assume the mutex bits in both AI classes (leap and arrow) prevent them from both running at the same time. So if the entity is far away from player it will choose to do arrow before it chooses leap because it only leaps when it is closer. Once it starts shooting, it will prevent the leaping. If you want it to change the priority of leap versus arrow based on how close it is to the player, I think you'll have to make some custom AI class. I'd probably combine them both into one AI -- and in that code you can have a field that keeps track of whether you want to leap or do arrow and such. To put it another way, the AI task lists give some control but not full control over how two AI tasks will work together. If you want to specifically control which AI task should be done I think combining them into one and using your own logic to decide is way to go.

The resource manager stuff is good, except it assumes that the "asset" file you want is only to be available on the client side (IResource is client only). For textures and sounds that is probably fine, but for example I put custom text files for things like structure generation into my assets and need them on the server side. I think my original "standard Java" answer is the more general answer for reading a file you happen to put in the JAR.

Something like this works for me. Since this contains file IO you'll have to add some try/catch exception handling: readIn = new BufferedReader(new InputStreamReader(getClass().getClassLoader() .getResourceAsStream("assets/my_mod/my_folder/myFile.txt"), "UTF-8")); firstInteger = Integer.valueOf(readIn.readLine()); With this, I'm reading a text file. You'd of course change the my_mod, my_folder, and myFile.txt to match your own assets directory and filename.

Yes, the way I do it is have main methods that handle the FML lifecycle events (pre-init, init, etc) that call proxy methods of same name. The client proxy should extend common proxy and for any method in client proxy, it should have same method in common proxy which is overridden by client method.

To be a bit more detailed, you need to use packets (as mentioned above) so you should implement the simple network wrapper according to diesieben07's tutorial linked above. After that the idea is that in you GUI you don't actually delete the block but instead it sends a custom packet (maybe call it MessageDeleteBlock) to the server and in that packet you would send the coordinates of the block you want to delete. Then in the message handler on the server side, when it receives that packet type, you would set an air block at the coordinates you get from the packet.

I know but the first thing you must learn when using tutorials is to go through every line, make sure you understand them, and then edit them to suit your mod. It is rare that copy and paste just works. So always go through every line very carefully. Have fun modding!

You have several mistakes in this line: @SidedProxy(clientSide="com.hurleyboarder.main.TutorialClientProxy", serverSide="telinc.tutorialmod.common.TutorialCommonProxy") First of all, based on your package declarations, the client proxy is in com.hurleyboarder.Main with a capital "M". Secondly, your common proxy is in a totally different package than what you wrote. It is also in com.hurleyboarder.Main not telinc.tutorialmod.common.

Yeah, I was working on the same thing today. The thing is that a "collision" with a block doesn't really occur because the pathfinding and movement code prevents actually colliding (overlapping) with a solid normal block. So the idea of a "collision" is really that the block allows the entity inside it's 1 cube space. Basically things like fire and portals allow "collision" but that really means you can move into the block space. Anyway, there are two ways to solve it. The first way is to change the block bounds with the setBlockBounds() method to be a bit inside the actual block -- this allows an entity to move inside the block space and "collide". This won't change the rendering as far as I can tell, except if you hover cursor over the block the thin black outline will show the bounds. The second way is to put invisible vines (or similar climbable block) next to the surfaces you want to climb. The problem though is that to control the generation you might need a tile entity, the invisible vines will take up a block and also if you try to destroy the block you'll have to dig through the vines first. If you only want to have a special entity climb it, then you can do it differently -- like you said the spider can climb regular blocks. But it would be very difficult to change all entities to climb like that. Anyway, I think using the setBlockBounds(0.1F, 0.0F, 0.1F, 0.9F, 1.0F, 0.9F) is the way to go. At least it is easy and gets the job done fairly well.

I'm still suspicious of your write NBT code. Did you know that ByteBufUtils has a writeTag() and readTag() method that allows you to directly put NBT into and out of a message buffer? I suggest trying those.

I think the problem is probably with your output stream. You keep creating new ones but never close them. In you write NBT code you should add a finally section to your try-catch and close the stream there.