Bektor

If it happens without mods too, so only with Forge, then I think it could be the same problem I had a while ago in 1.7.2 after the async world generation was added: http://www.minecraftforge.net/forum/index.php/topic,20213.0.html But well, this bug isn't fixed too and it describes the same that you describe here (only the Forge version is different). The only thing that I can say to this, use older builds of Forge, that was that what I'm did after it seems for me to be, that this bug will not be fixed and so I'm not interested in updating to newer versions of Forge or MC with Forge... And well, after I post my thread about lags, I saw a few days ago an other thread too, but there its by starting Minecraft and now your thread too.

I'm rendering in this code a Biped Model too, well the model is currently in re-creation, that I have my own model and after I recreated the model, I need not to change the render code

Change the doRender methods a bit: /** * Actually renders the given argument. This is a synthetic bridge method, always casting down its argument and then * handing it off to a worker function which does the actual work. In all probabilty, the class Render is generic * (Render<T extends Entity) and this method has signature public void func_76986_a(T entity, double d, double d1, * double d2, float f, float f1). But JAD is pre 1.5 so doesn't do that. */ public void doRender(EntityPFWarrior entity, double par2, double par4, double par6, float par8, float par9) { super.doRender((EntityLiving)entity, par2, par4, par6, par8, par9); } protected void renderEquippedItems(EntityPFWarrior entity, float par2) { super.renderEquippedItems((EntityLiving)entity, par2); } protected void renderEquippedItems(EntityLivingBase entityLivingBase, float par2) { this.renderEquippedItems((EntityPFWarrior)entityLivingBase, par2); } /** * Actually renders the given argument. This is a synthetic bridge method, always casting down its argument and then * handing it off to a worker function which does the actual work. In all probabilty, the class Render is generic * (Render<T extends Entity) and this method has signature public void func_76986_a(T entity, double d, double d1, * double d2, float f, float f1). But JAD is pre 1.5 so doesn't do that. */ public void doRender(EntityLiving entityLiving, double par2, double par4, double par6, float par8, float par9) { this.doRender((EntityPFWarrior)entityLiving, par2, par4, par6, par8, par9); } /** * Actually renders the given argument. This is a synthetic bridge method, always casting down its argument and then * handing it off to a worker function which does the actual work. In all probabilty, the class Render is generic * (Render<T extends Entity) and this method has signature public void func_76986_a(T entity, double d, double d1, * double d2, float f, float f1). But JAD is pre 1.5 so doesn't do that. */ public void doRender(EntityLivingBase entity, double par2, double par4, double par6, float par8, float par9) { this.doRender((EntityPFWarrior)entity, par2, par4, par6, par8, par9); } /** * Actually renders the given argument. This is a synthetic bridge method, always casting down its argument and then * handing it off to a worker function which does the actual work. In all probabilty, the class Render is generic * (Render<T extends Entity) and this method has signature public void func_76986_a(T entity, double d, double d1, * double d2, float f, float f1). But JAD is pre 1.5 so doesn't do that. */ public void doRender(Entity entity, double par2, double par4, double par6, float par8, float par9) { this.doRender((EntityPFWarrior)entity, par2, par4, par6, par8, par9); }

Thats weired. I will look into my code soon, to find out, whats wrong with your code.

Why extends RenderBiped? For me everything works by extending RenderLiving. Change the doRender methods a bit: /** * Actually renders the given argument. This is a synthetic bridge method, always casting down its argument and then * handing it off to a worker function which does the actual work. In all probabilty, the class Render is generic * (Render<T extends Entity) and this method has signature public void func_76986_a(T entity, double d, double d1, * double d2, float f, float f1). But JAD is pre 1.5 so doesn't do that. */ public void doRender(EntityPFWarrior entity, double par2, double par4, double par6, float par8, float par9) { super.doRender((EntityLiving)entity, par2, par4, par6, par8, par9); } protected void renderEquippedItems(EntityPFWarrior entity, float par2) { super.renderEquippedItems((EntityLiving)entity, par2); } protected void renderEquippedItems(EntityLivingBase entityLivingBase, float par2) { this.renderEquippedItems((EntityPFWarrior)entityLivingBase, par2); } /** * Actually renders the given argument. This is a synthetic bridge method, always casting down its argument and then * handing it off to a worker function which does the actual work. In all probabilty, the class Render is generic * (Render<T extends Entity) and this method has signature public void func_76986_a(T entity, double d, double d1, * double d2, float f, float f1). But JAD is pre 1.5 so doesn't do that. */ public void doRender(EntityLiving entityLiving, double par2, double par4, double par6, float par8, float par9) { this.doRender((EntityPFWarrior)entityLiving, par2, par4, par6, par8, par9); } /** * Actually renders the given argument. This is a synthetic bridge method, always casting down its argument and then * handing it off to a worker function which does the actual work. In all probabilty, the class Render is generic * (Render<T extends Entity) and this method has signature public void func_76986_a(T entity, double d, double d1, * double d2, float f, float f1). But JAD is pre 1.5 so doesn't do that. */ public void doRender(EntityLivingBase entity, double par2, double par4, double par6, float par8, float par9) { this.doRender((EntityPFWarrior)entity, par2, par4, par6, par8, par9); } /** * Actually renders the given argument. This is a synthetic bridge method, always casting down its argument and then * handing it off to a worker function which does the actual work. In all probabilty, the class Render is generic * (Render<T extends Entity) and this method has signature public void func_76986_a(T entity, double d, double d1, * double d2, float f, float f1). But JAD is pre 1.5 so doesn't do that. */ public void doRender(Entity entity, double par2, double par4, double par6, float par8, float par9) { this.doRender((EntityPFWarrior)entity, par2, par4, par6, par8, par9); }

Memory leaks. That sounds like that: http://www.minecraftforge.net/forum/index.php/topic,20213.0.html Well, its not exact the same problem, but there are memory lags to by generating a jungle world. (Here memory leaks on launching, there on generating a world with a jungle biome)

Add this to your render code: protected void renderEquippedItems(EntityPFWarrior entity, float par2) { super.renderEquippedItems((EntityLiving)entity, par2); } protected void renderEquippedItems(EntityLivingBase entityLivingBase, float par2) { this.renderEquippedItems((EntityPFWarrior)entityLivingBase, par2); }

Thanks. I will try it out. Anyone who can help me by my second question/problem?

Does really no one knows I could create a custom main menu and how I could make block breaking in 3D instead of 2D?

Anyone?

Try to change PortalPosition to Teleporter.PortalPosition. Because from that parts I looked into your code (Well, I looked not in the complete code, but in the most parts of it and this parts are correct), it could be an error in your PortalPosition code, so change it to the Mojang Teleporter and if it works then, then you know that in your PortalPosition was the error. And well, I understand how the Teleporter.class works a bit, mostly I understand the Portal.class itselft (in such a detail that I can make my own custom Portalframe ) Bektor

Then there could be a problem in your Teleporter. Look into it. If you didn't find the problem in this class, then post here back, because I can't look in it now. I'm going to sleep now, because in Germany its 1:04 am... Bektor

Ok. I mean that in the BlockFire.class is a method that calls the tryToCreatePortal method in the BlockPortal.class to check if the fire was added in/on a portal frame and that then the portal will be created. For the BlockFire.class its in this method: /** * Called whenever the block is added into the world. Args: world, x, y, z */ public void onBlockAdded(World p_149726_1_, int p_149726_2_, int p_149726_3_, int p_149726_4_) { if (p_149726_1_.provider.dimensionId > 0 || !Blocks.portal.func_150000_e(p_149726_1_, p_149726_2_, p_149726_3_, p_149726_4_)) { if (!World.doesBlockHaveSolidTopSurface(p_149726_1_, p_149726_2_, p_149726_3_ - 1, p_149726_4_) && !this.canNeighborBurn(p_149726_1_, p_149726_2_, p_149726_3_, p_149726_4_)) { p_149726_1_.setBlockToAir(p_149726_2_, p_149726_3_, p_149726_4_); } else { p_149726_1_.scheduleBlockUpdate(p_149726_2_, p_149726_3_, p_149726_4_, this, this.tickRate(p_149726_1_) + p_149726_1_.rand.nextInt(10)); } } } This method will be called when the block is placed. This line here checks in which dimension you placed the Fire block with the flient and steel and in that line, the tryToCreatePortal method is called. So with this line the portal will be created! (Well, in 1.7 the tryToCreatePortal methods is called func_150000_e). if (p_149726_1_.provider.dimensionId > 0 || !Blocks.portal.func_150000_e(p_149726_1_, p_149726_2_, p_149726_3_, p_149726_4_)) So to create your portal you need such a method in that Block class that activates the portal. So if the fire should open a portal, then you need to edit the BlockFire.class and put in the onBlockAdded line this line too: /** Change these to your portal frame and Portal block **/ // TODO: tryToCreatePortal if (world.getBlock(x, y - 1, z) == YourBlocksClass.YourPortalFrameBlock && YourBlocksClass.YourPortal.func_150000_e(world, x, y, z)) { return; } And thats why I have my own block to open the portal with my own onBlockAdded method with this lines inside of it and everything works fine. So if you didn't have this line/s of code that calls YOUR portal Block and not the minecraft portal block, like the BlockFire.class does it then your portal will not be created. Bektor

Well, I thought it has something to do with it, because of in the furnace the items stays in the crafting grid, too. And it could be that I understand here something wrong... (well, my english is not perfect...)

Did you call the tryToCreatePortal Method in the flient and steel code (if you make it with a right click; in vanilla its done by placing a fire block inside the BlockFire.class)? (Something like that?) /** Change these to your portal frame and Portal block **/ // TODO: tryToCreatePortal if (world.getBlock(x, y - 1, z) == PFBlocks.runes && PFBlocks.portal.func_150000_e(world, x, y, z)) { return; }

I would suggest to look into the furnace code. Or try to safe the items that are in the crafting grid with NBTData and read the NBTData, but don't forget to send the NBTDate to the server.

Hello. I have two questions: How could I create a custom Minecraft main menu with an option to switch from the custom menu to the normal menu and back? How could I change the 2D-Minecraft Block breaking into a 3D Minecraft Block breaking? Here's a screenshot that you can see what I mean with 3D-Block-Breaking: Well, the screenshot is from the EvilMinecraft Mod (1.2.5). With a custom menu, well I think thats self-explaining. (Something like the Aethers || menu) Bektor

Ok, everything works fine now.

Ok, thanks. I think its now fixed. (Well I didn't test it yet, but I will test it today, so that if that doesn't fix this issue, I will reply here back...)

Hello. I have one problem, that everytime when I am on a server and then switch from surface to the nether, a ClassNotFoundException occurs, on Client in SP everything works fine. I'm using Forge 1.7.2-10.12.1.1103. Here is the error and the code: And here the code: Bektor

Ok. Here it is: https://www.dropbox.com/s/qfnuni4l08e6azr/Modding.Test.Server.zip I hope that this will help you... Oh and its not exact the same, because the Minecraft Trees are spawning with an random factor (where are the leaves and the vines, but its not so big difference, but the terrain is the same...).

Well, but I think or thought that this is a performance issue, because I have a good Pc and with older Forge builds or Minecraft itself I had never such a lags by generting jungle terrain and I never had small lags by loading jungle terrain. (So my friend set up a server thats running on an older Forge build for testing the new version of my own mod Primeval Forest, that brings an Update for 1.7 with it, too. And with the older Forge version on that my friend is running the server --> no problems and on my own Pc, same --> older Forge versions for 1.7 are working fine (Forge 1.7.2-10.12.2.1122 and older), only versions with async terrain generation are laggy.)

Well, were I get it? From gradle with gradle build (Well, its currently for 1.7 in test state [because its not only a rewrite, but the update is unfinished, but I'm working on a Snapshot for this month...] and its currently in dev state for the 1.6 version of the Beta....) And well, did you read my posts? Tested with and WITHOUT mods. This time I reproduced it on the spawn, same seed with Forge itself (Forge 1.7.2-10.12.2.1126 this time). And I found some trees with that problem. It seems to be, that sometimes the generation of trees are failing and often not, because about 90 or 99% of all trees are spawned correct... I'm don't know if the trees will be spawned another time on that location wrong, so if you don't believe me I can send you screenshots, the server or the complete world...

Forge 1.7.2-10.12.2.1125. No mods installed by the last tests. Before the last tests were this mods and versions installed: LycanitesMobsComplete 1.6.1e [1.7.2] primevalforest-1.7.2-Dev Build 2 0.1.0

Wait this is too slow hardware: If that is too slow, whats then fast, need I really a Gaming-PC from 2014 with the newest hardware instead of an I think 2012 Gaming-PC with the newest I think 2012-Hardware? If a PC where you can play new games (late 2013, 2014) without lags on high graphic settings on it and without 80% CPU, if that is a too slow PC for Forge, then I stop playing MC-Forge, because I will never buy a new PC for only one Game, if everything else works fine...