Require a GM_KEY for GM lvl 250 and below

[LucidTheStick]

file zone/doors.cpp

after:

extern Database database;
extern EntityList entity_list;

add:

//Define GM key item_id:
#define GM_KEY 100001

change:

if (sender->GetGM())		// GM can always open locks - should probably be changed to require a key
		{
			sender->Message_StringID(4,DOORS_GM);
			if( !IsDoorOpen() || opentype == 58 )
			{ 
				md->action = 0x02; 
			} 
			else
			{ 
				md->action = 0x03; 
			} 
		}
		else if (playerkey)
		{	// they have something they are trying to open it with
			if (keyneeded && keyneeded == playerkey)
			{	// key required and client is using the right key 
				sender->Message(4,"You got it open!");		// more debug spam
				if( !IsDoorOpen() || opentype == 58 )
				{ 
					md->action = 0x02; 
				} 
				else
				{ 
					md->action = 0x03; 
				} 
			}

to:

if (sender->Admin() > 250)		// GM higher than 250 can always open doors
		{
			sender->Message_StringID(4,DOORS_GM);
			if( !IsDoorOpen() || opentype == 58 )
			{ 
				md->action = 0x02; 
			} 
			else
			{ 
				md->action = 0x03; 
			} 
		}
		else if (playerkey)
		{	// they have something they are trying to open it with
			if (keyneeded && keyneeded == playerkey)
			{	// key required and client is using the right key 
				sender->Message(4,"You got it open!");		// more debug spam
				if( !IsDoorOpen() || opentype == 58 )
				{ 
					md->action = 0x02; 
				}
				else
				{ 
					md->action = 0x03; 
				} 
			}
			else if (GM_KEY == playerkey)		// Player using GM key
			{
				sender->Message_StringID(4,DOORS_GM);
				if( !IsDoorOpen() || opentype == 58 )
				{ 
					md->action = 0x02; 
				} 
				else
				{ 
					md->action = 0x03; 
				} 
			}

There you go.
Not much but I was bored and saw a note about it should require a key not just GM =)

EDIT: Should be fixed to read lvl instead if GM (was REALLY tired. lol)

[RangerDown]

Might want to check how GetGM() works. I think this function is not intended to return your GM status level, but rather is your local GM flag on or off. That is, #gm on or #gm off. So it may just return true/false (1 for true, 0 for false), and all GM's may find themselves locked out.

(Edit: But I may be wrong. I'm not at home so can't see the CVS right now, feel free to tell me if I'm wrong :P )

[Rogean]

your looking for sender->Admin(), Which will return status. And why are you making it < 250? 250 is the highest anyways, nobody can be higher than 250, so that statement will always return true.

[sotonin]

i always make myself 255. /shrug

[RangerDown]

255 is highest status.

And I'm sorry for going on the tangent I'm about to go on, but I want to point out something that's bugged me for a while now. If you're not serious about this change going into the CVS, you can disregard my entire message :lol: But if you are, please take this into consideration:

I'm not a big fan of hard coding status level requirements into the code when a GetGM() check would do. There are plenty of spots in the existing code where status level requirements are hard coded. Problem is, your requirement for status 250+ may suit your server, but how about my server where I want status 100+, and then there's Joe Bob's Server that wants 50+, and Betty Sue's Server that wants 150+.

More examples of where status checks are hard-coded, and the minimum status was evidently arbitrarily set by the coder:

- GM-only items (ie, non-legit where #si is enabled but you get "You are not a GM to summon this item" when attempting summon the best of items. The minimum status for "being a GM to summon this item" is hard coded at 100. Although each item can be set in the database to either be or not be GM-only-summonable, it requires a C++ coder to get in the code if you want that status requirement of 100 raised/lowered.

- Most, if not all, of the GM slash (/) commands that become enabled when you turn your #gm flag on have a status level check. Now, some kind of check is necessary, otherwise some people know how to trick their client into thinking their GM flag is on when it's not, and then the client unlocks those commands for them. But instead of checking GetGM(), it checks status requirements. The status requirements vary depending on command, and many of them require 80+. Ironically, 80 is higher than Guide status, and guides on EQlive summoned, zoned, goto'd, and all that other stuff as part of their day to day activities. Why did they not use either GetGM(), or at least check the requirement of the # equivalent of the commands where applicable?

Also, I checked the items database for an item id 100001. In PEQ's db, there is no such item. Does the items database from Packetcollector have one?

Don't take my criticism personally, especially if you were just offering the code as a "whoever cares to do this," since that "whoever" can replace 250 with anything they like

[LucidTheStick]

hehe wrote this when I woke up. let me fix her up a bit. I ment it for any1 that wanted to use it. if CVS wants it then they can have it I just saw a note that it should be that way and did it. let me fix her up and edit.

EDIT: The hard code is so server owners can override the key. The key is also not int he DB as it needs to be added. You can change it to any id as itz not in CVS but just a fix to make it so it requires a key and not just GM. I want it on mine as I am working on a way to make houses locked with key and sometimes you want areas where even GMs can't get into.