User Accounts.

METALGod32
11 May 2005, 12:13
I Have a interesting Question.

Why does Questnet have user id's rather then account ID's?
a user ID Changes, a account wouldn't...so if userid 1 logs out and then sombody else logs in, they not only take userid 1, but they also take any saved information that the last userid 1 triggered.

so my question is, how would information be saved to that persons char?.....it's a dilema i've been trying to comprehend the last few hours, if anyone could answer that, that'd be great.



Thanks.

Alex
11 May 2005, 17:50
There needs to be user ID's as well as logins aren't compulsory, and even if logins are used then QuestNet Server needs to open sockets to receive connections, and these are what the user ID numbers correspond to.

Gary Brown
11 May 2005, 20:51
The way i'm doing it is to create an object with the same name as the user when they log in. All their information is save to that object, and you can just refrence the object for saved stats, skill, etc.

Gary

METALGod32
11 May 2005, 23:34
Yeah you could create a Object in the name of the user but the game wont do that by it'self, you'd have to do that manually....then there may still be issues, i think that each account should of had a perm id rather then a temp id, There are already user accounts...there should be user account id's...There is no real way for the game to save that accounts info..., it happens with objects to...i tested this.

I Logged on with two chars, i logged off userid 1, i logged on a 3rd char...he recieved userid 1, he also had the object that the last userid 1 had.

so in reallity you can't really make a normal multiplayer game, other thing that strikes me is that the server saves info, but that defeats the purpose because you dont want it to save to a temp id.

i'm trying to figure out ways around this, if i think of one i'll make a post of it.

Gary Brown
12 May 2005, 01:02
Well, what I'm doin' is making a character with the same name as the player. All of the properties are stored on the object with the same name, so, for instance, when I do a score command, you're just referencing the object rather than the player, but the name is the same. You're never using the actual userid to store info. Just to refer to it in context of the user name. Did that make sense?

Gary Brown
12 May 2005, 01:04
And for accounts, you could make a room that's named for the player and store your account info on objects that stay in the room. Or on properties of that room.

METALGod32
12 May 2005, 01:39
I Suppose that is doable, it sounds like it can be done...that means i needa write more vars...LOL, back to work i go.... :)

METALGod32
12 May 2005, 03:13
after further research, i found that the game still cannot save to that player, regardless...it wouldn't matter if you made a object named after the player...the game wouldn't know...lets say...i made a char named: METALGod, then named a object METALGod...i play for awhile...all information is passed to the object and saved...then i log out...once i log back in the Game wouldn't have saved the link between the player and object...there is noway that the game would know that the player METALGod refers to the Object METALGod.

and you cannot control a object"not that i know of"...so you cannot simple pretend your the object...and you cannot make a player invisible"to add to the illusion of the object being the player".

i even thought of making custom var's for each player, that to is impossible because there is still no commands available that points to the players name or account.

so i dont think you can assign var's to a specific player, i think you can but you have to hard code it out of QDK.

I'ma research this topic some more., Stay tuned.

P.S i'm prob going to convert my game back to Single player, until a new version of Questnet supports more commands directed at accounts.

francisstokes
12 May 2005, 08:56
Ummmm, METALgod, the player is actualy an object when you play the game.

But all you need to do is put all your information onto a var like #playername#.

Simple as that.

METALGod32
12 May 2005, 10:08
no, it's different in Multiplayer games, because the game doesn't save information on chars....it only saves via ID's..so if you were to make a player object, you wouldn't be saving anything about the char...because you still needa reference back to the player, expecially if your game involves stats/ranks etc"like mines does"...how can you tie a Object to a player if it's id changes?.

it's impossible...i've checked it out over n over..., i even thought of crazy stuff...LOL.

so even though your Player is a object, your players are unique objects with Temp ID's, unlike other objects.

if you think you can pull it off, then be my guess...I'll worship you if you can...i promise...LOL.

Now if there were no stats, ranks etc then MAYBE it can be done, but it'll still take trickery.

Lets say i did do exactly what you guys said can be done...ok?, i make a object named after my char and countless of other var's named after my char, everything will go fine untill you log off then log back on, because then you may end up on a new ID"if there are several people on", how would that player Access his stats?

if anyone can tell me how can a player whom was ID 1, access his so called saved stats as he is now ID 2, i'd be happy.

francisstokes
12 May 2005, 13:07
wouldnt it be different if everybody has a login?

Say i sign in as Frank.I am then an object called Frank.If you asign all your vars top the properties of Frank, then it would work, right?

Gary Brown
12 May 2005, 13:12
No, dude. When you log in you make an object named Metalgod32. You give that object all the properties that you want the player to have and when you save the game as a whole, that object is saved as part of the game itself. So all you have to do is make, (for instance) #tempname# = Metalgod32. Then when you need to refer to Metalgod32's properties, you use $objectproperty(#tempname#;health)$. You do that in each procedure that your players will call when they need to refer to specific properties.

Did that make sense?

Gary

METALGod32
12 May 2005, 14:06
That clears it up a bit, i'll try that routine to see what comes up.

But i'll need to make var's and a Object manually for every player though?


Thanks.

francisstokes
12 May 2005, 14:25
No you wont just use things like %userid% and #playername# to identify the vars.

METALGod32
12 May 2005, 14:39
well after i get some much needed zzzzzz's i'll give this a try, this should be fun :)

METALGod32
13 May 2005, 01:38
How would i refer to the properties of that object though?, i mean i know how but how would the game know who is refering to it?...not to mention the fact that items arent saved either....how would you save a item in the players inventory?...items only save via userid.

Gary Brown
13 May 2005, 21:12
You refer to it by, 1st thing in the procedure the player is calling setting a variable like:
#tempname# = $name(%userid%)

Then, if, for instance, you want to do a "score" command you'd print something like:

$objectproperty(#tempname#;health)$

That will check the health property on the object of the same name as the player calling the procedure. You're not using their userid at all. See?

And you would make all of your changes to the character's stats by refering to them the same way. The object will save as a regular object in the game.

Gary

Cryophile
13 May 2005, 21:45
Instead of two steps just do:
#$name(%userid%)$:health#

Just an example :)
#object:property# works the same as $objectproperty(object;property)$

Gary Brown
13 May 2005, 23:42
Cool. That's useful to know. :D

METALGod32
14 May 2005, 01:44
cool, Thanks for the Help guys , :)