DragonPrime - LoGD Resource Community
Welcome Guest
  • Good evening, Guest.
    Please log in, or register.
  • October 19, 2017, 08:03:32 PM
Home Forums News Downloads Login Register Advanced Search
* * *
DragonPrime Menu
Login
 
 
Resource Pages
Search

Pages: [1]   Go Down
  Print  
Author Topic: Account ID  (Read 818 times)
0 Members and 1 Guest are viewing this topic.
TGTarheel
Captain of the Guard
***
Offline Offline

Posts: 143


View Profile
« on: September 13, 2017, 12:23:16 PM »

Was curious, wondering if there is any way to change a player's account ID number?  Without, of course, causing them to lose everything they had accumulated?  Literally, something that would go thru the entire database and change every line pertaining to that character to a new account number?

So that, instead of being acctid 541 for example, they could be acctid 30?

I just want to condense all the unused acctid numbers?
Logged
Anharat
Codemeister
****
Offline Offline

Posts: 266



View Profile WWW
« Reply #1 on: September 14, 2017, 06:21:09 AM »

To make it simple: don't!

It would be possible, but there is really no reason to do so and the risk of failure - forgetting some values - is way to high. The max value of an int value in the DB is more than 2.1 billion. And if you require more (which is unlikely for accounts) you could use a (unsigned) bigint value. You should really not mess with IDs!
Logged

TGTarheel
Captain of the Guard
***
Offline Offline

Posts: 143


View Profile
« Reply #2 on: September 14, 2017, 06:57:26 AM »

To make it simple: don't!

It would be possible, but there is really no reason to do so and the risk of failure - forgetting some values - is way to high. The max value of an int value in the DB is more than 2.1 billion. And if you require more (which is unlikely for accounts) you could use a (unsigned) bigint value. You should really not mess with IDs!

The only reason I ever want to, is because I assigned all my admins to the lowest numbers, and I have certain modules that can only be accessed by those account numbers.  It's easier when they all fall into the same range.
Logged
Anharat
Codemeister
****
Offline Offline

Posts: 266



View Profile WWW
« Reply #3 on: September 14, 2017, 01:35:21 PM »

Ew, you don't check access by id <= and >=, neither by adding them to an defined array or something. Never do that!

Use a flag or role that is applied to the user. That can easily achived with a module pref so you can set access per user.
Logged

TGTarheel
Captain of the Guard
***
Offline Offline

Posts: 143


View Profile
« Reply #4 on: September 15, 2017, 07:26:12 PM »

Ew, you don't check access by id <= and >=, neither by adding them to an defined array or something. Never do that!

Use a flag or role that is applied to the user. That can easily achived with a module pref so you can set access per user.

How do i go about doing that then?

I like to use those when beta-testing new modules, so that the main playerbase does not stumble into what is being tested until bugs and kinks are worked out.
Logged
Stephen.Kise
Codemeister
****
Offline Offline

Posts: 375


So meme'd up.


View Profile
« Reply #5 on: September 17, 2017, 07:31:57 PM »

I heavily advise against this. The acctid is unique for a reason, it's how other tables sync properly. Why not just check for superuser values, or a module setting/pref? Those will be safer than changing the acctid.

If it is for the purpose of letting staff test things, or making a superuser only module, I would rather you go ahead and check against the user's superuser value ($session['user']['superuser']). You can do this with:

Code:
<?php
global $session;
if (
$session['user']['superuser'] & SU_CONSTANT) {
// Functionality
}

Replace SU_CONSTANT with any of the constants prefaced with SU_ in lib/constants.php. The constants are rather autological in that their name is the option you can set in the user editor.
Logged

Slowly progressing fork with PHP 7 support: https://github.com/stephenKise/Legend-of-the-Green-Dragon
Cheap VPS Hosting (10$ credit!): https://m.do.co/c/acde75b086c5
TGTarheel
Captain of the Guard
***
Offline Offline

Posts: 143


View Profile
« Reply #6 on: September 20, 2017, 01:57:52 PM »

OK...I could try.

What I am actually doing...

Is setting up so that in, let's say, in the hook for village (where my modue would show up)

While it is in the testing stage, I only want it to access certain values and add the nav ONLY for those values.  Everyone else would not have the nav, thus would not stumble into what is not fully tested.

The reason why this first came up in the multi-poke thread, was because that one has setting in it where you can allow ONLY certain account ID's to use certain pokes.

I wanted to know how I would set that up within a module, as a temporary thing, so that, once fully tested, it could then be taken out and thus everyone would get the nav, see?

Now, the way I had done this in the past would be something like this:

Code:
if ($session['user']['id'] <= 10) {
addnav whatever
} else {}

That way only users with an account ID 10 or lower would see the nav.

So, without setting superuser tags on someone...how would I make a player a betatester on something...so that they could still see the nav where other players could not?

THAT is where I am trying to get.  I do not want to give someone Grotto Access just in order to allow them to beta test.  I have some longer-term players that I normally would consider for use for beta-testing, but their account ID's are all over the place and I wanted to order those players so that everything was in the same rage, so that my above coding would work.

I am being told this is not a good plan.  So what I am looking for then....is code that would allow access only to certain players...and without giving them Grotto Access.
Logged
DarknessFalls
Militia
**
Offline Offline

Posts: 30


View Profile
« Reply #7 on: September 20, 2017, 02:10:29 PM »

I've actually got a couple of modules that make it so that you can grant access to certain players, by granting access to them via UE. I've added the necessary snippets of code for it. The first one goes at the top of the module, at the end of your $info section of the module.

Code:
"prefs"=>array(
"allowed"=>"Is this player allowed into the area?,bool|0",

Then, under the cases, where you've got your village case:

Code:
case "village":
$allowed = get_module_pref("allowed");
if ($allowed == 1 && $session['user']['location'] == "InsertVillageNameHere"){
addnav("Ale Alley");
addnav("Name for Nav","runmodule.php?module=InsertnameofModulehere&loc=enter");
}


That should help. I hope.

This would make it so that you can pick and choose which players have access to the specific module you are testing.
Logged
RaynDarren
Mod God
*****
Offline Offline

Posts: 732


View Profile WWW
« Reply #8 on: September 20, 2017, 02:23:02 PM »

dohook:
   $allowed_acctids = array( acct id's go here separated by commas  );

case "village or whatever"
            if(in_array($session['user']['acctid'],$allowed_acctids))
{
addnav
}
« Last Edit: September 22, 2017, 04:03:57 PM by RaynDarren » Logged

Stephen.Kise
Codemeister
****
Offline Offline

Posts: 375


So meme'd up.


View Profile
« Reply #9 on: September 22, 2017, 02:44:30 AM »

OK...I could try.

What I am actually doing...

Is setting up so that in, let's say, in the hook for village (where my modue would show up)

While it is in the testing stage, I only want it to access certain values and add the nav ONLY for those values.  Everyone else would not have the nav, thus would not stumble into what is not fully tested.

The reason why this first came up in the multi-poke thread, was because that one has setting in it where you can allow ONLY certain account ID's to use certain pokes.

I wanted to know how I would set that up within a module, as a temporary thing, so that, once fully tested, it could then be taken out and thus everyone would get the nav, see?

Now, the way I had done this in the past would be something like this:

Code:
if ($session['user']['id'] <= 10) {
addnav whatever
} else {}

That way only users with an account ID 10 or lower would see the nav.

So, without setting superuser tags on someone...how would I make a player a betatester on something...so that they could still see the nav where other players could not?

THAT is where I am trying to get.  I do not want to give someone Grotto Access just in order to allow them to beta test.  I have some longer-term players that I normally would consider for use for beta-testing, but their account ID's are all over the place and I wanted to order those players so that everything was in the same rage, so that my above coding would work.

I am being told this is not a good plan.  So what I am looking for then....is code that would allow access only to certain players...and without giving them Grotto Access.

Oh, alright. If you are going to give certain users, including non-superuser accounts, access I would use DarknessFall's method or use the 'beta' tag in user editor (Misc Info > Willing to participate in beta). The beta feature will make it so that you don't have a lot of modules where you assign specific access (less preferences saved in the database). Just keep in mind that the beta flag is for beta testing, meaning they have access to all beta features you provide, not just one module. If you are going to flag people as beta testers, then the code would be:

Code:
if ($session['user']['beta']) {
// Code for beta users to access.
}
Logged

Slowly progressing fork with PHP 7 support: https://github.com/stephenKise/Legend-of-the-Green-Dragon
Cheap VPS Hosting (10$ credit!): https://m.do.co/c/acde75b086c5
TGTarheel
Captain of the Guard
***
Offline Offline

Posts: 143


View Profile
« Reply #10 on: September 22, 2017, 04:32:54 AM »

Code:
dohook:
$allowed_acctids = array( acct id's go here );

case "village or whatever"
if(in_array($session['user']['acctid'],$allowed_acctids))
{
addnav
}
in this case, I assume the account id's a separated by commas?
Logged
TGTarheel
Captain of the Guard
***
Offline Offline

Posts: 143


View Profile
« Reply #11 on: September 22, 2017, 04:37:21 AM »

I've actually got a couple of modules that make it so that you can grant access to certain players, by granting access to them via UE. I've added the necessary snippets of code for it. The first one goes at the top of the module, at the end of your $info section of the module.

Code:
"prefs"=>array(
"allowed"=>"Is this player allowed into the area?,bool|0",

Then, under the cases, where you've got your village case:

Code:
case "village":
$allowed = get_module_pref("allowed");
if ($allowed == 1 && $session['user']['location'] == "InsertVillageNameHere"){
addnav("Ale Alley");
addnav("Name for Nav","runmodule.php?module=InsertnameofModulehere&loc=enter");
}


That should help. I hope.

This would make it so that you can pick and choose which players have access to the specific module you are testing.

Yes, I like it.  I see where this works.
I could then set the boolean to default 1 and re-install the module when beta-testing is done, thus keeping it in and making the ability to re-beta the thin if necessary later.

Thanks!
Logged
DarknessFalls
Militia
**
Offline Offline

Posts: 30


View Profile
« Reply #12 on: September 22, 2017, 07:56:26 AM »

Not a problem! Here to help!
Logged
RaynDarren
Mod God
*****
Offline Offline

Posts: 732


View Profile WWW
« Reply #13 on: September 22, 2017, 04:03:23 PM »

Code:
dohook:
$allowed_acctids = array( acct id's go here separated by commas);

case "village or whatever"
if(in_array($session['user']['acctid'],$allowed_acctids))
{
addnav
}
in this case, I assume the account id's a separated by commas?

They do yes, apologies, thought I put that in there!
Logged

TGTarheel
Captain of the Guard
***
Offline Offline

Posts: 143


View Profile
« Reply #14 on: September 23, 2017, 03:12:34 AM »

Thanks, everyone for the help, then.

I just needed to have a way to control beta-testing access to new modules, one that did not grant Grotto Access, so that some players could also beta-test.

This is something I like to do after I have first assured myself that there is nothing that causes a conflict or parsing error or call stack somewhere.  Then, the next thing is to test functionality to be sure things function as intended.
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  


*
DragonPrime Notices
Play LoGD on Dragonprime

Support Us
No funds raised yet this year
Your help is greatly appreciated!
Recent Topics
DragonPrime LoGD
Who's Online
30 Guests, 1 User
Maverick
Home Forums News Downloads Login Register Advanced Search