Sponge: Implement DataProcessors

[gabizou]

Given that Data API is rather large when it comes to the amount of data it is supposed to handle, this is a checklist of the data that is implemented.

If you'd like to implement one, please follow these guidelines by copy pasting this code block into your PR description and check mark as necessary:

---

Implementation of REPLACE_WITH_DATA_MANIPULATOR.

• [x] Registration of field getters and setters
• [x] Accurately used the appropriate AbstractData implementation

Implementation of REPLACE_WITH_IMMUTABLE_MANIPULATOR

• [x] Accurately extended the appropriate AbstractImmutableData implementation
• [x] Accurately instantiating final instance fields with an ImmutableValue counter part for any value getters
• [x] If necessary, creating a new ImmutableValue for a value that should not be cached, or, using the existing caching utils.

Implementation of the VALUE_PROCESSOR(s):

• [x] Appropriately extended AbstractSpongeValueProcessor
• [x] Individual processors for each source type possible (one for ItemStack/TileEntity/Entity as necessary).

Registration:

• [x] Registered the Key correctly by FIELD_NAME in the KeyRegistry
• [x] Registered the DataProcessors and DataManipulatorBuilder in SpongeSerializationRegistry
• [x] Registered the ValueProcessors in the SpongeSerializationRegistry

You should create and include a test plugin in your pull request. Preferably, it should test all possible value related methods with your DataManipulators and also test the serialization and deserialization of your DataManipulators.

---

The Checklist:

TileData

• [x] BannerData (@gabizou)
• [x] BeaconData (@Rain336)
• [x] BedData (@JBYoshi - replaced with DyeableData) - #1611
• [x] BrewingStandData (@Feeliiix)
• [x] CooldownData (@Rain336)
• [x] EndGatewayData (@kashike)
• [x] FurnaceData (@Feeliiix)
• [x] LockableData (@JBYoshi)
• [x] NoteData (@ZephireNZ)
• [x] SignData (@gabizou)
• [x] StructureData (@kashike)

EntityData

• [x] AbsorptionData (@kashike)
• [x] AchievementData (@ST-DDT / @windy1) - No longer relevant past 1.11
• [x] AffectsSpawningData (@kashike)
• [x] AgeableData (@Maxqia)
• [x] AgentData (@clienthax)
• [x] AggressiveData (@sanman00)
• [x] AngerableData (@sanman00)
• [x] AreaEffectCloudData (@gabizou)
• [x] ArmorStandData (@gabizou)
• [x] ArtData (@saladoc)
• [x] BodyPartRotationalData (@sanman00)
• [x] BreathingData
• [x] BreedableData (@oliverdunk)
• [x] CareerData
• [x] ChargedData (@clienthax)
• [x] CriticalHitData (@Rain336)
• [x] CustomNameVisibleData (@kashike)
• [x] DamageableData - Requires hooking into the CombatTracker (@Meronat) - #1643
• [ ] DamagingData - Requires hooking into attacking.
• [x] DespawnDelayData (@kashike)
• [x] DominantHandData (@ZephireNZ) - #712
• [x] ElderData (@ZephireNZ) - No longer existing
• [x] ExperienceHolderData (@lucdon)
• [x] ExpirableData (@gabizou)
• [x] ExplosiveRadiusData (@windy)
• [x] ExpOrbData (@clienthax)
• [x] EyeLocationData (@DDoS)
• [x] FallDistanceData (@ZephireNZ)
• [x] FallingBlockData (@clienthax)
• [x] FlammableData (@JBYoshi)
• [x] FlyingAbilityData (@hsyyid)
• [x] FlyingData (@hsyyid)
• [x] FoodData (@gabizou)
• [x] FuseData (@windy1)
• [x] GameModeData (@jamierocks)
• [x] GlowingData (@ZephireNZ)
• [x] GriefingData (@Cybermaxke)
• [x] HealingSourceData (@JBYoshi - replaced with EnderDragon.getHealingCrystal())
• [x] HealthData
• [x] HealthScalingData (@gabizou)
• [x] HorseData (@Aaron1011)
• [x] IgniteableData (@hsyyid)
• [x] InvisibilityData (@hsyyid)
• [x] InvulnerabilityData (@JBYoshi)
• [x] JoinData (@gabizou)
• [x] KnockbackData (@sanman00)
• [ ] LeashData
• [x] MinecartBlockData (@ZephireNZ)
• [x] MovementSpeedData (@clienthax)
• [x] OcelotData (@sanman00)
• [x] ParrotData (@meronat)
• [x] PassengerData (@me4502)
• [x] PersistingData (@oliverdunk)
• [x] PigSaddleData (@clienthax)
• [x] PlayerCreatedData (@clienthax)
• [x] PlayingData (@clienthax)
• [x] RabbitData (@sanman00)
• [x] RespawnLocationData (@simon816)
• [x] ScreamingData (@Grinch)
• [x] ShatteringData (@clienthax)
• [x] ShearedData (@clienthax)
• [x] SittingData (@clienthax)
• [ ] SizeData (@hsyyid / @meronat) - https://github.com/SpongePowered/SpongeCommon/pull/1492
• [x] SkeletonData (@sanman00)
• [x] SkinData (@simon816)
• [ ] SleepingData (@sanman00) - https://github.com/SpongePowered/SpongeCommon/pull/1488
• [x] SlimeData (@Aaron1011)
• [x] SneakingData
• [x] SprintData (@kashike)
• [x] StatisticData (@ST-DDT / @windy1)
• [x] StuckArrowsData (@kashike)
• [x] TagData (@meronat) - https://github.com/SpongePowered/SpongeCommon/pull/1490
• [x] TameableData (@gabizou)
• [x] TargetLivingData (@Me4502)
• [x] TradeOfferData (@Rain336)
• [x] VehicleData (@hsyyid)
• [x] VelocityData (@gabizou)
• [x] VillagerZombieData (@Aaron1011)

ItemData

• [x] AuthorData (@lucdon)
• [x] BlockItemData (@kenzierocks)
• [x] BreakableData (@JBYoshi)
• [x] CoalData (@JBYoshi)
• [x] CookedFishData (@JBYoshi)
• [x] DurabilityData (@Rain336)
• [x] EnchantmentData (@gabizou)
• [x] FishData (@JBYoshi)
• [x] GenerationData (@JBYoshi)
• [x] GoldenAppleData (@Aaron1011)
• [x] HideData (@Rain336)
• [ ] InventoryItemData - Requires Inventory implementation
• [x] LoreData (@lucdon)
• [ ] MapItemData - Needs Map API in general
• [x] PagedData
• [x] PlaceableData (@JBYoshi)
• [x] SpawnableData (@Rain336)
• [x] SplashPotionData
• [x] StoredEnchantmentData (@Rain336)

BlockData

• [x] AttachedData (@lucdon)
• [x] AxisData (@lucdon)
• [x] BigMushroomData (@lucdon)
• [x] BrickData (@lucdon)
• [x] ComparatorData (@lucdon)
• [x] ConnectedDirectionData (@lucdon)
• [x] DecayableData (@lucdon)
• [x] DelayableData (@lucdon)
• [x] DirectionalData (@lucdon)
• [x] DirtData (@lucdon)
• [x] DisarmedData (@lucdon)
• [x] DisguisedBlockData (@lucdon)
• [x] DoublePlantData (@lucdon)
• [x] DropData (@lucdon)
• [x] ExtendedData (@lucdon)
• [x] FilledData (@Me4502)
• [x] FluidLevelData (@Me4502)
• [x] GrowthData (@lucdon)
• [x] HingeData (@lucdon)
• [x] InWallData (@lucdon)
• [x] LayeredData (@lucdon)
• [x] LogAxisData (@gabizou)
• [x] MoistureData (@Me4502)
• [x] OccupiedData (@lucdon)
• [x] OpenData (@lucdon)
• [x] PistonData (@lucdon)
• [x] PlantData (@lucdon)
• [x] PortionData (@lucdon)
• [x] PoweredData (@lucdon)
• [x] PrismarineData (@lucdon)
• [x] QuartzData (@lucdon)
• [x] RailDirectionData (@lucdon)
• [x] RedstonePoweredData (@lucdon)
• [x] SandData (@lucdon)
• [x] SandstoneData (@lucdon)
• [x] SeamlessData (@lucdon)
• [x] ShrubData (@lucdon)
• [x] SlabData (@lucdon)
• [x] SnowedData (@lucdon)
• [x] StairShapeData (@lucdon)
• [x] StoneData (@lucdon)
• [x] SuspendedData (@lucdon)
• [x] TreeData (@lucdon)
• [x] WallData (@lucdon)
• [x] WireAttachmentData (@JBYoshi) - https://github.com/SpongePowered/SpongeCommon/pull/1934

Common Data

• [x] ColoredData (@kenzierocks)
• [x] CommandData (@sanman00)
• [x] DisplayNameData
• [x] DyeableData (@Rain336)
• [x] FireworkEffectData (@ZephireNZ)
• [x] FireworkRocketData (@ZephireNZ)
• [x] MobSpawnerData (@ZephireNZ)
• [x] PotionEffectData (@gabizou)
• [x] RepresentedItemData
• [x] RepresentedPlayerData (@saladoc)
• [x] RotationalData (@Rain336)
• [x] SkullData
• [x] TargetedLocationData (@kashike)
• [x] WetData (@sanman00)

Updated as of January 30, 2018

[gabizou]

I am taking requests and offering the public to freely implement a DataProcessor and the associated ValueProcessors for the DataManipulator.

[RobertHerhold]

VelocityData and SignData please :)

[Aaron1011]

I'll take GamemodeData.

[mmonkey]

I second the VelocityData!

[gabizou]

I'm implementing SignData as we speak. I'll get to VelocityData likely tonight as well.

[ST-DDT]

I'll help with StatisticData and AchievementData.

[gabizou]

I'll help with StatisticData and AchievementData.

Note that you'll have to implement far more than just the StatisticDataProcessor and StatisticValueProcessor since there is NO implementation of statistics in general in SpongeCommon.

[ST-DDT]

I know. I already mentioned it last weekend that I would start doing so before the data API merge.
I just checked in this issue, whether the data part is already implemented, and mentioned it here for documentation purposes.
However I cannot start immediately as I have to update my pending PRs first.

Thanks for your hint anyway.

[modwizcode]

I'll work on TradeOfferData.

[hsyyid]

I'd like to work on PassengerData

[DDoS]

Where's AABBData? It should be a common data (blocks and entities have it).

[hsyyid]

I'd like to work on Whitelist Data

[kamcio96]

I will work on TargetedLocationData.
But DataManipulatorBuilder has create method. I don't know what it should return.

[ryantheleach]

Currently working on TameableData https://github.com/SpongePowered/SpongeCommon/pull/134

[gabizou]

Tagging SpongePowered/SpongeAPI#812

[Aaron1011]

I'm taking PotionEffectData

[hsyyid]

I'm taking IgniteableData

[hsyyid]

I'd like to work on FlyingData

[lucdon]

i will work on LoreData and PagedData

[JBYoshi]

I'll work on BreakableData and PlaceableData. https://github.com/JBYoshi/SpongeCommon/tree/data/placeable-breakable

[gabizou]

Just to alert people of various PR's and intentions to implement, there have been recent changes to implementing DataProcessors for Entity related data, so please, consider reading the changes.

[hsyyid]

Okay

[sanman00]

I'm working on WetData.

[KAISERslin]

I really need "RepresentedItemData" to finish two of my open RPG Plugins.

[JBYoshi]

@KAISERslin RepresentedItemData was implemented with the recent Block data changes. af86add69d6cc75b618196461f2310ca9576b6b7

@gabizou Could you update this on the list?

[ZephireNZ]

ElderData implemented in #173

[gabizou]

After giving some thought with DataProcessors and ValueProcessors, I've decided to make a requirement for any and all PR's:

The PR must include a demo plugin (can be as simple as a listener listening for block changes that set the item in hand with various data) that uses all aspects of the processor implementations as expected (notwithstanding making API calls to try and retrieve data from known unsupported holders).

The reasoning behind this is that I've spent many many hours trying to make implementation easier to understand, but what I've found is that there's various mistakes made even when the author confirmed something was tested.

So, the PR itself will be reviewed with the following basis:

• The DataManipulator is implemented correctly using the appropriate abstraction of the sponge DataManipulator implementations.
• The ImmutableDataManipulator likewise is implemented correctly using the appropriate abstraction of the sponge ImmutableDataManipulator implementations.
• The Keys used by both manipulators are correctly registered in the KeyRegistry.
• The DataManipulatorBuilder for the DataManipulator is implemented and registered.
• The DataProcessor is implemented and uses the appropriate abstraction of DataProcessor for its uses.
• The ValueProcessor is implemented.
• None of the processors make method calls that would otherwise result in performing more lookups for the same processor that already existed (Examples include using container.supports(key) versus supports(container)).
• The demo plugin is easily copied and pasted into an IDE for live debugging.

Optionally:

• If the DataManipulator or data for the Keys being implemented are possible to exist in a BlockState, locating the proper mixin to manually implement the data such that BlockStates support the newly implemented Keys and DataManipulators is a plus
• If the data being implemented is also supported by any Entity in the entity hierarchy (like a Sheep supporting DyeableData), locating the proper mixin to not only override the necessary method to provide said data by default when an Entity#toContainer() is called is a plus.

Overall, my goal has been to try and help people understand the various systems and structures set in place to not only implement getting/setting data through the API, but have it work in all of it's designed intentions. Unfortunately, the only way I can see some people learning how and why certain things are implemented the way they are is by putting these types of requirements.

I hope that this will provide a learning experience, not to make reviewing PR's easier, but to help teach everyone what is required to implement certain aspects of the API to help future contributions require less code cleanup and less sanity testing.

The following PR's are ones I've selected that need to meet these guidelines:

• #135
• #136
• #139
• #143
• #144
• #148
• #159
• #165
• #166
• #173

Tomorrow, I will comment with the checklist on each of these PR's. If a PR is significantly old enough that the author is taking too long, I will manually fix the minor changes required and merge. However, if a PR is still awaiting for the author to respond after a while, the PR may be disregarded and re-implemented by a member of the dev-team.

I'll repeat once more, this measure isn't to slow down PR's, it's to help people learn that when they implement a piece of Data, all of that part of data they're implemented must work 100% of the time. If I can break a PR's implementation, then the PR hasn't been properly tested. If there are some things being done incorrectly (like caching values of near infinite possibilities), then the implementation is doing something wrong. I want PR's to be as fast as possible, and the only way I can see them getting accepted quickly is if these guidelines are met.

[lucdon]

I'm working on ExperienceHolderData

[ST-DDT]

I have a question regarding the Data API.

How can mods/plugins make their custom entities return existing data instances for data that are not supported over inheritance.

Example. A new special protester/demonstrator villager carries a (readable) sign with some text on it.
The plugin author wants to use SignData for this for obvious reasons. (Or DyeData for coloured Villager clothing.) However the registered DataProcessors only support blocks / other data holders. How does he support this, without rewriting the entire data implementation for this entity.

[gabizou]

How can mods/plugins make their custom entities return existing data instances for data that are not supported over inheritance.

Multiple processor registration. If you have your own custom entity, you're already interacting with forge, and what you can do is register the processors directly in your mod or in a compatibility module. SpongeCommon already handles multiple processor registration quite well (it's how it works already).

[ST-DDT]

@gabizou Thanks.
One more thing, could you check/flag the recently merged data classes? (Ignite, Sneaking...)

[JBYoshi]

@gabizou EnchantmentData, GoldenAppleData, IgniteableData, LoreData, PagedData, RepresentedItemData, and SneakingData have been implemented. Could you update these on the list?

[Tzky]

FlyingData was just pushed too.

[JBYoshi]

Implementing CoalData, CookedFishData, and FishData, please wait...

Done. #180

[gabizou]

I'm going to make some minor changes to the implementation regarding getting cached values. The functionalities will still remain the same, nothing will break code wise, but getting cached values will be easier.

Namely, what will be doable is the following:

final ImmutableValue<Boolean> canFly = ImmutableSpongeValue.cachedOf(Keys.CAN_FLY, false, actualValue);

The reasoning is that it'll become much simpler to do this than being unaware of the constructor arguments for supposed values. They will still use the ImmutableDataCachingUtil, but nonetheless, it is something that will make some implementations easier.

[lucdon]

implemented AuthorData while listening to SoS6

[hsyyid]

I'll do the value processor for Keys.CAN_FLY (Unless it should be added to FlyingData?)

[Aaron1011]

I'm taking FuseData

[hsyyid]

I'm taking InvisibilityData

[felixoi]

Started work on the FurnaceData

[gabizou]

I've updated the issue description for what I'd like to see in every Data PR as the top PR description (the first post).

[clienthax]

Taking SittingData, done
Taking ShearedData, done
Taking PigSaddleData, done
Taking SlimeData, Ninjad by @Aaron1011 who cba to post here :p
Taking PlayingData, done
Taking ExpOrbData, done

[Aaron1011]

I'm taking VillagerZombieData.

[felixoi]

I'm taking the BrewingData

[hsyyid]

I'm taking SizeData

[gabizou]

Updated the list as of this comment.

[gabizou]

I will work on TargetedLocationData.
But DataManipulatorBuilder has create method. I don't know what it should return.

Any updates on this @kamcio96? It's been two months and haven't seen any PR's for TargetedLocationData.

[lucdon]

will implement stone and prismarine data #206

[hsyyid]

I'm taking MapItemData

[gabizou]

I'm taking MapItemData

Note that you'll have to write and implement Map API as well for that to work.

[hsyyid]

@gabizou Yep

[octylFractal]

I will dutifully take ColoredData.

[SocraticPhoenix]

Rather than attempt to implement one and fail horribly, I'll politely request that AgentData be implemented to the point that we can enable/disable AI.

[clienthax]

Taking AgentData - Done

[gabizou]

List is updated to here.

[me4502]

I'm claiming the following:

MoistureData
FluidLevelData
FilledData

Edit:
And TargetLivingData as well, as the past 3 are blocked waiting on @lucdon's PR.

[lucdon]

@me4502 im trying to finish my pr today and else tomorrow

[sanman00]

I'm working on LockableData.

[clienthax]

taking ChargedData, Done

[clienthax]

taking PlayerCreatedData

[hsyyid]

Taking OccupiedData Never mind, it was already done. @gabizou please update list.

[clienthax]

Taking ShatteringData

[hsyyid]

InWallData was also done..

and LayeredData

and DecayableData

[lucdon]

working on attributedata and the attribute implementation(and some api changes)

[ZephireNZ]

@lucdon Attributes got removed from the API in SpongePowered/SpongeAPI@a6391b6

[lucdon]

@ZephireNZ ahh thx did not update my api fork so i didnt see it.
@gabizou can you remove attribute data from this issue
and gabizou dont forget to remove InstrumentData from api and from this issue

[me4502]

I'm going to hate myself for this, but I'll take FireworkData as well.

[felixoi]

FurnaceData and BrewingStandData finished!

Taking FlamableData now!

[lucdon]

taking the 14 remaining block data manipulators:
AttachedData
AxisData
ConnectedDirectionData
DirectionalData
DisarmedData
DropData
ExtendedData
GrowthData
OpenData
PoweredData
RedstonePoweredData
SeamlessData
SnowedData
SuspendedData

[ZephireNZ]

@me4502 have you made progress on fireworks? I got partially into implementing it before I saw you your comment haha

[me4502]

@ZephireNZ I haven't started it yet, I've been waiting on my first data PR to be accepted before doing more.

[ZephireNZ]

Did you want to keep it, or shall I do it? :)

[me4502]

@ZephireNZ You can do it, I only grabbed it as I wanted it done, and no one else had grabbed it.

[ZephireNZ]

Sweet :)

[octylFractal]

I'll take BlockItemData.

[gabizou]

Updated the description up to here.

[gabizou]

Also, a correction: OccupiedData may be implemented in that the manipulator exists, but the actual implementation backing it is not done. So, it's still up for grabs, maybe @lucdon ?

[clienthax]

@SocraticPhoenix AgentData is implemented and merged

[gabizou]

@clienthax, yes, as the description said, it was implemented...

[JBYoshi]

@gabizou What's the difference between AngerableData and AggressiveData?

[ZephireNZ]

@JBYoshi Angerable is for mobs like pigmen I believe. As for Aggressive I believe that's for "hostile" mobs

[SocraticPhoenix]

@clienthax thanks
Now all I need is InvisibilityData to be completed and my NPCs will be complete!

[hsyyid]

@SocraticPhoenix I'm working on it :wink:

[lucdon]

will implement 'OccupiedData' with the rest of the blockData

[lucdon]

will implement these 3 too because only the manipulators are created and nothing more(and @hsyyid thought the were implemented which is false)
InWallData
LayeredData
DecayableData

[gabizou]

So, just to make sure, @hsyyid isn't going to be implement those?

[JBYoshi]

Taking LockableData.

[SocraticPhoenix]

I'd like to request that FallingBlockData be implemented

[gabizou]

Updated to here. Added SplashPotionData.

[ghost]

SignaledOutputData is on the list, but does not seem to exist in the API.

[hsyyid]

@gabizou No. @lucdon is correct, I thought they were done, but they're only half done. I am fine with @lucdon doing them instead, as he's already done most if not all blcokdata processors.

[lucdon]

@gabizou what about creating delayableData for RedstoneRepeaters?

[gabizou]

Yep, go ahead and add it @lucdon

[clienthax]

Taking FallingBlockData

[SocraticPhoenix]

@clienthax Thank you!

[sanman00]

I'm working on SkeletonData. Now I'm working on it alongside OcelotData and RabbitData

[felixoi]

Hey guyz,

i started to implement the FlammableData, but in my opinion it does not store what it has to store. At the moment FlammableData returns is a entity is aflame, but i think flammable means if something could burn and not if something is aflame.

There are 2 reasons i think:

1. Rename FlammableData to something like AFlameData
2. Create a 2nd data named like "AFlameData" and let FlammableData store was it has to store.

Thanks for your opinion @gabizou @Aaron1101 and all other guyz.

[JBYoshi]

@Feeliiix Any entity that supports FlammableData can be set aflame.

[felixoi]

@JBYoshi right but in my opinion than it should be store a boolean if it support that and not a boolean that represents the aflame state

/**
* Gets the {@link Value} for the "aflame" state.
*
* @return The value for the aflame state
*/


[ST-DDT]

There was a discussion for this on IRC lately, but it did not have an answer.
The suggestion there was:
BurningData for things that are on fire and FlammableProperty for things that could be on fire.

[gabizou]

The way I thought of it is that since it only stores the "ticks" of being on fire, it's only available when the entity is actually on fire. If the entity is not on fire, then there's no flamabledata to get. Also, I'd appreciate not cluttering up this issue in the future to take it to a new issue, possibly in API as it most directly affects that more than anything.

[felixoi]

@gabizou I See your point, but i suggesting a rename because the name is very cunfusingly, when it does only store the ticks, the entity is aflame

[clienthax]

@SocraticPhoenix FallingBlockData is in master now

[SocraticPhoenix]

@clienthax
thank you

[sanman00]

I'm working on OcelotData and RabbitData alongside SkeletonData now.

[gabizou]

Updated the checklist as of now.

[ZephireNZ]

I'm taking MobSpawnerData

[gabizou]

@ZephireNZ you'll have to wait for @Deamon's world gen PR

[ZephireNZ]

Can do, which part of his PR am I needing?

[Deamon5550]

@ZephireNZ The WeightedTable and related value changes in api and common.

[sanman00]

I'm working on AggressiveData and AngerableData.

[ryantheleach]

Keen to see AgeableData implemented soon, if someone tackles it, could they also consider keys for BABY / ADULT?

[sanman00]

I'm working on SplashPotionData.

[JBYoshi]

I'll write an implementation of CloneableData and upload a _copy_ of it. (Pun intended.)

EDIT: @gabizou What happened to CloneableData?

[gabizou]

@JBYoshi, it's now GenerationData

[JBYoshi]

Okay, thanks.

[Aaron1011]

Implementing remove properly can sometimes be tricky to get right. When writing it, keep these things in mind:

(Note: there is an open issue regarding the behavior of DisplayNameData with relation to Humans. For the purpose

---

1. Does the data in question always exist (even if it's some 'empty' or 'null' value)? If so, remove should not set it to this value. Instead, it should return DataTransactionResult.failNoData.

   Take DisplayNameData, for example. On a Humanoid (a Player or Human), this data will always exist. At best, you can set the display name to the empty string (or Texts.of()), but it still exists! You can see this for yourself by setting the display name of a Human to Texts.of(), and observing that a nameplate still appears over its head in game.

   In the case of an ItemStack, however, the data does _not_ always exists. If the ItemStack does not have an NBT compound, or does not have the proper key set in it, the data is not present at all. Thus, removing it makes sense, since there's no 'empty' or 'null' value that gets set.

2. Does calling remove immediately followed by get return a present Optional (if removing the data is supported)? If so, this is definitely a bug, and likely a sign that removing the data only sets it to some default value.

3. Can the behavior of remove be replicated through normal usage of the Data API by a plugin? This is similar to the above case, and means that remove isn't actually removing anything. It should only be supported in the case where a meaningful way exists to 'delete' the data from DataHolder, such that it no longer exists at all.

   In the DisplayNameData example, this would mean that a plugin could remove the data of a (non-Human) Entity by setting its display name to the empty Text. This won't work, since a non-present display name is different from one set to the empty Text.

   In the case of a Human, this is a non-issue, since DisplayNameData cannot be removed at all, by remove or otherwise.

---

Hopefully, these questions will help to clear up any confusion as to whether remove should be implemented for a given DataProcessor.

[gabizou]

@saladoc @Tzky probably want to include the above in the contributing docs.

[sanman00]

I'm working on CommandData.

[gabizou]

Updated the checklist as of now. @ZephireNZ the mob spawner changes are updated, including the implementation of the data manipulator itself.

[sanman00]

I'm working on KnockbackData.

[JBYoshi]

@Rain336 is working on DyeableData (#359).

[oliverdunk]

Tick off PersistantData? (#370)

[sanman00]

I'm working on BodyPartRotationalData.

[kashike]

SprintData is mine: #378

[oliverdunk]

I'm working on BreedableData

[JBYoshi]

Taking most of the remaining entity data:

• FlammableData
• GriefingData
• HealingSourceData
• InvulnerabilityData
• CriticalHitData (if @saladoc doesn't finish it)

@gabizou Could you remove LeashData from the list since it's been replaced with Entity methods and CloneableData since it's been renamed (and the new name, GenerationData, is already on the list)?

[kashike]

@JBYoshi PersistingData is taken already

[JBYoshi]

@kashike Okay, removing that from my todo list.

[JBYoshi]

So is CriticalHitData.

[ghost]

Taking a shot at ExplosiveRadiusData

[JBYoshi]

Sure.

[kashike]

I'm reclaiming unimplemented potion data.

[sanman00]

I'll be working on FuseData since it does not appear to be implemented and I haven't found a pull request for it.
@Aaron1011 is this fine with you?

[Rain336]

I implemented HideData(#388)

[Aaron1011]

@sanman00: Sure! :)

[ghost]

I unclaim ExplosiveRadiusData because I feel like it would keep me from the docs too long. See SpongePowered/SpongeAPI#1008 for my findings/problems.

[gabizou]

Description/checklist updated as of this comment.

[hsyyid]

@JBYoshi Can I take AgeableDataoff of your plate?

[JBYoshi]

@hsyyid Sure.

[gabizou]

I've freed up TargetedLocationData and BeaconData.

Edit: sorry @kamcio96, totally didn't see your PR.

[clienthax]

taking BeaconData

[JBYoshi]

@clienthax In your BeaconData PR, could you also update line 51 in SpongeBeaconBuilder?

[clienthax]

@JBYoshi yep

[JBYoshi]

@clienthax Thanks. Eclipse (with my custom compiler error/warning settings) has been nagging me about a few null errors (due to unimplemented data) for the past few months, and this is the last of them.

[clienthax]

Yeah screw beacondata, stupid freking optional bs.
if anyone wants to finish it, https://github.com/clienthax/SpongeCommon/commit/22e8abbe94213a42a430a557a04fe9222c58cc4b

[ryantheleach]

I'd like to request JoinData it's currently blocking any form of setting the spawn for players logging on for the first time, as it's currently not firing RespawnEvents(they were never dead, just not born)

[randombyte-developer]

I wanted to use TargetedLocationData, read the list of this issue and saw that TargetedLocationData isn't done. So I waited and waited, nothing happened. Today I wanted to implement it myself and saw this PR.
TargetedLocationData should be ticked in the list above.

[kashike]

@gabizou This list needs updating whenever you get time :)

[simon816]

I have updated the list

[ryantheleach]

Cheers simon! It's damned close to being closed.

[octylFractal]

I'm going to take WireAttachmentData.

[gravityfox]

DisplayNameData does not work for Itemstacks. It doesn't seem to be fully implemented.

https://github.com/SpongePowered/SpongeCommon/blob/master/src/main/java/org/spongepowered/common/data/processor/data/DisplayNameDataProcessor.java#L129

The key Keys.DISPLAY_NAME seems to work fine though, for some reason.

[ZephireNZ]

@gabizou Beds don't have a manipulator for their "part" property.

They're different enums, but should we just make it use PortionData instead? We could add a note that "TOP" corresponds to "HEAD" etc.

[kashike]

This has been updated, thanks to @Meronat.

[parlough]

I will start BedData and possibly LeashData later today or tomorrow.

[sanman00]

I am working on DominantHandData.

[ryantheleach]

@Meronat @sanman00 How are the data's going? Not many left!

[parlough]

Working on it as time allows. Have a few PRs open implementing various data that should be good to go. Will be opening a PR to add disabled slot control to ArmorStandData soon, then I'll look into bed and leashes. Then from there we will see, I may look into the missing combat ones.

[JBYoshi]

What's left for WireAttachmentData?

[ryantheleach]

The ShortList:

• [ ] DamagingData - Requires hooking into attacking.
• [x] DominantHandData (@ZephireNZ / @Meronat) - #712
• [ ] LeashData
• [ ] SizeData (@hsyyid / @Meronat) - #1492
• [ ] SleepingData (@sanman00) - #1488
• [x] TagData (@Meronat) - #1490
• [ ] InventoryItemData - Requires Inventory implementation
• [ ] MapItemData - Needs Maps API in general
• [x] WireAttachmentData - Partially done

[gabizou]

@ryantheleach Maps API was abandoned ~again~, so it's something that modwiz isn't going to be getting to anytime soon.

[XakepSDK]

Keys.DISPLAY_NAME does not work for players.

[kashike]

...yes it does? If it didn't we'd have 100 issues opened by now.

[JBYoshi]

I'm finishing up WireAttachmentData. https://github.com/SpongePowered/SpongeCommon/pull/1934