Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

MrCaracal

Members
  • Content Count

    80
  • Joined

  • Last visited

Community Reputation

17 Good

About MrCaracal

  • Rank
    Stone Miner

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!
  1. Ignorance, I suppose. I didn't look at the code before asking.
  2. There are methods for damaging ItemStacks that don't require an Entity as a "damage dealer". ItemStack damageMe; damageMe.attemptDamageItem(amount, rand) // Parameters are an integer quantity of damage to deal, and a Random object to use. Don't forget to call markDirty() afterwards!
  3. A chunk is 16x16 blocks, so if you multiply the chunk coordinates by 32 before passing them to your generate[dimensionName] methods, you'll actually be generating very far away from the intended chunks. Consider the following line-by-line walkthrough: At L17 your method has been called; suppose it receives chunk coordinates (2,2). On L21 the method multiplies these values by 32 and pass them to the individual dimension methods. The values are now (64,64). At L56 the method then adds a random integer between 0 and 32 to each of them. Worst case scenario, the values are now (96,96). Th
  4. The if statement in your class will never run, since you are using a bitwise "and" instead of a logical "and". I'm assuming it's just a typo. if ( age >= 7 & R > 8 ) // Will always be false in this context, should have two ampersands: ((age >= 7) && (R > ) { ret.add(new ItemStack(this.getSeed(), 1, 0)); } Also as Jabelar said, you are retrieving the drops list from the superclass which probably isn't what you want at all. It looks like you just copy pasted the method from BlockCrops. I think you'd be better off writing a new metho
  5. Yes, they absolutely should be written to NBT - I'm only commenting on Trekkie's onUpdate method as it currently exists in the top post. (Did you look at it?) I had no way of knowing whether the mod had some kind of external custom packet handler for synching these values not shown in the original post, hence my wording. To recap, for Trekkie's benefit: - Only side-local fields are being modified - The TE's NBT isn't being notified of this, (hence the builtin handling Draco mentioned isn't being used) - There is no custom packet handling synching the values, hence the block has the
  6. Trekkie is only modifying variables local to the side's TileEntity in his updateEntity method - the builtin isn't going to synch those values unless it is actually written to NBT, no?
  7. I get the sense that you're getting into modding in order to learn how to code, and I think that's wonderful, but the forums here are very much not a Java school so I suggest you look elsewhere for those kinds of tips. To answer your question by adding to what's already been said: there is a way to define an ItemStack to have a particular item, a particular size, and a particular metadata value. If you set the metadata value of an ItemStack to OreDictionary.WILDCARD_VALUE (which is actually equal to INT_MAX, behind the scenes), the ItemStack when used to define a recipe will produce a rec
  8. I think the change made your TileEntity have the appearance of not working, since unless you have a packet handler notifying the client of changes, the client is going to be unaware of any of the changes made to the TileEntity serverside. Effectively, your updateEntity logic doesn't happen on the client, and unless you have a packet handler to let the client know about these state changes, it will look (from the client perspective) like it isn't working anymore.
  9. The biggest stumbling block in updating to 1.8 for me was ensuring that the model .jsons had the correct name. My advice is to break down your registerRender method and set a breakpoint at the end of it so that you can see exactly what name the mesher is expecting. The method adjusted for debug might look something like this: public static void registerRender(Block block) { Item item = Item.getItemFromBlock(block); String modelName = ref.uid + ":" + block.getUnlocalizedName().substring(5); ModelResourceLocation resLocation = new ModelResourceLocation(modelName, "i
  10. I am an enormous fan of DF. The music and the entity models you have shown off so far are quite beautifully done, I am impressed. Your project has certainly piqued my interest, but I am wary of recruiting-type posts such as these. I'm not saying this is the case here, but I have found that projects presented in this way often have a deficit of programmers on the team and a surfeit of idea-persons and/or artists. I have nothing against idea-persons or artists but my interest would be in the experience of mutual collaboration with a team of fellow programmers and not being simply "the progr
  11. Ordinary shapeless recipes don't examine the item stack size, only the item reference, because it would cause problems with mass crafting otherwise. You may require a new recipe class to accomplish this coin changing thing.
  12. It looks like you're using Java 8. I do not think that is currently supported/recommended. Mojang is still targeting Java 6 I believe.
  13. Such a thing is perfectly possible! Here are your ingredients: Anywhere you are given a World as a parameter, you can call getEntitesWithinAABB(Class passedClass, AxisAlignedBB passedAABB), which will return an ArrayList of entities of the passed class type within the passed bounding box. Dropped items are objects of type EntityItem; and EntityItems have a method called getEntityItem which returns the ItemStack they "contain".
  14. You are correct in that this issue is caused by rendering classes being "client-side" only - meaning that the rendering classes don't exist at all on a dedicated server. What you need is a way to ensure that your rendering stuff is only called upon by the Minecraft client. The way this is accomplished is by the use of a proxy class, like Ernio said. You will create two classes with identical method signatures: one that will be loaded for the client, one that will be loaded for the server. If you make your client proxy class inherit from your common proxy class and override the common prox
  15. Ah, fabulous! I didn't see the edit that said you'd solved your issue. The mod concept sounds very cool by the way.
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.