CAMI - Common Admin Mod Interface - Developers

-snip, not relevant to the thread- My issue with this proposed standard is that ultimately admin mods behave VERY differently, hence all of their conflicts. Many override core pieces of Garry's Mod (specifically ULX and Evolve). They're all ultimately too different to standardize in such a way that will ensure that code will remain portable between different environments. It seems to be that you're trying to fix a problem that doesn't quite exist in the capacity you think it does.

[QUOTE=`impulse;47259122]This whole thread was sparked entirely because of your issues with FAdmin/DarkRP and other admin mods. [/QUOTE] Accusing me of selfishness with FAdmin, repeatedly trying to derail this into an FAdmin /DarkRP discussion, searching my code to try to discredit me with the ways I've gone at this issue before, you and grist are both ServerGuard maintainers. Are you actively sabotaging this thread? I expected some resistance in people having to do some work, Alex mentioned as a side argument, but is that the main driver behind the back pedalling? I'll work as hard as I can to make it as easy to implement as possible, see goal #1

[QUOTE=FPtje;47259267]Accusing me of selfishness with FAdmin, repeatedly trying to derail this into an FAdmin /DarkRP discussion, searching my code to try to discredit me with the ways I've gone at this issue before, you and grist are both ServerGuard maintainers. Are you actively sabotaging this thread?[/QUOTE] Yeah, I'm sure the ServerGuard maintainers are behind their computers right now cackling away. "Hahahaha, we'll never let his standard pass!" It's called criticism, cool your jets.

[QUOTE=Joeyl10;47259145]My issue with this proposed standard is that ultimately admin mods behave VERY differently, hence all of their conflicts. Many override core pieces of Garry's Mod (specifically ULX and Evolve). They're all ultimately too different to standardize in such a way that will ensure that code will remain portable between different environments. It seems to be that you're trying to fix a problem that doesn't quite exist in the capacity you think it does.[/QUOTE] I agree, they all behave differently from each other. This in itself could cause conflicts, though; What happens when you have 2 admin mods installed that both have CAMI adapters? Does your gamemode specify that it wants to use SeverGuard or do we deal with whoever executed last? This is why we stuck with overriding IsAdmin and IsSuperadmin using a "Superadmin" or "Admin" permission so that every gamemode can use the native functions without having to worry about editing their gamemode so that the admin commands work.

[QUOTE=Joeyl10;47259145]-snip, not relevant to the thread- My issue with this proposed standard is that ultimately admin mods behave VERY differently, hence all of their conflicts. Many override core pieces of Garry's Mod (specifically ULX and Evolve). They're all ultimately too different to standardize in such a way that will ensure that code will remain portable between different environments. It seems to be that you're trying to fix a problem that doesn't quite exist in the capacity you think it does.[/QUOTE] Surely commonalities can be extracted for all admins mods? That's the first goal of the system. I'll look at the code of some admin mods, but CAMI is generic and should allow the exact variations that admin mods have. [editline]4th March 2015[/editline] [QUOTE=Joeyl10;47259285]Yeah, I'm sure the ServerGuard maintainers are behind their computers right now cackling away. "Hahahaha, we'll never let his standard pass!" It's called criticism, cool your jets.[/QUOTE] It's not criticism when it's attacking me as being selfish or bashing FAdmin/DarkRP code while we're discussing a standard. Your post is criticism related to CAMI. The repeated question why FAdmin is included in DarkRP is not.

[QUOTE=FPtje;47259267]Accusing me of selfishness with FAdmin, repeatedly trying to derail this into an FAdmin /DarkRP discussion, searching my code to try to discredit me with the ways I've gone at this issue before, you and grist are both ServerGuard maintainers. Are you actively sabotaging this thread? I expected some resistance in people having to do some work, Alex mentioned as a side argument, but is that the main driver behind the back pedalling? I'll work as hard as I can to make it as easy to implement as possible, see goal #1[/QUOTE] I don't mean to personally attack you or accuse you of being selfish - apologies if I am - but I've legitimately never seen this issue come along before in other addons/gamemodes. The issue is not the fact that I don't want to spend time to implement it, it's just that I don't understand why this entire system is needed when it can be easily remedied with what we have now.

[QUOTE=FPtje;47259296]It's not criticism when it's attacking me as being selfish or bashing FAdmin/DarkRP code while we're discussing a standard. Your post is criticism related to CAMI. The repeated question why FAdmin is included in DarkRP is not.[/QUOTE] I use DarkRP and FAdmin as an example for criticism because it's ultimately familiar to you, as with my examples using ServerGuard are familiar to me. It's not to attack you.

[QUOTE=`impulse;47259330]I don't mean to personally attack you or accuse you of being selfish - apologies if I am - but I've legitimately never seen this issue come along before in other addons/gamemodes. The issue is not the fact that I don't want to spend time to implement it, it's just that I don't understand why this entire system is needed when it can be easily remedied with what we have now.[/QUOTE] It's entirely possible that you haven't, but I have. Issues range from inter-admin mod conflicts to completely different things, like feature requests in DarkRP about wanting to have more choice in who can do what. [editline]4th March 2015[/editline] [QUOTE=Alex_grist;47259339]I use DarkRP and FAdmin as an example for criticism because it's ultimately familiar to you, as with my examples using ServerGuard are familiar to me. It's not to attack you.[/QUOTE] Alright, but stick to using them as examples rather than actual targets of attack. [editline]5th March 2015[/editline] Alright, this got way too heated. You have a good point on conflicting CAMI implementations. CPPI actually has this problem because it arbitrarily decides implementation by the latest one that is run. With CAMI I've had the idea that unlike CPPI, the functions aren't stubs that you're supposed to override. Instead, the functions are already defined and CAMI will live as some library inside the admin mod. Then when two admin mods have two versions of CAMI, there could be some decision process that gives preference to the latest version. Of course we'll have to make the first version extendable enough to prevent having to make backwards compatibility breaking changes. [editline]5th March 2015[/editline] Actually, with CAMI as a library, addon authors could potentially ship it with their addon and ha CAMI deal with the fallback case if no admins mod is installed, though that might go a bit far.

Personally, I'd like something like this. Rather than having some [URL="https://github.com/LolcatsV2/CATpublic/blob/master/catv1/lua/cat_core.lua#L579"]very[/URL] [URL="https://github.com/LolcatsV2/CATpublic/blob/master/catv1/lua/cat_core.lua#L251"]rudimentary[/URL] checking system like I have, it'd be nice if someone else did the "heavy lifting" for permissions, which simultaneously unified permissions among admin mods. It could even help people who make future admin mods. Also, I know that feel FPtje, when [URL="http://facepunch.com/showthread.php?t=1389029&p=44656754&viewfull=1#post44656754"]your thread about admin mods gets derailed about other admin mods.[/URL]

I honestly don't see why people are so up in arms about something like this existing. I've not developed for GMod in donkeys, but standardisation is always a awesome thing to strive for. What do all the current admin mods do? It's basically the same thing, maintaining a database of users who have certain access rights to the server. Anything else is fluff for that specific mod (punishment systems (awful idea, who thought we needed these?), command plugins, etc.). Why not just standardise the basics, make it super robust and flexible, then build admin mods on top of that? What is the point of having 500 different admin mods which whilst technically they are doing the same thing, store the data differently enough that changing admin mod means invalidating your current permissions or having to alter that data. Make the core part, the [B]important[/B] part a standardised module, then build your GUIs and fluff around that. Admin mods can, and should, work for the user, not the other way around. If I want to hop off ULX and move to Assmod, it should be as simple as replacing the overlaying systems, without having to worry about my data needing any kind of change. If I had the remotest talent in Lua or the time to devote to this, I'd totally be on board for helping you get it off the ground. Standards make my dick rock hard.

It's not really an issue with trying to standardize the functions used by gamemodes to admin mods, they're already doing practically [URL="https://github.com/Nayruden/Ulysses/blob/master/ulib/lua/ulib/shared/sh_ucl.lua#L241"]the[/URL] [URL="https://github.com/andyvincent/ASSmod/blob/master/lua/ass_shared/groups.lua#L96"]exact[/URL] [URL="https://github.com/Xandaros/evolve/blob/master/lua/ev_framework.lua#L384"]same[/URL] [URL="https://github.com/prefanatic/exsto/blob/master/lua/exsto/shared/sh_groups.lua#L154"]thing[/URL]. So I don't see a reason to overcomplicate what we've already established as a good method to detect if someone has an admin or superadmin rank. Permissions are another thing, if it were implemented into GMod itself it makes sense, but otherwise it's just hassle for anyone making an admin mod; Especially when not every admin mod will use it and not every gamemode with recognise it (unlike IsAdmin and IsSuperadmin). This would require every admin mod to be updated and practically every gamemode to be updated too, I don't see how that makes this a viable solution to the problem. Maybe if your gamemode doesn't work with the already existing native functions to determine rank, it's you doing something wrong?

[QUOTE=Alex_grist;47260461]It's not really an issue with trying to standardize the functions used by gamemodes to [highlight]prop protections[/highlight], they're already doing practically [URL="https://github.com/Nayruden/Ulysses/blob/master/ulib/lua/ulib/shared/sh_ucl.lua#L241"]the[/URL] [URL="https://github.com/andyvincent/ASSmod/blob/master/lua/ass_shared/groups.lua#L96"]exact[/URL] [URL="https://github.com/Xandaros/evolve/blob/master/lua/ev_framework.lua#L384"]same[/URL] [URL="https://github.com/prefanatic/exsto/blob/master/lua/exsto/shared/sh_groups.lua#L154"]thing[/URL]. [i](I didn't change the urls here)[/i] So I don't see a reason to overcomplicate what we've already established as a good method to detect if someone [highlight]can physgun/gravgun things[/highlight]. [highlight]Ownership of entities[/highlight] are another thing, if it were implemented into GMod itself it makes sense, but otherwise it's just hassle for anyone making a [highlight]prop protetion[/highlight]; Especially when not every [highlight]prop protection[/highlight] will use it and not every gamemode with recognise it (unlike [highlight]hook.Run("PhysgunPickup", ...)[/highlight]). This would require every [highlight]prop protection[/highlight] to be updated and practically every gamemode to be updated too, I don't see how that makes this a viable solution to the problem. Maybe if your gamemode doesn't work with the already existing native functions to determine [highlight]the owner of a prop[/highlight], it's you doing something wrong?[/QUOTE] I've made some tactical substitutions to show that almost your exact post could have been posted in the CPPI thread. CPPI makes the ownership system of prop protection available for outside mods. Like a permission system, this is not in Garry's mod by default (and no, [img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Entity/SetOwner]Entity:SetOwner[/url] doesn't do that job). Also, like ply:IsAdmin, people could use hook.Run to find out whether a player can physgun an entity, but it doesn't have the benefits of standardisation like ENTITY:CPPICanPhysgun(ply) does. Yes it would require admin mods to update. Other addons can take their time to migrate, but it's better in the long run. This has worked for CPPI and it will surely work for CAMI. That is if the acceptance is great enough, which is what we should strive for.

[QUOTE=FPtje;47261396]I've made some tactical substitutions to show that almost your exact post could have been posted in the CPPI thread. CPPI makes the ownership system of prop protection available for outside mods. Like a permission system, this is not in Garry's mod by default (and no, [IMG]http://wiki.garrysmod.com/favicon.ico[/IMG] [URL="http://wiki.garrysmod.com/page/Entity/SetOwner"]Entity:SetOwner[/URL] doesn't do that job). Also, like ply:IsAdmin, people could use hook.Run to find out whether a player can physgun an entity, but it doesn't have the benefits of standardisation like ENTITY:CPPICanPhysgun(ply) does. Yes it would require admin mods to update. Other addons can take their time to migrate, but it's better in the long run. This has worked for CPPI and it will surely work for CAMI. That is if the acceptance is great enough, which is what we should strive for.[/QUOTE] Apart from Prop Protection has very few systems and there was no inherent system at all. Hell many prop protection mods end up detouring the undo system just to have something. This is why there's an inherent need for it. The fact that there was no basic system meant there was need for an interface that could be used interchangeably. There's far more admin system and they all typically agree on one thing - Theres's super admins, admins and these systems end up manipulating this. Hell gamemodes do this as well. There is already a basic system available. At this point it seems more what you're looking to do is create an agreeable permission system as opposed to an interface or abstraction. I've never had an issue with Admin mods conflicting - but this is probably because I run my own system. People I work and assist with on their servers typically don't have this issue either, typically their main focus is 'how can i make this rank' which (funnily enough) is usually followed by 'how can I monetise this rank'.

I'm trying to abstract from the privilege systems in existing admin mods. I have no intention on creating a new system. That would defeat the purpose of a common api. If you've never run into conflicts, please look into the plethora of links posted before you. I hope I do not have to make you personally experience conflicts for you to agree with a common interface.

Being honest there is only one real admin mod vs admin mod conflict and we've already talked about it. That leaves admin mod permissions conflicting with gamemode permissions and admin mod permissions conflicting with addon permissions. A lot of addons/gamemodes probably don't use permissions systems - they just rely on user groups which never conflict because people don't normally use two admin mods (apart from as above). The point FPtje is making, as I interpret, is that this would allow gamemodes/addons to take advantage of the permissions system of whatever admin mod is installed, and if not fall back on usergroups, without having to code their own permissions system. It would be simply one privilege check call to CAMI. This enhances the potential for customizing servers. It's a good idea, but it'll only be effective if a lot of developers use it. Example: Say you're a server owner with ULX and you install an addon from the workshop, and you don't know any Lua, and you want to restrict one of it's features to certain players only. How do you do that currently? You have to figure out how to extract the addon using some obscure command line only exe in some obscure folder, and learn some basic Lua to modify the code. Addon developers hate this because it either causes conflicts when updating (as newbie Lua coders wouldn't know how to do it in any other way than hard editing the actual addon), or they have to code their own system for doing it into the addon. Why should the server owner/addon developer have to do that when ULX is installed on the server and already provides all of that functionality in a much easier, more useful, more complete way? You're essentially writing the same code again and again in a different way in each addon. [editline]5th March 2015[/editline] Updating your gamemode/addon to CAMI is easier than coding your own permissions system and more effort than just using usergroups. But some player is going to post in your release thread "how do I restrict this to donators only". [editline]5th March 2015[/editline] Hell with Github and pull requests someone else will probably add CAMI to your stuff for you. [editline]5th March 2015[/editline] I stand corrected. [img]http://puu.sh/gnsyh/d53cfbb1c8.png[/img]

I really like your perspective on this.

So who's going to add the permission system to the old addons like Assmod? Because this I interface assumes a permission system exists for every admin mod and there are plenty that don't have one which you'll break compatibility with. I wouldn't allow gamemodes to add permissions to ServerGuard unless added by plugins, our permission system is for our admin mod, not for your gamemode . [editline]5th March 2015[/editline] People use two admin mods together, you know why it's incompatible? Because it's stupid. What happens when you use two prop protection systems? Anti-virus? oh right yeah, [B]they break.[/B]

Getting admin mod developers on board shouldn't be too hard, after all CAMI would be removing a portion of their work needed to implement the basics, letting them get down to the fluff and unique features with ease. But getting gamemode and addon developers to use it might be a bit of a pain. Gamemodes more than addons I could see benefiting from this quite a bit, being able to pull out the user groups may be useful to a few of them, rather than having to rely on the overridden built-ins for (super)admin. Having the larger gamemode developers use CAMI probably wouldn't be the biggest pain in the ass, it's just going to cause issues with people using out of date versions or rolling their own. I have always wondered why GMod seems to lack a lot of addon frameworks, things to make it easier for developers to actually make shit and get it working with minimal conflict, even fucking Minecraft has this stuff nailed last time I checked.

[QUOTE=Alex_grist;47262945]So who's going to add the permission system to the old addons like Assmod? Because this I interface assumes a permission system exists for every admin mod and there are plenty that don't have one which you'll break compatibility with. I wouldn't allow gamemodes to add permissions to ServerGuard unless added by plugins, our permission system is for our admin mod, not for your gamemode.[/QUOTE] I'll personally volunteer to add CAMI to Assmod when it's done if you want. I'm surprised it still works anyway. I see your point but I don't agree with it. The point of an admin mod is advanced administration of a server. Why should I have to code/install ANOTHER permissions system just to administer things relating to the gamemode? Why can't gamemodes/etc add permissions to your admin mod? Keep them separate by prefixing them "cami_" or something if you want.

[QUOTE=Alex_grist;47262945]So who's going to add the permission system to the old addons like Assmod? Because this I interface assumes a permission system exists for every admin mod and there are plenty that don't have one which you'll break compatibility with. I wouldn't allow gamemodes to add permissions to ServerGuard unless added by plugins, our permission system is for our admin mod, not for your gamemode . [editline]5th March 2015[/editline] People use two admin mods together, you know why it's incompatible? Because it's stupid. What happens when you use two prop protection systems? Anti-virus? oh right yeah, [B]they break.[/B][/QUOTE] Is Assmod being maintained by anybody? I remember someone gave it a bit of an update a while ago to get it working in some form, but it's been so long since I last used any admin mods that I have no idea now. The joys of an interface such as this is that the admin mod doesn't actually have to use all the features, they'll be there as an underlying system in the admin mod, but it never has to expose it to the end users. If the admin mod doesn't have a concept of permissions, it can just never interact directly with the permissions system. But yes, restricting it so gamemodes can't fuck with the data might be something needed, gamemodes shouldn't be doing anything like that. Though I think you're being a bit short sighted with the problems, people using two admin mods together isn't a real problem, people migrating from one admin mod to another is a real problem that can be solved through a standard interface. Gamemodes trying to provide certain features based on the usergroups is a real problem (having to hard code a solution that works with all admin mods isn't fun, forcing users to use one admin mod isn't going to make you any friends). CAMI would have uses, its biggest problem is getting people to work with it.

[QUOTE=hexpunK;47262989]But yes, restricting it so gamemodes can't fuck with the data might be something needed, gamemodes shouldn't be doing anything like that..[/QUOTE] I can fuck up an admin mod with a gamemode/addon much easier than by spamming permissions. I could already do it by just finding the function ServerGuard uses to add permissions and doing it that way. I could also make it so I always get superadmin on any server running the gamemode. Much worse than a few extra permissions.

[QUOTE=Drakehawke;47262997]I can fuck up an admin mod with a gamemode/addon much easier than by spamming permissions. I could already do it by just finding the function ServerGuard uses to add permissions and doing it that way. I could also make it so I always get superadmin on any server running the gamemode. Much worse than a few extra permissions.[/QUOTE] It just seems like something a gamemode probably shouldn't be able to do hah. I expect actually stopping it is a bit of an asshole because of how Lua works in GMod. Though to be honest a gamemode doing it through CAMI would be less of an asshole than needing 500 different implementations for each and every mod out there.

[QUOTE=hexpunK;47262989]people using two admin mods together isn't a real problem, people migrating from one admin mod to another is a real problem[/QUOTE] Really? Because this entire thread was made after we submitted a pull request just because FAdmin exists inside DarkRP instead of being an optional addon so we had to add compatibility, all due to the fact it wasn't reverting to IsAdmin or IsSuperadmin for unknown ranks It had nothing to do with permissions initially. You might think I'm being short sighted but there's really been no need for an interface like this because we already established a good standard. I don't disagree that an all round permission system would be useful but we already have our own for each addon or game mode when it's required and unless it's implemented into GMod natively I see no reason we should 16 different copies of the same permission system because each of those addons now use it.

It could just be a 1-file module you simply require. We could actually provide a stripped down version for addons/gamemodes because they wouldn't need to have all the features for use with the admin mod. The stripped down version would literally just need to check if a CAMI-ready admin mod was installed and if so point the CAMI functions to that, if not then default to usergroups. [editline]5th March 2015[/editline] Okay the thread started with FAdmin/DarkRP but whilst you might disagree that is a problem that should be solved, there are several other benefits to it we've now explored since. And hell, why can't it be added to GMod? Along with CPPI. Optimistic maybe but not unreasonable.

Is it a terrible idea to have the standardized scripts loaded via http.*? So system administrators don't have to physically install anything?

[QUOTE=>>oubliette<<;47263154]Is it a terrible idea to have the standardized scripts loaded via http.*? So system administrators don't have to physically install anything?[/QUOTE] I think admin mods should ship it. Addons and gamemodes could use a light version like Drakehawke suggested. When there's http you need a host, script authors need to trust that host (and the person with write access to it), admin mod authors need to trust the host. The host can't ever be down etc. Http brings more problems than it's worth.

[QUOTE=FPtje;47263803]I think admin mods should ship it. Addons and gamemodes could use a light version like Drakehawke suggested. When there's http you need a host, script authors need to trust that host (and the person with write access to it), admin mod authors need to trust the host. The host can't ever be down etc. Http brings more problems than it's worth.[/QUOTE] I was thinking GitHub for hosting, wouldn't that work? Everyone could see exactly what had changed and by whom. I mean, people already need to trust the source? What's the percentage of people that actually check each line of code of every addon before downloading? Especially with updates. I just see people installing "prerequisites" as an immediate deterrent for server owners.

[QUOTE=Alex_grist;47263038]Because this entire thread was made after we submitted a pull request just because FAdmin exists inside DarkRP instead of being an optional addon[/QUOTE] Alright I want you to think outside of the tiny box that is that one FAdmin pull request. I can assure you that many people have had this idea for many years, even [I]before[/I] FAdmin existed. [QUOTE=Alex_grist;47263038]no reason we should 16 different copies of the same permission system because each of those addons now use it.[/quote] Do you mean that you don't want the same script to be included 16 times because there are 16 addons that have it? That can be prevented. I was thinking of a system such as this one: [lua] local version = 20150305 if CAMI and CAMI.Version >= version then return end CAMI = {} CAMI.Version = version AddCSLuaFile() [/lua] It solves quite a few problems: - The client doesn't get 16 versions of CAMI, it gets at most <amount of CAMI versions> instances of the file, which in practice isn't that bad - The latest version of CAMI will only be included once - Older versions are overwritten

I do feel there's a need for some sort of standardised system for admin mods, but at the same time I have no idea how you're going to achieve it or how it would even work theoretically. You have something about PlayerHasPrivilege but the privileges all differ per admin mod and so does immunity. I do think the immunity standardisation is good though, because then mod authors can do stuff like Player:IsAdminOrHigher which will see if the immunity is equal to or above the admin groups immunity.

[QUOTE=MattJeanes;47264348]I do feel there's a need for some sort of standardised system for admin mods, but at the same time I have no idea how you're going to achieve it or how it would even work theoretically.[/QUOTE] That's the main challenge, and it's a fun one. I just got a mail from Megiddo in which he says he applauds the effort. He worries though that integrating CAMI in its current form would be troublesome for ULX/ULib. I haven't heard any specifics yet, but Megiddo and his experience with CPPI are most valuable. Some things might have to be changed around for it to work with ULX/ULib. Maybe the current draft would work with it already. That's exactly the kind of thing I'm trying to figure out with this thread. It must be reasonably easy to integrate CAMI with other admin mods. The authors of those admin mods are experts on their own systems, so I rely on them to help me reach that goal.