Hello people. I bring you some pictures of my sanctuary MOD.
Waiting extrabiomes villagers are added, and the trees of FN and MTJT
My favorites are the sauce, jacaranda and baobab.
The mod used are:
Extrabiomes XL
Parachute MOD
MCA
Mine and Blade 2
Better Villages
MyCrayFish mod furniture
Balkons Weapon Mod
Enviromine
Bibliocraft
Wild Caves 3
Reis MiniMap
Lord Of The Rings mod
Awaiting update of: Plant mega pack, mo creatures.
Hey guys, I have a problem and I was unable to fix it myself in any way.When I chop down a redwood tree with Treecapitator, the canopy stays floating in the air.
I already tried multiple ideas I had, including playing around in TreeCapitator.cfg and even compiling the ExtrabiomesXL version with a changed TreeCapitator compatibility java file, where I added the single redwood log into the log definition (complete with %d,3; and the newlog part copied from the rainbow eucalyptus) (sorry if i wasn't allowed to :/), i also checked the right order. But that only made it worse, after this change, none of the leaves were removed and the single wood logs stayed anyways (so only the quarter logs and no leaves were chopped). I modified the definition so it was similar to the rainbow eucalyptus treecapitator part, but unlike with the rainbow eucalyptus, the redwood was not fully chopped down.
Can i fix this in any other way? I would prefer to chop down my whole redwoods.
Hey guys, I have a problem and I was unable to fix it myself in any way.When I chop down a redwood tree with Treecapitator, the canopy stays floating in the air.
I already tried multiple ideas I had, including playing around in TreeCapitator.cfg and even compiling the ExtrabiomesXL version with a changed TreeCapitator compatibility java file, where I added the single redwood log into the log definition (complete with %d,3; and the newlog part copied from the rainbow eucalyptus) (sorry if i wasn't allowed to :/), i also checked the right order. But that only made it worse, after this change, none of the leaves were removed and the single wood logs stayed anyways (so only the quarter logs and no leaves were chopped). I modified the definition so it was similar to the rainbow eucalyptus treecapitator part, but unlike with the rainbow eucalyptus, the redwood was not fully chopped down.
Can i fix this in any other way? I would prefer to chop down my whole redwoods.
Thanky for your help,
- Shad0w
We changed how the redwoods generate and they are much taller now....so I am guessing that treecapitator is doing what it does with the Natura redwoods which is only take down about 3/4 of the tree. I believe this is a treecapitator issue and not an EBXL issue since it does the same with other mods. I will talk with our guys and with bspkrs and see if there is a way to chop the entire tree down.
It's being worked on...but having to rewrite all of our code every time Minecraft updates has really slowed the implementation of new things to the mod as well as work on v4. I don't have a time frame of when we will have it ready to release as we are waiting to see now what will go on with 1.8 and Forge.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_65]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:134) [launchwrapper-1.9.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?]
Caused by: java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.0.1208\1.7.10-Forge10.13.0.1208-natives-9078289506545\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary1(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at java.lang.Runtime.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.System.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at org.lwjgl.Sys$1.run(Sys.java:73) ~[lwjgl-2.9.1.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.7.0_65]
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.loadLibrary(Sys.java:95) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.<clinit>(Sys.java:112) ~[lwjgl-2.9.1.jar:?]
at net.minecraft.client.Minecraft.func_71386_F(Minecraft.java:2660) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:72) ~[Main.class:?]
... 6 more
I mean, MC won't launch at all. Get the first screen, hit play---nothing. Just watch java in the Task Manager disappear. Worked fine 5 hours before, computer shut off, magically---now it doesn't. (yes, I know it's not full logs, yet).
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_65]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:134) [launchwrapper-1.9.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?]
Caused by: java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.0.1208\1.7.10-Forge10.13.0.1208-natives-9078289506545\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary1(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at java.lang.Runtime.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.System.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at org.lwjgl.Sys$1.run(Sys.java:73) ~[lwjgl-2.9.1.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.7.0_65]
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.loadLibrary(Sys.java:95) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.<clinit>(Sys.java:112) ~[lwjgl-2.9.1.jar:?]
at net.minecraft.client.Minecraft.func_71386_F(Minecraft.java:2660) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:72) ~[Main.class:?]
... 6 more
I mean, MC won't launch at all. Get the first screen, hit play---nothing. Just watch java in the Task Manager disappear. Worked fine 5 hours before, computer shut off, magically---now it doesn't. (yes, I know it's not full logs, yet).
I don't know what would be causing that...and Shecky has been out of town this weekend. I will leave a msg in our group chat and that he'll see when he gets back or if one of the other guys if they are around. They will most likely need your entire Forge log.
[quote=harley9699;/members/harley9699;/forums/mapping-and-modding/minecraft-mods/1282126-extrabiomesxl-3-15-8?comment=14251]Can you tell anything from this? Short version:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_65]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:134) [launchwrapper-1.9.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?]
Caused by: java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.0.1208\1.7.10-Forge10.13.0.1208-natives-9078289506545\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary1(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at java.lang.Runtime.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.System.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at org.lwjgl.Sys$1.run(Sys.java:73) ~[lwjgl-2.9.1.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.7.0_65]
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.loadLibrary(Sys.java:95) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.<clinit>(Sys.java:112) ~[lwjgl-2.9.1.jar:?]
at net.minecraft.client.Minecraft.func_71386_F(Minecraft.java:2660) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:72) ~[Main.class:?]
... 6 more
I mean, MC won't launch at all. Get the first screen, hit play---nothing. Just watch java in the Task Manager disappear. Worked fine 5 hours before, computer shut off, magically---now it doesn't. (yes, I know it's not full logs, yet). From the logs: Caused by: java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.0.1208\1.7.10-Forge10.13.0.1208-natives-9078289506545\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform.
[Scott]: Things I have managed to get in the last five minutes, in order of ascending importance: cobblestone, planks, lapis lazuli, redstone, gold, coal, diamond. VERY LOST.
Can't load IA 32-bit .dll on a AMD 64-bit platform
Ok it seems that you have both the 32bit and the 64bit versions of java installed at the same time and for some reason it is having issues figuring out what minecraft is using an trying to load a library for the wrong version of java.
From my understanding the best solution is to uninstall both versions of java and then re-install the 64 bit version and everything should be fixed, although you might be able to get away with just uninstalling the 32bit version though I am not sure about it as I have never encountered the issues myself and only know the cause and fix do to a one minute google search.
Thanks. I think I've tried that (been messing with it ALL day), but I'll try that again. I saw that line and figured it was because I only had the 64x in at that point in time. I just don't understand how it can magically change, in a five hour period, without the comp even being on. I've tried all three off and on: 64x 7u65, 7u67, and 32x i586. Both exasperated and confused.
EDIT: Tried that again just now, got the exact same error. Thought I remembered once upon a time, that 64x OS had to have a 32x version as well. Geez, man, I just don't know. After this and rein dx, video drivers, etc. all day long, thinking 15 hours may be enough. Stlll can't believe it just stopped.
@beckyh: no, haven't recently updated java. Too strange.
SO, I can get it to the Mojang screen now. Had to only install the 32x Java---isn't that going to cause me problems later, on a 64x machine? NOW, it's saying that it's a permgen issue. The default doesn't work. Neither do these:
-Xmx2G -XX:PermSize=512m -XX:MaxPermSize=1024m
-Xmx2048M -Xms128M
-Xmx4096M -Xms512M
Or, variations (up and down)of the bottom two. What's the proper java settings? (keeping mind that I have 102 mods). ANY ideas would be appreciated.
Oh, this is the default (and unchecked):
-Xmx1G -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M
[08:22:13] [Client thread/ERROR] [LaunchWrapper]: Unable to launch
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_67]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_67]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_67]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_67]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:134) [launchwrapper-1.9.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?]
Caused by: java.lang.NoClassDefFoundError: net/minecraft/client/Minecraft$5
at net.minecraft.client.Minecraft.func_71396_d(Minecraft.java:2331) ~[bao.class:?]
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:873) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:148) ~[Main.class:?]
... 6 more
Caused by: java.lang.ClassNotFoundException: net.minecraft.client.Minecraft$5
at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:188) ~[launchwrapper-1.9.jar:?]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.7.0_67]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.7.0_67]
at net.minecraft.client.Minecraft.func_71396_d(Minecraft.java:2331) ~[bao.class:?]
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:873) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:148) ~[Main.class:?]
... 6 more
Caused by: java.lang.OutOfMemoryError: PermGen space
It is a lot of work to help those mods accomplish functionality that is already present in our API. We also put a lot of work into our API so that modders could use it without having a hard dependency on our code...
Also...not a lot of users are banging down the door for this...and our development resources are limited...
Well, it's good that you got it working - but not fantastic that you had to resort to 32-bit. What you're likely seeing is indeed the issue of running 32-bit rather than 64-bit java - minecraft running out of memory, because it simply can't address enough with a 32-bit java install.
Out of curiosity, did you try backing up your minecraft directory and moving just the modpack/mods/resourcepacks and mod config directories back after reinstalling it (and having only 64-bit java installed)?
It's not exactly working---just goes to the Mojang screen, never loads. Didn't try your idea though exactly. (Always have everything backed up). Did a fresh dl, then put all the stuff back in...but not on a straight 64x. I'll try that.
Don't know if it matters (since it ran fine before), but I'm doing all of this trying to run heavily modded 1.7.10. Still doesn't make sense that it would just stop working. Baffling.
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.8\1.8-natives-13297572773621\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at org.lwjgl.Sys$1.run(Sys.java:73)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
at org.lwjgl.Sys.loadLibrary(Sys.java:95)
at org.lwjgl.Sys.<clinit>(Sys.java:112)
at bsu.I(SourceFile:2462)
at net.minecraft.client.main.Main.main(SourceFile:40)
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.8\1.8-natives-13297572773621\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at org.lwjgl.Sys$1.run(Sys.java:73)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
at org.lwjgl.Sys.loadLibrary(Sys.java:95)
at org.lwjgl.Sys.(Sys.java:112)
at bsu.I(SourceFile:2462)
at net.minecraft.client.main.Main.main(SourceFile:40)
Has to be java---something.
Probably a bit of a shot in the dark (and this bug report is kind of old) but does running the following in a command prompt fix it:
He's responding to your request on the previous page about the naming of biomes and why it's not a good idea to do that. I've asked Scott to reply to this and explain it here as he explained it to me.
We already provide ways in our API for modders to determine if a biome is ours or not and we put in a lot of work to make it easy to use our API. The mods in question should not be keying off of biome names and it is difficult to justify helping them to do that when we have limited resources and we do not have an overwhelming demand for this feature. (Even if we did...it is hard to justify helping other mods do things incorrectly.) As a rule, the biome name is only for display purposes on the F3 screen and should *never* be used internally by modders to identify a biome. (Doing things that way also happens to be hugely inefficient)
That being said, it is fairly straightforward for anyone to fork the code on github, change the biome names in the code and rebuild according to the instructions provided here. This might solve the compatibility issues...but I also fear some other popular mods are depending on the names as they are now...so this might introduce incompatibilities in those cases.
I was surely hoping that was the magic answer...but, no. With everything I've done, the only way to even get to the mojang screen is with 32 bit java only in the system. I know I had 64 in there before. Freaking me out. More so, that I can't get it to load at all, modded or vanilla.
Again, if anyone has a great java argument line...(what I used before obviously doesn't work any more).
EDIT: Got it! Only took me three days, but finally fixed it! It took older versions of both 32 bit and 64 bit installed. Man, what an ordeal. Thanks for all of the suggestions that came through.
We already provide ways in our API for modders to determine if a biome is ours or not and we put in a lot of work to make it easy to use our API. The mods in question should not be keying off of biome names and it is difficult to justify helping them to do that when we have limited resources and we do not have an overwhelming demand for this feature. (Even if we did...it is hard to justify helping other mods do things incorrectly.) As a rule, the biome name is only for display purposes on the F3 screen and should *never* be used internally by modders to identify a biome.
Allow me to chime in, then.
Mystcraft internally represents biomes by their biome number, and has done so since 0.10 came out for 1.4.7.
But the name presented to the user on the symbol pages is the text string of the biome.
Seeing two different stacks of "Plains biome", or two different stacks of "Glacier biome", or three stacks of "Savannah biome" is very hard for the user to work with, especially when all of them actually generate differently.
You say that not many people are complaining about this; I'll say that not many people are aware of the issue. I wasn't until I saw this post of yours.
I will also request that biome names get tagged by the mod, just like "twilight forest", or "dense twilight forest", or "twilight clearing", or "twilight lake". Now, granted, they left out "twilight glacier" (and I'm off to suggest that right now :-).
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
We changed how the redwoods generate and they are much taller now....so I am guessing that treecapitator is doing what it does with the Natura redwoods which is only take down about 3/4 of the tree. I believe this is a treecapitator issue and not an EBXL issue since it does the same with other mods. I will talk with our guys and with bspkrs and see if there is a way to chop the entire tree down.
Well, the problem is not that Treecapitator does not reach the top, but that only the trunk made of quarter logs is chopped down (but the whole way up). The distance upwards does not seem to be a problem, because in 1.5.2 I also used a modified version of ebxl with 1.5 to 1.8 times taller redwoods, and they were easily chopped down. Now (I'm using 3.15.8), when I chop down a redwood, the trunk made out of quarter logs is chopped and some leaves in a cubic form are removed too. But the outer leaves stay, as do the "branches", made out of single block. Because of these branches, the rest of the leaves is unable to despawn and half the canopy still hovers in the air.
At some point, I found out that rainbow eucalyptus trees can be fully chopped down, even though they consist of 2 or 3 different blocks and also have a trunk made out of quarter blocks. When I then looked into the code, I saw that the extra blocks creating the redwood branches are not even used for the redwood definition in the TreeCapitator plugin, so I added them in, exactly the same way as they are added in the rainbow eucalyptus (of course changing the metadata to the right values). I built the modified version and tested it. But then, only the quarter log trunk was chopped down WITHOUT removing any leaves in the canopy, leaving it fully intact. Only when I chopped away one of the branch blocks, the other blocks above were chopped too.
So now I ask myself, how can I make it so that TreeCapitator is able to chop down whole redwoods like rainbow eucalyptuses, so I can properly clear the area for my base in the redwood forest. Because I didn't find any solution, I asked you.
So in short: I don't think that the heigt of the tree affects the chopping algorithm, but the blocks which are not chopped are somehow not properly recognized, even when added manually to the plugin.
Thanks for asking the Treecapitator team anyways.
- Shad0w
Well, the problem is not that Treecapitator does not reach the top, but that only the trunk made of quarter logs is chopped down (but the whole way up). The distance upwards does not seem to be a problem, because in 1.5.2 I also used a modified version of ebxl with 1.5 to 1.8 times taller redwoods, and they were easily chopped down. Now (I'm using 3.15.8), when I chop down a redwood, the trunk made out of quarter logs is chopped and some leaves in a cubic form are removed too. But the outer leaves stay, as do the "branches", made out of single block. Because of these branches, the rest of the leaves is unable to despawn and half the canopy still hovers in the air.
At some point, I found out that rainbow eucalyptus trees can be fully chopped down, even though they consist of 2 or 3 different blocks and also have a trunk made out of quarter blocks. When I then looked into the code, I saw that the extra blocks creating the redwood branches are not even used for the redwood definition in the TreeCapitator plugin, so I added them in, exactly the same way as they are added in the rainbow eucalyptus (of course changing the metadata to the right values). I built the modified version and tested it. But then, only the quarter log trunk was chopped down WITHOUT removing any leaves in the canopy, leaving it fully intact. Only when I chopped away one of the branch blocks, the other blocks above were chopped too.
So now I ask myself, how can I make it so that TreeCapitator is able to chop down whole redwoods like rainbow eucalyptuses, so I can properly clear the area for my base in the redwood forest. Because I didn't find any solution, I asked you.
So in short: I don't think that the heigt of the tree affects the chopping algorithm, but the blocks which are not chopped are somehow not properly recognized, even when added manually to the plugin.
Thanks for asking the Treecapitator team anyways.
- Shad0w
We have some ideas as to why it isn't working. The guys will be checking into the issue as soon as they have some time. Currently they are trying to get the last of the bugs worked out of the 1.7.10 version so we can release it. One of us will post as soon as the issue is resolved.
Well, the problem is not that Treecapitator does not reach the top, but that only the trunk made of quarter logs is chopped down (but the whole way up). The distance upwards does not seem to be a problem, because in 1.5.2 I also used a modified version of ebxl with 1.5 to 1.8 times taller redwoods, and they were easily chopped down. Now (I'm using 3.15.8), when I chop down a redwood, the trunk made out of quarter logs is chopped and some leaves in a cubic form are removed too. But the outer leaves stay, as do the "branches", made out of single block. Because of these branches, the rest of the leaves is unable to despawn and half the canopy still hovers in the air.
At some point, I found out that rainbow eucalyptus trees can be fully chopped down, even though they consist of 2 or 3 different blocks and also have a trunk made out of quarter blocks. When I then looked into the code, I saw that the extra blocks creating the redwood branches are not even used for the redwood definition in the TreeCapitator plugin, so I added them in, exactly the same way as they are added in the rainbow eucalyptus (of course changing the metadata to the right values). I built the modified version and tested it. But then, only the quarter log trunk was chopped down WITHOUT removing any leaves in the canopy, leaving it fully intact. Only when I chopped away one of the branch blocks, the other blocks above were chopped too.
So now I ask myself, how can I make it so that TreeCapitator is able to chop down whole redwoods like rainbow eucalyptuses, so I can properly clear the area for my base in the redwood forest. Because I didn't find any solution, I asked you.
So in short: I don't think that the heigt of the tree affects the chopping algorithm, but the blocks which are not chopped are somehow not properly recognized, even when added manually to the plugin.
Thanks for asking the Treecapitator team anyways.
- Shad0w
Ahh, yeah that would explain it. That came about when we switched from using the old Redwood generation code and switched to the FN Redwood code and added in usage of our logs for the trunk. The Treecapitator tree registration never got updated to add support fur the extra blocks, so I'll have to add that to my long list of things that still need doing...
Waiting extrabiomes villagers are added, and the trees of FN and MTJT
My favorites are the sauce, jacaranda and baobab.
The mod used are:
Extrabiomes XL
Parachute MOD
MCA
Mine and Blade 2
Better Villages
MyCrayFish mod furniture
Balkons Weapon Mod
Enviromine
Bibliocraft
Wild Caves 3
Reis MiniMap
Lord Of The Rings mod
Awaiting update of: Plant mega pack, mo creatures.
Thank you for your beauty! A big hug!
I already tried multiple ideas I had, including playing around in TreeCapitator.cfg and even compiling the ExtrabiomesXL version with a changed TreeCapitator compatibility java file, where I added the single redwood log into the log definition (complete with %d,3; and the newlog part copied from the rainbow eucalyptus) (sorry if i wasn't allowed to :/), i also checked the right order. But that only made it worse, after this change, none of the leaves were removed and the single wood logs stayed anyways (so only the quarter logs and no leaves were chopped). I modified the definition so it was similar to the rainbow eucalyptus treecapitator part, but unlike with the rainbow eucalyptus, the redwood was not fully chopped down.
Can i fix this in any other way? I would prefer to chop down my whole redwoods.
Thanky for your help,
- Shad0w
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWe changed how the redwoods generate and they are much taller now....so I am guessing that treecapitator is doing what it does with the Natura redwoods which is only take down about 3/4 of the tree. I believe this is a treecapitator issue and not an EBXL issue since it does the same with other mods. I will talk with our guys and with bspkrs and see if there is a way to chop the entire tree down.
It's being worked on...but having to rewrite all of our code every time Minecraft updates has really slowed the implementation of new things to the mod as well as work on v4. I don't have a time frame of when we will have it ready to release as we are waiting to see now what will go on with 1.8 and Forge.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_65]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:134) [launchwrapper-1.9.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?]
Caused by: java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.0.1208\1.7.10-Forge10.13.0.1208-natives-9078289506545\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary1(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at java.lang.Runtime.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.System.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at org.lwjgl.Sys$1.run(Sys.java:73) ~[lwjgl-2.9.1.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.7.0_65]
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.loadLibrary(Sys.java:95) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.<clinit>(Sys.java:112) ~[lwjgl-2.9.1.jar:?]
at net.minecraft.client.Minecraft.func_71386_F(Minecraft.java:2660) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:72) ~[Main.class:?]
... 6 more
I mean, MC won't launch at all. Get the first screen, hit play---nothing. Just watch java in the Task Manager disappear. Worked fine 5 hours before, computer shut off, magically---now it doesn't. (yes, I know it's not full logs, yet).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI don't know what would be causing that...and Shecky has been out of town this weekend. I will leave a msg in our group chat and that he'll see when he gets back or if one of the other guys if they are around. They will most likely need your entire Forge log.
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_65]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_65]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:134) [launchwrapper-1.9.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?]
Caused by: java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.0.1208\1.7.10-Forge10.13.0.1208-natives-9078289506545\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary1(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.ClassLoader.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at java.lang.Runtime.loadLibrary0(Unknown Source) ~[?:1.7.0_65]
at java.lang.System.loadLibrary(Unknown Source) ~[?:1.7.0_65]
at org.lwjgl.Sys$1.run(Sys.java:73) ~[lwjgl-2.9.1.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.7.0_65]
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.loadLibrary(Sys.java:95) ~[lwjgl-2.9.1.jar:?]
at org.lwjgl.Sys.<clinit>(Sys.java:112) ~[lwjgl-2.9.1.jar:?]
at net.minecraft.client.Minecraft.func_71386_F(Minecraft.java:2660) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:72) ~[Main.class:?]
... 6 more
I mean, MC won't launch at all. Get the first screen, hit play---nothing. Just watch java in the Task Manager disappear. Worked fine 5 hours before, computer shut off, magically---now it doesn't. (yes, I know it's not full logs, yet). From the logs: Caused by: java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.7.10-Forge10.13.0.1208\1.7.10-Forge10.13.0.1208-natives-9078289506545\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform.
You upgrade Java recently?
Ok it seems that you have both the 32bit and the 64bit versions of java installed at the same time and for some reason it is having issues figuring out what minecraft is using an trying to load a library for the wrong version of java.
From my understanding the best solution is to uninstall both versions of java and then re-install the 64 bit version and everything should be fixed, although you might be able to get away with just uninstalling the 32bit version though I am not sure about it as I have never encountered the issues myself and only know the cause and fix do to a one minute google search.
EDIT: Tried that again just now, got the exact same error. Thought I remembered once upon a time, that 64x OS had to have a 32x version as well. Geez, man, I just don't know. After this and rein dx, video drivers, etc. all day long, thinking 15 hours may be enough. Stlll can't believe it just stopped.
@beckyh: no, haven't recently updated java. Too strange.
-Xmx2G -XX:PermSize=512m -XX:MaxPermSize=1024m
-Xmx2048M -Xms128M
-Xmx4096M -Xms512M
Or, variations (up and down)of the bottom two. What's the proper java settings? (keeping mind that I have 102 mods). ANY ideas would be appreciated.
Oh, this is the default (and unchecked):
-Xmx1G -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -Xmn128M
[08:22:13] [Client thread/ERROR] [LaunchWrapper]: Unable to launch
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_67]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_67]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_67]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_67]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:134) [launchwrapper-1.9.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?]
Caused by: java.lang.NoClassDefFoundError: net/minecraft/client/Minecraft$5
at net.minecraft.client.Minecraft.func_71396_d(Minecraft.java:2331) ~[bao.class:?]
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:873) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:148) ~[Main.class:?]
... 6 more
Caused by: java.lang.ClassNotFoundException: net.minecraft.client.Minecraft$5
at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:188) ~[launchwrapper-1.9.jar:?]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.7.0_67]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.7.0_67]
at net.minecraft.client.Minecraft.func_71396_d(Minecraft.java:2331) ~[bao.class:?]
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:873) ~[bao.class:?]
at net.minecraft.client.main.Main.main(SourceFile:148) ~[Main.class:?]
... 6 more
Caused by: java.lang.OutOfMemoryError: PermGen space
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt is a lot of work to help those mods accomplish functionality that is already present in our API. We also put a lot of work into our API so that modders could use it without having a hard dependency on our code...
Also...not a lot of users are banging down the door for this...and our development resources are limited...
It's not exactly working---just goes to the Mojang screen, never loads. Didn't try your idea though exactly. (Always have everything backed up). Did a fresh dl, then put all the stuff back in...but not on a straight 64x. I'll try that.
Don't know if it matters (since it ran fine before), but I'm doing all of this trying to run heavily modded 1.7.10. Still doesn't make sense that it would just stop working. Baffling.
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\Clayton\AppData\Roaming\.minecraft\versions\1.8\1.8-natives-13297572773621\lwjgl.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at org.lwjgl.Sys$1.run(Sys.java:73)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
at org.lwjgl.Sys.loadLibrary(Sys.java:95)
at org.lwjgl.Sys.<clinit>(Sys.java:112)
at bsu.I(SourceFile:2462)
at net.minecraft.client.main.Main.main(SourceFile:40)
Has to be java---something.
Probably a bit of a shot in the dark (and this bug report is kind of old) but does running the following in a command prompt fix it:
Source: https://bugs.mojang.com/browse/MCL-1297
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHe's responding to your request on the previous page about the naming of biomes and why it's not a good idea to do that. I've asked Scott to reply to this and explain it here as he explained it to me.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWe already provide ways in our API for modders to determine if a biome is ours or not and we put in a lot of work to make it easy to use our API. The mods in question should not be keying off of biome names and it is difficult to justify helping them to do that when we have limited resources and we do not have an overwhelming demand for this feature. (Even if we did...it is hard to justify helping other mods do things incorrectly.) As a rule, the biome name is only for display purposes on the F3 screen and should *never* be used internally by modders to identify a biome. (Doing things that way also happens to be hugely inefficient)
That being said, it is fairly straightforward for anyone to fork the code on github, change the biome names in the code and rebuild according to the instructions provided here. This might solve the compatibility issues...but I also fear some other popular mods are depending on the names as they are now...so this might introduce incompatibilities in those cases.
I was surely hoping that was the magic answer...but, no. With everything I've done, the only way to even get to the mojang screen is with 32 bit java only in the system. I know I had 64 in there before. Freaking me out. More so, that I can't get it to load at all, modded or vanilla.
Again, if anyone has a great java argument line...(what I used before obviously doesn't work any more).
EDIT: Got it! Only took me three days, but finally fixed it! It took older versions of both 32 bit and 64 bit installed. Man, what an ordeal. Thanks for all of the suggestions that came through.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAllow me to chime in, then.
Mystcraft internally represents biomes by their biome number, and has done so since 0.10 came out for 1.4.7.
But the name presented to the user on the symbol pages is the text string of the biome.
Seeing two different stacks of "Plains biome", or two different stacks of "Glacier biome", or three stacks of "Savannah biome" is very hard for the user to work with, especially when all of them actually generate differently.
You say that not many people are complaining about this; I'll say that not many people are aware of the issue. I wasn't until I saw this post of yours.
I will also request that biome names get tagged by the mod, just like "twilight forest", or "dense twilight forest", or "twilight clearing", or "twilight lake". Now, granted, they left out "twilight glacier" (and I'm off to suggest that right now :-).
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Well, the problem is not that Treecapitator does not reach the top, but that only the trunk made of quarter logs is chopped down (but the whole way up). The distance upwards does not seem to be a problem, because in 1.5.2 I also used a modified version of ebxl with 1.5 to 1.8 times taller redwoods, and they were easily chopped down. Now (I'm using 3.15.8), when I chop down a redwood, the trunk made out of quarter logs is chopped and some leaves in a cubic form are removed too. But the outer leaves stay, as do the "branches", made out of single block. Because of these branches, the rest of the leaves is unable to despawn and half the canopy still hovers in the air.
At some point, I found out that rainbow eucalyptus trees can be fully chopped down, even though they consist of 2 or 3 different blocks and also have a trunk made out of quarter blocks. When I then looked into the code, I saw that the extra blocks creating the redwood branches are not even used for the redwood definition in the TreeCapitator plugin, so I added them in, exactly the same way as they are added in the rainbow eucalyptus (of course changing the metadata to the right values). I built the modified version and tested it. But then, only the quarter log trunk was chopped down WITHOUT removing any leaves in the canopy, leaving it fully intact. Only when I chopped away one of the branch blocks, the other blocks above were chopped too.
So now I ask myself, how can I make it so that TreeCapitator is able to chop down whole redwoods like rainbow eucalyptuses, so I can properly clear the area for my base in the redwood forest. Because I didn't find any solution, I asked you.
So in short: I don't think that the heigt of the tree affects the chopping algorithm, but the blocks which are not chopped are somehow not properly recognized, even when added manually to the plugin.
Thanks for asking the Treecapitator team anyways.
- Shad0w
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWe have some ideas as to why it isn't working. The guys will be checking into the issue as soon as they have some time. Currently they are trying to get the last of the bugs worked out of the 1.7.10 version so we can release it. One of us will post as soon as the issue is resolved.
Thanks for letting us know.
Ahh, yeah that would explain it. That came about when we switched from using the old Redwood generation code and switched to the FN Redwood code and added in usage of our logs for the trunk. The Treecapitator tree registration never got updated to add support fur the extra blocks, so I'll have to add that to my long list of things that still need doing...