Alright, I'm trying to do something cool (dealing with rendering), but the problem is that in order to do what I want, I need a world object (that is, I'm going to be rendering a location to a texture).

 

Problem is that at the code entry point for the rendering, there's no passed world object.  I have a dimension ID as well as position and look vector, but no world.

 

And no, I don't have a player object either.  Just a handful of strings and integers, none of which are particularly useful.

 

Thoughts?

Away from PC but may be you can do some looking in the client side only files (because this is rendering) for the world as a Varible that is private and use it because forge makes all variables public on run.

 

Also where are you using this?

I'm using this as part of an API package for another mod.  They expose a section for rendering some effects on a specific GUI screen--what I'm trying to do is a future-goal as it is, the mod author just hasn't figured out how they want to send the world information to do this rendering yet, thought I'd take a stab at it.

Hi

 

This might help

http://greyminecraftcoder.blogspot.com.au/2013/10/client-side-class-linkage-map.html

http://greyminecraftcoder.blogspot.com.au/2013/10/server-side-class-linkage-map.html

WorldClient is probably easy

WorldServer might be harder if you can't tell what world the player is in

 

-TGG

This might help

http://greyminecraftcoder.blogspot.com.au/2013/10/client-side-class-linkage-map.html

http://greyminecraftcoder.blogspot.com.au/2013/10/server-side-class-linkage-map.html

WorldClient is probably easy

WorldServer might be harder if you can't tell what world the player is in

 

I have a dimension ID of the location to render, which is not going to be the dimension that the player is currently in 95% of the time.

Rendering is client side.

There is only one world that renders at a time, Minecraft#theWorld.

Rendering things where the player isn't...is a complete waste of rendering power.

It think its for like a camera system like mod you would.

Can't you spawn a fake entity and teleport it to the dimension? Since you have the dimension ID you should be able to do that.

You will probably have to have some "camera" entity or whatever there anyways to project the view, so it might work?

...is a complete waste of rendering power.

 

Because seeing where a portal-like-object is going to take you before you go is a waste. :U

 

Can't you spawn a fake entity and teleport it to the dimension? Since you have the dimension ID you should be able to do that.

You will probably have to have some "camera" entity or whatever there anyways to project the view, so it might work?

 

Hmm.  Wouldn't I need a world to spawn the object into first?

Hi

 

Hmmm that sounds pretty ambitious.  I had a quick look through NetClientHandler.handleRespawn() and it looks like you would have a lot of work to do in order to set up the second world properly, and I'm not sure that you could actually happily co-exist two WorldClients at the same time.

 

You might be able to get the effect you want if you actually teleport the player to the new dimension but "freeze" the game from updating or somehow prevent the player from appearing in the world or interacting with it, until they "commit" to the teleport.

 

-TGG

 

 

...is a complete waste of rendering power.

 

Because seeing where a portal-like-object is going to take you before you go is a waste. :U

Indeed. The client do not have any information about the other dimensions before going in because it is a waste.

Imagine you have that second entity in the other world. You'll need to forward every packets from that entity, and rebuild the rendering process for each client being forwarded.

 

Anyway...you can use DimensionManager#getWorld(int) to get a world object from its dimension id.

and rebuild the rendering process for each client being forwarded.

 

It'd actually be "one client" most of the time, as it's not drawing the result in the world, but rather in a GUI.

But yes, that does pretty much account for the work that needs to be done.

 

Hmmm that sounds pretty ambitious. 

 

You might be able to get the effect you want if you actually teleport the player to the new dimension but "freeze" the game from updating or somehow prevent the player from appearing in the world or interacting with it, until they "commit" to the teleport.

 

May or may not work.  Imagine if the link destination is entirely covered in lava....

Teleport them to a safe place in the new world, then change their rendering viewpoint to correspond to the portal location?

 

-TGG

Teleport them to a safe place in the new world, then change their rendering viewpoint to correspond to the portal location?

 

Define "safe place" that doesn't involve modifying the blocks that are already there.  Keep in mind that "sky exposure" is potentially deadly.

 

In any case, I think I have a solution.

keen.  Let us know how it goes?

 

-TGG

Earlier test:

http://s18.postimg.org/5leo4j8ih/2013_11_08_13_35_01.png[/img]

Render occurred before the client had block and weather data, so all it managed to screenshot was the dimension's two suns.

 

But it totally worked.

Mystcraft?

But it totally worked.

Sweet!

 

Mystcraft?

 

Yup.  I'm doing a plugin.

 

Working on increasing my texture size.  64x64 is just NOT enough.  But that means breaking the data into smaller packets.  >..x

Custom packet with an array woukd help you.

Custom packet with an array woukd help you.

 

PACKET SIZE is the limiting factor, not what KIND of packet.

Hi

 

During my browsings I have noticed something called FMLPacket which splits its data into packets of 32000 bytes and reassembles at the other end.

 

That's all I know (didn't look further) but it might be of interest to you?

 

-TGG

Hi

 

During my browsings I have noticed something called FMLPacket which splits its data into packets of 32000 bytes and reassembles at the other end.

 

That's all I know (didn't look further) but it might be of interest to you?

 

-TGG

 

I'll take a look.  I do have my system fully functional using 4 packets right now (the first one locks in data editing until the fourth one from a matching source comes through) and other than some positioning data getting corrupted slightly between "saving the result" and "loading it from disc to send back to the client" things are working.

(As in, the destination is getting offset by 1 block, preventing the server from locating the existing render)