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


Forge Modder
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Matryoshika

  1. Hmm... Path to texture seems fine json is valid json file name equals registryName You are using ModelLoader You sure that your proxy is being called at all?
  2. *Cough cough* Tried checking your json file here? http://jsonlint.com/ Just try that... Might find it interesting
  3. its fine for me... 1.10.2 works perfectly Here's a quote from @jeffryfisher explaining it a bit better: @luckie12 You can look through my own GitHub and compare against what I have: https://github.com/Matryoshika/Underworld/tree/master/src/main/java/se/Matryoshika/Underworld/Content/Rendering The Renderers are called from the ClientProxy in preInit.
  4. Sorry, but ModelLoader.setCustomModelResourceLocation is the Forge-provided method for registering your model for an item/block, and should be initialized in your preInit, not init. Don't use Minecraft.getMinecraft().getRenderItem().getItemModelMesher. Bit more info on why, here: http://www.minecraftforge.net/forum/index.php?topic=35986.0
  5. Hello! Got another question here. I have a Lantern item. It spawns an invisible, intangible block with a light-value of 15(like a torch). All that jazz works. However, I want to spawn fire-particles inside the held item itself, to show that it is lit. I know how to spawn particles, but how would I translate the particle position with the rotation-yaw of the player, so that the particles are always spawned inside the held item?
  6. Done outside IDE, cannot guarantee if it will work from copy/paste, but the gist of it should be clear. As this is for a client-side only mod, you could instead likely cast it directly to Minecraft#getMinecraft()#thePlayer() or whatever the structure of that is again. public void getPlayer(EntityJoinWorldEvent event){ //Check if the entity is what we are looking for. if(event.entity instanceof EntityPlayer){ //If its a player, cast the entity to EntityPlayer. EntityPlayer player = (EntityPlayer) event.entity; //Now you use "player" instead of "event.entity" } }
  7. The issue here, as far I can see, is purely logical. The code is placing what you tell it. Every fluid, has a source-block. This is what is being placed when you do not specify the meta in your world#setBlock method. You use the method setBlock(x, y, z, block),when you should be using the other method setBlock(x, y, z, block, meta, flag). Your meta-damage seems to be the ore#getItemDamage(), so use that for the meta tag. The flag variable, in it's simplest description, is a notification. If the flag has a value of "1", it marks the block for update. If it is "2", it sends the update to the client (almost always wanted). "3" does both flag 1+2. "4" is special, in that it prevents the block from being re-rendered.
  8. If you are not already using EntityInteractEvent, then I would recommend that you do so. The event#getEntityPlayer = the player. The event#getTarget() = the entity the player interacts with. The event#getItemStack() = what the player is holding (Can be null! Always null-check) To set new ItemStack, just use event.getEntityPlayer().inventory.setInventorySlotContents(event.getEntityPlayer().inventory.currentItem, your new ItemStack);
  9. 1) you are accessing the "mc" (Minecraft#getMinecraft()) on what is likely both server-side & client-side. Minecraft#getMinecraft() is purely clientside. 2) You never cast the entity to EntityPlayer. 3) You do not need to get Minecraft#getMinecraft(), to get access to the player's motionx|y|z, see #2 4) Always, always provide a crashlog if you want help with fixing a crash issue. I can only guess that the issue is caused by you calling Minecraft#getMinecraft(), and that alone. Might be another issue before, or after this one, entirely. if(entity instanceof EntityPlayer){ EntityPlayer player = (EntityPlayer) entity; player.motionX =..... }
  10. Actually, what Draco18s said, is related, you are accessing the Minecraft#getMinecraft(), from what is quite likely your CommonProxy, or directly from your main, as you are also registering your block there, which means that you are calling the Client-side only Minecraft#getMinecraft(), on the Server-side. Move the render-registration to your client-proxy, and do please use the Forge provided way of registration, than the Vanilla ItemModelMesher#register.
  11. There is no PlayerFlying event. List of available events: https://dl.dropboxusercontent.com/s/h777x7ugherqs0w/forgeevents.html (Put together by Vic_) If you want to check if the player is flying, you would need to subscribe to a commonly fired event, like the LivingEvent#LivingUpdateEvent, which is fired on each tick (when the entity updates). Check if the entity is an instance of EntityPlayer, if so, cast the event#entity to EntityPlayer. Once that has been done, you gain access to EntityPlayer#capabilities#isFlying. I however, strongly urge you to not disable flying, from this event. If a player is flying using other methods, like creative mode, various baubles, spells etc, the event will still disable the flight, breaking the flight, which had nothing to do with your flight mechanic. If you want to enable/disable flight, especially if based on armour/items, do so through the item's onUpdate methods, or by the LivingEvent#LivingUpdateEvent again, and check the worn armour.
  12. You are trying to place the block coined "crop_tomato", before it is created. Try switching the crop_Tomato to before the seedTomato declaration.
  13. Well, here's a breakdown of what I've managed to make sense of at least. (World-Generation only, as wanted. Keeping calculateCelestialAngle etc out) Very basic, and all from, as stated, what I've been able to make heads or tails of. If anyone sees a flaw, or something missing, don't be hesitant to yell at me, and state what it actually does 1) Dimension Each Dimension is registered in the DimensionManager with ID & DimensionType(name, suffix, id, WorldProvider*, keepLoaded boolean) 2) WorldProvider The WorldProvider gets the BiomeProvider*, terrainType* & the ChunkProvider*. Also has methods getBiomeForCoords(BlockPos) & canDropChunk(can be unloaded?) 3) BiomeProvider The BiomeProvider, in simplified terms, sets the selected chunk to a certain biome. Yes, biomes are chunk-based, but it makes use of a byte[256] (16*16 block count) to set the blocks individually to a biome with desired size of width*depth. 4) terrainType The terrainType is an instance of the WorldType* being used for the active dimension. The terrainType, called from the WorldProvider, defaults to WorldType.DEFAULT, which is the very basic, first vanilla type you can create when making a world. As said, it defaults, meaning that unless specified somewhere else, it will be WorldType.DEFAULT. 5) ChunkProvider The ChunkProvider is where the block are actually placed. It makes use of NoiseGeneratorOctaves/Perlin. It gets the BiomeProvider's biomesForGeneration, and sets them unto each block using the mentioned byte[]. It gets the Sealevel of the world, and then it starts to place blocks. Do note, on the size of worldgen as is done here, it does not use world.setBlockState, rather it actually just makes use of pure numbers, representing the BlockPos, and setting to a blockstate, which has an enormous resource-cost decrease, comparably. The shape and form of the basic terrain is made by the mentioned perlin & octave noise. The ChunkProvider also has a populate method which fires the DecorateBiomeEvent. This is where IWorldGenerators are fired, once the event is called. It also calls the BiomeDecorator#decorate, which places dirt, gravel, clay, the ores etc in the world. 6) WorldType The WorldType changes how the previously mentioned classes act: Vanilla Minecraft makes use of Default, Superflat, Large Biomes, AMPLIFIED & Customized, all of which make use of various booleans etc in the mentioned classes, to significantly edit the overall worldgen. This is where the BiomeProvider & ChunkProvider originates from, as the WorldProvider gets them from the terrainType, which as said, is the WorldType in use. I have a GitHub project for 1.10.2, called Underworld, a Cave-World dimension that replaces the Overworld dimension, which makes use of all of these classes, and implements custom IWorldGenerators, though none for actual ores. Feel free to look through if you want: https://github.com/Matryoshika/Underworld
  14. As you have not given any source code to go over, I will presume your "world generator" implements IWorldGenerator, and it not based on the decorate event. You need to add a check before spawning the pillar. Using the world.getSpawnPoint(); you get access to a BlockPos. Where the spawn-point is. Before anything is placed, get the chunk you are currently in. The generate method supplemented by IWorldGenerator provides the chunkX & chunkZ coordinate. Of course, as your pillars seem to be quite big, you need to check if your pillar generator is placing near the spawn-point. This can be done by having two for-loops (x-axis & z-axis), that each let's say start at negative 5, and end at positive 5, meaning you would check a 11x11 chunk area, centered on the spawn-chunk, if you modify the chunkX & chunkZ variable. It would be something akin to this: for(int dx = min; dx < max; dx++){ for(int dz = min; dz < max; dz++){ if(world.getChunkFromBlockCoords(world.getSpawnPoint()) == world.getChunkFromChunkCoords(chunkX+dx, chunkZ+dz)){ return; } } } Let's say the min variable is indeed -5, and max is 5. This means: if pillar generator tries to place a pillar in a chunk that is 5 or less chunks away from the spawn-chunk, then do not generate the pillar.
  15. World#getSpawnPoint gives you a BlockPos of the world's spawn-point. Of course, the WorldProvider gives a "spawnfuzz" meaning players spawn randomly around that BlockPos provided by World#getSpawnPoint. Not much, but about anywhere within ~10 blocks out from the BlockPos. Make sure that your worldGenerator does not spawn in a chunk that is within the world-generators range of the world#getSpawnPoint, and your issue should be solved.
  16. The change is not being sent to the client. Change your setBlockState method from world.setBlockState(pos, state0); to world.setBlockState(pos, state0, 2); where the 2 is a flag that sends the updated state to the client. Please read over the world#setBlockState documentation inside your IDE, for the various flags available.
  17. You can make a class that implements IWorldGenerator, but you might find it easier to subscribe to the DecorateBiomeEvent.Decorate. Either of the two will do what you want. One of my old classes with the event: https://github.com/Matryoshika/Saligia/blob/master/src/main/java/Matryoshika/mods/saligia/worldgen/biomeDecorationAltar.java 1.10 example of IWorldGenerator (About the same for 1.7.10) https://github.com/Matryoshika/Underworld/blob/master/src/main/java/se/Matryoshika/Underworld/WorldGen/Dirty/DirtyTreeGen.java Both of these are called from the respective main classes. Remember: Make sure that what you want to spawn, spawns where it should. Try to make the requirements simple though. Continuously getting and setting blocks will drain most computers, until they seem to load worlds like ten year old toasters. If you have something big to place, lookup chunkproviders and see how they deal with raw bytes instead. Oh, and do think about upgrading to 1.10. I know that everyone is saying that on this forum, but, is it really worth it to code for something obsolete? If you're coding just for yourself, or to learn etc, that's all fine, but if you want people to play with your mod, you kinda do have to pick up the pace, so to speak, lest you finish your mod, but find none playing it.
  18. It's an issue with the actual implementation of your biome. private Biome[] biomesForGeneration = new Biome[] { MoreOresModBiomes.otherlyworldBiome }; You never tell the chunkprovider what size you want your biome. I'd recommend you leave biomesForGeneration as uninitialized, and initialize it in the provideChunk method, as it is done in the vanilla code. this.biomesForGeneration = this.worldObj.getBiomeProvider().loadBlockGeneratorData(this.biomesForGeneration, x * 16, z * 16, 16, 16); here, it takes the Biome array, chunkX ->blockX coord, chunkZ ->blockX coord, width & depth. Note, it is best to keep all of the width & depth variables at 16, as otherwise they seem to bleed into the other chunks, recreating the issue you had. I had a couple issues myself for my own WorldType, until I noticed that damned part. The nether chunkProvider (single biome) makes use of Biome[] abiome = this.world.getBiomeProvider().loadBlockGeneratorData((Biome[])null, x * 16, z * 16, 16, 16); This should get the ball going for you Do note, that Overworld etc sets this.biomesForGeneration twice, so if you still get issues, you might want to look into that.
  19. I'm sorry to say this, but you should learn, at least basic, java coding before venturing into the Minecraft world. Java is both simple and complex, but if you dive into minecraft modding before you know how to swim, you would sadly likely give up and do something else. Start with the universal「Hello World!」system-output that most languages teach you. Do you know what OOP (Object Oriented Programming) truly means? What's a class? What is a method? Field? Boolean, Integer, String, Byte, Array, List, etc. What's a for-loop? While-loop? If-Else statements? What's the difference between private, global, static, void & abstract methods? These are rudimentary terms required to understand Java, heck, any coding language. Whilst they may seem big and scary, it is still a language. Know the grammar, and you can write your essay (mod)
  20. Wait... am I correct in this? Iron is better than any of the metals you want to add You want to force players to use these inferior metals? Forcing the Copper|Tin<Bronze<Iron level, but want the player to use copper|tin|bronze, is a bit perplexing. Essentially, this is in fact your mindset: "I want you to use the less useful metals, because I say so" If you want a win|win scenario where you and whoever plays with your mod gets happy, then add something, anything, that has 1, just 1 advantage over iron. Heck, give it 15 disadvantages, as long as it is better than iron for something. When comparing Iron & Copper in real life, Copper is more malleable, doesn't rust (it does discolour over time though) and is an excellent conductive material. Iron is the harder of the two metals, but also more brittle, leading to the possibility to shatter. While this does not happen in Minecraft, think about it. They are similar, but also very different. Not to speak, pure Iron/Copper tools are quite rudimentary. When making tools, we combine various metals into alloys, to make them less brittle, or more conductive, or more durable, or even softer! It all depends on what task this thing is for.
  21. It all depends on what you are interested in. Magic mod? Tech? Agriculture? War? Custom WorldGen? Custom fauna? Flora? Why not a mix and match? Maybe something like Extra Utilities, tech & magic combined, with whatever-you-wanted-to-code. I could say "Make a Jurassic Park clone" or "Star wars clone". Maybe your own RPG-fantasy mod, but, they all sound intimidating. Custom entities, custom-modeled blocks & tiles, heck, maybe your own API so that other's can hook into your mod and make addons/incorporate cross-mod functions. In the end, I can throw thousands of suggestions, but they'd get scrapped, because they are not what you want to do. What can you code? What are you prepared to code? Though, as a few last words of advice, create your own things before you venture out and interact with other mods. If you start out by making an addon, or just something similar to what someone else has done, you can come to lean too much on what has been provided. Learn to make your code from scratch. God knows there are too many lucky-block clones out there
  22. Your Devil sword, it doesn't happen to have a call to multiplayer#WorldClient, does it? It is, as the log states, a client-side only piece of code, which is being fired, on the server-side. This works fine in SP, where Server & Client are essentially merged into one. Oh, and please read the logs for the secondary issue: [05:25:09] [server thread/INFO]: You need to agree to the EULA in order to run the server. Go to eula.txt for more info. You should find the EULA.txt inside the IDE's directory, for your project.
  23. Hmm, is your onItemUse ever called at all? (System.out.println("This works") is a lifesaver for testing) Is the onItemUse using the @Override annotation? Last I checked, onItemUse requires more variables ( onItemUse(ItemStack stack, EntityPlayer player, World world, int x, int y, int z, int par7, float xFloat, float yFloat, float zFloat)) You can try onItemRightClick instead, which only requires ItemStack stack, World world, EntityPlayer player variables.
  24. No, I have not done anything with GenLayer, bar a single call in my BiomeProviderCaves constructor, which only calls the Genlayer#initializeAllBiomeGenerators(). I just made my own GenLayerCaves, which mirrored your code, and with multiples tries, with variables becoming quite ridiculously large, for testing, but no actual difference at all, even if I throw in a GenLayerZoom#magnify call in there as well.
  25. Hello! I have a Custom WorldType, called CAVES (Underworld in localization), which uses a crude Nether ChunkProvider & BiomeProvider, that have been converted to make use of Overworld blocks & biomes instead. Everything works fine, bar one thing. Let's say I stand in a Taiga biome. I take 1 step forward, and I'm in an ocean biome. Another step, and I'm inside a river biome. Some biomes are just 1x1 block big, others can be up to 30 wide, but barely 10 long. If I fly more than 20 blocks, I almost always encounter 10 different biomes shoved unto eachother. I have gone over my code countless times now for over two days, and I cannot find anything that relates to the size of the biomes. I tried changing the width variable in the biomesForGeneration inside my ChunkProviderCaves#prepareHeights, which was the only variable that seemed related to the size of a biome. A change from 10 to 99 did nothing, sadly. I just want these damned biomes to be of "proper" size, not a minimalist's dream. Anyone here able to make heads or tails of this issue? My GitHub with the related sourcecode: https://github.com/Matryoshika/Underworld/tree/master/src/main/java/se/Matryoshika/Underworld/WorldGen Issue fixed: my chunkProvider had 2 calls to the biomesForGeneration, and wasn't using multiples of 16, causing the biomes to bleed into eachother
  • Create New...

Important Information

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