Yay new update, deprecated stuff :(

Finally got a new RB bukkit update!

But i see that a LOT of stuff have been deprecated, how do i find out what to use instead? I tried reading on the javadocs, but can't find anything there other than this: http://jd.bukkit.org/rb/doxygen/da/d58/deprecated.html

these are the ones i see so far that i need to fix:
getTargeBlock
block.getData /getTypeId
getting the skeleton type id
pretty much any block changing or interactions

 

As for the TypeId thingy, those have been deprecated because the people at Mojang decided it's no longer a valid way of looking up an item. Instead, use the items name.

 

items? no i'm talking about the Block interaction, getting the block type and id.

 

Yeah, it's all to do with phasing out magic values, i.e. numeric block ID's and data bytes. Which is a good thing in itself.

However, deprecating all these methods without having a replacement ready (e.g. there's no getTargetBlock() method which takes a set of Material) is poor planning, IMHO. If a method is being deprecated, it should always be in favour of a new alternative, and there's no indication of what that might be in many cases here.

And why's it being done for CB 1.6.2, when as I understand it, the changes Mojang are pushing are for MC 1.7?

 

Yeah i couldn't agree more. Fixing magic values are a great thing, but before i see any replacement i guess i'll have to use older versions

 

I personally really liked item-ids. They made it easy to automatically support new items in plugins using a universal ID, which avoided confusion. Oh well, guess

 

hmm, hope they get a replacement soon

 

How can plugins support minecraft mods, which introduce new blocks and items? For example, how can we write a plugin which blocks players from placing blocks of certain block ids, if we can't lookup by ids?

 

I think that they made a giant mistake, using the Item Id's make plugins makes everything a lot more simple.

I know of a bunch of plugins that assign custom items to new id's. How are we supposed to allow for those if they're slowly getting rid of using the Id's.

 

I'm going to throw this out there,

Just because a method is deprecated, doesn't mean it's removed.

No one in their right mind would favor comparing item names over comparing item ids. If those yellow underlines and wonderful strikethroughs really bug the hell out of you in eclipse... NMS, the one place where deprecation is a fallacy!

 

blablubbabc Item names. Instead of using the items ID, use its name.

 

what about getting the target block? is there a magic number there? thought it only returned block, and not it's id

and what about the getData() from a block? i don't understand what that can be replaced by. adding new block types?

 

mollekake I haven't had time to take a look at all changes (although I will have to soon, since my Stats plugin partially relies on magic numbers :O), but I will get back to this once I find it out. I think it had something to do with .getMetaData().getData

 

ok, cool! Yeah some of mine also contains magic numbers, which is kinda one of the the first rules you learn when learning programming

 

Right, I would imagine everything will be done with MaterialData and its subclasses soon.

I'm interested to know how (or indeed if) we'll be able to easily specify such materials & data in a config file. E.g. if I want to specify a north-facing ladder right now, I can use something like this in a YAML config:

Code:

block: "ladder:2"

and that's quite easy to parse into a material id and data byte (and I already do this in my ChessCraft plugin in the piece style config files). I really hope Bukkit will provide a way to properly serialise/deserialise a material plus its data byte without plugins having to write a ton of custom code for every material there is...

 

mollekake
add the method playEffect for Player

 

huh? for what?

 

mollekake
In your list of deprecated stuff

Code:

player.playEffect(player.getLocation(), Effect.SMOKE, 1);

 

But there is now a playEffect(Location, Effect, T) method, where T is the class representing the data for that particular effect. The Javadocs could use updating to document what the appropriate class is for each effect, but if you look at Effect.java in the github repo, it's obvious enough. E.g. to play an effect of smoke going straight up, you should now be able to say:

PHP:

player.playEffect(loc, Effect.SMOKE, BlockFace.UP);


...which is nice.

 

All this deprecation is making my eclipse go "No you shouldn't do that! I am going to give you 72 errors!"

The methods should not be deprecated since there is, 1, no alternative, 2, no point in deprecation yet, and 3, no reason to switch to a different method in the API (they should just fix it on craftbukkit's side!).

 

2 is invalid as deprecation is a way of showing these methods will be removed soon, and giving developers warnings beforehand is a better idea than just removing the methods at some point.

 

My point was that they shouldn't even be thinking about removing it yet as 1.7 is still fairly far away and the block id changes are AFAIK unconfirmed.

 

If you follow Dinnerbone, you'd know.
The new ID system goes minecraft:item_name
Why did they do this? To add better support for mods. Mods in the future will have item names like modName:item_name

 

Hopefully Bukkit, being as smart as they are, come up with a way to allow us to keep using the methods that are deprecated, to make it easier for us. Instead of just removing them.
I have to say, this will surely slow down my development on plugins.

 

Why would this slow down development? most of The deprecated methods have perfectly good replacements right now, and for the ones that don't, you can expect to see replacements shortly, and in the meantime you can continue using deprecated methods with no issue, they will exist at least until the next major release of bukkit after 1.7, if not longer.

 

They shouldn't mark methods as depreciated until they replaced them. For instance, CraftBukkit is still using a lot of depreciated methods...

 

Whether something is depreciated or not, does not mean they don't work, and nor does it mean you have to use earlier craftbukkit versions. As it has been pointed out, some things are depreciated because there is an alternative better method or It can also mean that it may get replaced and an alternative is in the works, giving you a warning. However not all depreciated code gets removed. Some are left for quite some time before ever being removed. Why complain about something being depreciated right now, when the code your using works? I would worry about things not working once there is an update available so you can check.

Best solution is, try to not use depreciated code best you can, unless there is no alternative for what your doing then use the depreciated code to accomplish what your doing.

 

Deprecating the (byte) data value is going to make it very difficult for developers to add interactions for specific blocks. For instance, I'm creating a plugin where you can cook the zombie flesh to remove remove it's chance of giving your player the hungry status. It's the same Material (ROTTEN_FLESH), but with a data value of 1 instead of 0, so when the PlayerItemConsumeEvent is fired, I can simply check the data value and cancel the hunger...

It works for now in Deprecated mode, but once it's removed, extending items like rotten flesh in this way is going to make things very difficult for mods.

 

javaguy78 I think there will be an alternative for data values in the next update!

 

none ever remembers the mod comunity.