coolAlias

EDIT: Found it. Sorry to be such a retard lately

EDIT: Open eula.txt in the working directory and change the value to true. I'm feeling pretty smart today... derp. Hi guys, After updating to Forge 1180, attempting to run a debug server in Eclipse always crashes with the following log: I tried deleting the old server world data, commenting out all my network code just in case, and even commenting out the entire code in my main class so it isn't loading anything, which leads me to believe it is a problem with my run configuration; I'm using GradleStartServer for my main class with no program or VM arguments - is that incorrect? Thanks for any assistance.

Thanks for that explanation - I don't know anything about how Java actually compiles code (always more to learn...), but that makes sense if using reflection causes a deeper analysis of a class. I wonder if it is at all possible to refactor IMessage and SimpleNetworkWrapper to not use reflection? I imagine many people will run into the same crash and have no idea what went wrong, especially coming from previous networking solutions that were less tricky to use :\ Thanks again.

Using the ItemMonsterPlacer code should be the way to go - do your custom entities fall into the ground moreso than vanilla entities? Have you registered your custom entities via EntityRegistry.registerModEntity? If all that fails, have you tried spawning them at posY + 1?

Oh... I did not know that... so why is it that in many cases simply nesting is enough? Some examples that will not crash the server: // in an event: @SubscribeEvent public void onHurt(LivingHurtEvent event) { if (event.entity.worldObj.isRemote) { // I don't do this - just an example! EntityPlayer player = Minecraft.getMinecraft().thePlayer; } } // in an item: @Override public ItemStack onItemRightClick(ItemStack stack, World world, EntityPlayer player) { if (world.isRemote) { // able to access objectmouseover, Keyboard and other client-side only stuff // without crashing server } } I could give many more examples that I have used previously, none of which have any problems loading client classes in a class that may be accessed on both sides. I have never had to resort to using proxies to access such things, but merely as a convenient place to register client-only classes such as renderers. In fact I've always thought modders who placed tons of things in their client proxy were doing unnecessary work, but it appears I don't understand this stuff nearly as well as I had thought. I promise I'm not trying to be obtuse, but I don't see what the difference is between my examples, which have worked perfectly fine for me, and the message classes above, which crash the server immediately. I've been going about modding very incorrectly this whole time if we're supposed to have always used proxies for this kind of thing. Is there perhaps a resource somewhere that explains this in more depth?

Yes, that does work, but it seems like a very bizarre step to have to take. I guess I'm just frustrated with the fickle behavior of SimpleNetworkWrapper and the lack of documentation explaining such nuances. The 'memory-leaky' network code never had any such trouble and was very easy to use, whereas now I feel like I'm jumping through hoops that most certainly shouldn't exist in the first place. Btw, does anyone know specifically which part of the wiki code causes a memory leak? It always worked without fail for me, and I didn't notice any memory problems, so I'm curious what's wrong with it. Anyway, thanks again for the responses.

It is looking for your Minecraft assets folder, which Gradle should set up for you automatically. Open the folder it specifies and see if you have both an 'indexes' and 'objects' folder; if you do, try restarting your IDE, sometimes that's all it needs; if not, try running 'gradlew --refresh-dependencies setupDecompWorkspace' again.

Thanks for the further insight, but I am still very confused; even when NOT using my abstract classes but instead implementing IMessageHandler directly (still as an inner class), the server will crash with the exact same error: public static class SyncPlayerPropsMessageHandler implements IMessageHandler<SyncPlayerPropsMessage, IMessage> { @Override public IMessage onMessage(SyncPlayerPropsMessage message, MessageContext ctx) { EntityPlayer player = Minecraft.getMinecraft().thePlayer; ExtendedPlayer.get(player).loadNBTData(message.data); return null; } } // crashes with: Caused by: java.lang.RuntimeException: Attempted to load class net/minecraft/client/entity/EntityClientPlayerMP for invalid side SERVER // pointing to the line that registers the above message class To me, this means that it is impossible to handle many client side messages, since the server will crash every single time even though this code should not be accessed during start-up. As a counter-example, the way the rest of Minecraft works: public class SomeRandomClass { public void someRandomMethod(World world) { if (world.isRemote) { // on the client EntityPlayer player = Minecraft.getMinecraft().thePlayer; // works perfectly fine } } } This has been my experience and understanding of the code so far - there has never been a need to use @SideOnly for stuff like this, simply checking side via the world or FMLCommonHandler is enough to segregate the code and prevent the server from trying to access it. But with SimpleNetworkWrapper, this does not seem to be the case. If we can't access things like Keyboard, Minecraft class, etc. in our client messages, then the network code seems fairly broken to me still. Of course it seems to work, but only on single player; has anyone been able to use it successfully for a wide variety of different messages in a server environment?

Thanks everyone for the various solutions - I think it should work now, though I get a funky server error that I've only seen with 1180: Anyway, I shall mark this as solved for now, but I find it very bizarre that the class loading is so fragile in this particular case. As larsgerrits mentioned and I already tried in my first attempts, usually nesting such code in an 'if (client side)' statement is enough, and as my println proved, the offending code was never even called, but FML still somehow both found and decided to load that class, which is even more surprising because no packets are even being sent at that point to trigger the onMessage method. Requiring such bizarre workarounds to simply get an EntityPlayer while handling a packet does not seem like the most ideal framework, but I don't know much about what needs to happen in FML so maybe it is the only way. I hope that a patch comes along soon that fixes this issue, if possible. Thanks again everyone.

Interesting; so how is one supposed to get the player in messages sent to the client in the IMessageHandler#onMessage class? public static class SyncPlayerPropsMessageHandler implements IMessageHandler<SyncPlayerPropsMessage, IMessage> { @Override public IMessage onMessage(SyncPlayerPropsMessage message, MessageContext ctx) { // THIS DOES NOT WORK: EntityPlayer player = Minecraft.getMinecraft().thePlayer; ExtendedPlayer.get(player).loadNBTData(message.data); return null; } }

Only for the client configuration, and they are the same as they have always been: -Dfml.ignoreInvalidMinecraftCertificates=true

If you want the message to appear for your custom blocks, then no, you can just override the onBlockPlacedBy method in your custom block class; if you want a message to appear for ALL blocks placed, then the simplest solution is to use PlayerInteractEvent for Action.RIGHT_CLICK_BLOCK. Access Transformers are needed less and less as Forge becomes more sophisticated (Forge uses them behind the scenes to make modding much easier for the rest of us).

No need to copy the inventory, and there are already methods that look for items, i.e. player.inventory.hasItem(Items.apple) and player.inventory.hasItemStack(ItemStack).

You can find one from here, put together by Vic, and you can also find them in the various Forge packages, namely in cpw.mods.fml.common.gameevent and net.minecraftforge.event. There are lots of nested classes in there, though, so you'll want to expand each file to see what else is available.

@Elyon: My PacketDispatcher class is just a wrapper for the SimpleNetworkWrapper: @GotoLink - interesting idea, I'll give it a try and let you know how it goes. EDIT: Nope, gives the same crash :\

Hey again, So I thought I had this server-client stuff all worked out, but I've run across a perplexing situation: trying to access Minecraft.getMinecraft(), even inside a conditional to check if we're on the client, causes the server to crash on startup, before the method that this is in can even be called! The offending class: A class implementing the above: Registering the messages is nothing out of the ordinary: // registered during pre-initialization dispatcher.registerMessage(OpenGuiMessage.OpenGuiMessageHandler.class, OpenGuiMessage.class, packetId++, Side.SERVER); dispatcher.registerMessage(SyncPlayerPropsMessage.SyncPlayerPropsMessageHandler.class, SyncPlayerPropsMessage.class, packetId++, Side.CLIENT); Crash Log: I have used similar code in many other classes without ever causing a problem, but for some reason this one seems to be an exception. So my question: Why is the above code attempting to load EntityClientPlayerMP during server startup, when the onMessage method should not even be called yet? At the very least, if I didn't check side and tried to access Minecraft.getMinecraft(), I would expect it to only crash when the line was actually reached in the code, but as can be seen from my println (which never prints), it never even tries to access Minecraft.getMinecraft(). Is this possibly a bug in FML, or am I just completely off base here? Thanks for reading, coolAlias

What version of Forge are you using? If it's not the latest recommended version (for 1.7.2), you should at least update to that as SimpleNetworkWrapper was not working correctly in some earlier versions.

A huge part of your problem is your 'upgrade stat' packet handler looks like it is handling the packet on the client side, but aren't you trying to send the packet to the server? // this is a client player: EntityPlayer player = Minecraft.getMinecraft().thePlayer; I can't see how you registered your packet, but it should be registered for Side.SERVER, i.e. the server receives the message from the client. You would then use 'ctx.getServerHandler().playerEntity' to get the player entity when handling the packet.

Every packet always has a player referenced somehow, so the easiest solution is to use player.worldObj, regardless of whether you're on the server or client.

^^^ Great stuff, there Pretty amazing for someone 'not too familiar' with Minecraft modding and Forge! @OP - don't take it personally that the tutorial you happened to watch has things wrong with it; it is certainly no reflection upon your character, but rather should spur you on to become more proficient in Java so you can select which tutorials to watch with a more discerning eye. At any rate, you have two methods that can affect the facing of your block: onBlockAdded, which you have call setDefaultDirection and I'm pretty sure is called every time a block is added to the world, and onBlockPlacedBy, in which you also set a direction, but which is only called when the player places a block. Now I can't remember in which order these are called, i.e. placed by player first or block added first, but that is where you should start your debugging. The fact that you still have a missing texture is concerning as well.

This gave me a good laugh I haven't watched the video in question, but I've seen others that were absolute garbage. Sadly, knowledge of Java is not required to make a video tutorial. @OP As many have mentioned, having at least a decent grasp of basic Java (or any other programming language) will help you immensely in your efforts at creating a mod. A site that I find myself going back to again and again is Oracle's own Java site, which not only has all of the Java docs, but also an excellent tutorial series on all the fundamentals that you will need. As for your code, first of all I recommend adding @Override above all your class methods, just to make sure you didn't make any typos in the names and such. Note that this only goes for inherited methods (i.e. ones that are from the vanilla 'Block' class). It looks like your png files are named correctly, so one thing that could be wrong is that Eclipse has not yet recognized the files as existing - this can happen if you copy/paste the files into your folder using Windows Explorer instead of pasting them in using Eclipse. Just to double-check, right-click your assets folder in the Eclipse package explorer and click 'Refresh' to re-scan the directory. This has happened to me lots of times.

That's just it, though: for passive mobs that never have an attack target, the 'entity to attack' should be the one that attacked them last (as seen in the attackEntityFrom method), from which they are now running away, assuming that there is no further logic in the sub-classes that nullifies that assumption. Getting that field from getAITarget should work, but I suppose you could set the lastAttacker manually if you are really set on that specific field

Every Entity has a world object, e.g. player.worldObj, but like diesieben07 mentioned, it sounds like you are perhaps going about whatever it is you are trying to do in the wrong way... so let me repeat the question: what are you trying to do?

Same way, but the method name has not yet been deobfuscated: world.func_147480_a = world.destroyBlock

Sure. You can view my entire source on Github (sorry, it's the 1.6.4 version of my mod on there still!), and here is a relevant snippet from the 1.7.x version (which is pretty much unchanged from 1.6): That's pretty much all you need. I use the exact same modifier value of 0.3D and operator '2' (which adds 30% of the current speed value, see the wiki) for almost all of my speed enhancing items and effects; using multiple of these at the same time, sprinting or running, has not yet caused any problems for me.