In case you guys are interested: the project has been started by falkreon, and you can find his commit on github.com/falkreon. I created an organization, PortalAPIDevGroup and I will add you to contributors if you want to seriously participate in laying down the code. On the organization page you’ll also find the latest fork.
Original post:
Considering that we all know what kind of plugins almost every server needs, we will need some form of organization as to who is going to contribute on what so that we can achieve better results. This topic has been covered here and here on the boards already.
That said, I’m trying to start out well by gathering together everyone who is going to want to collaborate on writing an essential portal/teleportation plugin. The idea is that instead of developing twenty separate plugins that do the same thing, we create one big, well maintained and documented plugin that does it really really well.
This page is intended for discussion on the features needed. Further discussion and actual programming will follow once we have a more precise idea on the shape the Sponge API will assume.
I will be updating this post with features as they get proposed. If some features are contested, the consensus of the majority shall prevail.
Repo
Permissions##
Who can go where
Who can see what
Who can build, What materials detecting built portals, creation by commands?
Waypoints:
Players should be able to set waypoints to teleport easily, without typing coordinates
What kind of location can the player teleport to? Random, beds, homes, portals, cross world / cross server?
Portals:
Players should be able to build structures that allow teleportation without the use of commands. This is intended for servers who need to limit the use of teleportation, either by needing a specific permission to build portals or by making it expensive for the survival player to build one. I’m thinking something about this plugin or the several plugins that make use of signs to create portal-points
How do you select locations? INVGUI commands signs etc
Mechanics (warm ups, cool downs, danger detection, Costs/Payments Group transport entites?)
The trickiest and most important parts of this plugin are ducking out of events early enough and pattern matching the gates. I’ve written one of these (it used signs to mark the gates initially, much like MassiveCraft uses the named clocks - I like that idea - and then the sign popped off and the gate was freestanding from there).
I’m hoping in Sponge we get a lighter playerFromTo event that only fires when the block the player’s feet is centered over changes. That’d be ideal for this plugin, and honestly most of the other plugins that hook this kind of data.
Thoughts on Features
Multi-world capable, BungeeCord compatibility (once Bungee is compatible with Sponge)
CustomBlocks compatibility for gate materials (it’ll probably happen without any effort on our part)
Consider using per-block metadata to speed up the test of whether a player is within a portal. The Bukkit metadata system was somewhat overengineered and far more efficient than a normal HashMap solution, plus it smooths interop with other plugins that want to know about gates. I’m hoping in addition to that we get persistence, which takes a huge load off of your gate storage and discovery.
Some kind of standard discovery of whether a client has a Waypoint plugin, probably via a plugin channel; download of server waypoints to the client so that it can manage the visual aspect of them. Otherwise, perhaps default to Octoshrimpy’s beacon beam idea, I really like that one.
I’m kind of surprised Nijiko-san hasn’t spoken up about permissions plugins. We don’t yet know in what combination we’ll be seeing starnodes, groups, rank ladders, etc., and permissions interop is going to be important. Some people do like having a staff interaction aspect to activating warps.
Permission-affected limits on how many warps one can make.
Optional per-world configs
Basically, the config files are going to be a mess if we’re not careful.
Makes me wonder, I remember seeing a post on Bukkit about flying falling sand(which aren’t really falling). It would be interesting to see a flying, moving portal which players would have to chase to get in.
CustomBlocks for portal materials! Mostly kidding. Mostly.
BlockChange for beacons is probably a bad idea, considering the sheer number of phantom blocks you’d need to send, and then resend the real blocks for when you got close. Then resend the beacon blocks when you walk further… I don’t know. I do know that the beacon beam is not an entity that we could just send packets for, it’s a clientside effect. I like the falling sand idea, I’ve built sky temples out of flying blocks with fallingSand rising from the ground, so I know how much you can do with them.
This should all be considered as part of this plugin’s permissions system even though I reckon it would be unwieldily for the player to set up such a friend list. Regarding the per player limit, it sounds reasonably easy to make. Overall permission necessary to create a gate is a no brainer.
I agree with @Falkreon on the difficulty of handling the block’s beams. That seems like an over complication to me. But anyways, I think this time is more suitable to more generic design issues, and then when we’ll have actually made the plugin work, we can fork it and have one displaying beacons, one with custom blocks, one with regular blocks and named clocks… Whatever you like, you know?
@Falkreon: Would you want to partecipate on the development of the plugin? And more generally, how many of you intend to participate in coding? This is to understand if this tiny subproject can be useful as an organization method or if it will become a pointless feature wish list with nobody developing.
I’m afraid I have the expertise but not the time. As more of my projects mature I should have more time to actually lay down some code, but it’s always seemed like 3’s my absolute limit.
I’m (mostly) no good behind code. Not like @Falkreon, but I can read and test, and think, and I’m a great idea generator. I’ll help where I can, definitely.
@Falkreon that’s unfortunate. I am in no way able to handle a good form, vaste public plugin. Maybe you could swoop in after I made the basics work and fix it up to be presentable and efficient. @octoshrimpy I guess that’s always good to have! Since we have so long before Sponge will possibly be ready for actual use, you might want to look into some java tutorial and get ready for that.
That means overriding the portal cooldown, no? otherwise, bad things happen… unless the portals have frames, and if player is inside the frame, teleport the player with the frame.
If you use fallingSand and turn the entity’s block-placement off, then nobody’s ever standing in a portal block. They just happen to be in roughly the same place as an entity.
Or at least the functionality needed to replicate it into this plugin/framework if it takes off.
We need to concentrate on:
Locations, (Random, beds, homes, portals, cross world / cross server)
Access (who can go where who can see what)
Build-ability (who can build, what materials detecting built portals, creation by commands?)
UI (how do you select locations? INVGUI commands signs etc)
Mechanics (warm ups, cool downs, danger detection, Costs/Payments Group transport entites?)
Effects (Lightning, beacons, other?)
Mostly kidding. Mostly.
I’ll help where I can, definitely.