Kinniken

No problem, I just assumed it still worked since it was there. Good to know my issue came from something simple like this. For the stream the reason I asked is because I have a lot of utility methods I wrote to read/write my custom objets and that currently use DataOutputStream/DataInputStream and are used both via the spawner interfaces and to send packets. So I'm wondering whether I should switch everything to the new streams.

Thanks. So ISpawnHandler is basically deprecated? Any reason for keeping it around? Also, I see the new one uses ByteArrayDataOutput. Is it recommended to switch to using those for all network communication?

As the topic says I'm having issues with ISpawnHandler - it doesn't seem to be firing at all. Even a simple log in writeSpawnData() fails to show. Has anything changed for it in Forge4? Note that my entities do get created client-side, just without their custom data. My entities are registered using ModLoader.registerEntityID() followed by EntityRegistry.registerModEntity(). Am I missing something? Thanks K.

Won't that always return client though if it's not a stand-alone server, even if the event is being triggered by a LAN player disconnecting, in which case it's really a "server-side" event?

Thanks, that works. I hadn't seen it because I do my own project configs due to wanting to use my existing workspace. This means BTW that the code in minecraftserver is no longer used at all? Very strange. And I get the same error when running it with your Eclipse workspace. I also tried zipping it and same deal. I guess I'll try and see if I can get an other Forge mod to work. Anyone has anything to suggest regarding this? :

I've been working on updating Millénaire to MC 1.3/Forge 4 and I finally got it to run. I like the new APIs and the general setup, but the upgrade is a bit steep I really like the new event system though. Anyway, I have a few questions linked to some stuff that's not working yet. The most important as the title say regards resource loading. In MC 1.2 I loaded my active textures that way: ImageIO.read((net.minecraft.client.Minecraft.class).getResource("/graphics/item/ML_om_amulet.png")); Where the PNG file is in mod/millenaire/graphics/item/ (not zipped). In 1.2 it worked fine, in 1.3 the resource is null. Has anything changed there? Same problem BTW with custom items, blocks and skins. Otherwise, two bonus questions: - is there a convenient way of knowing which side we are in in IConnectionHandler.connectionClosed()? And of getting the name of the user if it's server-side? It used to be possible to get it from the networkManager but that doesn't seem to work anymore. - in MCP, if I make an Eclipse project with the code from common and minecraft it compiles fine (with the proper libraries in the build path of course). However if I make one with common and minecraftserver, I get 20 compile errors, the most common being due to BaseMod missing (in ASMModParser and ModLoaderModContainer for instance). Is this normal? Is there a way of configuring a server env in MCP? Thanks! K.

Thanks, I had completely missed that thread!

What Jenkins are you people referring to? Isn't it http://lexmanos.no-ip.org:8080/? Because I'm not seeing the new releases there

Maybe I'm missing something but I can't see any recent build on Jenkins, the last one is #171 from the 3rd of August? Instead I tried using the "fml.zip" from GitHub, it works in that it decompiles and recompiles but it doesn't seem to include all the Forge classes.

Shared classloader is what I wanted to know. And I don't want to use it - that would defeat the point of having SP be handled as MP. I was in fact hoping it wasn't the case, now I have to review all my statics usage. And yeah, the new merged setup will be cool and help a lot

Quick question, does anyone who has played with the new code know how the classes are loaded in SP? I assume there's an instance of both Minecraft and MinecraftServer running, each with their own data interacting only via packets, but are they loaded in the same thread? And more specifically are the classes themselves shared (i.e. are static fields the same on both sides)? If yes I can look forward to quite a bit of restructuring.

I agree, in practice two packages will probably be better. I also have data that are not needed server-side like skins for instance. But still, having only one code base sounds very good

Sounds particularly good Will it be possible to ship a single mod for client and server or will obfuscation stop that?

Sounds interesting and ambitious. Also sounds like it will be quite a bit of work to move too Code-distribution-wise, how will SP work? It will be a package of SP+MP code?

Yeah, an update in four days would be quite impressive. Lex, do you foresee any change in how the Forge APIs will work due to the rework in 1.3? I assume that for MP mods things should be about the same, what about SP? And thanks for the quick work.

Actually Lex if you wanted something better a custom page with Google AdSense ads gives me better return than I had with Adf.ly (a bit better, not massively so), and AdSense doesn't show dodgy ads like adf.ly sometime does.

Thanks Lex, I was almost sure it was a length issue but hadn't been able to find the actual limit or even if it was a a "hard" limit. It's a bit annoying, restructuring my packet around that limit will be tricky, but at least I know what I have to do now.

Hi guys, Does anyone know what could cause a "bad packet ID 118" error on the client? I'm getting that in a new dev release of Millénaire. It seems to be triggered by a new packet type I've added (in my usual channel), that can include up to 30-40k of data (it's a packet sending missing content to the client if need be on login, i.e. for most players it will never get sent and when it is it will be once only, so the size shouldn't be an issue). Any ideas? Thanks K.

Well, that's true. Though it would still leave players having to make sure they get the precise update required by their servers. If they play on more than one it might not even work. Glad you enjoy the mod so much However I feel that with MP I shouldn't assume that every player does so much. There are bound to be users on a given server that do not care much about Millénaire, but need it to play on that specific server. So I want Millénaire not to bother them more than needed.

Well, looks like I'm alone on this... I'm surprised, how do other mod makers with client/server mods manage? Just force all the users of a server to upgrade whenever there's a new version, even a small one? I'm afraid that if I do that it will just annoy people needlessly.

Hi guys, This had been discussed in my Millénaire thread in this forum but I want to make it its own thread. This was the discussion so far: Lex, any chance of that happening? Thinking more about my future update plans I realise that what I really need is asymmetric compatibility - basically, when I add new features such as items or blocks, I can have the new client be backward compatible with older servers, but obviously not the reverse. With the toString() method this can't be done in any way I can think of. My only "solution" would be to keep the strings the same and then do my own check on start-up. Would anyone else feel the need for this? It could of course be made completely optional and backward compatible with the current system just by providing a default implementation of checkModMatch that does the same check as today (that toString() returns the same string on the client and server mods).

Cool, added mine.

Seconded, that would be very useful. 4096 blocks should be enough for everybody.

Ok thanks. Then I'll do that for times where the ordering is critical and just assume that they are in the correct order when it isn't.

Quick question: does anyone know if the packets sent by a mod are guaranteed to arrive in the order they are sent?