[SOLVED] [1.7.10] Cross-dimensional chunk loading/rendering, server & client

[Elyon]

Hi!

 

 

I have been toying with forced chunk loading through the

ForgeChunkManager

.

 

I have tried following the suggestions in this and that topic, but either they are too vague or I am too daft to make it work.

 

 

Either way, I am successfully registering my (stub)

LoadingCallback

class in

CommonProxy

:

 

public void preInit(FMLPreInitializationEvent event) {
    super.preInit(event);
    ForgeChunkManager.setForcedChunkLoadingCallback(Chocolate.instance, null);
}

 

As it needs to work for both the combined client/server singleplayer experience, as well as for dedicated servers, I felt I couldn't put it in

ServerProxy

.

 

My Block class similarly successfully requests a ticket and forces the chunk:

 

@Override
public void onBlockAdded(World world, int x, int y, int z) {
    super.onBlockAdded(world, x, y, z);

    if (!world.isRemote && this.ticket == null) {
        this.ticket = ForgeChunkManager.requestTicket(Chocolate.instance, DimensionManager.getWorld(1), ForgeChunkManager.Type.NORMAL);

        if (this.ticket != null) {
            ForgeChunkManager.forceChunk(this.ticket, new ChunkCoordIntPair(0, 0));
            FMLLog.info("Forcing chunk ( %d , %d )", 0, 0);
        }
    }
}

 

I have tried to paste only the related bits of code, but please let me know if I ought to paste more code. These are the only bits I have that relate to chunk loading, though.

 

Note that I am well aware the

ticket

field (and indeed, the instance) of my Block class is shared across all blocks of that class. Currently I am simply testing whether I can force chunk ( 0 , 0 ) in the Nether to be loaded while I am in the overworld.

 

I built a simple command block clock completely within chunk ( 0 , 0 ) that outputs "Nether" to the chat once per second whenever it is loaded. If I travel to the Nether, it joyfully chirps "Nether" every second, but as soon as I leave the Nether, it ceases to do so.

 

 

Certainly, I am just missing something obvious, here - but I have no idea what grave oversight I have made.

 

 

-----

 

 

As a bonus/follow-up question that need not be answered (I will be working on it myself, soon as I can get regular cross-dimensional chunk loading working):

 

How would I go about force-loading chunks not only serverside, but clientside as well?

 

I would like to be able to load chunks cross-dimension for rendering remote Nether regio-- uh. Remote chunks in the Nether. Yes.

 

 

Any feedback/constructive criticism will be appreciated

 

Thanks!

[Elyon]

Ah, yes. The log.

 

The "Forcing chunk" message is being printed (and only once, when the block is added).

 

From that, and from the fact there is no errors or warnings or otherwise indications that the call had failed, I make the assumption that the

ForgeChunkManager#forceChunk

call succeeds, as well.

 

There aren't any gotcha's regarding cross-dimension chunk loading, I presume?

 

 

As for chunk loading cross-dimension on the client side - I guess I will have to reimplement what I need for my idea to work, then.

 

It really is vital for me that both the Overworld and the Nether are rendered simultaenously without unloading one or the other, sadly.

 

 

EDIT: You are right, there is no good reason to even keep a CommonProxy, when I might just as well put the code there in my main mod class. Thank you!

[Elyon]

Hmm. I will try having a go at outputting the values of the various fields of the

ForgeChunkManager

cache, to see if I can pinpoint the issue.

 

You'll most likely need a RenderGlobal instance for every additional World you're gonna load, because that is what manages the chunk renderers (chunk as in rendering chunk = 16 x 16 x 16).

I figured as much. Well, thank you, now I know that approach is probably the best (only) way to go about it. I have already written quite a bit of a custom world renderer, so it shouldn't be too difficult to keep another instance of

RenderGlobal

around specifically for that renderer.

 

I realise the client was never meant to be in more than one dimension at once, but I am sure I can work around that. I may turn to asking more questions about this approach, once I can get the server chunk loader (a prerequisite for client chunk loading, I presume) working.

 

Again, thank you for your input.

 

I will update this thread once I solve the issues mentioned.

[Elyon]

Welp.

 

For future reference, the Nether is dimension -1, not 1.

 

The chunk now loads as expected, and the command block clock chirps away even while I am in the overworld, having never entered the Nether.

 

 

Now, I am wondering how to fetch the Nether chunks while in the Overworld on the client.

 

Since I have no experience with packets in Minecraft, this seems a daunting task. I will give it a go and report my findings.

 

In the meantime, any additional pointers to the best course of action will be immensely positively received

[Elyon]

I went ahead and worked some more on clientside loading and rendering of chunks.

 

 

This is the current modus operandi:

• Client adds block in overworld
  
• Server sends ChunkMessage to client
  
• Client parses chunk message, gets chunk from separate WorldClient, fills chunk with received data, and marks it for render update
  
• Client's RenderCamera calls renderWorld after setting up basic rendering stuff
  
• Separate RenderGlobal with the WorldClient from above calls sortAndRender
  

Everything in that list seems to work by itself, according to numerous FMLLog#init calls, as well as the fact that using Minecraft's native RenderGlobal/WorldClient renders the overworld exactly as expected at the given coordinates.

 

However, using a separate RenderGlobal/WorldClient (as initialized in RenderCamera#initialize, called in ChunkMessage.Handler#onMessage), populated as described above and seen in the ChunkMessage.Handler class, only the sky is rendered.

 

Disabling the call to RenderGlobal#renderSky() for the separate RenderGlobal/WorldClient pair - which I have done in the pasted code already - leaves me with the result of having an absolutely transparent quad.

 

 

As said, most if not all the items in the list work as expected on their own, and I suspect the issue is related to what happens between Chunk#fillChunk and RenderGlobal#sortAndRender. However, I cannot pinpoint why the sortAndRender call does not work for the separate RenderGlobal/WorldClient pair with the populated chunk data.

 

I have been combing over the vanilla/forge classes to try gaining some insight into what I must do for these "fake" filled chunks to render, but so far, I have come up with nothing.

 

 

Any input on the matter will be immensely appreciated. If there is any more info I should provide (there are no error logs as there are no errors), I will try my very best to do so.

 

I cannot imagine how the issue could be found anywhere else than in the code I have posted, though.

 

 

Thank you for your time!

[GotoLink]

Well, there is only one Minecraft#renderViewEntity...did you move it to the other dimension or make another ?

[Elyon]

Ah, it seems I forgot to paste the code where I instantiate a new EntityCamera for use as

renderViewEntity

, as well as where I set that. Thanks for pointing that out!

 

I have since moved some things around, still to the same effect, though:

 

I instantiate a new clientside EntityCamera on line 60 of RenderCamera. EntityCamera is just a stub descendant of EntityLivingBase.

 

Furthermore, before the call to

RenderCamera#renderWorld

, I made sure to set the

Minecraft#renderViewEntity

to this EntityCamera instance. After the call, I reset it.

 

I have moved this getting and setting of

Minecraft#renderViewEntity

into RenderCamera#renderWorld, as can be seen in the updated paste from the paragraph above.

 

 

As said, this whole setup works brilliantly so long as I use

Minecraft#renderGlobal

and

Minecraft#theWorld

, though - but that renders only the current dimension, not specifically the Nether.

 

Thank you very much for your input, and my apologies for not having pasted the code where I instantiate and set a new renderViewEntity!

[Elyon]

After digging around in various vanilla rendering classes, I figured out the issue:

 

I needed to call

RenderGlobal#updateRenderers

before calling

RenderGlobal#sortAndRender

.

 

I more or less consider the issue solved, but I will wait a few hours and see if I stumble upon any more clientside chunk rendering issues related to this thread before marking it [sOLVED].

[Elyon]

I have been working hard on making clientside chunk loading/rendering done, and I have made great progress.

 

Now (and for the past two days), however, I am faced with the issue of only chunks with positive X and Z coordinates render. For some - to me inexplicable - reason, chunks with negative X or Z coordinates refuse to render.

 

I have verified that the chunk data for all chunks is:

• Serialised properly by the server
  
• Sent by the server
  
• Received by the client
  
• Assembled by the client
  
• Filled into the correct chunks on the client
  
• Existing on the client at the time of rendering
  

 

Yet the custom world chunks at (0, 0) and all other positive coordinates render flawlessly, while not a single custom world chunk at (0, -1) or any other negative coordinate combination render at all.

 

I have dug through the entirety of the RenderGlobal and WorldRenderer classes, inserting conditional breakpoints and outputting various values, but nothing at all seems out of place in my renderGlobal instance compared to the default renderGlobal instance's way of handling things.

 

These are the related parts of my

EntityCamera

class, and just in case it might be a problem with the chunk block injection, here is the

ChunkResponse.Handler

class, as well.

 

Bear in mind I have verified that the data received is correct, and that all the chunks stay populated both pre- and postrender.

 

 

EDIT: If you don't clip your renderers, it'll just clip with the last clipping used - in this case, that was along the X- and Z-axes.