Jump to content

[1.8] Block and TileEntity Event (receiveClientEvent).


Ernio

Recommended Posts

Block:

public boolean onBlockEventReceived(World worldIn, BlockPos pos, IBlockState state, int eventID, int eventParam)
{
super.onBlockEventReceived(worldIn, pos, state, eventID, eventParam);
TileEntity tileentity = worldIn.getTileEntity(pos);
return tileentity == null ? false : tileentity.receiveClientEvent(eventID, eventParam);
}

TileEntity (example is from chest)

public boolean receiveClientEvent(int id, int type)
{
if (id == 1)
{
	this.numPlayersUsing = type;
	return true;
}
else
{
	return super.receiveClientEvent(id, type);
}
}

 

So there is this thing, used in few vanilla classes. Now, I tried to utilize it somehow, but didn't get far.

onBlockEventReceived is never called, no matter what I do, same goes (obviously) for receiveClientEvent.

Logically - they don't get called because there is no event for them to call.

How to add event to block for those methods to use, I can't find any vanilla declaration.

 

Also - how exacly does it work?

Is it like: client performs some action with id and value and sends action to server or other way around, thet you can update client int values using those methods?

 

This might be useful for e.g Buttons in my GuiContainer and/or sending changing values - depending on what does it do (the question above).

 

Thanks.

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

Nice, thanks.

 

Would you please validate my knowledge:

 

getDescriptionPacket() and onDataPacket(...) are called initially when client loads tileEntity, only once.

1. When else is it being called and can I force it?

 

receiveClientEvent() can be used to transport any integer to block/tileEntity.

2. Can/should it be called anywhere at any time? 3. I am guessing packet goes to everyone who loaded given BlockPos?

 

4. For any other synchronization I implement my own packet which will send x/y/z and data, or is there some other way I don't know about?

 

5. What exacly markDirty does? Tells Minecraft that chunk changed - what next? Is it "chunk changed, save it to disk" (still not sure)?

 

6. Should I know anything else regarding tileEntities (it's nice to know as much as possible)?

 

Thanks :D

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

Next part of MC in my head.

 

As I was diggin into code I actually hit this part:

- TEs are recreated when metadata changes unless you override shouldRefresh in the TE

 

I did some debugging:

- Printing worldObj.loadedTileEntityList and worldObj.tickableTileEntities sizes()

- Checking vanilla/breakpoints

- Printing when TE's constructor is called.

 

Results:

1. When shouldRefresh returns true both client and server will construct new TE - yet, that TE will NEVER be added to world's TE lists and will actually be discarded. I belive it is simply making sure that if in this pos there was no TE it would be set (but is not, since there is "old" TE), correct?

2. Sometimes Client constructs 2 TE for one server TE. Probably some synchronization stuff?

3. When shouldRefresh returns false - server STILL constructs new TE, only client doesn't.

 

Now what I want to know is to understand what the author of shouldRefresh docs had in mind saying:

/**
     * Called from Chunk.setBlockIDWithMetadata, determines if this tile entity should be re-created when the ID, or Metadata changes.
     * Use with caution as this will leave straggler TileEntities, or create conflicts with other TileEntities if not used properly.
     *
     * @param world Current world
     * @param pos Tile's world position
     * @param oldID The old ID of the block
     * @param newID The new ID of the block (May be the same)
     * @return True to remove the old tile entity, false to keep it in tact {and create a new one if the new values specify to}
     */

 

"if this tile entity should be re-created" - it doesn't seem to be recreated in any situation :C - when exacly that happens? "old" TE is never replaced by new one (new one is constructed), so what is "recreation" in this case?

 

"this will leave straggler TileEntities" - when?

 

"True to remove the old tile entity, false to keep it in tact" "create a new one if the new values specify to" - what?

 

EDIT

Indeed - when that will return false - server's TE is removed, client's one stays!

Where exacly is "danger" is bad usage of  this method? What can happen (aside client synchronization problems)?

 

Thanks :D

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

While I'm not sure exactly what the documentation is implying, I override shouldRefresh to return false for ALL of my TileEntities so that they behave identically to vanilla - if you look at the base implementation, NO vanilla TE will ever return true.

 

It's a mystery why the default behavior for modded TEs is opposite that of vanilla (per diesieben: "SOMETHING had to be chosen for the default..."), but I know people have run into unexpected issues because of it: their TE data suddenly disappearing after setting a state property, for example, so clearly the server side must also be getting refreshed, though your experiment seems to suggest otherwise.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.