How to use Data API 2.0

How would one change the respawn location of a player in a given world?

With RespawnLocationData.

/**
* Returns true if the data was set successfully.
*/
public boolean setRespawnLocation(Player player, Location<World> location) {
    RespawnLocationData data = player.getOrCreate(RespawnLocationData.class).get(); // It's a player, assume it can be created
    data.respawnLocation().put(location.getExtent().getUniqueId(), location.getPosition());
    return player.offer(data).getType() == DataTransactionResult.Type.SUCCESS;
}

@simon816 Thanks for the reply, I noticed setRespawnLocation in the docs, however, when I get an instance of RespawnLocationData from the player it doesn’t have that method. I’m assuming it hasn’t been merged yet or some changes are being made, however I can accomplish the same thing using the implementation you have provided, thanks!

That’s on the PlayerRespawnEvent, the event has some convenience methods, including getRespawnLocation() and setNewRespawnLocation(Location)

Ah, my mistake for not clarifying, I was trying to accomplish this outside of the PlayerRespawnEvent. Thanks.

Thanks for the comments guys.

Be patient with us, we are getting data implemented as fast as we can. Loving the interest so far.

I just tried velocity data on the latest sponge, after updating my dependencies, and I get this error:

java.lang.NoSuchFieldError: VELOCITY

This is my code:

Optional<Vector3d> optional = entity.get(Keys.VELOCITY);
if (optional.isPresent()) {
    final Vector3d velocity = optional.get();
    double x = velocity.getX();
    double y = velocity.getY();
    double z = velocity.getZ();
    getLogger().info("Vector3d<" + x + ", " + y + ", " + z + ">");
 }

any thoughts?

Create a class called MyCustomData and have it extend DataManipulator<MyCustomData, MyImmutableCustomData> and create a class called MyImmutableCustomData and have it extend ImmutableDataManipulator<MyImmutableCustomData, MyCustomData>. Then implement the methods as necessary, generate some Keys and Values for use, and make absolutely sure that you register a DataBuilder<MyCustomData> and DataBuilder<MyImmutableCustomData> so that your custom data can be properly deserialized.

I’m planning on helping @Tzk to document how to get from start to finish with custom data, but as long as you follow the contracts as dictated by the API, you should be able to player.offer(myCustomData) at will, and know that it will persist. Of course, the primary issue at the moment is that custom data doesn’t actually get stored on anything yet, the implementation is pending on my part.

You’d have to wait for some of the BlockState specific data is actually implemented. For now, I can provide you with a snippet of code that will work when everything is properly implemented:

public void setBlockToGranite(Location location) {
  location.setBlock(BlockTypes.STONE.getDefaultState().with(Keys.STONE_TYPE, StoneTypes.SMOOTH_GRANITE));
}

Not yet. Saving arbitrary data to blocks will likely require some further thought, but for Players, it will be simple enough soon.

Yes. It will be well documented on the SpongeDocs.

Sponge might not be updated for SpongeCommon, in which case, probably we need to bump the SpongeCommon dependency…

Also, sorry for taking so long to reply, been busy the last day and a half.

4 Likes

After offering velocity data on an entity (in my case a Player), I get a DataTransactionResult of “SUCCESS”, however there are no visible results, and no errors.

Like if I do this ^ on every tick, nothing happens. Any ideas?

Thanks for your feedback, gabizou
I have been tunnel-visioned on trying to make a granite block and going through every variation of things I could throw at it, paralleling previous documenation, feeling out the api objects/returns… the construct you give is exactly the ‘intuitive’ form that I first came up with out of all those trials, but I did see it was abstraction-errors indicating not implimented and thought ‘there must be another way in the meantime’ but I can now drop the obsession and just wait for most of the data stuff to be implimented.

It was the confusion that all the recent talk and planning was “Must have implimentations ready to push with API pushes” in the video briefing, and in comments here and there as being part of the plan for forward moving, thinking that the huge data2.0 push meant ‘is coming with a lot of implimentation at the same time’

1 Like

How do you get block ID’s? (ex. 1 for stone, 1:1 for granite)

Thanks

You don’t.
Block IDs are strings in SpongeAPI.
you can get the string ID from the BlockType with getId().

For blocks like granite, the variant data is stored in the BlockState and you can query a block for StoneTypes.GRANITE

Not to complain, but even if I figure out which methods are not necessary for a basic custom data, thats alot of methods. Is it not recommended to extend the abstract manipulators in SpongeCommon? or perhaps my own abstract version?

How would I go about querying a block for such information?

BlockState state = getSomeBlockState();
Optional<StoneType> opStone = state.get(StoneType.class);
boolean isGranite = opStone.isPresent() && opStone.get().equals(StoneTypes.GRANITE);

With this new API, how would I set a block to granite/andesite etc; like @TheBoomer, but instead of getting a location object, setting it in a MutableBlockVolume during the base generation phase like so:

public void setToGranite(MutableBlockVolume vol, int x, int y, int z)
{
      vol.setBlockType(x,y,z,BlockTypes.STONE);
     //extra stuff to set it to granite
}

Or would you have to create a Location object to operate on?

I’m not sure on how you’re planning to do that, but i’m ready to help out anytime :smile:


I guess the questions asked in this thread may be helpful too, when documenting basic examples and the DataAPI itself. We’ll see.

1 Like

I’ll have to do some debugging, that is, if Sponge is actually updated to SpongeCommon’s implementations. If you’re building and testing against Sponge dev builds, they might be a little behind as a lot of implementation is contributed to SpongeCommon, and when verified that Sponge works with the latest changes, Sponge is updated. I’ll double check today when I get the chance.

This was mainly targeted at more feature-esque API’s that were being contributed as API’s alone. The biggest problem we face right now is the lack of implementation, and the last thing we want to do is add more API to implement. With Data, it was impossible to implement it all without the help of several people, so, the API was pushed with implementation compiling and semi working for a few data, but of course, as you’ve seen by now, not all data.

You can’t. We wrote out all “damage values” from the API. There’s nothing anywhere in the API that should be referencing these “damage values” as Minecraft itself is writing them out (evidence even being with 1.9 snapshots). You’ll have to refer to their BlockStates and figure out the rest ;).

You can very well write your own AbstractCustomDataManipulatorForMyPlugin<M, I> etc, but note that the pre-existing ones are very dependent on not just SpongeCommon, but also on the DataProcessors that make them work.

You could do something like so:

public void setToGranite(MutableBlockVolume vol, int x, int y, int z) {
  final BlockState myGranite = BlockTypes.STONE.getDefaultState().with(Keys.STONE_TYPE, StoneTypes.SMOOTH_GRANITE).get();
  vol.setBlock(x, y, z, myGranite);
}

Basically, I’m going to write up a bunch of words, and you make them look pretty :wink:

2 Likes

Is there a list of keys that are either implemented or going to be implemented somewhere on github?

:smile: