Restrict access to server
 

What's the best way to limit access to the server by invitation only? Currently I'm adding access by using the gm_ips field and then add the players account name, Account ID and IP.

Is their an easier way of doing this? Currently I enabled this server rule and use this script.

World:GMAccountIPList = true

INSERT INTO gm_ips (name,account_id,ip_address) VALUES ('xxxxxx','xxxxxxx','xxx.xxx.xxx.xxx');

Not sure if this is much help, but you could always #lock the server and individually set the player status high enough to bypass the lock. Don't quote me, but I think it's status of 80
to bypass ? I could be wrong.

Thanks Grumpy!

Found this thread on something like it.

http://www.eqemulator.org/forums/showthread.php?t=38968

Now i just need to do is figure out how to sett the required account level to unlock to 21 as all user accounts are default 20 on my server. Then I don't have to worry about players getting access to GM commands. Not sure what they get with account 80.

What commands they have access to is all up to you. You just have to go into the command settings table and set all
the status requirements high enough so nobody can use them (just make sure your own GM status is high enough, haha

Thanks again! Yeah i forgot about that..did that with #mystats (very cool command!) already. OK will do that instead! :)

Personally, if I was to ever go that route (invite only), I would set the starting/bind points for everyone to land in old tutoriala zone.
The only way out is to talk to a GM, hahaha

Default status is set in the config file and that can be changed to 0.

And I'm pretty sure this is the code that handles the locked bypass: https://github.com/EQEmu/Server/blob...erver.cpp#L126


EDIT:

Bot commands also have their own settings table for aliases and status.

HA! I love that idea, but then I would need to talk to a lot of alts. I guess EQemu does not have heirloom objects. I could then give them an account only port object if that was possible.

We don't have the heirloom flag implemented in the server code as yet...

I'm not even sure we have the correct field identified for all clients that support it.


One thing to remember is that not all EQEmu supported clients have the same characteristics..so, something you implement based on a later client may
kill older client support on your server.

I think the changing of account status will work the best. I noticed a lot of accounts change IPs so to avoid having to change those manually I will just make all those that have access to account status 100 so they can get past the "lock".

Then I will set all commands over 20 to 250 as that is what I use for my GM account. This should work i think.

If anyone else does the changes I made then make sure you run this query below or players will be able to go to all zones.

UPDATE zone SET min_status = 250 WHERE min_status = 80;

Do I need to manually add accounts that are not in the database to the server for them to be able to login? I tried with an account that's not in the database and it gets the error that the server is not available (because it't locked). I tried to manually add it but since its an eqemu account I dont know what the account ID is. How do I get this account into the database without unlocking the server?

I found this info, but this for local login account.

http://wiki.eqemulator.org/p?Windows...er_Setup_Guide

INSERT INTO tblloginserveraccounts (AccountName,AccountPassword,AccountEmail,LastIPAd dress,LastLoginDate)
VALUES ('your_account_name',sha('your_password'),'me@me.c om','127.0.0.1','2014-01-01 00:00:01');

I always unlock the server, have them login and then relock when I change their status.

Or host a private login server and only share the information after forum registration.

Nevermind. I took the other advice with a twist. All accessible zones are status 100. Unassailable ones are 250 and start zones are 20. Then i changed the start zones and bind to the status 20 ones.

Server unlocked ;)

Oh didn't see your reply Maze. Yeah that's what i was thinking too, but thanks for replying!