Return on Server/Client

[American2050]

Few questions about the return for methods (Example: onBlockActivated) on the Block class.

 

Should we always return the same boolean server and Client side? If no, what would be exceptions to this.

 

Also. When we do need to return the same boolean both sides, what's the best way to do it, when some of our code should run only Server side?

 

Example: onBlockActivated and under certain conditions the method will spawn items (Entities) on the world, thing that should happen only Server side.

 

I do the conditions check on both sides, then I wrap my spawn entities on server side only and then outside this I return true?

 

[jabelar]

1 minute ago, American2050 said:

I do the conditions check on both sides, then I wrap my spawn entities on server side only and then outside this I return true?

Do it the other way around. Check if you're on server and then check the conditions.

 

Frankly it can be hard to know which methods run and return valid values on each side unless you trace it. If you have a couple methods you are specifically concerned about, just use the debugger or some console print statements to confirm. In the console statements it will tell you if it is running on the server or client ("main" thread).

[American2050]

1 minute ago, jabelar said:

Do it the other way around. Check if you're on server and then check the conditions.

 

Frankly it can be hard to know which methods run and return valid values on each side unless you trace it. If you have a couple methods you are specifically concerned about, just use the debugger or some console print statements to confirm. In the console statements it will tell you if it is running on the server or client ("main" thread).

 

But if I do the conditions check, only server side, how do I know client side if the conditions check on server triggered some action or not so I can return same boolean both sides?

[jabelar]

Just now, American2050 said:

 

But if I do the conditions check, only server side, how do I know client side if the conditions check on server triggered some action or not so I can return same boolean both sides?

What are you trying to do? Are you making custom blocks and worried about where the results will be used? Or are you using methods from blocks and wanting to make sure they lead to result you want?

 

Generally, if you're writing a method for custom blocks you should have it return the logically correct value. You shouldn't worry about which side it will be used.

 

Remember, the reason any game logic runs on the client is because the client needs to predict what the server will do. So best is to make sure client gets same values as server. Then if the client does use that method it gets the right value, and if it doesn't use the method then who cares?

 

In what case would you want the client to get a result that doesn't match the server?

[American2050]

Well I noticed in this case, when I right click on a block and the server does nothing, then the block I have in my hand gets placed next to my block, when I right click with other conditions, like holding a panel (an item) that goes into my block, everything is working correctly.

 

However, and as I'm doing like the Vanilla Furnace does and I check if world is client side, return true (100% the time) I notice that, when a block is placed, it doesn't plays the sound of a block been placed

 

Vanilla doesn't worry about it, because a right click on a furnace will always open a gui, but that's not the case for my block.

 

Quote

In what case would you want the client to get a result that doesn't match the server?

 

PS: That's what I was asking, I guess one case would be when I want something to happen on the block, but I don't want the player "swing" the hand? Isn't that one of the things that returning true client side in that method handles? it makes the player swing the hand, and maybe other stuff?

[jabelar]

Okay, that is an interesting situation. You basically want some of the vanilla block interaction but not all of it.

 

In this case I would recommend handling the RightClickBlock event and handling the case of your block (and cancel the event to avoid the further processing). On the client you would not return the SUCCESS since that would cause the arm swing, but on the server you would.

 

I think you can make that work, but still might be a bit tricky. Normally you don't use events on your own things, but in this case it does seem the best way to intercept the vanilla behavior.

Edited January 19, 2018 by jabelar