Posts: 17
Threads: 6
Joined: Apr 2015
Thanks: 6
Given 2 thank(s) in 2 post(s)
05-04-2015, 08:15 AM
(This post was last modified: 05-04-2015, 05:42 PM by NathanFlurry.)
Hello,
I'm attempting to make a block break particle effect occur, but I've had no success. Among a couple alterations, I've attempted to do it with this code:
Code: world:BroadcastParticleEffect("blockdust_152_0", position.x, position.y + Receiver:GetHeight() / 2, position.z, particleRange, particleRange, particleRange, 0.3, 30)
However, the client only shows the default particle effect, meaning it doesn't work.
Can somebody help me out with this?
Thanks,
Nathan
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
I can't give you a big answer, because it's hard to type on my mobile, but here is an example:
World:BroadcastSoundParticleEffect(2001, a_BlockX, a_BlockY, a_BlockZ, BLOCKTYPE)
I believe it's done like this.
Posts: 17
Threads: 6
Joined: Apr 2015
Thanks: 6
Given 2 thank(s) in 2 post(s)
(05-04-2015, 08:38 AM)NiLSPACE Wrote: I can't give you a big answer, because it's hard to type on my mobile, but here is an example:
World:BroadcastSoundParticleEffect(2001, a_BlockX, a_BlockY, a_BlockZ, BLOCKTYPE)
I believe it's done like this.
Thanks, that works fine. However, I'd still like to know how one would do this without playing a sound.
Thanks,
Nathan
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
I don't think that's possible. Not because of MCServer, but because vanilla doesn't support it either.
Posts: 350
Threads: 18
Joined: Oct 2014
Thanks: 26
Given 54 thank(s) in 47 post(s)
05-05-2015, 07:29 AM
(This post was last modified: 05-05-2015, 07:32 AM by DiamondToaster.)
I think it might be possible. I think that the cWorld:BroadcastParticleEffect() function needs to be changed to put in block ID for the effect "blockdust" I can do this:
function OnPlayerRightClick(Player, BlockX, BlockY, BlockZ, BlockFace, CursorX, CursorY, CursorZ)
if BlockFace == BLOCK_FACE_NONE then
return false
end
local vec = Player:GetPosition() + Player:GetLookVector()
Player:GetWorld():BroadcastParticleEffect("blockdust", vec.x, vec.y, vec.z, 0, 0, 0, 0, 1)
return false
end
...but I run into protocol errors where the client gets kicked. The client spits out:
java.lang.IndexOutOfBoundsException: readerIndex(38) + length(1) exceeds writerIndex(38)
So it could probably be done without sound. I'm not a protocol expert though, so what I'm spouting out could be crap.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1074 thank(s) in 852 post(s)
05-05-2015, 07:35 AM
(This post was last modified: 05-05-2015, 07:35 AM by xoft.)
It seems that the protocol got extended in this packet ( http://wiki.vg/Protocol#Particle ) and we didn't notice / implement the change. It shouldn't be too difficult to implement, but the decision about how to interface the API is somewhat difficult - how do you represent something that has a variable number of parameters, in a future-proof manner? What if the protocol adds a new particle with 3 params in the next version? Etc. And you need to decide both C++ and Lua side of things.
Posts: 4,628
Threads: 115
Joined: Dec 2011
Thanks: 693
Given 494 thank(s) in 423 post(s)
We could make the function take a variable number of arguments?
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
On the lua side the interface seems obvious, just use varargs. On the c++ side it looks more complicated, and I'd be in favour of completely refactoring of how particle effects are broadcast. I'd personally like to move the logic out of cWorld/cChunkMap/cChunk to simplify things a little.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
I'm implementing this now. I've gone for an overload that takes a two element array for c++, which won't be used for one element, and varargs for lua. The lua API is extendable to longer data arrays and the c++ API works for now and can be easily extended. I had to add manual bindings for another refactor I'm doing so separate lua/c++ interfaces is not a issue. Whats more of an issue is what do you do if a plugin specifies data and the protocol doesn't support the additional data field. At the moment I'm ignoring it, but I'm not sure if that is the best answer.
|