Our BlockMetadata in Sponge appears to be Components. Under the Components system, the basic sketch would look something like:
public class PortalComponent extends BlockComponent {
Portal portal;
public Portal getPortal() {
return portal;
}
public void setPortal(Portal p) {
this.portal = p;
}
}
Now, BlockComponent isn’t implemented yet, but it probably will be quite soon. Portal itself:
public class PortalNetwork {
private ArrayList<Portal> portals = new ArrayList<Portal>();
public @Nullable Portal first() {
return (portals.isEmpty()) ? null : portals.get(0);
}
public Portal after(Portal p) {
if (!portals.contains(p)) throw new IllegalArgumentExcepton("Portal not in this network");
//TODO: Return the next portal in this network, wrapping around to zero if the supplied portal is the last one.
}
//(...)
}
public class Portal {
private String name;
private PortalNetwork network;
public String getName() { return name; }
public PortalNetwork getNetwork() { return network; }
}
Again, broad strokes here. I think PortalNetworks should probably also be obtainable by name from a per-world factory, and the factory be obtainable from a static… factory… method. I know that sounds needlessly complex, but this system will flex into all the places we’ve been talking about.
This. I think this kind of reflections is what we need, so that we are able to direct the creation of the teleporting backend. After that is ready, we can bind the teleporting/portaling behavior to whatever we want, be it a memory stone, a gate that flies in the air, whatever. Can we think about this as a “Portal API”?
@Falkreon looks beautiful. When the interfaces needed are implemented why don’t you start the github repo?
@Falkreon awesome. As for the networks, I put together a little thought on how they could work. Let me know what you think, @blahsd & @ryantheleach :
imagine 2 players, player1 and player2.
player1 creates portal (portal1) portal1 added to network1
player1 creates portal (portal2) portal2 added to network1
player2 creates portal (portal3) portal3 added to network2
player2 creates portal (portal4) portal4 added to network2
player2 cannot use portals from network1 without permission from player1 (who owns network1)
player1 can give player2 permission to use a portal (portal2)
once that is done, portal2 is added to network2, and player2 can use it.
thoughts:
Interacting with the portal (if you have permission to use it) brings up a GUI that allows you to choose the destination.
Chest GUI:
has icons for each portal in network.
ability to customize portal look (fallingSand block texture)
option to add/remove players to portal/network
Player can pick the icon for the network, as well as the name (use anvil.cmdBlock GUI).
If player2 added portal from player1 to his network, a new icon will be added to his GUI, but will keep the name/icon from the portal creator (possibly append creator’s name: "octoshrimpy: home sweet home ")
portals can alternatively be named portal1-1, 1-2, 2-1, 2-2, and so forth.
I agree with everything except the use of a GUI which seems to me an unnecessary complication! I’d rather portals to take you to the next portal in the network, if there’s more than one, you need to cycle through. So there’s portals 1,2,3 in the network. 1 brings you to 2, which brings you to 3, which brings you to 1. This encourages building multiple networks an hubs, which can be made into great looking and useful structures.
Adding someone else’s portal to your network would append the portal to the portal list, then? I was thinking something like advanced portals from Attack of the B-Team.
I don’t know anything about the portals in Attack of the B-Team. Honestly as far as getting the plugin out in its basic form, I’d rather do just that - the most basic, while functional, form (of player interaction). Forking it after that to add a functionality like a GUI would not be any more work than adding the functionality in the first place, so that will always remain a viable option.
Eh. I’m waiting on Forge 1.8 in order to do the main tests I need to set down custom sponge blocks. So I guess the universe is just conspiring to get this thing done X)
I do independent contracting, and I’ve even done for-pay Bukkit and Forge plugin development, but I’ve been out of work for a while. So… wink, wink, all you code shops that are hiring, I’m unattached!
I’ll be rewriting my Waypoints plugin for Sponge, which has an emphasis on the player’s experience. With the Components system, I’ll be able to provide even more customization (like configurable porting effects) and cleaner execution, without exposing the player to commands.
The big difference is that it’s about letting the player/adminstrator build the desired frame and place their portals over it. I might put in a feature to require defined frames in order to funtion.
If you wanted to create a ‘Stargate’ type plugin I always like this idea using signs:
(Imagine a sign looking like this):
First row: Town
Second Row: Shops
Third Row: > Spawn
Fourth Row: Spleef
Then if you right clicked the sign it’d change to:
First row: Spleef
Second Row: Town
Third Row: > Shops
Fourth Row: Spawn
then you’d pull the lever, enter the portal, then the next person can release the lever and change to where they want to go.
We could do more than just one type of portal but have an ultimate portal plugin with all kinds of different types of portals, and then if somebody has another portal idea they could create an addition or request ideas.
The only issue is if not everybody gets their fair share of appreciation or creditability nobody will want to add additions and will just create their own plugin, also if that developer wants donations for their plugin they won’t really want to make an addition to a plugin where a lot of people are making additions.
Overall I like the idea of having 1 central plugin with community modifications and advancements, that way there won’t be 100 portal plugins, 100 grief-protection plugins, etc and a lot more organization and ease for servers.
Probably should of watched the video then, haha. I like a style like that, also. It’s clean and easy to use, you could even just use a lever that will auto retrach on the signs then a button for the portal, then when the lever is pulled the gate resets until the button is pressed.
I had an in-development plugin called Transporters. I wanted it to be like Star Trek transporters. Worked really well, but I didn’t get a chance to finish it before bukkit kicked the… well.
I based the linking on the LapisPortals plugin, using a chest with items in it- the same items would link to each other. So players didn’t have to learn any commands.
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 which you can find at github.com/PortalAPIDevGroup (obviously) 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.
It also has a good idea when talking about custom portals, allowing administrators to set the output of their portals, design and other things (I don’t know a way to bring it to the player side).
awesome. As for the networks, I put together a little thought on how they could work. Let me know what you think, 