collapse

: [1] 2 3 ... 10
1
News and Info / Re: Thoughts on Minecraft 1.13
«  Fredashay February 07, 2018, 06:24:46 PM »
Anything but #1. 

- Perhaps a combination of #2 and #3 so you can use either mechanism (or both)?  I'm not sure if that's possible, though cuz I don't know the internals of Minecraft or the Rainbow API. 

- Or have two interfaces, and you choose one or the other, but that's prolly impractical cuz you'll essentially be supporting 2 versions of Rainbow, bleh.  And CodeCrafter already said that updating Rainbow is gonna be a Hurclean task.

- Or Some mechanism like what JD9999 suggested. 

- Or do #3 and then write a Rainbow/Rainbow bridge...

- Okay, I guess I vote for #2, but assign our own block IDs to the new blocks (and all the variants of wool) so we can use the new blocks. 
2
News and Info / Re: Thoughts on Minecraft 1.13
«  CodeCrafter47 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:

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

to...

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

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

:
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.
3
News and Info / Re: Thoughts on Minecraft 1.13
«  JD9999 January 23, 2018, 05:38:41 AM »
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:

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

to...

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

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

:
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!
4
News and Info / Re: Thoughts on Minecraft 1.13
«  UnknownUser500 January 21, 2018, 12:36:40 PM »
Not number 1.
5
News and Info / Re: Thoughts on Minecraft 1.13
«  BlackScorpion January 20, 2018, 04:00:58 PM »
Honestly, we should be moving forward with Minecraft, why not do like Sponge and spigot did? Would this be a big undertaking?
6
News and Info / Thoughts on Minecraft 1.13
«  CodeCrafter47 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.
7
Plugin Releases / Re: VNAP - Authentication Plugin
«  Algoru December 25, 2017, 05:33:27 PM »
------------- VNAP 1.2 RELEASED -------------
9
Plugin Releases / Re: Pl3xHeads
«  JD9999 December 20, 2017, 10:06:52 PM »
His _PI3XLibs doesn't purely use the PluginReference API
:
[14:43:44] [INFO]:
\/\/\/\ _Pl3xLibs.jar
[14:43:44] [INFO]: Set PluginClassLoader as parallel capable
java.lang.NoClassDefFoundError: joebkt/World
        at net.pl3x.pl3xlibs.Logger.send(Logger.java:32)
        at net.pl3x.pl3xlibs.Logger.info(Logger.java:16)
        at _Pl3xLibs.MyPlugin.onStartup(MyPlugin.java:41)
        at org.projectrainbow.plugins.PluginManager.LoadPlugins(PluginManager.java:120)
        at org.projectrainbow.plugins.PluginManager.enable(PluginManager.java:26)
        at org.projectrainbow._DiwUtils.Startup(_DiwUtils.java:415)
        at lh.handler$onServerStart$zza000(SourceFile:34)
        at lh.j(SourceFile)
        at net.minecraft.server.MinecraftServer.run(SourceFile:436)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: joebkt.World
        at java.net.URLClassLoader.findClass(Unknown Source)
        at org.projectrainbow.plugins.PluginClassLoader.findClass(PluginClassLoader.java:61)
        at org.projectrainbow.plugins.PluginClassLoader.findClass(PluginClassLoader.java:49)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        ... 10 more

[14:43:50] [ERROR]: Failed to pass event to plugin _Pl3xLibs
java.lang.NoClassDefFoundError: joebkt/World
        at net.pl3x.pl3xlibs.Logger.send(Logger.java:32) ~[?:?]
        at net.pl3x.pl3xlibs.Logger.info(Logger.java:16) ~[?:?]
        at _Pl3xLibs.MyPlugin.onShutdown(MyPlugin.java:47) ~[?:?]
        at org.projectrainbow.Hooks.onShutdown(Hooks.java:17) [Hooks.class:?]
        at org.projectrainbow._DiwUtils.Shutdown(_DiwUtils.java:453) [_DiwUtils.class:?]
        at net.minecraft.server.MinecraftServer.handler$hook_onShutdown$zze000(SourceFile:200) [MinecraftServer.class:?]
        at net.minecraft.server.MinecraftServer.u(SourceFile:415) [MinecraftServer.class:?]
        at net.minecraft.server.MinecraftServer.run(SourceFile:499) [MinecraftServer.class:?]
        at java.lang.Thread.run(Unknown Source) [?:1.8.0_131]
Caused by: java.lang.ClassNotFoundException: joebkt.World
        at java.net.URLClassLoader.findClass(Unknown Source) ~[?:1.8.0_131]
        at org.projectrainbow.plugins.PluginClassLoader.findClass(PluginClassLoader.java:61) ~[PluginClassLoader.class:?]
        at org.projectrainbow.plugins.PluginClassLoader.findClass(PluginClassLoader.java:49) ~[PluginClassLoader.class:?]
        at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_131]
        at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_131]
        ... 9 more

And neither does this plugin:

:
\/\/\/\ Pl3xHeads.jar
java.lang.NoClassDefFoundError: joebkt/World
        at Pl3xHeads.MyPlugin.init(MyPlugin.java:57)
        at Pl3xHeads.MyPlugin.onStartup(MyPlugin.java:44)
        at org.projectrainbow.plugins.PluginManager.LoadPlugins(PluginManager.java:120)
        at org.projectrainbow.plugins.PluginManager.enable(PluginManager.java:26)
        at org.projectrainbow._DiwUtils.Startup(_DiwUtils.java:415)
        at lh.handler$onServerStart$zza000(SourceFile:34)
        at lh.j(SourceFile)
        at net.minecraft.server.MinecraftServer.run(SourceFile:436)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: joebkt.World
        at java.net.URLClassLoader.findClass(Unknown Source)
        at org.projectrainbow.plugins.PluginClassLoader.findClass(PluginClassLoader.java:61)
        at org.projectrainbow.plugins.PluginClassLoader.findClass(PluginClassLoader.java:49)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        ... 9 more

[14:43:50] [ERROR]: Failed to pass event to plugin Pl3xHeads
java.lang.NoClassDefFoundError: joebkt/World
        at Pl3xHeads.MyPlugin.disable(MyPlugin.java:62) ~[?:?]
        at Pl3xHeads.MyPlugin.onShutdown(MyPlugin.java:51) ~[?:?]
        at org.projectrainbow.Hooks.onShutdown(Hooks.java:17) [Hooks.class:?]
        at org.projectrainbow._DiwUtils.Shutdown(_DiwUtils.java:453) [_DiwUtils.class:?]
        at net.minecraft.server.MinecraftServer.handler$hook_onShutdown$zze000(SourceFile:200) [MinecraftServer.class:?]
        at net.minecraft.server.MinecraftServer.u(SourceFile:415) [MinecraftServer.class:?]
        at net.minecraft.server.MinecraftServer.run(SourceFile:499) [MinecraftServer.class:?]
        at java.lang.Thread.run(Unknown Source) [?:1.8.0_131]
Caused by: java.lang.ClassNotFoundException: joebkt.World
        at java.net.URLClassLoader.findClass(Unknown Source) ~[?:1.8.0_131]
        at org.projectrainbow.plugins.PluginClassLoader.findClass(PluginClassLoader.java:61) ~[PluginClassLoader.class:?]
        at org.projectrainbow.plugins.PluginClassLoader.findClass(PluginClassLoader.java:49) ~[PluginClassLoader.class:?]
        at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_131]
        at java.lang.ClassLoader.loadClass(Unknown Source) ~[?:1.8.0_131]
        ... 8 more

The errors are happening at both startup (the top one) and shutdown (the bottom one)

What's even more confusing, is that after digging through the code, I don't know what's causing the problem. I'll look further into it later, but I wonder if the problem is when the class is loading, and not actually the code that is executing.
If so, then all we have to do is remove parts of the _PI3XLibs and put it into the _PI3XHeads jar file to have it run. Though that's just a theory, I'm not sure yet.
10
Plugin Releases / Re: Pl3xHeads
«  CodeCrafter47 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.
: [1] 2 3 ... 10

* Notifications

* Member Info

 
 

* Recent Topics

Re: Thoughts on Minecraft 1.13 Fredashay
[February 07, 2018, 06:24:46 PM]


Re: Thoughts on Minecraft 1.13 CodeCrafter47
[February 07, 2018, 09:29:50 AM]


Re: Thoughts on Minecraft 1.13 JD9999
[January 23, 2018, 05:38:41 AM]


Re: Thoughts on Minecraft 1.13 UnknownUser500
[January 21, 2018, 12:36:40 PM]


Re: Thoughts on Minecraft 1.13 BlackScorpion
[January 20, 2018, 04:00:58 PM]

* Forum Stats

  • stats : 3684
  • stats : 12313
  • stats : 1663
  • stats : 5
  • stats : 16
  • stats Most Online: 568
Powered by SMFPacks Alerts Pro Mod
SimplePortal 2.3.5 © 2008-2012, SimplePortal