MySQL User Groups?

[rainbow Dash]

Before you say "Ugh, not this again..." please hear me out.

ULX is a great admin mod. There's one flaw I have with it, one thing I see everywhere else.

MySQL support.

Yes, I know... there are addons n stuff floating around that do this, but none of them are garunteed to work, and/or their release date is dated back to 2012 (makes me scared that it wont work with GMOD 13)

So, I am asking this, where would I find a ULX MySQL Usergroup extension that is confirmed to be working? It makes it harder to do things like Forum Signatures generated from PHP without a database to work off of.

[Megiddo]

My knowledge on what works and what doesn't is limited to the forums -- you know as much as I do on the subject.

Part of the reason we don't officially support MySQL is that everyone envisions that working a different way. Should it integrate with something? Should it track more than just permissions?

[JamminR]

Maintenance of keeping ULib, and ULX that relies on it, up to date with Gmod's constantly moving coding targets is, litterally, quite often a headache for not only our team, but the community here that writes for it.

I hate to say it, but support of a publicly released SQL library would be a nightmare.
Heck...we can't stop long enough to keep from answering "I have DarkRP, how can I make myself owner?" or "How do I make myself admin?" long enough to think about supporting a complex idea like SQL that constantly changes.

Trying to keep a SQL library would make ones head explode.
Just search from the front page of our forums for 'sql', and you'll find at least 3, maybe more binary releases over the years (gm_sql, sqlloo, some others I don't remember)
Each one had it's own lua function dependency.
Even more mentions of code that various community members have done that only broke some months later with whatever update, including Megiddo and MrPresident.

Basically, what I'm thinking is, if you're advanced enough to run a SQL database for multiple servers, you're advanced enough to write a module for ULib to use it to tie them together. ULib has some nice 'post' and 'pre' command checks that could be used to perform any functions necessary, without ever touching/breaking any other ulib/ulx function.

[rainbow Dash]

Hm, unfortunately the only thing i can say im an expert in is IF THEN loops (referencing my DarkRP hud which is full of them),

If you are to officially support MySQL, I would recommend using the same modules DarkRP uses.

As for what to store, simply store anything that the server writes in its existing JSON mode (I assume thats how it saves it atm), and therefor dont actually use the database per say, but rather use it as a remote backup. In order for multiple servers to know which one is the latest version, simply add a datestamp to the information saved.

As for format, well thats simple.

Each table that contains ULX information (the default stuff) should be prefixed with ulx_ and should be named appropriately (ulx_permissions, ulx_groups, ulx_players, ulx_settings, etc).

On top of that, each ulx/ulib addon that would utilise this (and in theory, if you make it a module that actually dittos the information rather than modifying ULib or ULX, this would be harder but add support for future updates) would have their tables formatted as [shortandsweetaddonname]_[informationset]. Example: urs_ragdolls

And running back to the datestamp, ULib/ULX/whatever would stamp the time (similar to Utime) to a local file first, before taking that time (obviously not the current time at this point) and stamping it to a table called "miscellaneous" with 1 row per server, 2 columns. Column 1 (being the identifier) would be an identifier for the server. Something that makes that server stand out. Perhaps a unique ID that can be set by the coder/admin/owner. The second column would be lastupdated, containing the datestamp mentioned earlier of when that server last updated their local files. When each server is told to update (whether it be manual, scheduled, or on an event), they search through that table to find the most recent update, and if their local update is the same time as the remote database, then it wont sync. If local is older, take the remote copy. If the local is newer, update the remote copy.

Simple really! It's the most logical layout really. And given that the database is redundant, you do not have to worry about lack of connection. If there is no connection present, ULX wouldn't notice because it isn't even using the remote copy. Its only copying from the remote copy.

As for the stupid questions people ask, isn't that why you have the FAQs? To answer the stupid questions like "How do I use ulx adduser" or "Should I delete FAdmin from DarkRP even though FAdmin is supposed to work WITH ULX?"

[MrPresident]

MySQL support will never be officially supported until Garry adds official MySQL support to GarrysMod.

This has been said plenty of times.

Until then, there are a few working examples of how to integrate ULX into MySQL through community made modules. I made one myself. As always, I would be willing to share it if you'd like.
My module controls bans and user groups. The only thing it can't do is per-user permissions.

[JamminR]

MrP, exactly.
Sorry if I didn't make that clear.

Dash, "what to store" was never a question that needed answering.
And, "isn't that why you have the FAQs?" makes me cry until I laugh hysterically.
Yes. Absolutely why we have the FAQs.
Absolutely why we add a search box.

But unfortunately, most feel the need to just ask the questions without looking through the FAQs or searching the forum first.
I just saw yet another "wnen i change maps I lose access" question in our general help/support that I know we've answered many times with "make sure you're using SVN".
It's POSSIBLE that some new gmod update has broken it since our SVN update, but you'd think the poster would at least give more information as to what version of ULX they are using before saying the generic "it doesn't work"
But, nope.
So, no SQL support directly.

[rainbow Dash]

bah humbug.

I was on a roll with that idea i was expanding too.

And yes MrP, i would very much like that...dont think it will effect the sourcebans module i have in place for ban management