Its unlikely that the data manipulators have been implimented for them, maybe they have, but I have been back and forth between blocks and entities and how tspawning a falling block would be done. Is it a matter of offering a default block state the falling block data, or somehow offering blockstate data to a falling_block entity?
I have tried the following code, bypassing the optional stuff with a get to directly throw an error if nothing could be made and for why, but I see absolutely nothing happen other than the two bookend messages display with no errors logged.
public void spawnFallingBlock(Player p) {
Extent ext = p.getLocation().getExtent();
broadcast("Creating fb entity, fingers crossed");
BlockState dirt = BlockTypes.DIRT.getDefaultState();
//use GET only for now to trigger error if not implimented etc
Entity fb = ext.createEntity(EntityTypes.FALLING_BLOCK, p.getLocation().getPosition().add(5, 5, 5)).get();
fb.offer(Keys.FALLING_BLOCK_STATE, dirt);
ext.spawnEntity(fb, Cause.of(this));
broadcast("Spawned fb entity, what happened?");
}
What am I missing to additionally tack onto the entity / define the entity first, or am I going at this entirely wrong?
Confirmed no change in recent combination: Spongeforge 1543-794 , Forge 1543, API-107
FallingBlockData is not implemented just yet ;).
@gabizou Thanks for responding
Figured that would be the case, wondered why no error anywhere though - i guess there is an invisible falling_entity on my map just waiting for manefestation?
Is this code what would be used eventually to make falling dirt, or am I way off base?|
Your code is nearly identical to what I was planning to use for spawning falling blocks, so I would think it is the correct approach. Also, in the future, if you want to check if the Data Manipulators are implemented check https://github.com/SpongePowered/SpongeCommon/issues/8. In addition, you can request (in the comments of the issue) that a certain data manipulator be implemented. I requested AgentData and got a response pretty quickly.
I’m very glad to hear that, meguy26 (all of it) cause its giving me confidence that I’m actually grasping and soaking up a bit more of these new things each time I fiddle with them a while - actually hitting some working code and then modifying it, deconstructing the parts to do the ‘ah ha’ and apply to others is the supreme goal of course, but its a process.
@meguy, This is an update to this post for those who find it in searches etc.
Ive been using the falling blocks for a few days now and noticed there is a quirk, that just using the position of the block as the entity position results in the block spawning halfway offset, and most falling blocks then break by hitting other blocks
After a lot of trial and error, it seems that even after adding a 0.5 block offset to the x and z to compensate for the initial position isn’t solving the problem – reporting the block position every tick after falling shows that it …randomly… gets an x and z offset of small amounts 0.01 to 0.3 offsets so still, falling damages .
What does work to produce 100% straight-down falling drops, zero block damages is:
Entity fallingBlockEntity = blockLocationToFall.getExtent().createEntity(EntityTypes.FALLING_BLOCK, blockLocationToFall.getPosition().floor().add(0.5d, 0, 0.5d)).get();
it seems like a bug in something to provide a specific double spawnpoint, and the entity to actually be spawned ‘somewhere around there’, im just happy to have finally worked through several puzzles to make a "2 hour " plugin job (2h to build in bukkit, 15m to port to sponge) work after a couple days of various mystery behaviors like this, and may post concer/query about this behavior later.