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

MrCaracal

Members
  • Content Count

    80
  • Joined

  • Last visited

Everything posted by MrCaracal

  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.
  16. The "spawn point" can actually be a coordinate that is underground. You'll need to write some sort of function that checks for that and returns more suitable coordinates nearby instead of trusting the location of the spawn point.
  17. Do you mean you can't "view" the base codes? Because you certainly should not be editing them, it is deliberate that you cannot. If you can't view the code, it might be a workspace issue; you might try carefully stepping through the setup process again. As far as your random crashes, ConcurrentModificationExceptions are typically caused by modifying an iterable collection while still traversing it. Is there any place where you're editing some form of Collection at the same time as you (or some other vanilla code) is iterating through it?
  18. I'm trying to read between the lines here, but as I understand it: you have a block or structure of blocks that generates in the spawn chunk in your custom dimension. At some point track the placement of this block needs to be tracked as you need to know a coordinate to teleport the player to; and so you need to know the Y-position of your block/structure, which obviously won't exist until after the block has been placed. The solution you're proposing is to load the entire spawn chunk once so you can get the Y coordinate of your block for later use in your teleport system, so you're asking how
  19. To expand on that, the "normal" recipe class you're using doesn't care about the size of an ItemStack when checking the validity of a recipe. Otherwise, it would only recognize a recipe of a specific ItemStack size, or it would have to check for all possible stack sizes. Imagine how inconvenient that would be! Your options, I believe are to either create a new item that is equal in "material worth" to a stack of 64 torches and use that item in your recipe, or to create and register a custom recipe handler class that does care about the ItemStack size and register your recipe using that.
  20. Well, if the solution works as well as you need it to, I won't rain on your parade any further, but I will advise you to put it on your to-do list for things to take another look at in the future. As for the other thing you just mentioned, isDead only returns true on the tick before the entity is to be destroyed. It's not exactly a "dead" flag in the way we'd think of a dead pig, i.e. one with zero hearts remaining. If you want your model to halt the breathing animation some time before that, I think you'll need to come up with a different trigger.
  21. You're extending BlockContainer, and BlockContainer already extends Block, so that's your Block class. Since you're using a TESR and not a ISBRH, you should register your renderer with ClientRegistry.bindTileEntitySpecialRenderer, as the tutorial suggests. This is typically done somewhere in the main mod file, during Init. I'm sorry if I was unclear, those directions were written under the assumption that you'd be using ISBRH. You're using a TESR, so you don't need to worry about Render IDs. FYI though, A Render ID is basically a number (integer) that Minecraft uses to correlate a bl
  22. EDIT: I only just saw your PS. The first thing I think you should do is move your rendering stuff to a proxy class so that it doesn't load on a dedicated server, which does not have any of the rendering functions. Minecraft.getMinecraft(), for instance, is client-side only and will crash a dedicated server. I like your gumption but I advise you to start at the beginning of the tutorials on the wiki because you're missing some very necessary boilerplate. It certainly is possible! Have you perused the wiki? -> http://www.minecraftforge.net/wiki/Using_wavefront_model I know you asked
  23. May I ask for a clarification? Are you saying that you would like to implement your own .obj model loader, or that you have an .obj that you'd like to use as a model for a block? I ask because Forge already includes such a model loader. To answer either of the above potential questions I recommend you peek at WavefrontObject.class, and ObjModelLoader.class in the net.minecraftforge.client.model.obj package.
  24. I see your solution, but I don't know that I would recommend it. You've employed a workaround to the fact that every time you call rand.nextFloat() you receive a different value. You don't need a new random value every time render() is called on your model, and you certainly don't need to be polling a HashMap every time render() is called to make sure the random number you got this time is the same one you got the first time. I doubt that this will scale very nicely with a large number of entities. A random number generator simply isn't what you need for this application, I think...
×
×
  • Create New...

Important Information

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