100 réponses à ce sujet

[Irisiri]

How to prevent players from camping inside another player's vault?

[FunkySwerve]

Long story short, you don't, not in vanilla nwn. It's likely possible to develop a plugin to prevent this, but we haven't had to, since it only blocks login on the same server, and we have 12 up and running at any given time. This has never happened on HG, to my knowledge - at a minimum, it's never been reported. Are you currently having this issue?

Funky

[jess_amour]

Can you please explain how to set up the item conversation fired when they log into the docks? i cannot quite understand how it would automatically fire up if it is an inventory item. Thankyou

[FunkySwerve]

I answered this in a pm - please let me know if you have followup questions.

Funky

[Khuzadrepa]

This is FANTASTIC code! Thank you so much for all you give to the community, Funky!!

[Greyfort]

All I can say is great Job Funky.

You have always been generous and helpful to nwndb, nwnx, windows,linux users. For that I thank you. Also I have visited your server and enjoyed very much.

As a programmer I have tried to offer solutions to the community for all data base systems, knowing that all of us are at different levels of programming skills. I am curious to see any code one of us comes up with, giving us greater resources to insure security and expand our ability to keep this great game going.

All of you keep up the great work, thank you for sharing that's what will keep this community and game going.

[jess_amour]

FunkySwerve wrote...

I answered this in a pm - please let me know if you have followup questions.

Funky

Thankyou Funky. I haven't attempted to add it in yet as i have to add it to an allready exisiting script but i shall most certainly ask if i have problems.

[HUNTER_of_Wisdom]

This is wonderful.
But I would like a set of SCRIPTS to link the players' login passwords, does anyone could help me?

I thought about creating a table on my website, called LOGIN, that stores information through the previous registration, and at some point the script made ​​the connection with this table and check whether the password is actually the real ... this would be possible, could someone help me?

(The table is in MySQL, i have de script conection in PHP)

Thanks ...

Modifié par HUNTER_of_Wisdom, 20 mai 2012 - 09:31 .

[Sir Elric]

I’ve been out of the NWN scene for awhile now but still run a 24/7 PW and this issue was only brought to my attention recently by a player.

Firstly, thanks for the code Funky saves me messing about scripting something. I implemented the native Bioware database version you posted and gave it a quick test and it seemed to be working fine. There is however a simple way round it, which luckily we stumbled across when I asked player to test it and he managed to still log in on my account with the scripts in place. It’s a simple tweak to the existing code to fix it. I have PM’d PM Funky with my findings and leave it to him to change the code if he agrees with what I found. This effects the Bioware database version and possibly the MySQL version too.

Modifié par Sir Elric, 08 juin 2012 - 01:59 .

[4BOLTMAIN]

Im not sure if this has been though of before but...

Is it possible to prevent the module from displaying a players account name... like when you click their avatar to whisper them?

I took my mod offline when the master server went down but would like to bring it back up again.

Hiding a players account name would be very helpful.

Thank You FunkySwerve and Sir Elric for helping me out back in the day on the old forums : )

Modifié par 4BOLTMAIN, 04 juillet 2012 - 09:31 .

[HUNTER_of_Wisdom]

Well it would help, 4BOLTMAIN.
If you can post the LINK to do this would be great, however I was thinking about change .exe, that makes logging into the website of BIOWARE to altentincar tables in my MySQL PHP of my website .... Well all I want is to give more security in my SERVER.

Thanks to all.

[4BOLTMAIN]

HUNTER_of_Wisdom wrote...

Well it would help, 4BOLTMAIN.
If you can post the LINK to do this would be great, however I was thinking about change .exe, that makes logging into the website of BIOWARE to altentincar tables in my MySQL PHP of my website .... Well all I want is to give more security in my SERVER.

Thanks to all.

I dont have a link and havent looked into it other than asking here if it could be done.

I know you can do a lot of stuff with SIMTools, something like this would be great for the community.

[4BOLTMAIN]

How long will the pc be flagged for accepting a new key?

Can I delay a sql command by 5 minutes (to remove the flag) or will that cause problems?

EDIT____

I never messed with sql commands before... this is why I am asking.

Modifié par 4BOLTMAIN, 05 juillet 2012 - 10:09 .

[Baaleos]

Yes - you can set the system to remove the 'new cdkey' flag, after x amount of seconds.

    object oPC = GetPCSpeaker();
    string sPlayer = SQLEncodeSpecialChars(GetPCPlayerName(oPC));
    string sSQL = "UPDATE pwdata SET tag='Adding' WHERE name='PlayernameKey_"+ sPlayer + "'"; //must mark as adding
    SQLExecDirect(sSQL);
    AssignCommand(GetModule(),DelayCommand(300.00,TimeDelayedRemove(sPlayer)));

void TimeDelayedRemove(string sPlayer)
{
    string sSQL = "UPDATE pwdata SET tag='' WHERE tag ='Adding' and name='PlayernameKey_"+ sPlayer + "'"; //must mark as adding
    SQLExecDirect(sSQL);

}

This will reset the player back to a non-adding state after 5 minutes, but only if they have not managed to log in with the new CDKey within that timeframe.

[4BOLTMAIN]

Baaleos wrote...

Yes - you can set the system to remove the 'new cdkey' flag, after x amount of seconds.

    object oPC = GetPCSpeaker();
    string sPlayer = SQLEncodeSpecialChars(GetPCPlayerName(oPC));
    string sSQL = "UPDATE pwdata SET tag='Adding' WHERE name='PlayernameKey_"+ sPlayer + "'"; //must mark as adding
    SQLExecDirect(sSQL);
    AssignCommand(GetModule(),DelayCommand(300.00,TimeDelayedRemove(sPlayer)));

void TimeDelayedRemove(string sPlayer)
{
    string sSQL = "UPDATE pwdata SET tag='' WHERE tag ='Adding' and name='PlayernameKey_"+ sPlayer + "'"; //must mark as adding
    SQLExecDirect(sSQL);

}

This will reset the player back to a non-adding state after 5 minutes, but only if they have not managed to log in with the new CDKey within that timeframe.

I was thinking something more like...

sSQL = "UPDATE pwdata SET tag='Set' WHERE name='PlayernameKey_" + sPlayer + "'";
DelayCommand(300.0, SQLExecDirect(sSQL));

Sorry I wasnt more clear in my previous post.

What exactly does this do...
AssignCommand(GetModule(),DelayCommand(300.00,TimeDelayedRemove(sPlayer)));

Edit____

I just tested my code and it worked, I also add a check in the condition so the conversation node wouldnt show again if your account was already flagged.

Modifié par 4BOLTMAIN, 05 juillet 2012 - 12:33 .

[Baaleos]

The way I understood your request, was that
1. Player would toggle their account to be in 'add' mode, so the next cdkey that logs in, would be added to the allow list.
2. However, if after 5 minutes, they have not signed back in, then the system would automatically toggle them back to normal mode, to prevent someone else from logging in and gaining access to their account.

The code I gave you, does the following
1. Sets the players account to be in 'Add' mode, so it is ready to accept a new cdkey.
2. Assigns a command to the module/server, to wait 300 seconds, and then remove the add mode, but only if the add mode is still enabled - this way, it wont touch/influence database entries that have already completed the 'adding of a new cdkey'

Note - I wasnt sure if it was '' empty, or 'Set' for the default value.

But if you wanted a delayed system, you still need to assign the command to the module/server, and give a delay command statement to get the delay.

[4BOLTMAIN]

I want to prevent the flag from being permanent for obvious reasons... I just didnt understand that line of code cause I dont understand how  TimeDelayedRemove(sPlayer) works.

Modifié par 4BOLTMAIN, 05 juillet 2012 - 02:07 .

[4BOLTMAIN]

I have implemented this code into my server and it works as it should but the database doesnt store the values when the server resets. I am running NWNX2 and am using the sql version.

What I am overlooking?

EDIT____

I use a hb script to reset the server every 8 hours.

Modifié par 4BOLTMAIN, 08 juillet 2012 - 11:41 .

[HUNTER_of_Wisdom]

Thanks 4BOLTMAIN and Baaleos...
But,
Please, I am not able to implement this solution in my SERVER.

Here in Brazil, some have opted to put an SERVERS SRIPT SET, which does the following, by filing a CHAR, it is requested that the PLAYER generate a password for it (PASSWORD FOR NUMERICAL six to eight digits through the CHAT), all time the PLAYER comes with that CHAR he must enter the password, or your CHAR is paralyzed and inert.

Some of you know this system and could help me?

Again, thank you.

[Thayan]

Query related to this:
Has anyone developed a method to enforce case sensitivity upon login? The reason I ask is that without Master Server authentication, I can login as either 'Thayan' or 'thayan' or 'ThAyAn', and so on. This in turn causes a variety of problems with functions like GetLocalString, GetCampaignString, etc. I'd kind of prefer *not* to rewrite all our scripts that rely on case sensitivity by enforcing case sensitivity to match whatever was used the first time a player logged in by expanding on this script (or something like it) to check for that.

[Lightfoot8]

Why not just add something like this to you CD check script. 

   object  oPC = GetEnteringObject();
   string AccName = GetPCPlayerName(oPC);
   string AccNameRefLable  = GetStringLowerCase(AccName);

   string AccNameRef = GetCampaignString("DBName",AccNameRefLable);

   if  ( AccNameRef == "") SetCampaignString("DBName",AccNameRefLable,AccName );
   else if (AccNameRef != AccName)BootPC(oPC);

[Thayan]

That would certainly work for new players. But my problem is primarily for returning players we already have stored in the DB. If they login with different case names, much of their persistent information is 'gone' since GetLocalString and GetCampaignString are case sensitive and when we use their PlayerName+PCName combo it won't retrieve any information for them then.

So for returning players, unless their player name was already lowercase this script would boot them until they logged in with a lowercase name - at which point their persistency settings would then be incorrect. I was thinking the only way to truly check case sensitivity would be some type of iteration through each letter of the name comparing it to that in the DB, but as that seems very cumbersome, I was hoping that someone else may have developed a better method.

I would really prefer not to lose the year or so of player names and associated CD Keys that have been stored in the database. But I suppose worst case is that the database could be deleted and we start over utilizing a solution like Lightfoot proposed - if there isn't any other alternative to check for case sensitivity for existing player names already stored in the DB.

[Failed.Bard]

If you have a way of parsing the DB directly, you could make a lowercase entry for each that stores the case sensative name in it. Then you would be able to compare it directly.

Obviously, for new entries this would just be a matter of adding one more stored variable into the DB, and one more small check when they logged back in.

For existing ones, I'm not sure of you can parse the table by entry position from in game. It might have to be handled externally if you decide to go this route.

[Lightfoot8]

The Script above does take into account returning players. It just assumes that they will Log-In with the correct form of there name the first time they return. It stores one entry into the DB Using the Lowercase Account name as the Lable to store the case sensitive from of there name.

Now if you had to you could prepopulate the DB with there Case sensitive accounts names. I will have to wait until I get home to look at the best way of doing that.

@Failed.Bard. It is pretty much what the code above does. IT just assumes that a Player will Log in with the proper case the first time. If nothing else it at least stops players from using different forms of there account name to exploit the server.

[Lightfoot8]

ok, I hope you are using windows.  I do not know if this works the same on linux or not.  Mainly because I do not know if the folder names in the server directory are all lower case or not.  In Windows the names of the folders in the server vault folder  are the player account names.  All you need to do is use the names from the folders to pre-populate your DB with the allowable case of the player name.   

To do that.   open a new test file and paste the following into it.   

echo>"popdb.nss" const string DB_NAME = "Enter DB name";
echo>>"popdb.nss" void SetAccCase(string sAccName);
echo>>"popdb.nss" void main()
echo>>"popdb.nss" {
For /D %%A in (*.*) do echo>>"popdb.nss"     SetAccCase("%%A");
echo>>"popdb.nss" }
echo>>"popdb.nss" void SetAccCase(string sAccName)
echo>>"popdb.nss" {
echo>>"popdb.nss"     SetCampaignString(DB_NAME,GetStringLowerCase(sAccName),sAccName);
echo>>"popdb.nss" }   

  

Save it as AnyFileName.bat  in your server vault.  
double-click the newly created .bat file to run it. 

once it is finished running you will have a file named popdb.nss in your server vault.  

Compile it and run it.  

Your choice of method for compiling and importing it into a mod for running. 

I myself would just use the compiler from the utils folder and place the .ncs into the override folder then Start any game as a DM and run it from the command line.   

AnyWay that will populate the DB so that the Previous code will work for old accounts.

EDIT:  Make sure you edit the value of DB_NAME to match your data base name.

Modifié par Lightfoot8, 06 septembre 2012 - 03:36 .