Jump to content

putra

Members
  • Posts

    9
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

putra's Achievements

Newbie

Newbie (1/3)

0

Reputation

  1. i haven't done any changes to the patch, you might have to manually code in the patch because i haven't had a chance to look at the last 30 commits
  2. that would be correct, i've had the current one running live with people actually on the realms and haven't had any issues at all with it....all the hiccups seem to have been worked out
  3. hehe yeah, sadly i had to find it out about my code the hard way but it's been running live for the past few days now and there haven't been any incidents at all happening (i also did semi-extensive testing on it on this last change with the order of values returned)
  4. *updated for 8971* http://pastebin.org/63648 pasted the updated code into pastebin force_permission.patch fixed: * players getting admin permissions if they don't have a permission forced on the realm * allowed you to not have to set "regular permissions" in the forced permission table for anyone that you've forced a permission for i made the sql pull the record from the account_forcepermission table that contains the realmid of the realm you are logging in first putting the sql return fields into the proper array elements solving the issues listed above put the code on pastebin, and uploaded the patch file to filebeam (if needed, i can put the patch file onto my rapidshare so it can have a more permanent home). i made the patch file using revision 8971. if you are having problems applying the patch through git bash, just look at the changes in code in pastebin
  5. what i was thinking yesterday with that order by clause worked, it's putting the permission for that realm if there are multiple on an account as the first record returned. the sql can probably be cleaned up a little more by limiting it to return only a single row but it works. testing yesterday i also added in a couple lines to make it so that you don't have to assign the account's gmlevel if you don't have any forced on the realm they're trying to log into but do on other realms. i'll be busy tonight and tomorrow as well, but i'll post the code changes on sunday for ya'll to see what i'm talking about here having "ON a.id = a_fp.AccountID where `username` = '%s' " would be the correct way, the reason you'd probably be getting errors in your console over it is if someone doesn't have permissions being forced. if they don't have permissions being forced they'd just have a NULL value being returned for the 3 values that are in the account_forcepermission table and an int value can't equal NULL as you can guess. though this has no impact on data being returned. a quick way to see what i mean, is to open up your preferred database editor (navicat, sqlyog, command line, etc) and use the following as your query: SELECT a.id, a.gmlevel, a.sessionkey, a.last_ip, a.locked, a.v, a.s, a.expansion, a.mutetime, a.locale, a_fp.accountid, a_fp.realmID, a_fp.security FROM account as a LEFT JOIN account_forcepermission as a_fp ON a.id = a_fp.AccountId WHERE a.username = '%s' ORDER BY FIELD(a_fp.realmid,'%u') DESC replace %s (where clause) with a username that doesn't have a forced permission in the table, and replace %u (order by clause) with an id from one of your realms. if someone has permissions being forced upon multiple realms then you can see how it will be returned by replacing the %u with a specific realm id (all that will happen is that realm's specific permissions for the user will be first in the list).
  6. how is this correct over what i had mate? it's doing a left join between account (table 1, primary table that has to have data) and account_forcepermission (table 2, secondary table that doesn't have to have data). correct me if i'm wrong, but when doing a left join it pulls it from the one on the left of the = in your ON... the table that has to have the data to begin with.... which in the case of what i had would be the account table and in the case of what you have is the account_forcepermission table granted, i haven't done joins on a daily basis since my oracle cource back in highschool until the past few months since i haven't had a real need for joins until i started working on trying to get the forced permission functionality back i even checked out w3's stuff to see if i'm correct in what i said: http://www.w3schools.com/sql/sql_join_left.asp edit - also, i've noticed that if you have more than 1 realm with forced permissions on an account that the code will completely ignore your 2nd, 3rd, 4th, etc realm's specific permissions and assign the account to have whatever your administrator level is... that it's only using the first record returned if there are more than 1 on an account. of course you can't add in on the where condition to check for the realm's id when it's pulling the authentication data, since that will make the account "not exist" for any account that doesn't have a forced permission on that realm since it only reads the first record returned on the sql (within the 12 array elements) you can order the sql by the realm id retrieved from the config files: order by field(a_fp.realmid,#) desc; replace the # with '%u' and make it use the realm number given from the config and that will make the realm you're trying to log into with a forced account be the first record. i'll do some code testing tonight when i get home from work to see if that will actually work correctly with it, the sql returns the values in the order that we'd want it but that doesn't necessarily mean that the c++ will interpret it the way we want it.
  7. i was wondering if there was a way or if anyone was willing to help with getting a patch created to reset spells without resetting a player's mounts and those vanity pets and possibly creating a command to reset a player's mounts/vanity pets as well it gets a little frustrating to reset someone's spells (or even your own spells) and have to readd previously obtained mounts and/or vanity pets. looking at the code for the function called when removing spells via a reset it seems that this would be possible, especially if the spells have some flag on them letting you know that it's a companion to be put on the companion tab or a mount to be put on the mount tab instead of in the spellbook. any help in this would be greatly appreciated, even if it's one to push me in the correct direction for it.
  8. yeah sorry about not answering sooner, i've been sorta busy at my work during the day and finishing up a complete conversion from aspire to mangos for 2 realms that are over 2 1/2 years old at nights/weekends anyway, i noticed after some extra testing a few weeks ago on it that it was applying whatever permission was the last forced permission (if it was 1, then everyone that didn't already have a forced permission assigned in that table would get 1 for example) and noticed why you'd need to change level2.cpp if( fields[4].GetUInt32() != NULL ) // checking to see if there is any data in the account_forcepermission for account if( fields[6].GetUint32() == realmID ) // checks to see if there are forced permissions on the realm security = fields[5].GetUInt16(); // sets forced permissions and worldsocket.cpp if ( fields[10].GetUInt32 () != NULL ) // check to see if data is in account_forcepermission table for account if ( fields[11].GetUint32 () == realmID ) // check to see if the realm has any forced permissions security = fields[12].GetUInt16 (); // set forced permission if so to have {}'s around the 2nd if statement in each one, making it level2.cpp if( fields[4].GetUInt32() != NULL ) // checking to see if there is any data in the account_forcepermission for account { if( fields[6].GetUint32() == realmID ) // checks to see if there are forced permissions on the realm security = fields[5].GetUInt16(); // sets forced permissions } and worldsocket.cpp if ( fields[10].GetUInt32 () != NULL ) // check to see if data is in account_forcepermission table for account { if ( fields[11].GetUint32 () == realmID ) // check to see if the realm has any forced permissions security = fields[12].GetUInt16 (); // set forced permission if so } after changing those 4 lines i haven't had any problems at all, though i'm not entirely sure if anything has changed in the authentication in the past couple weeks as i haven't even had time to look at all updates that have been done (i know i've got a bit of catching up to do, i'm running revision 8720 and mangos is on revision 8862 ). if the authentication handlers haven't changed any, then all you have to do is manually type in the code (copy and paste each line ftw right?) and as yasuno says, blizzard gm's don't have commands on every server that's up. they're actually forbidden from playing on the realms they gm on as a safety/precautionary measure on blizzard's behalf. instead, they're assigned to a battlegroup. in the private server community with the way server mapping is handled a battlegroup is essentially a specific realm on that server, so a server with multiple realms basically has multiple battlegroups . also with the way the code i wrote handles things, accounts only have their permissions force changed on a realm if they are in that table in your logon database and putting data in that table is even optional when assigning permissions.
  9. just noticed something with it that i didn't realize earlier on the select statements to the login database it's requiring the realmid, meaning that if you don't have anything set in the forced permissions table for that realm you can't log onto the account due to it not finding the information and you get a "WorldSocket::HandleAuthSession: Sent Auth Response (unknown account)." error i edited my original post with the correct code, making it check the realm id directly before applying the forced permissions instead of in the select statements
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use