Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

* Notifications

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - CodeCrafter47

Pages: [1] 2 3 ... 35
News and Info / Re: Thoughts on Minecraft 1.13
« on: February 07, 2018, 09:29:50 AM »
Honestly, we should be moving forward with Minecraft, why not do like Sponge and spigot did? Would this be a big undertaking?
Creating an actually useful API for interacting with blocks would require quite some work. If you take a look at the part of the Sponge API for interacting with blocks you'll find that there are ton's of classes and it's awfully complex. I most certainly won't create something like that.

Not number 1.
I suggested that because I think stopping development is better than continuing while breaking all existing plugins. Without plugins Rainbow really loses the last bit of its usefulness.

Short answer: 2nd one much easier.

Here are my thoughts:

Lots of plugins and commands <1.13 use those block and item ids. Then again, most of those plugins aren't even updated anymore, and those that are could be easily updated to match a name only system.

On the other hand, no one wants to update 50 plugins because of one API change.

I wonder if the ID stores inside the PluginReference (ID, BlockId, ItemId) could be mapped (as your suggestion 2). I assume this would be:

MC_Server.getBlock(int) --> minecraft.getBlock(int) --> Block --> MC_Block


MC_Server.getBlock(int) --> MC_ID.stringValue(int) --> minecraft.getBlock(String) --> Block --> MC_Block

And dependant on how well each ID has been named...

Code: [Select]
public String stringValue(int magicNumber){
String constantName = getConstantName(int); //I don't know how you could use the value to get the variable's name, or if this is the most efficient way
String blockName = constantName.startsWith("BLOCK_") ? constantName.substring(6) : constantName.substring(5);
return blockName;

For example, if the id was 0, the method above would realise that 0 = BLOCK_AIR, and take the BLOCK_ bit off it so that it is just AIR, which I assume would be OK.

While I'm here, there are a couple of other concerns I have:
-Data packs: This would mean Rainbow would need a way to add recipes, blocks, etc.
-New co-ordinate syntax: May have to use formatting in our FloatTriplet class, or to parse other commands for plugin compatibility

Thanks for working on this!
Such a mapping is certainly something I can implement. Though there will be quite a few problematic cases like wool which currently is one block with 16 "subblocks" but it 1.13 will be 16 blocks.

Regarding data-packs:
 * there is already a way to add recipes via the API (no need for change there)
 * data packs can't add blocks

The coordinate syntax is a change only in how players can interact with commands. It doesn't change how minecraft works internally. So I don't think the API needs to change because of it.

News and Info / Thoughts on Minecraft 1.13
« on: January 20, 2018, 06:27:24 AM »
Hello everyone,

I've been looking at the latest snapshot, and thought a bit about the implications it has for Rainbow. There are lots of technical changes which are not really in line with our API. The greatest impact is caused by the removal of block ids and item ids. That is bad since numeric ids are just how Rainbow plugins identify blocks and items. The way I see it we have three options going forward:

  • Don't update Rainbow to 1.13
    This means there won't be any versions of Rainbow supporting Minecraft 1.13 and beyond. It doesn't mean this website, the source code or the downloads are going to disappear. These resources will remain available online indefinitely (or for a very long time).
  • Implement our own ID -> Block/Item mapping
    Implementing our own ids allows plugins to continue to function (more or less), despite of the changes in the underlying Minecraft server code. While this keeps old plugins functional it increases the distance between the Minecraft code and our API, also there will be issues, mostly concerning newly added blocks.
  • Change the Rainbow API to no longer use magic numbers
    This way the changes are reflected in the API giving plugins full access to all features, but breaking compatibility with old plugins. I kind of dislike this solutions, it's like re-inventing the wheel. Both Sponge and Spigot already provide APIs not relying on magic numbers.
Any opinions welcome. I'd love to hear some of your opinions before making any decision.

Plugin Releases / Re: Pl3xHeads
« on: December 21, 2017, 04:48:17 AM »

Plugin Releases / Re: Pl3xHeads
« on: December 18, 2017, 04:16:07 AM »
BillyGalbreath's plugins are all open source, and high quality code from what I remember. The code repositories might be gone by now, but I should have a copy of the source code lying around. Also these plugins exclusively use the API, so most of them should still be working just fine.

With DiW's plugins it's something else. A lot of them call internal code which may no longer be present. Updating these might be harder.

And as JD9999 said, let us know which plugins you're having problems with, and we'll look into fixing them.

Plugin Development / Re: How does onPlayerDeath work?
« on: October 04, 2017, 04:53:08 AM »
plrVictim is always the player who died. But I think the onPlayerDeath event is slightly broken, it's not being called when death messages are disabled. I'll fix that when I get around. Should be called on kill command though.

News and Info / Re: Rainbow 1.12
« on: September 23, 2017, 06:25:33 PM »
Thanks to Bayside308 a 1.12.2 build of rainbow is now available.

News and Info / Re: Rainbow 1.12
« on: September 21, 2017, 05:12:35 AM »
I'm currently on vacation, so rainbow probably won't be updated before October.

You can use onAttemptPlaceOrInteract an check whether there's a repeater or comparator at the targeted location.

Instead of rounding or casting it might be better to use
Code: [Select]
int x = plr.getLocation().getBlockX();
int y = plr.getLocation().getBlockY();
int z = plr.getLocation().getBlockZ();

plr.getLocation() will give you the location of the player (of his feet, horizontally centered). In the case of a pressure plate the above will give you the coordinates of the pressure plate (as with pressure plates the player literally stands inside them).

Instead of using onAttemptPlayerMove I'd recommend using onTick to check for every player whether he's standing on a pressure plate. Checking the block every player stand on once every tick shouldn't make your server lag.

General Discussion / Re: Mojang released 1.12.1
« on: August 03, 2017, 12:56:53 PM »
1.12.1 Rainbow builds can now be downloaded from jenkins.

General Discussion / Re: Mojang released 1.12.1
« on: August 03, 2017, 09:25:58 AM »
I will update Rainbow soon.

News and Info / Re: Rainbow 1.12
« on: June 07, 2017, 04:39:11 PM »
You need to use Java 8. With the 1.12 update Minecraft requires Java 8 to run, thus Rainbow also needs Java 8.

News and Info / Rainbow 1.12
« on: June 07, 2017, 03:50:17 PM »
Hello everyone,

As of now, Rainbow for 1.12 is available for download. You can get it here.

Have fun playing.

1.12.1 is available now.

Yes it will. I just arrived at home after a day at university, I'll start working on it right now, so you can expect an update for Rainbow to be available in a few hours.

General Discussion / Re: Rainbow Documentation
« on: April 03, 2017, 03:40:11 AM »
First of all, you shouldn't be building off Rainbow anyway. The idea is that you build off the PluginReference, which everyone who downloads the Rainbow.jar has a local copy of. You can just add the library as a dependency in Eclipse or whatever IDE you use. I would recommend including a link to the javadoc for Rainbow, as well as DIW's tutorial.
I agree with that. You cannot access the implementation classes anyway, and if you need some of the libraries included in Rainbow it's better to directly add these as dependencies than to add the Rainbow.jar as dependency.

Secondly, no Rainbow plugin will ever require a POM file. The only two times you will ever need a file other than java class files is a plugin.properties file, and the manifest, as you can see about here and here, though most people won't need to worry about bytecode injection (the second one). The first one could be useful though.
I don't agree with that. While using a build system like maven or gradle is not necessary, it is good practice and will speed up the development. I think it's good to have the maven repository and artifacts we use documented somewhere.

Pages: [1] 2 3 ... 35