shieldbug1

It is for this case, I can just use sendToPlayer with the 'Response' without the request. I was just testing the request to make sure it works and it seems it does not. Could it be because the request packet is empty?

The request packet is empty from client > server and the response is sent back from server > client with appropriate details so that the client resyncs is information from the server. I'm sending the packet from the EntityConstructing event, I know that the event is called on both Server and Client. I check to make sure the entity is an instance of EntityPlayer, then check to make sure world.isRemote is true (So I'm only sending the request client side). The reason I'm using the Request/Response is because I'm going to need to use it in GUIs, and other client-only things where I can't send the 'response' directly. I was testing out to make sure it works first so I don't run into issues later.

I believe this is a problem with Java version 8 update 20. Use update 11 instead.

My Client > Server Request packets never seem to be being recieved on the server. I registered the message using NETWORK.registerMessage(MessageSyncEPP.Request.Handler.class, MessageSyncEPP.Request.class, 0, Side.SERVER); This is the Handler class: public static final class Handler implements IMessageHandler<Request, Response> { @Override public Response onMessage(Request message, MessageContext ctx) { System.out.println(String.format("REQUEST RECIEVED ON SIDE: %s", ForestMagic.instance.getSide())); LogHelper.packetRecieved(message); ExtendedPlayer properties = ExtendedPlayer.get(ctx.getServerHandler().playerEntity); Response response = new Response(); //ADD PROPERTIES HERE LogHelper.packetSent(response); return response; } } onMessage never seems to get called. I'm sending the packet like this MessageSyncEPP.Request request = new MessageSyncEPP.Request(); LogHelper.packetSent(request); NETWORK.sendToServer(request); The packetSent logging DOES happen, and it definitely happens from the client side. Is sendToServer not the proper way to send the message to the server? EDIT: Forgot to mention that my NETWORK variable is declared like this: public static final SimpleNetworkWrapper NETWORK = NetworkRegistry.INSTANCE.newSimpleChannel(Reference.MOD_ID.toLowerCase());

Okay, thank you for clearing that up. c:

I'm using IMessage and SimpleNetworkWrapper to sync things between client and server right now, whenever I try to run a dedicated server it crashes between PreInitialisation and Initialisation, because it tries to load EntityClientPlayerMP on the server side. Registering the message (this is the cause of the exception): NETWORK.registerMessage(MessageSyncEPP.Response.Handler.class, MessageSyncEPP.Response.class, 1, Side.CLIENT); The offending line (if I remove this line, it works fine): ExtendedPlayer properties = ExtendedPlayer.get(Minecraft.getMinecraft().thePlayer); The offending line is in my onMessage method of my Response.Handler class. From my understanding, registerMessage takes a handler, the packet it handles, an id, and the side it should be handled on. I know Minecraft.getMinecraft().thePlayer is Client only, but shouldn't the onMessage only be called on the client side (since I used Side.CLIENT as the last parameter in registerMessage)? On top of that, why is the onMessage being called in the preinitialisation stage, and why isn't it appearing in the stack trace?

What are you actually trying to do?

For glass you'd look at BlockEvent.BreakEvent. Just do your logic there. For obsidian there's PlayedEvent.BreakSpeed or something like that. I suggest you read on forge events.

You should only spawn items on the server.

The first one is canBonemeal. If returning true then the second gets called. It's shouldBonemeal. This is where you should put your check if you want it to actually grow (like I believe saplings use return random.nextFloat()< 0.6;). If that returns true then the void method gets called. I call it doGrow. Here is where you ACTUALLY grow your plant. Saplings calls it's markForGrowthAndGrow method from there. Now I'm not sure what the Boolean in the first method is, but from my testing it seems to be true on the client and false on the server. Not sure what use it has (since you can straight up do world.isRemote)

I haven't tested this, but this seems to do it. MinecraftServer.getServer().getConfigurationManager.func_152596_g(player.getGameProfile());

The client resets whenever it is restarted. You should only be saving mana on the server, and synchronising it with packets whenever you need it on the client.

You are trying to cast your blocks, into bytes. This is very basic Java. Solution: Don't cast your block into a byte.

Run gradlew setupDecompWorkspace again.

The error was not with railcraft, it was with the game running out of memory (look at the last line).

Put some debug statements there as well and see what gets called, and what doesn't.

Could you show your render code? I don't mess much with rendering, but if the proxy get's called then it has to be a problem with the renderer.

Set up some debug statements in your rendering code to see if it gets called when you expect it to.

Could you post your proxy code?

proxy.yourMethod(); This method should exist in both common/server proxy, and client proxy, but should be empty in the common/server proxy.

That shouldn't be it. If it isn't 15, then it sets the metadata to be one more than itself.

Put that line of code in your client proxy, and make sure to call it.

Well, that's client code, and rendering should ONLY go on the client through the client proxy. When you put it in the proxy, did the game still crash?

Not really. Metadata is stored. It's stored weirdly as an Integer, although it's values are never going to be outside the bounds of 0 and 15. You use bitwise AND, OR and XOR operations to determine things. So say you used the two bits on the right for rotation, and you wanted to see what type of log it was (the right two bits). You'd take the metadata and use a bitwise AND to do checks. Say you had the last type of log (11**) and the highest rotation value (**10). It's metadata would've been 1110. That translates to 8 + 4 + 2 = 14. So you would do metadata & 12 (1100), which would give you back 12 (1100). You'd then know for certain it's the last type of log. Take a look at the maths in the vanilla log classes.

You could give FMLNetworkEvent.ClientCustomPacketEvent a go. I haven't looked into it, but I'd assume chat messages, and the score board would update using packets. This will allow you to control both the packet that was received, and change the reply so that you might even get away with other clients seeing it the way you want to (as the server will get your information, and relay it to all other clients). Edit: Nevermind, that's only for custom packets. I misread, sorry.