Kinniken

Hi guys, I've updated my mod to the new network system and got packets from the client to the server to work fine at least at a network level. I'm having issues with server-to-client packets however. I create them the following way: public static void displayNewVillageGUI(EntityPlayer player, Point pos) { final ByteBufOutputStream data = getNewByteBufOutputStream(); try { data.write(ServerReceiver.PACKET_OPENGUI); data.write(CommonGuiHandler.GUI_NEWVILLAGE); StreamReadWrite.writeNullablePoint(pos, data); } catch (final IOException e) { MLN.printException(ServerSender.class+": Error in displayNewVillageGUI", e); } sendPacketToPlayer(createServerPacket(data), player); } public static S3FPacketCustomPayload createServerPacket(ByteBufOutputStream data) { return new S3FPacketCustomPayload(ServerReceiver.PACKET_CHANNEL, data.buffer()); } public static void sendPacketToPlayer(Packet packet, EntityPlayer player) { ((EntityPlayerMP)player).playerNetServerHandler.sendPacket(packet); } And then read them the following way: @SubscribeEvent public void onPacketData(ServerCustomPacketEvent event) { if (FMLCommonHandler.instance().getSide().isServer() && (MLN.LogNetwork>=MLN.MAJOR)) { MLN.major(this, "Received a packet despite being server."); return; } if (event.packet==null) { MLN.error(this, "Received a null packet!"); return; } if (event.packet.payload()==null) { MLN.error(this, "Received a packet with null data on channel: "+event.packet.channel()); return; } if (Mill.clientWorld==null) { MLN.error(this, "Received a packet despite null clientWorld."); return; } ByteBufInputStream data = new ByteBufInputStream(event.packet.payload()); try { final int packettype=data.read(); Mill.clientWorld.millenaireEnabled=true; if (MLN.LogNetwork>=MLN.DEBUG) { MLN.debug(this, "Received client packet type: "+packettype); } (...) } catch (final Exception e) { MLN.printException("Error in ClientReceiver.onPacketData:", e); } } In the packet I gave as example above, the first data written in ("data.write(ServerReceiver.PACKET_OPENGUI);") is 104. On the client side however when I try to read it I get 0. If I look at the content of the packet on the server side and then on the client side using the debugger I get the two attachments below. As you can see most of the content is the same (and fits what I wrote in my packet), but the beginning isn't. On the client side the first byte has changed from 104 to -56. Server: https://dl.dropboxusercontent.com/u/14307461/temp/forge/Capture%20d%E2%80%99%C3%A9cran%202014-03-15%20%C3%A0%2012.27.12.png[/img] Client: https://dl.dropboxusercontent.com/u/14307461/temp/forge/Capture%20d%E2%80%99%C3%A9cran%202014-03-15%20%C3%A0%2012.26.32.png[/img] I assume I must be miss-using the new system in some ways, anybody knows more? BTW my client-to-server code is almost exactly the same, but uses the C17PacketCustomPayload class. Thanks!

I did not mean to imply that I was expecting people to find my mod in my signature. Just that my question was not related to a specific bit of code but to a more general question on the working of Forge. Not every issue can be narrowed-down to 20 lines of code

sequituri, my mod's line count is of around 45 000 lines (Minecraft itself is around 230 000). The init part alone spans a dozen classes. Bit hard to quote it all Thanks Zzyxz, it was that! That and declaring my blocks and items in load and not preInit, which worked in 1.6 but apparently not in 1.7. And apparently changing the language causes Minecraft to refresh its resources, which explains why that solved it for me. Any idea why the language doesn't change though? Is it a bug specific to my setup or a more general one?

Hi guys, I've finally gotten my mod to compile in 1.7.2 and not to crash while loading... whew. I have a weird problem though: if I launch Minecraft (from Eclipse/MCP) and check my blocks/items in the creative mode inventory, they all have missing textures. If I try to change Minecraft's running language however, they work (for this launch - relaunching the game gives me the issue again). Bonus weirdness, the in-game language has not actually changed, it stays English. It's entirely possible that this is due entirely from my code - I do have some logic tied to language changes, though nothing to do with textures. But if anybody had an idea of what could cause something like this, it would be great. Thanks K.

Indeed not. Then I guess the proper way to do things will be to setup my own blocks and items in @Init but build up my datastructures in @PostInit. Works for me. Now only 2000+ compilation errors to go through and I can test it

That's exactly what I was looking for, thanks!

Well, I guess I'll make my own reference table then. I have an other question regarding the life-cycle of the items and blocks objects - are they stable throughout a Minecraft run? With Minecraft only updating the ids if switching to a world that has a different ID config? I'm asking because I'm in the process of switching the references in my Millénaire objects loaded at startup from using ids to using direct references to the items and blocks. Should that be normally safe across worlds? Or should I avoid doing things like this at startup and instead move it to the world loading events?

I can't even being to image the work that would be required to provide a reasonably complete API for Minecraft in a non-JVM language...

I might be missing something obvious, but is there a way to get the item/block name (the minecraft:sandstone one) from the block or item object? It doesn't seem to get stored in the object itself and it does not always match getUnlocalizedName(). BTW, the new gradle setup is excellent. Very easy to setup and clean dev environment.

Ok great, that solves it. Thanks.

Sounds good, that's what I was hoping. The one thing ID-wise that I was doing that no longer seems possible though is for Millénaire content makers to "register" new blocks and items for use by Millénaire via text files, by giving the id and a name for the item/block. Is there any other way to identity an item or block from an other mod?

Hi, I've started working on updating Millénaire to 1.7. Just a question regarding the new system of dropping item and block ids: how does that work for saving and transmitting references to blocks and items? Should I still use ids for that? That's what ItemStack seems to be doing in its readFromNBT method. Is there a guarantee that for the same world ids will be persistent across clients (in MP- and across saves and reloads? Thanks K.

OK, thanks. Then yes no point on working on my own version of ForgePacket.

Hi Lex, Is there any info on the web on the differences between 1.6 and 1.7? Just to get an idea of what I'll be facing Also, do you know if there are any planned changes to the Forge packet system? Thanks to ProfMoebius I finally know that the occasional Millénaire client crashes are due to trying to send packets larger than the limit, so I'd like to know if there is any point working on a solution in 1.6 or if that code is going to be impacted in 1.7 anyway. Thanks

I solved it that way too, though I put the call in the constructor to avoid doing every tick. Weird system though.

You're right, and I was making the same mistake, testing on existing entities. Did you find a way to set it for existing entities though? At least for 1.5 worlds it will be needed. And so far at least I don't really get the point of the new system. If it was just to enable horses with custom attributes there were more straightforward ways of implementing it...

I'm having the same issue. Increasing the value makes the mobs a little less glacially slow, but nowhere near normal speed.

So if I understand correctly upgrading to the latest Forge release should fix it? Awesome news. I'll let my users know and see if it fixes it for them. Edit: is this server-side or client-side in MP? Or do both need to be upgraded?

I'm having no luck at all with this. And it seems I was wrong to think it was linked to the chunks loading/unloading - one player has reported (with screenshots from a video he was recording) a villager disappearing client-side in front of him, maybe twenty blocks away. Very annoying. AM I really the only one with this issue?

Thanks for all the information, it makes things clearer. I hadn't realised that Forge ran Minecraft in deobf mode. BTW if you tested Millénaire using the latest version (4.6) it was a version-independent one. And yes I know MCP is conservative when it comes to renaming methods. For my 1.5.1 update most of them were indeed new 1.5 methods getting a proper name for the first time. In the past I've noticed real renames mainly on major version bump - I assume because they felt that it's the good time to do it, as people have to update anyway (and I agree). Anyway, so with no speed difference to speak of, I guess I'll continue using the new feature. That it works over bug fix versions is really nice. My only concern is that for major updates it will likely "mostly work" with unpredictable crashes wherever Mojang changed the code. That could potentially lead to nasty bugs, maybe data-destroying ones (hard to say since it will depend on what has changed, of course). Maybe a setting could be added to forbid a mod from running in a different major version? And good luck with MCPC+, it's really a cool product.

Ok, thanks for the review LexManos. I had not realised that the "srg" names were the "field_1234_b" ones, not the user-friendly ones. With that setup yes most mods should indeed work across bug fixes. IIRC when I updated Millénaire to 1.5.1 the only compilation errors were due to mapped names changing. Any performance hit in that new setup though? The srg names must be remapped to the obfuscated ones when MC runs right, doesn't that slow thing down a bit?

Thanks, that worked! And my mod now runs in MCPC 1.5.1. Any particular pros and cons of using this BTW? Beyond of course that my mod will no longer be affected by changes in obfuscation (but will still likely need updating due to change in method signatures etc. in about every version)?

Hi guys, Is there any doc somewhere on releasing a version-independent mod? I know it's supposed to be possible now but couldn't find any instructions. Just using the compiled but not reobfuscated code from mcp/bin doesn't work for me, I get this early in my mod's loading (probably the first call to an MC method): java.lang.NoSuchMethodError: net.minecraft.client.Minecraft.getMinecraftDir()Ljava/io/File; I'm not so much interested in releasing version-independent client versions (even without the reobf my experience is that every MC releases except for some bug fix ones break Millénaire anyway) but in testing MCPC+ for 1.5.1. Thanks K.

I'll check that radius thing. To be clearer, they are not really "invisible", they are absent client-side. If I use getEntitiesWithinAABB() on the client and the server at the same time around the player I'll find them all server-side but will miss some client-side. Anyway, I'll see if I can narrow it down.

I'd like to bump this. I'm still getting it in MC 1.5.1 with the latest version of Forge, same symptoms. As far as I can tell new villagers spawn properly client-side, but if the player moves away from the village and comes back, sometime they go missing (always client-side only). Saving and reloading the world (SP) or disconnecting and reconnecting (MP) solves the problem, until the next occurrence at least. Any idea welcome, it's now clearly Millénaire's most annoying bug.