[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]
You could use GitHub raw for that, history and all speaks for itself.
I'm currently working on an admin mod that I plan on making open source, I'd implement something like this if it was simple to implement. I like what Drakehawke said about it being a single module you would just have to require.
[QUOTE=Phoenixf129;47266009]You could use GitHub raw for that, history and all speaks for itself.[/QUOTE]
I'm still not sure it's a nice way to do it. It's a bit of an intuition that you shouldn't download scripts through http. I mean those trust issues are there, but how many devs will understand the guarantees of git history? Besides, you can change git history. People will notice that when they pull, but not when downloading the raw.
Downloading a script through http is a barrier for many devs, and it really hurts acceptance. They would still need to add some library of code that does the downloading. If I were given a standard that was to be downloaded like that, my first reaction would be "NO, not happening" even before I look at where it's hosted. None of my stuff ever downloads scripts from a site. I don't want that standard to be the first one. Vital scripts are to be available on startup, not downloaded in hindsight from some server.
Have a less intuition based argument: http forces the loading to be somewhere way after InitPostEntity. Admin mods may very well want to load and sync their stuff before that. Other addons would want to add privileges asap too. The http method would make things really annoying.
What [B]is[/B] important is for server owners to actually understand the game that they're hosting. I know you'd like to make it easier for the less code-inclined, but to what lengths do we really need to go? If you're going to host a Garry's Mod server, you should, at the very least, know basic lua. If you don't, well then to me you're not entirely qualified to be a server owner. It's akin to saying the CEO of a company has no idea how the company's product/service works (much less how to manage the company).
Providing a general framework for administration mods to use probably won't stop the influx of "how i does" issues on your github pages (or whatever you happen to use), and I feel like it might create a kind of barrier for admin mod developers — example, developer wants to add some fancy way of checking permissions, or to have multiple groups assigned to one person, or whatever, but they can't do that since they have to make it compatible with CAMI.
Don't get me wrong, I like the idea, but I really do feel that if you're going to host a server, you need to take the time to set it up and configure everything to what you have installed, which probably would require you to learn basic lua. I don't like the thought of people just throwing servers together like some kind of soup, turning it on, and saying "ok when does my money start flowing in?!?!"
[QUOTE=Z0mb1n3;47313644]What [B]is[/B] important is for server owners to actually understand the game that they're hosting. I know you'd like to make it easier for the less code-inclined, but to what lengths do we really need to go? If you're going to host a Garry's Mod server, you should, at the very least, know basic lua. If you don't, well then to me you're not entirely qualified to be a server owner. It's akin to saying the CEO of a company has no idea how the company's product/service works (much less how to manage the company).
Providing a general framework for administration mods to use probably won't stop the influx of "how i does" issues on your github pages (or whatever you happen to use), and I feel like it might create a kind of barrier for admin mod developers — example, developer wants to add some fancy way of checking permissions, or to have multiple groups assigned to one person, or whatever, but they can't do that since they have to make it compatible with CAMI.
Don't get me wrong, I like the idea, but I really do feel that if you're going to host a server, you need to take the time to set it up and configure everything to what you have installed, which probably would require you to learn basic lua. I don't like the thought of people just throwing servers together like some kind of soup, turning it on, and saying "ok when does my money start flowing in?!?!"[/QUOTE]
This guy is right. As a (former) DarkRP developer (both GitHub end AND on a server), I constantly had to solve the war between the server owner and the server stability, because the owner just wanted more addons and would complain to me when they were incompatible.
While the idea is right, the problem comes down to a phrase you yourself used on GitHub the other week Falco: "Give them a finger and they will take an arm." If we keep pandering to those who have no understanding of LUA, we will end up with more mindless 12 year old server owners who have no reason to learn LUA. It's the same reason I'm against Coderhire, Scriptfodder, and paid-for pre-made scripts. I'm even... to a degree... against the Workshop because it makes it too easy for dumbies to start a server, and other dumbies think they've put a lot of work into it.
CAMI will just be another inch to the stake being driven into Garry's Mod. Personally, I vote against CAMI as a whole, and instead propose that individual developers, if they so choose, should make helper functions that can identify what admin mod(s) are currently active on the server, and roll from there.
TLDR Cami sounds nice, but ultimately its pandering to morons and would only give those morons another excuse to not learn LUA and instead buy absolute crap from ScriptFodder. and I do mean crap, a mate gave me a votemenu for TTT to install from that, the damn thing was so shitty it removed all the HUD hooks just so it could localize them. When you closed the menu, pressing the chat key caused your aim to snap up to the left.
[editline]30th March 2015[/editline]
[QUOTE=FPtje;47263897]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.
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[/QUOTE]
[LUA]if CAMI and CAMI.Version >= version then return end[/LUA]
Wouldn't this prevent live code updates too?
[QUOTE=InterVafe;47418381]This guy is right. As a (former) DarkRP developer (both GitHub end AND on a server), I constantly had to solve the war between the server owner and the server stability, because the owner just wanted more addons and would complain to me when they were incompatible.
While the idea is right, the problem comes down to a phrase you yourself used on GitHub the other week Falco: "Give them a finger and they will take an arm." If we keep pandering to those who have no understanding of LUA, we will end up with more mindless 12 year old server owners who have no reason to learn LUA. It's the same reason I'm against Coderhire, Scriptfodder, and paid-for pre-made scripts. I'm even... to a degree... against the Workshop because it makes it too easy for dumbies to start a server, and other dumbies think they've put a lot of work into it.
CAMI will just be another inch to the stake being driven into Garry's Mod. Personally, I vote against CAMI as a whole, and instead propose that individual developers, if they so choose, should make helper functions that can identify what admin mod(s) are currently active on the server, and roll from there.
TLDR Cami sounds nice, but ultimately its pandering to morons and would only give those morons another excuse to not learn LUA and instead buy absolute crap from ScriptFodder. and I do mean crap, a mate gave me a votemenu for TTT to install from that, the damn thing was so shitty it removed all the HUD hooks just so it could localize them. When you closed the menu, pressing the chat key caused your aim to snap up to the left.
[/QUOTE]
Giving people the option to switch admin mods and give developers an easier time developing a project that interfaces with admin mods is useful. CAMI has very little to do with stupid server owners and more to do with admin mods being compatible. Making other developers dig through multiple admin mods source to figure out how to get a group is more of a hindrance than having a single method to get the group.
I agree with mostly everything FPtje says. We need a system like this.
I highly appreciate the effort you have put into this, keep up the good work.
I am checking up on the document and posting my thoughts every now and then. Please continue to work on and refine this.
I look forward to the day that we can include and mix administration modules. People like to pick and chose.
An À la carte system would be greatly beneficial to
server owners (to select only the powers their staff need, and to delegate those powers to ranks)
server administrators(to have all the tools/controls they need)
and to the users(no goddamn errors when people try to mix admin mods)
[QUOTE=Alex_grist;47263038
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.[/QUOTE]
I disagree, i get a lot of requests to add support for admin mod X to a script because they are all slightly different. It takes a lot of time to support each admin mod, a simple permission interface would be nice.
Have any admin mods fully implemented this yet?
[QUOTE=Ott;47795274]Have any admin mods fully implemented this yet?[/QUOTE]
I'm thinking about adding it .. tho tbh. I'm not sure if its a good idea.
There are pro and cons, but CAMI looks more like an adminmod than an interface.
I can see the good side:
- Ability to add global commands.
- Global ban systems .. ect
But at the same time, mod-extensions shouldn't go as far as edit/block privileges, usergroups or any of the 'core' functions. It can easily break or hijack the adminmod.
It should only support extra commands and add/check privileges.
Don't add this yet, it isn't finished yet.
Just so I understand this, you are trying to get all admin mods somewhat compatible? Also I fail to see why one would run multiple admin mods togheter, this already sounds wrong to me. It reminds me of some guy where I had to fix his PC and he had pretty much all AV's installed you can think of and they had to always fight for the file access which was pretty funny actually to see later in the trace.
Don't get me wrong I like the idea I just see no real use for me, I always end up doing my own stuff :v
[QUOTE=Dear_Matt;47800105]Also I fail to see why one would run multiple admin mods togheter, this already sounds wrong to me.[/QUOTE]
Not to many other people.
Because one administration mod offers something the other does not and vice versa, mainly because the servers operator is inexperienced, dumb or doesn't know how to Get the functionality they need (or want) in the other system.
It should be used to ease checking of privilege for addons and such. Sure, we have IsAdmin and SuperAdmin and admin mod makers can always override these, but not all admin mods do it the same way. CAMI would unify that.
[QUOTE=FPtje;47800352]Not to many other people.[/QUOTE]
You have to rewrite most of the adminmods to make them support each other, and data between them might get de-synced .. also witch adminmod have the highest priority over the other in that case?
The only stable way would be, to make CAMI an adminmod itself .. and disable the 'core' of the other mods.
It raises too many questions/problems to make two admin-mods run on the same server.
Instead I think it would be better to focused on mod-extensions instead.
Something like:
CAMI.AddCommand(str,...)
CAMI.HasCommand(str)
CAMI.AddPrivilege(str)
CAMI.HasPrivilege(ply,str)
CAMI.CanTarget(ply,ply2)
That alone can allow gamemodes and exstra-command-mods to interact with the chosen adminmod.
Who's idea was it to run multiple admin mods at once?
You know, addon conflict is a really big issue when it comes to Garry's Mod, and not just with admin mods.
I have received, idk, about 4,000 complaints about how my Portal Gun isn't working when the user has another person's portal gun installed. Both of us used weapon_portalgun as the class for our weapons, and while at any point one of the authors could yield and change the name of the weapon, it's still an unfavorable situation.
When addon authors are irresponsible and use global variables, return a hook they shouldn't, etc. it can cause tons of issues.
Perhaps a more encompassing solution to these conflicts would be a system of sandboxing for individual addons, as well a tutorial on the wiki which explain common compatibility pitfalls and a list of standards for the responsible scripter to follow.
For instance, "Unless absolutely necessary, all your functions should be declared as local." or "Never return a hook by default."
As for CAMI, your best bet is to ship it as a 1-file module or otherwise get Robotboy to add it to the gmod git once it is stable enough, that way both admin mod creators and everyone else can use a standardized system without having to go out of their way.
[editline]few seconds later[/editline]
[QUOTE=hexpunK;47262959]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,[B] even fucking Minecraft [/B]has this stuff nailed last time I checked.[/QUOTE]
It's a sad day when we're getting stood up by those Minecraft shits.
[QUOTE=Willox;47803388]Who's idea was it to run multiple admin mods at once?[/QUOTE]
DarkRP ships with FAdmin, many people want to install another Admin mod along with it and use them both.
[editline]26th May 2015[/editline]
Conflicts between them can be resolved, which is a much better approach than telling people not to do it I The first place.
[QUOTE=FPtje;47805811]DarkRP ships with FAdmin, many people want to [B]install another Admin mod along with it and use them [U]both[/U].[/B][/QUOTE]
To use the other one instead* :v:
[sp] No hard feelings [/sp]
I thought CAMI would be used to allow for FAdmin to be disabled without losing any of DarKRP's features. Good luck having multiple admin mods running at once with a single instance of CAMI managing both.. or vice-versa.
[QUOTE=Willox;47805984]I thought CAMI would be used to allow for FAdmin to be disabled without losing any of DarKRP's features. Good luck having multiple admin mods running at once with a single instance of CAMI managing both.. or vice-versa.[/QUOTE]
FAdmin can already be disabled without losing any real DarkRP features. CAMI is not for FAdmin only, CAMI does two things:
- Common interface to admin mods for third party mods to use
- Make it possible for admin mods to coexist without either or all of them throwing a tantrum
Seriously, the biggest problem with having multiple admin mods installed is them [url=https://github.com/Nayruden/Ulysses/issues/463]fighting over what the usergroup of a player is.[/url] Standardise a simple [I]PlayerUsergroupChanged[/I] hook and this problem is [B][I]history.[/I][/B]
[QUOTE=FPtje;47806218]FAdmin can already be disabled without losing any real DarkRP features. CAMI is not for FAdmin only, CAMI does two things:
- Common interface to admin mods for third party mods to use
- Make it possible for admin mods to coexist without either or all of them throwing a tantrum
Seriously, the biggest problem with having multiple admin mods installed is them [url=https://github.com/Nayruden/Ulysses/issues/463]fighting over what the usergroup of a player is.[/url] Standardise a simple [I]PlayerUsergroupChanged[/I] hook and this problem is [B][I]history.[/I][/B][/QUOTE]
Not all adminmods are working the same way or use usergroups like that. [QUOTE]
What will happen if an adminmod supports invisible ranks? What will happen if you edit the ranklist in one of them? What will happen if you got a mod to sync the ranks between multiple servers? What will happen if one of the mods break?[/QUOTE]
Instead of including an adminmod in a gamemode (which I find ridiculous, sorry). You should replace FAdmin with CAMI and add those functions DarkRP need. Then release FAdmin as a standalone mod that uses CAMI.
If DarkRP is too entangled with FAdmin .. disable FAdmin if CAMI has been initialize.
Everyone is happy.
[b][Edit][/b]
If needed, label FAdmin to support DarkRP only.
[b][Edit2][/b]
Remember. Some adminmods need the commands to be added clientside as well .. but lets focus on making CAMI first.
[QUOTE=Nak;47806839]Not all adminmods are working the same way or use usergroups like that.
[/QUOTE]
[url=http://wiki.garrysmod.com/page/Player/SetUserGroup]GMod itself uses usergroups like that[/url]
[QUOTE=Nak;47806839][quote]What will happen if an adminmod supports invisible ranks?
[B]Then it bypasses GMod's usergroup system and the behaviour w.r.t. CAMI is undefined. [/B]
What will happen if you edit the ranklist in one of them?
[B]Good point, maybe the UsergroupChanged hook should use SteamID instead of a player object. I think it's safe to assume all admin mods use some derivative of the SteamID, be it SteamID64 or UniqueID, which can both be easily calculated from the SteamID. I might be wrong here.[/B]
What will happen if you got a mod to sync the ranks between multiple servers?
[B]Have the admin mod call the hook when the player joins and all admin mods will be in sync. Also have the admin mod listen to the hook and sync usergroup changes from other admin mods with the other servers. This way, you can even have two admin mods that both sync with other servers since they'll both update each other. This can get complicated, but it should be managable by calling the hook at the right times and properly updating the database.[/B]
What will happen if one of the mods break?
[B]In what way can a mod even break such that it negatively affects CAMI? Sure, it can misbehave and not stick to CAMI's rules, but that would just be a bug for the author to fix.[/B]
[/quote][/quote]
[QUOTE=Nak;47806839]Instead of including an adminmod in a gamemode (which I find ridiculous, sorry). You should replace FAdmin with CAMI and add those functions DarkRP need. Then release FAdmin as a standalone mod that uses CAMI.
If DarkRP is too entangled with FAdmin .. disable FAdmin if CAMI has been initialize.
Everyone is happy.
[/QUOTE]
This thread is not about whether FAdmin should be in DarkRP. That's how it is and that's how many people like it. FAdmin is merely an example as to why some people want multiple admin mods. [url=http://forums.ulyssesmod.net/index.php?topic=3779.0]One can find[/url] [url=http://forums.ulyssesmod.net/index.php?topic=8216.0]other examples[/url]. I mean we can be glad that (AFAIK) there's only [B][I]ONE[/I][/B] big conflict: the difference in usergroups between them.
CAMI is about solving that conflict, not about telling people not to run two admin mods at the same time.
[QUOTE=FPtje;47807443]This thread is not about whether FAdmin should be in DarkRP. That's how it is and that's how many people like it. FAdmin is merely an example as to why some people want
[/QUOTE]
You where using it as an example .. and how it had created problems. I'm just giving you a solution.
CAMI is NOT an interface in this state. It looks more like a framework.
It doesn't exchange functions with the given adminmod .. it controls the adminmod to allow it to coexist with another. It will create more problems than it will solve.
The only valid goal I can see is: [QUOTE]Provide an interface to third party addons to create and query privileges (/commands).[/QUOTE]
That alone will still support the TAB menu in DarkRP .. and its commands .. ect
If you want CAMI to control the adminmods like that, I suggest to rename CAMI to CAF (Commen Admin Framework) or something.
[QUOTE=Nak;47809453]You where using it as an example .. and how it had created problems. I'm just giving you a solution.[/QUOTE]
It is a solution only in the sense that it defers the responsibility to the end user who is unable to do anything but avoid the problem altogether.
[QUOTE=Nak;47809453]CAMI is NOT an interface in this state. It looks more like a framework.
It doesn't exchange functions with the given adminmod .. it controls the adminmod to allow it to coexist with another. It will create more problems than it will solve.[/QUOTE]
Are you reading the "[B]Won't do[/B]" section here? I scrapped more than half of CAMI since this thread started. CAMI now only has two things:
- Privilege registering and checking for third party mods (and third party mods only! admin mods are not supposed to sync all the privileges!!)
- Usergroup syncing, to fix the conflicts between admin mods. It currently exists of registering usergroups (with the most basic info) and the CAMI.PlayerUsergroupChanged hook.
Of course it has the book keeping functions to make it work, but they all come down to the above two concepts. The only thing CAMI itself will do is keeping track of the registered usergroups and privileges. The rest is [B]all[/B] up to the admin mods and third party mods.
I really don't understand why people are so pissed at falco here like wtf. It seems like a neat idea that will solve problems for somebody somewhere so stop trying to fit your irrelevant bullshit about how he's asserting its usefulness and how DARKRP and fadmin are all shit and instead focus on how you could potentially utilise this project to better your own projects - can't? Then fuck off unless you want to make a genuine contribution to the thread and to better falco' idea - there is literally no benefit to doing any of the following:
- Stating how this is only a problem in DarkRP - if it solves a problem even in one spot the community should be enthused to improving that solution rather than quoting it's redundancy
- Being pedantic over the exact definition of CAMI
- anything other than constructive criticism of the project - nobody gives a fuck what you think of darkrp nor fadmin nor the implementation of the latter.
<3 feel free to pick apart the above if I'm mistaken but this is what I see
As for the actual topic: it seems like a solution to a problem server owners who like the fadmin scoreboard and easy access buttons but want ulx because of 'reasons' and then get mad when shit breaks and any solution to kids getting mad and begging for solutions is a tick in my book <3
[QUOTE=DrJenkins;47816478]I really don't understand why people are so pissed at falco here like wtf. [/QUOTE]
Most people don't like being proved wrong in an open forum, and Falco does a good job at proving people wrong. Though he can be a bit abrasive about it.
I liked the idea of a common interface for adding chat/console commands for admin mods. Apart from the user group situation, I see that as one of the primary benefits. Conventionally, you'd have to check which admin mod was installed and add your command appropriately. If they used a non-standard admin mod, you'd have to add support manually.
Sorry, you need to Log In to post a reply to this thread.
