Introducing Phoenix

Nowadays, people are hesitating in choosing Sponge server and Spigot server.

Because Sponge server can not load Spigot plugin, Spigot server can not load Sponge plugin neither

Plugin developers are also have do some thing twice in order to make thier plugin compatible with two server.

That’s terrible, we need some change.

PhoenixFramework

PhoenixFramework is a plugin framework just like SpigotAPI and SpongeAPI.
Plugin developers can develop plugin as a Phoenix module, server owners can install the correct version of PhoenixFramework.

For Sponge server

PhoenixForSponge is a Sponge plugin that will be installed on a Sponge server, once loaded, will proceed to load PhoenixFramework modules from a special directory into Sponge. When these modules make a call to PhoenixAPI, PhoenixSponge will translate it to a Sponge call.

For Spigot server

PhoenixForSpigot is a Spigot plugin, which will translate PhoenixAPI calls to Spigot calls.

For Nukkit server

Just like above, but for Nukkit server.

Features

Expect for being complicate with them, Phoenix will add more features.

CommandRouters

Getting rid of a lot of if... else, using Phoenix’s command routers to beatify your command executors.

@PhoenixCommand(label="demo")
public class DemoCommandExecutor implements Command {
    @CommandRouter(args="help", permission = "demo.help", sender = CommandRouter.Sender.ALL)
    public boolean help(CommandSender sender, String label, ArgumentsMap args){
        sender.sendMessage(new String[]{
                "*",
                "* Hello World",
                "* -----------",
                "* /demo echo <msg> - Echo test",
                "* /demo echo_2 <msg1> <msg2> - Echo + router test",
                "* /demo echo_a <msg...> - Echo + array test",
                "* /demo <Anything_expect_above> - Mismatch test"
        });
        return true;
    }

    @CommandRouter(args = "echo <msg>")
    public boolean echo(CommandSender sender, String label, ArgumentsMap args){
        sender.sendMessage(args.getString("msg"));
        return true;
    }
    @CommandRouter(args = "echo_2 <msg1> <msg2>")
    public boolean echo_2(CommandSender sender, String label, ArgumentsMap args){
        sender.sendMessage("[Echo] msg1: " + args.getString("msg1") + " msg2: " + args.getString("msg2"));
        return true;
    }
    @CommandRouter(args = "echo_a <msg...>")
    public boolean echo_a(CommandSender sender, String label, ArgumentsMap args){
        sender.sendMessage( args.getStrings("msg..."));
        return false;
    }

    @Override
    public boolean onMissHandled(CommandSender sender, String label, String[] args) {
        sender.sendMessage("Wrong sub command?");
        return false;
    }
}

Helping us

Phoenix Framework is a huge project, it haven’t finished yet.

We need people help us in finishing PhoenixForSponge and PhoenixAPI.

I’d appreciate that if you could help us.

Github: https://github.com/ThePhoenixMC

Telegram chat: https://t.me/PhoenixMCDev

1 Like

16 Likes

I mean…
do we really need Spigot plugin compatibility?

Instead of spending your time on this project, you realize you could’ve been porting other projects, thus contributing to our plugin base and resolving the issue without having a plugin that’s going to be hell to maintain.

4 Likes

Interesting idea. Although I have to agree with codeHusky, I’m not quite sure it is necessary. It’s a hodge podge of hacking together code to support two completely different platforms. It’s not even like you’re building an API on-top of two implementations. SpongeAPI is its own API, and Bukkit(SpigotAPI for most now) is its own API. API for two APIs? Choose your platform and commit. Not sure where you’re getting the information about hesitation about. If you’re choosing a platform, research each- make a decision. Best of luck with the project!

EDIT: I also feel like not only initial development, but maintenance/updates will take longer due to the amount of code that must be translated.

1 Like

You said it’s compeletely right. We don’t need a api for two api. But It’s not like we want to develop just for sponge and spigot. Lots of people want to create their own platform like nukkit or cuberite. But there’s some probleam. No one want to develop plugins on these un-famous platforms. While once they support PhoenixAPI. They will have tons of plugins they can use. Don’t worry about community anymore.

Moreover, thank you support our project! We will do it better! xD

There are already a couple of platforms that purport to do this. More have been attempted. What makes yours different? First of all, your API is only as strong as its weakest supported platform. Bukkit is a lot less powerful than Sponge, so you won’t be able to support any features on Sponge that aren’t supported on Bukkit, because there will be literally no point in a Phoenix plugin that only runs properly on one platform.
Second, with Nukkit included, you take the effect from above and quadruple it, because now you’re supporting Bedrock, which runs decently differently from Java Edition. What you’re left with is a really stripped-down API that nobody really wants to use.
Finally, the reason people want Sponge to be compatible with Bukkit is not to get new plugins. People want Sponge to be baseline compatible with Bukkit so they can run the massive library of already existing Bukkit plugins. I hate to say it, but you’re targeting an audience that doesn’t exist.

Honestly, you’d be better off trying your hand at Pore.

7 Likes

Thanks for your reply. You just focus on Bukkit and Sponge again. Bukkit and Sponge is just a lab. We develop the PhoenixSponge and PhoenixSpigot is just like a example. We want to attract people develop on Phoenix. But the final goal of us is not just develop plugins on exist platform such as Bukkit or Sponge.We’d like more people create their own platform.

There is a interesting thing about develop a platform. No user means no developer. No developer means no user. So If some people want to develop their own platform, they need tons of plugins. They may have their own api, but we hope them can just make some adaptation for Phoenix, try their best to implement the all function of Phoenix. Then some user will try this platform. More user, more developer. More developer, more user.

Moreover, It’s doesn’t mean you are wrong. Your reply surely teach us what we should do, what we need do. Thank you again. Wait for your more advice on this project. Have a nice day! xD

Just… Maintain pore? There’s nothing wrong with Pore besides the fact that it’s a pain to maintain. We don’t need 3 APIs for no reason at all.

Trust me, if your trying to combine Bukkit and Sponge API into some fancy single API, it’s not going to work. For one, sponge API changes so often that it’s gonna be nearly impossible to keep your adaptor API working for more than a few API revisions.

Your API isn’t gonna cause some super crazy renisannce movement of plugins, as it seems like your implying?

Why encourage more platforms? Shouldn’t we focus on contributing to existing platforms to improve and stabilize our options rather than create more options?

1 Like

What you said is actually makes sense. We need make thing improve and stabilize. But is isn’t sponge or existing platforms. We want to improve Minecraft.

Why not? There is no any platforms is perfect. It’s true that sponge is more powerful than spigot. I like SpongeAPI, because it can implement more function I want to do. But It’s too hard to understand, It cost me lots of time to learn how to make plugin on Sponge. By this side, I’d like to use BukkitAPI, It’s easy to understand and cost me less time on making plugin. We develop PhoenixAPI is also for do some standardization. It can make new platform more stabilize.

Moreover, thank you for you advices. and thank you for your attention.

Then maintain Pore?

SpongeAPI is an advanced Minecraft server API. Not intended to be more complex or harder to understand. Although sometimes an API may take more time to understand in order to work with more advanced subjects. It is also worth-while to note that this API has gone through many iterations and still is- changing to be more/less complex based off community/developer feedback and has been nothing but spectacular so far.

Pore is substantially different from Phoenix.

The design of Phoenix is basically just an abstraction layer over both Sponge, Spigot and potentially more.

Pore was flawed in that it was trying to make Bukkit compatible events over the Sponge events which just wasn’t going to happen as they are fired in different places.

An abstraction layer like Phoenix has the possibility of succeeding, but needs a solid team behind them.

WorldEdit, CommandHelper, CraftBook, NoCheatPlus, are several plugins that have used abstraction layers successfully to work over multiple API’s or Minecraft internal versions.

That said, There probably is several others doing the same, WetSponge comes to mind as one I’ve seen on Spigots side that supports Sponge. There are probably more.

As for people that go, “Please just support Pore”

Pore was doomed, Phoenix isn’t, provided they can stay maintained, and maintain trust.

It would be easier to make an alternate server platform, that implemented both Bukkit and Sponge then make Pore using only Sponge.

Additionally you need to consider the crisis that caused CraftBukkit to self-DMCA.

Bukkit is GPL Bukkit/LICENCE.txt at master · Bukkit/Bukkit · GitHub. Minecraft code is not.

3 Likes

The thing is, Phenoix has to do practically the same thing as Pore, except they are building a common abstraction on two very different APIs. Developers need to expect Phenoix code to behave exactly the same between Sponge and Bukkit, and if it doesn’t, people are simply not going to deal with it.

If this turns into a beautifully crafted piece of software that harmoniously bridges the two APIs, beautiful. I’d consider using it. It’s just when developers have to rely on someone to update something that depends on someone else updating their thing is where it gets tricky.

Developers have to haul their own weight to make sure their stuff is working, but when the things they depend on stop working and stop being maintained, their workload increases exponentially and that’s my main concern.

1 Like

Thank you for your reply. And we are very interested on this.

Hoestly, just two days ago. My silly boss asked me to write a point plugins on both of Sponge and Spigot. He havs set up a mod server, but he want to use Spigot as a login server. So in this case we need to develop a plugin for 2 APIs. Right?

It’s seem like we should rewrite our Introduction, people always think we are developing a stupid API for other APIs. It’s just a API for APIs. Funny thing, isn’t it? Yes, we used to think like this. But now, we get what we are developing is a framework. It’s have lots different with pore. Pore is just a plugin allow us to use Bukkit plugins on sponge. But we not.

In this situation, I recommend you write the core of the plugin logic independent of Sponge or Spigot. You can abstract out the differences in APIs by making your own interfaces (rather than a full-blown API, simply include the things that you need).
Then use the Adapter pattern to connect your interfaces to Sponge and Spigot.

1 Like

Oh my gosh, I’ve been developing my own API like that since 2016. I believe that this idea can work, but I do not want to end with two abstraction layer alternatives (this is not what we want to “resolve” ?). Besides this, this type of project needs to ensure consistency of implementations between platforms, this is hard to do, but not impossible, also, Bedrock is essentially different from Java Edition, so, more hard work (and hard [nms] hacking?) to achieve the objective.

Sponge is also bad at forge plugin based servers idk about anyone else but I gave up on sponge all together because of the poor code on both ends sponge and mod creators and now I just stick to forge. Cauldron, kcauldron and Thermous atleast worked now a days servers blow balls trying to do any plugins I want the 1.5.2-1.7.10 days back!

@TitanzTv If you have specific gripes, can reproduce them, please make a ticket, Your post is off-topic for this thread.


But in response,

Sponge catches and protects more then anything I ever experienced on any modded server implementing the Bukkit API I had tried.

It has it’s faults, but it’s largely down to there being more mods, more coremods, and a variety of way mods can implement things that are surprising.

Whilst Sponge may spam errors occasionally, I’ve never had someones based griefed because the protection failed, which I’ve seen multiple times on old public modded servers. Shrug At least Sponge tells you something is wrong 99% of the time rather then silently hiding the bugs.

2 Likes

I agree on that one for sure. I remember trying multiplayer modded back in the Cauldron days, and the fact that they just banned all the useful items because protection plugins couldn’t cope rather turned me off to the whole thing.

1 Like