Its troubling to see that almost no Minecraft packets sent to client come with a dimension id, and while in vanilla minecraft I can simply write the the bytebuffer before the packet gets sent, I can't seem to get access to packets sent from mods. More troubling is that once the packets are received they always default to Minecraft.getMinecraft().theWorld all on the assumption that there is only one world being watched at a time.

 

I know this is an annoying question but I've got the demonstration to justify it:

 

[embed=425,349]<iframe width="560" height="315" src="https://www.youtube.com/embed/r2b86Wv3HeY" frameborder="0" allowfullscreen></iframe>[/embed]

 

Any ideas on how I could get compatibility with mods similarly to the way I get it with default packets? If Lex would force a dimension parameter on all world packets it would be like Christmas morning and that would enable 100% compatibility with every mod that exists!

 

Unfortunately the odds of Lex delivering my Christmas are 0, and I can't be bothered with writing custom packets for every mod that exists. Is this even possible?

Each ship is its own world. This means everything works by default, but certain things like buildcraft like a will move items, but the packets that handle the visuals don't go through so you can't see them.

Couldn't your mod take any packet received by any one of your worlds and propagate the info to the other worlds?

After pondering on it the biggest problem is the fact that mod packets use Minecraft.getMinecraft().theWorld for applying changes to the world. I can easily intercept packets and repackage them, but the problem is by default the packets will only run on the Minecraft.theWorld . It is possible to change the world reference to the ones the packet would run in, and that would work. The problem is if the game tries to render while I have the Minecraft.theWorld changed then it just crashes.

 

Unless could there be a way to make different threads get different references for the same object?

 

What I'm saying is that if there was a way I could change theWorld value on the game thread, but not for the rendering thread then this would be 100% possible.

Sometimes this happens -- you come up with a clever architecture and start coding it and after a lot of work it is mostly working but then you find a fatal flaw in the approach. That might be your case.

 

Instead of multiple active client worlds, can't you recode the airships so they don't require different worlds?

I would suggest looking at meta worlds mod source. It does exactly this ("multiple worlds on client"). However, it required a lot of of bytecode changes and is still not updated from 1.6.4...

But then nothing would work. The whole point of multiple worlds is so that all things mods work on ships. As it stands you can build anything that works in default minecraft. Thankfully tile entity inventory packets are independent of the world so you can see changes in things like items piped into a chest.

 

The alternative which would be not having a world has the same problem, expect you can't even build things on it anymore D:

 

After doing some thinking I was wondering if it was possible to use ASM to do something along the following:

 

Replace ALL references to Minecraft.theWorld with a getter method that inputs the thread calling it. That way I would be able to change the world used by the game without changing the world used by the render thread.

 

Would that be possible and how would I implement it if it was?

 

As for Metaworlds none of that code works today. The reason he quit was because they changed block id's to block states and coordinates to blockPos. I wish that code had relevance today but it doesn't work D:

Replace ALL references to Minecraft.theWorld with a getter method that inputs the thread calling it. That way I would be able to change the world used by the game without changing the world used by the render thread.

 

That is an interesting idea.

 

By the way, are you sure you can't use some of the render events to make sure you're in proper world for rendering?

Forgot to say, you should know that yes, rendering happens on different thread, but lwjgl renders things from buffer of vertexes which is filled/changed by mincraft whenever there are new blocks to render or some blocks changed. This happens on main thread.

 

Also, few months ago i was working on mod that also requires having multiple worlds on clients. Haven't finished it yet though. What i want to say by this is that different modders may want to make multiple worlds on client. If ASM is used, mods will probabaly be incompatible as they change same parts of code. So the question appears: is there a need for multi-client-worlds-api?

...I wonder what happens if you run your mod along side Looking Glass.