I really like the way the permissions are looking. Although I’m a bit confused about the commands. Will the arguments of commands be parsed automatically into the datatypes requested by the command methods? I’m not entirely sure how it’d decide which overloaded method to pick from based on a String array of arguments.
There’s a whole system of dispatchers and parsing that the average plugin dev won’t need to worry about. In the end, we want it to look like this: http://docs.lapis.blue/commons/command/
Correct. When you register your commands (which will be something straightforward like
CommandService.getInstance().registerCommands(this);
It will create a series of CommandConfigurations based on the arguments you specified. So for instance:
@CommandHandler(names={"tp","teleport"}, permissions={"teleport.to.coords"})
public void onTP(CommandContext<Player> context, int x, int y, int z) {...}
@CommandHandler(names={"tp","teleport"}, permissions={"teleport.to.player"})
public void onTP(CommandContext<Player> context, Player target) {...}
This implies two CommandConfigurations:
1. /tp <Integer> <Integer> <Integer>
2. /tp <Player>
When resolving a sent-in command, it goes down the list trying to find a line that makes sense, so if you type “/tp Falkreon”, it fails to interpret “Falkreon” as an Integer, and then finds a match on line 2.
For how it tries to mistakenly interpret “Falkreon” as an integer, check the javadocs for TokenParser.
Edit: “teleport.to.player”? Wow. Fluent permission nodes need to be a thing.
1 Like
We are not Essentials.
Primary we are a toolkit for plugin authors!
Please read the start post.
I was meaning the modules you’ve mentioned, such as Chat, Permissions and Economy. I know you guys won’t be adding “/nuke” et al, hence the “without the useless tidbits” part. The actually useful bits of Essentials.
Well, we may make a repo later on called Lapis/Fun. It may have /nuke, /barrage, /slap, /strike, you never know 
.
But you’re right. Our main focus is on Lapis Commons, which will sort of be like Essentials minus the fat.
However, in the first versions we’re mainly going to focus on making it easy for developers to hook into our permissions, economy, command, etc. APIs. There won’t be much for the end user besides some primitive command interfaces. We plan to later add simple end-user support for the APIs through our commands system.
LapisCommons is not Essentials
For a server you need:
LapisPlugin
EconomyPlugin (hooks into EcoApi of Lapis)
PermissionPlugin (hooks into PermApi of Lapis)
…
LapisCommons provides NO commands for users or server owners …
We are not a real plugin.
We provide only a API and some implementations that made it easier for plugin authors,
e.g. for the EconomyPlugin authors and PermissionPlugin authors.
Maybe in the future we have a LapisFun plugin as a “real” plugin, similar to Essentials,
Or a LapisEco or a LapisPerm plugin, but that is not our primary goal (read the start post again)!
I know there’s probably a simple enough reason, but wouldn’t it be a bit better to push API ideas like this towards Sponge rather than already creating an API on top of an API? Since Sponge is still in early development, they might prefer some of the API structures that you’ve introduced, possibly. Or is it designed with functions you know aren’t inclined to the Sponge API?
Either way, I like the way it’s looking so far!
2 Likes
If and when this becomes a ‘plugin’ for sponge, can you please please please make everything editable? That was another problem with essentials. (By that I mean the “You do not have permisison” or be able to make the /kill to /slay). Just a thought
I think they mentioned that this is simply an API layer that adds absolutely no functionality to Sponge unless a plugin extending Lapis is installed. So there wouldn’t be anything to edit. They may be able to add some API stuff to making altering stuff easier, but it’d ultimately be up to the plugin devs writing plugins for Lapis.
Yea Saw that after I posted. Thanks! 
Absolutely! We’ve been talking with Sponge team throughout this whole process, and I don’t think there’s a single one of us that hasn’t sent in both developer forms. We’ve been ubiquitous voices throughout the discussions of ECS, permissions, metadata, and commands. Contribution to Sponge is our first impulse and an ongoing effort from all of us.
Lapis’s role in all this is for things which do not belong in Sponge. Sponge commands, for instance, will not have any annotation system, and will not have any facility for resolving tokens into game objects. It won’t even tokenize the String for you the way Bukkit would. But it’s precisely this simple, straightforward design that allows extremely high-performance bindings and interchangeability between Lapis and Sponge commands.
The mod community kind of misuses “API”. That’s why I prefer toolkit or commons, because this is less of a shared interface and more just making a good implementation available of features that are more specific than what Sponge provides.
4 Likes
I just saw this excellent post by sk89q about the various pieces of the Minecraft plugin and modding ecology, and thought, that’s a fantastic way to explain where Lapis sits in the stack!
As shown, the Lapis stack neither touches Forge nor user-space. You place java or lua plugins on top of Lapis, and/or use our own optional vertically-integrated Codex. Also, Commands and Permissions features from Lapis bind down into Sponge to provide basic services for plugins no matter what abstraction they sit on.
6 Likes
I was thinking that Foundation was like Essentials and this was more of an API?
This is the Lapis thread, @Squawkers13. I think Foundation is more alike Essentials than Lapis, but Lapis is more of an API. If you want more information about Foundation, check this thread out instead XP
This seems very very cool! 
I don’t know much about programming (yet), but I can’t wait for this. To me it looks like you’re going to be implementing something sort of like Skript for bukkit offered, except in what looks like a very well-thought-out package deal of all sorts of APIs for plugins to hook into. Which means that amateur server owners (like myself? 
) can make their own plugins for their servers with little knowledge of programming. Needless to say, I’m ecstatic! I wish the lapis dev team good luck.
Also, foundation also looks very cool. However, I think that it would be bad if they tried to merge with lapis, because lapis seems more like a set of APIs for plugins to hook into, and only looks to implement a few utility commands, if any. Foundation seems more like essentials to me, with the end user in mind. Perhaps the lapis and foundation devs could brainstorm ideas and stuff together, though, so that they don’t end up clashing.
2 Likes
@gratimax Some evidences:
- 12 days ago (at this time, and now 12 days ago is Septembre 18th), @Kornagan, developer of Foundation, came up with the idea. We immediatly started discussing on how we wanted to do it. At this time, Lapis didn’t even exist.
- Our first commit which included some APIs were on Septembre 20th, a time this post didn’t even exist, and the outside world didn’t know it either.
And i agree with you on some points, but here are some questions from me:
- Aren’t we allowed to have a website? We began programming one about 1-2 days after you told me.
- Yes, i changed the post a little late: so what? Look at GitHub and the thread…
- Indeed, that graphic stack was inspired, but again, aren’t we allowed to show our plan?
- I changed the FoundationDevTeam to FoundationDriven, because our package naming was com.foundationpowered.foundation. I changed that to FoundationDriven, because the powered was completely unoriginal (SpongePowered, you get it?)
Personally I have to say that so far it does seem like Lapis is more professionally managed and the staff likewise, but I won’t say that it’d hurt to have both teams working on it. Who’s time is anyone really wasting by working on their own version of anything? Only their own, presuming no copyright infringements are involved.
2 Likes
I don’t understand why Permissions and “Buckets” are 2 things. In Bukkit, every permission was a “Bucket”, that means every permission can have child-permissions. Why do you want to separate permissions and “Buckets”?
Stated on the perms page about Buckets:
Because they are not really groups, I chose to adopt a different name: Buckets. A bucket is simply a collection of permissions. It has no other given meaning.
It seems a bit confusing, but I suppose they mean that it isn’t a structure of parent-child permissions (On second look, it kinda is), but rather a label given to a collection of permissions. It’s very very similar by all means. And I suppose as well that it’s only because the labels given don’t really resemble permission nodes. That’s about as best I can describe it. I’d also appreciate some more clarification XD