[FIXED] Account flags aren't properly applied.
-
Grimson
- Developer
- Posts: 802
- Joined: Sat Jun 04, 2005 1:52 am
- Location: Germany
- Has thanked: 0
- Been thanked: 0
Account flags aren't properly applied.
It seems that the FLAGS setting from the account files is no longer properly applied to newly created chars. So every new char I create with my GM account (FLAGS set at 0x8000) has the privileges of a normal player instead of those of a GM. While I can still the commands (probably because it's account 0) the char starts out vulvernable, he has to pay at vendors and isn't recognized as a GM by UOX3.
-
Grimson
- Developer
- Posts: 802
- Joined: Sat Jun 04, 2005 1:52 am
- Location: Germany
- Has thanked: 0
- Been thanked: 0
Hmmm, the comments in accounts.adm say 32768 is GM, which is 0x8000 in hex. And 0x8000 worked in the past for GM accounts. As for Counsellors, do we actually support them?giwo wrote:0x8000 would actually be Counsellor, 0x10000 is a GM. Not sure if that is the cause of the problem you are having, though....
0x10000 doesn't work too. The strangest part is, that at least the chars on account number 0 should always be GMs, but this doesn't work eigther.
-
giwo
- Developer
- Posts: 1780
- Joined: Fri Jun 18, 2004 4:17 pm
- Location: California
- Has thanked: 0
- Been thanked: 0
Yes, I'm aware of what the comments say. However when the system was switched over to a bitset, the system was changed a bit, I'm guessing unintentionally.
Basically instead of listing the flags by their actual hex value, with a bitset they are in numerical order, from 0 to whatever. The math is then done 2^N so 2^0 is 1, 2^1 is 2, etc. Howver what we had set as flag 0, a NONE option, is superfluous, since none should be 0x0000, not 0x0001. Thus I removed it, and with that change in the next update, GM flags will once again be 0x8000.
As for the flags not being set properly, still looking into that one.
Basically instead of listing the flags by their actual hex value, with a bitset they are in numerical order, from 0 to whatever. The math is then done 2^N so 2^0 is 1, 2^1 is 2, etc. Howver what we had set as flag 0, a NONE option, is superfluous, since none should be 0x0000, not 0x0001. Thus I removed it, and with that change in the next update, GM flags will once again be 0x8000.
As for the flags not being set properly, still looking into that one.
Scott
-
giwo
- Developer
- Posts: 1780
- Joined: Fri Jun 18, 2004 4:17 pm
- Location: California
- Has thanked: 0
- Been thanked: 0
Based on what I'm seeing in the AccountsClass, being account 0 only guarantees that you can use any command. There is, however, a seemingly unused section of accounts.adm where account 0 would automatically be given GM privs.
As for 0x10000, that won't work as we use a UShort when we convert the string, thus the number will roll over. once it goes above 0xFFFF.
As for 0x10000, that won't work as we use a UShort when we convert the string, thus the number will roll over. once it goes above 0xFFFF.
Scott
NOOOOOOOOOOOooooooooooooooooooooooooooooooo.giwo wrote:
Fix is up on the CVS
Works, Thanks.
This is not a bug. I've wanted forever for a character type who is vulnerable YET can use the GM commands.
(I like to DM as a PC, and because of this I have to make certain GM commands available to my player characters. There is a chance they can be abused.).......if only we can set this "bug" to a new character type...
