Has your developmental version been taking note of the changes to Mekanism API that are being made for version 8?
I tried to build from their github to use with AOBD and some other mods, but AOBD caused crashes by referring to API classes in mek that no longer exist.
server is using java version:
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
my client uses this java:
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
friend's client uses this java:
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
we are experiencing a crash when more than one player logs in.
Client experiences a series of exceptions like this one
[17:01:25] [Client thread/ERROR] [FML]: SimpleChannelHandlerWrapper exception<br>java.lang.NullPointerException<br> at com.kentington.thaumichorizons.common.lib.PacketPlayerInfusionSync.onMessage(PacketPlayerInfusionSync.java:26) ~[PacketPlayerInfusionSync.class:?]<br> at com.kentington.thaumichorizons.common.lib.PacketPlayerInfusionSync.onMessage(PacketPlayerInfusionSync.java:11) ~[PacketPlayerInfusionSync.class:?]<br> at cpw.mods.fml.common.network.simpleimpl.SimpleChannelHandlerWrapper.channelRead0(SimpleChannelHandlerWrapper.java:37) ~[SimpleChannelHandlerWrapper.class:?]<br> at cpw.mods.fml.common.network.simpleimpl.SimpleChannelHandlerWrapper.channelRead0(SimpleChannelHandlerWrapper.java:17) ~[SimpleChannelHandlerWrapper.class:?]<br> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:98) ~[SimpleChannelInboundHandler.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337) [DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323) [DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:101) [SimpleChannelInboundHandler.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337) [DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323) [DefaultChannelHandlerContext.class:?]<br> at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) [MessageToMessageDecoder.class:?]<br> at io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111) [MessageToMessageCodec.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337) [DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323) [DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785) [DefaultChannelPipeline.class:?]<br> at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:169) [EmbeddedChannel.class:?]<br> at cpw.mods.fml.common.network.internal.FMLProxyPacket.func_148833_a(FMLProxyPacket.java:77) [FMLProxyPacket.class:?]<br> at net.minecraft.network.NetworkManager.func_74428_b(NetworkManager.java:212) [ej.class:?]<br> at net.minecraft.client.multiplayer.PlayerControllerMP.func_78765_e(PlayerControllerMP.java:273) [bje.class:?]<br> at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1590) [bao.class:?]<br> at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:961) [bao.class:?]<br> at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:887) [bao.class:?]<br> at net.minecraft.client.main.Main.main(SourceFile:148) [Main.class:?]<br> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_17]<br> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_17]<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_17]<br> at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_17]<br> at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.11.jar:?]<br> at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.11.jar:?]<br> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_17]<br> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_17]<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_17]<br> at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_17]<br> at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:286) [NewLaunch.jar:?]<br> at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:376) [NewLaunch.jar:?]<br> at org.multimc.EntryPoint.listen(EntryPoint.java:165) [NewLaunch.jar:?]<br> at org.multimc.EntryPoint.main(EntryPoint.java:54) [NewLaunch.jar:?]<br><br>
and this one
There was a critical exception handling a packet on channel thaumichorizons<br>java.lang.NullPointerException<br> at com.kentington.thaumichorizons.common.lib.PacketPlayerInfusionSync.onMessage(PacketPlayerInfusionSync.java:26) ~[PacketPlayerInfusionSync.class:?]<br> at com.kentington.thaumichorizons.common.lib.PacketPlayerInfusionSync.onMessage(PacketPlayerInfusionSync.java:11) ~[PacketPlayerInfusionSync.class:?]<br> at cpw.mods.fml.common.network.simpleimpl.SimpleChannelHandlerWrapper.channelRead0(SimpleChannelHandlerWrapper.java:37) ~[SimpleChannelHandlerWrapper.class:?]<br> at cpw.mods.fml.common.network.simpleimpl.SimpleChannelHandlerWrapper.channelRead0(SimpleChannelHandlerWrapper.java:17) ~[SimpleChannelHandlerWrapper.class:?]<br> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:98) ~[SimpleChannelInboundHandler.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337) ~[DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323) ~[DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:101) ~[SimpleChannelInboundHandler.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337) ~[DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323) ~[DefaultChannelHandlerContext.class:?]<br> at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) ~[MessageToMessageDecoder.class:?]<br> at io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111) ~[MessageToMessageCodec.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337) ~[DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323) ~[DefaultChannelHandlerContext.class:?]<br> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785) ~[DefaultChannelPipeline.class:?]<br> at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:169) ~[EmbeddedChannel.class:?]<br> at cpw.mods.fml.common.network.internal.FMLProxyPacket.func_148833_a(FMLProxyPacket.java:77) [FMLProxyPacket.class:?]<br> at net.minecraft.network.NetworkManager.func_74428_b(NetworkManager.java:212) [ej.class:?]<br> at net.minecraft.client.multiplayer.PlayerControllerMP.func_78765_e(PlayerControllerMP.java:273) [bje.class:?]<br> at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1590) [bao.class:?]<br> at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:961) [bao.class:?]<br> at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:887) [bao.class:?]<br> at net.minecraft.client.main.Main.main(SourceFile:148) [Main.class:?]<br> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_17]<br> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_17]<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_17]<br> at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_17]<br> at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.11.jar:?]<br> at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.11.jar:?]<br> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_17]<br> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_17]<br> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_17]<br> at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_17]<br> at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:286) [NewLaunch.jar:?]<br> at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:376) [NewLaunch.jar:?]<br> at org.multimc.EntryPoint.listen(EntryPoint.java:165) [NewLaunch.jar:?]<br> <br>
and promptly loses its connection and returns to the main menu.
What would the expected performance be for a system with these specs:
OS: Win7 64 bit
cpu: AMD FX 8150 8-core 3.61 GHz
gpu: Nvidia GTX 260
RAM: 16GB (I tend to give MC permission to use 5GB b/c i'm running TFC and its historically memory heavy, tho it only seems to consume around 1.5-2 before glsl was added).
minecraft version is 1.6.4 as needed for TFC. This will be improved as they're working on bringing tfc to newer versions of MC but the focus is on bugfixes atm.
I can use lite version, any other version makes minecraft chug (down to 2-3 fps, and almost completely non-responsive inputs. (I remember to remove cloud shadows). Am I experiencing a hardware limitation or something else going wonky?
another note, i it seems to be specific to your shader pack, as i tested it with some others and not all of them do this, but it does WEIRD stuff to the mob radar in zan's minimap, you end up with large black occluding marks on the map around the units portraits, which shrink to almost single-pixel size. Player portraits still work, and so does the minmap of the world itself.
Just dont forget the other tall-climbables like registering mod-fences and/or support beams and other such things. Hell, a treetrunk style ladder type (for animation purposes) as suggested above would be pretty cool too.
maybe allow_tree_climbing true/false could be a value in the config file, and then one of the ladder types would be "log".
This would be particularly cool in TFC, as the leaves are set to non-solid, so you could climb straight up the tree.
Perhaps one could also set the climbing difficulty for certain ladders to be higher, and have it drain the smart moving endurance bar. (so you don't have people just climbing straight up a sequoia)
edit----
it occurs to me that for the ladders that stand alone in the middle of a block, it may make sense to query the block for which portions are solid so you animate the climbing according to the position of the solid ladder within the block. IT isn't required for functionality, but given that the blocks could be varying thicknesses having only one animation might look slightly derpy on thin vs thick or off-center vs centered ladders if someone were to make these.
Divisor I've been looking into compatibility issues with TFC &amp;&amp; carpenters blocks as you may recall. I think the best compatibility solution would be to have a registry of ladder types, basically another config file specifically for registering blocks from other mods.
entries should be able to be entered in reference either to ID or fully-specified classname (you could have it use reflection @ runtime to do the comparisons if you deem that sensible, so that if/when ids are changed in other mods users don't have to come back and edit the other config again if they KNOW the classname), then specifying what climbable type the ladder is.
distinct ladder types that I can think of currently:
vines/ropes (may animate differently, but not altogether different)
wall-mounted ladders (vanilla ladders behave like this)
stand-alone ladders
ladders that may be wall mounted OR standalone (Carpenter's Ladders)
Complex Logic ladders: (Defer to block's FML isLadder function, or potentially other named functions so long as they take standard arguments, should be possible with reflection or ASM commands) TFC has some wall chiseling patterns in its blocks that can become climbable if they meet certain shape-based rules.
There also needs to be a registry for fence-blocks, metal bars, and other from mods that may be entities or otherwise wouldn't work by default that the users think should be grab-climbables.
Stand alone refers to ladders like carpenter's ladders when placed in the center of a block that has no surfaces horizontally nearby.
I know that you've been trying to defer to the isLadder functions, but in my experience the functions are not always recognized or called properly, in part because smart moving does not have the capacity currently to know how to handle ladders that are not wall-mounted. (and thus have 2 climbable sides, a top and/or bottom, and 2 not climbable sides), and also because smart moving was checking for ladder identity against vanilla ladder & vine IDs instead of just asking whether the block was climbable and accepting that result as a valid isLadder boolean.
There should also be a way to register which meta-data values refer to which directional facing, in case they don't follow the vanilla standard with this.
This probably means you'll need to create some new facing objects to account for the behavior required by freestanding ladders. (i.e. they aren't just climbable only on one side, and they aren't climbable from ALL sides either, need to account for both whether the facing is N-S / E-W and how the player's avatar is approaching/facing the sides)
how would you handle orientation for "ladders" that are not wall-sided, but can be placed in the center of a block surface? (i.e. facing would be up or down rather than north/south/east/west). I think this lies at the root of the incompatibility for at least one other mod, but it definitely makes sense for that sort of option to be provided for mod ladders.
Also recommend you add some mechanism that allows other mods to tell smart moving which of their blocks and/or tile entities that should be treated as ladders, that way even if the main mod doesnt do it, we can always make a compatibility mod that registers the blocks on behalf of the mod we want to make compatible. I.e. create/change your own isLadder method to do a lookup in a list/arraylist/etc instead of a direct ID comparison to vanilla ladder/vine
Nope.
Seems that checking only against vanilla vine/ladder id is the problem, so I tried creating a mod-mod that uses ASM edits to change how smart moving works. It works perfectly except for 1 issue. I THINK Smart moving assumes ladders are against a wall, and when you approach a ladder that is freestanding it gets a nullpointer error.
is it just me or is the last version of NEI for 1.6.2 having weird texture and button label issues? I'd upgrade but the mods I use aren't 1.6.4 equipped yet.
Divisor I strongly urge you to add some sort of registry for ladders/vines/ropes/fences etc. I'm thinking an array of Enums the same size as Block.blockslist where the possibilities are None,LADDER,VINE,ROPE,FENCE, so your isThing(blockid) methods have a shot at working.
Also, it looks like your reflection call still isn't working, maybe you should move those isThing methods to another package and swap it out between a forge/non-forge version so you can just call it directly?
My thought is that you would use isVine,isLadder,isRope to determine what animation should be used, but use isClimbable for the final say on whether the player can actually climb the object or not (as a ladder) so that in forge mods the isLadder call takes precedence and gives the final boolean for it.
during the post-init step in forge, you can issue calls to all blocks testing if they return true to isLadder(null,0,0,0,null) & surround it with a try/catch, capturing any nullpointer or other exceptions that get issued, anything that returns true gets registered as a ladder and anything that returns false that isn't already registered is marked as None. This should auto-capture any ladders from mods that don't register their ladders, but are always-ladders. (some mods like TFC's slabs apply conditions to whether a block is climbable or not, so you can't reduce it to just true/false or an ID match)
I put together a small mod that ASM edits smart moving to test out whether this works, but it would be best if you took the idea and internalized it into smart moving. My current implementation uses a pair of ladder/vine arraylists, but I realized that was inneficient and will be switching it to some sort of array method shortly. I only plan to keep it maintained until smart moving change in a way that ladders work without intervention, it was done as a quick fix. I can post the link here if you give the ok, otherwise you can find it by searching for smart moving ladder registry
as a test, if you can, issue a WARNING log if the reflection call on isLadder returns a null. That will give instant feedback to you at runtime whether or not the reflection is working.
all I can tell you is the mod ladders dont work without my ASM edits in place.
Do you have a version control system and a build method description handy? I'd like to try to help you solve this and when I find a solution, I could put on a pull request or something similar.
Theres no pics for this, it doesnt add blocks it only changes the way smart moving checks for isLadder and isVine. The mod adds two registries for vines and ladders.During its post-init step it auto-registers any blocks that return true from a call to isLadder(null,0,0,0,null) as ladders, autocapturing any Nullpointer Exceptions. If you want smart moving to treat your block as a vine, you must register it.I suspect smart moving only checks isClimbable for vines and ladders, so if you have a block that is conditionally climbable, register it, as it will probably not auto-return true for automatic ladder registry.
If Divisor wants to have smart moving absorb this functionality i'm not against that, I just wanted smart moving to work with the ladders and ropes mods were adding to my worlds. Until he fully fixes the smart moving isLadder problem I'll try to keep this updated.to install this:You need minecraft forge. I haven't tested extensively on different versions but I built it with the 1.6.2-9.10.1.871 source.You also need smart moving 14.4 and its dependency Player Api.Install forge and place the mods in the mods directory of your chosen launcher profile's game directory.
WARNING: if you have a mod that allows placement of a ladder that is not against a wall, it will crash smart moving. I'm investigating why this occurs and have notified divisor.
0
is there a way to cure infected?
0
can't see the recipes in NEI at all. Does anybody know of a plugin?
0
Will there ever be a stable 1.7.10 build or has development focus shifted?
0
did he stop using his github? It still has a link to the site and the wiki, both of which don't appear to exist.
0
Has your developmental version been taking note of the changes to Mekanism API that are being made for version 8?
I tried to build from their github to use with AOBD and some other mods, but AOBD caused crashes by referring to API classes in mek that no longer exist.
0
server is using java version:
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
my client uses this java:
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
friend's client uses this java:
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
list of files & directories in client mods directory:
http://pastebin.com/j4sp3w75
list of files & directories in server mods directory
http://pastebin.com/gQ4Jqf8w
we are experiencing a crash when more than one player logs in.
Client experiences a series of exceptions like this one
0
OS: Win7 64 bit
cpu: AMD FX 8150 8-core 3.61 GHz
gpu: Nvidia GTX 260
RAM: 16GB (I tend to give MC permission to use 5GB b/c i'm running TFC and its historically memory heavy, tho it only seems to consume around 1.5-2 before glsl was added).
minecraft version is 1.6.4 as needed for TFC. This will be improved as they're working on bringing tfc to newer versions of MC but the focus is on bugfixes atm.
I can use lite version, any other version makes minecraft chug (down to 2-3 fps, and almost completely non-responsive inputs. (I remember to remove cloud shadows). Am I experiencing a hardware limitation or something else going wonky?
another note, i it seems to be specific to your shader pack, as i tested it with some others and not all of them do this, but it does WEIRD stuff to the mob radar in zan's minimap, you end up with large black occluding marks on the map around the units portraits, which shrink to almost single-pixel size. Player portraits still work, and so does the minmap of the world itself.
0
0
maybe allow_tree_climbing true/false could be a value in the config file, and then one of the ladder types would be "log".
This would be particularly cool in TFC, as the leaves are set to non-solid, so you could climb straight up the tree.
Perhaps one could also set the climbing difficulty for certain ladders to be higher, and have it drain the smart moving endurance bar. (so you don't have people just climbing straight up a sequoia)
edit----
it occurs to me that for the ladders that stand alone in the middle of a block, it may make sense to query the block for which portions are solid so you animate the climbing according to the position of the solid ladder within the block. IT isn't required for functionality, but given that the blocks could be varying thicknesses having only one animation might look slightly derpy on thin vs thick or off-center vs centered ladders if someone were to make these.
0
entries should be able to be entered in reference either to ID or fully-specified classname (you could have it use reflection @ runtime to do the comparisons if you deem that sensible, so that if/when ids are changed in other mods users don't have to come back and edit the other config again if they KNOW the classname), then specifying what climbable type the ladder is.
distinct ladder types that I can think of currently:
vines/ropes (may animate differently, but not altogether different)
wall-mounted ladders (vanilla ladders behave like this)
stand-alone ladders
ladders that may be wall mounted OR standalone (Carpenter's Ladders)
Complex Logic ladders: (Defer to block's FML isLadder function, or potentially other named functions so long as they take standard arguments, should be possible with reflection or ASM commands) TFC has some wall chiseling patterns in its blocks that can become climbable if they meet certain shape-based rules.
There also needs to be a registry for fence-blocks, metal bars, and other from mods that may be entities or otherwise wouldn't work by default that the users think should be grab-climbables.
Stand alone refers to ladders like carpenter's ladders when placed in the center of a block that has no surfaces horizontally nearby.
I know that you've been trying to defer to the isLadder functions, but in my experience the functions are not always recognized or called properly, in part because smart moving does not have the capacity currently to know how to handle ladders that are not wall-mounted. (and thus have 2 climbable sides, a top and/or bottom, and 2 not climbable sides), and also because smart moving was checking for ladder identity against vanilla ladder & vine IDs instead of just asking whether the block was climbable and accepting that result as a valid isLadder boolean.
There should also be a way to register which meta-data values refer to which directional facing, in case they don't follow the vanilla standard with this.
This probably means you'll need to create some new facing objects to account for the behavior required by freestanding ladders. (i.e. they aren't just climbable only on one side, and they aren't climbable from ALL sides either, need to account for both whether the facing is N-S / E-W and how the player's avatar is approaching/facing the sides)
0
Also recommend you add some mechanism that allows other mods to tell smart moving which of their blocks and/or tile entities that should be treated as ladders, that way even if the main mod doesnt do it, we can always make a compatibility mod that registers the blocks on behalf of the mod we want to make compatible. I.e. create/change your own isLadder method to do a lookup in a list/arraylist/etc instead of a direct ID comparison to vanilla ladder/vine
0
Nope.
Seems that checking only against vanilla vine/ladder id is the problem, so I tried creating a mod-mod that uses ASM edits to change how smart moving works. It works perfectly except for 1 issue. I THINK Smart moving assumes ladders are against a wall, and when you approach a ladder that is freestanding it gets a nullpointer error.
0
0
Also, it looks like your reflection call still isn't working, maybe you should move those isThing methods to another package and swap it out between a forge/non-forge version so you can just call it directly?
My thought is that you would use isVine,isLadder,isRope to determine what animation should be used, but use isClimbable for the final say on whether the player can actually climb the object or not (as a ladder) so that in forge mods the isLadder call takes precedence and gives the final boolean for it.
during the post-init step in forge, you can issue calls to all blocks testing if they return true to isLadder(null,0,0,0,null) & surround it with a try/catch, capturing any nullpointer or other exceptions that get issued, anything that returns true gets registered as a ladder and anything that returns false that isn't already registered is marked as None. This should auto-capture any ladders from mods that don't register their ladders, but are always-ladders. (some mods like TFC's slabs apply conditions to whether a block is climbable or not, so you can't reduce it to just true/false or an ID match)
I put together a small mod that ASM edits smart moving to test out whether this works, but it would be best if you took the idea and internalized it into smart moving. My current implementation uses a pair of ladder/vine arraylists, but I realized that was inneficient and will be switching it to some sort of array method shortly. I only plan to keep it maintained until smart moving change in a way that ladders work without intervention, it was done as a quick fix. I can post the link here if you give the ok, otherwise you can find it by searching for smart moving ladder registry
as a test, if you can, issue a WARNING log if the reflection call on isLadder returns a null. That will give instant feedback to you at runtime whether or not the reflection is working.
all I can tell you is the mod ladders dont work without my ASM edits in place.
Do you have a version control system and a build method description handy? I'd like to try to help you solve this and when I find a solution, I could put on a pull request or something similar.
1
---Download---
http://kotoro.com/mi...LadderRegistry/
---Repository for code and issues---
https://github.com/k...gLadderRegistry
If Divisor wants to have smart moving absorb this functionality i'm not against that, I just wanted smart moving to work with the ladders and ropes mods were adding to my worlds. Until he fully fixes the smart moving isLadder problem I'll try to keep this updated.to install this:You need minecraft forge. I haven't tested extensively on different versions but I built it with the 1.6.2-9.10.1.871 source.You also need smart moving 14.4 and its dependency Player Api.Install forge and place the mods in the mods directory of your chosen launcher profile's game directory.
WARNING: if you have a mod that allows placement of a ladder that is not against a wall, it will crash smart moving. I'm investigating why this occurs and have notified divisor.