For loops...
paul_one
31 Jul 2005, 18:47Right, so I'm using a variable 'index' as this for <> is going through a loop...
BUT this index is global by nature (for <index; 1; 10>) so if I have 2 people at the same time then you'll get clashes. So what I want is to be able to make this variable for the singular user.
BUT in my code I use both "%index%" and "[index]".
So I can't have %index[userid]% ([index[userid]] would confuse Quest)
And I can't have index.%userid% (%index.%userid%% would confuse Quest).
Any answers?
I could re-write the loop as a "while" and have it as a property, but surely there must be a way to have variables in the scope of the user.
Personally I'd like a #global:var# #uservar# #var[userid]# setup. where globals would be using the : (or userid of 0), the scope of the user would just use the normal #var# (so set string <dddd[userid]; > becomes set string <dddd; >) and to get someone elses var you would use #var[userid]#. Would just define everything properly.
BUT this index is global by nature (for <index; 1; 10>) so if I have 2 people at the same time then you'll get clashes. So what I want is to be able to make this variable for the singular user.
BUT in my code I use both "%index%" and "[index]".
So I can't have %index[userid]% ([index[userid]] would confuse Quest)
And I can't have index.%userid% (%index.%userid%% would confuse Quest).
Any answers?
I could re-write the loop as a "while" and have it as a property, but surely there must be a way to have variables in the scope of the user.
Personally I'd like a #global:var# #uservar# #var[userid]# setup. where globals would be using the : (or userid of 0), the scope of the user would just use the normal #var# (so set string <dddd[userid]; > becomes set string <dddd; >) and to get someone elses var you would use #var[userid]#. Would just define everything properly.
Arbutus
01 Aug 2005, 01:13Use a stats object with properties for the numbers.
OR
Use an indexed string variable (#variable[userid]#).
Neither very elegant for just a number variable but they may work for you.
OR
Use an indexed string variable (#variable[userid]#).
Neither very elegant for just a number variable but they may work for you.
Elexxorine
01 Aug 2005, 08:48had a thought, this'll be inconviant for the user BUT will stop clashes. (btw: thanks again tron). have a global 'isplayerlogging' variable/flag. when a user starts to log in (and use all the variables) turn it on. when a player wants to log in etc, check it. put a message saying that a user is already logging in, and have it wait 2 seconds before trying again. if loads of people try to log in at once then they'll be in like a waiting list.
more advanced waiting list: have an array 'waitinglist[queuenumber]' each queue number is their place in the 'waiting line', when theirs equals 1, let them log in, clear that queue space, move 2 to 1, 3 to 2, etc. a structured list. if you wish, specail or staff members can be checked to see if they're in the wiating list and when slot 1 frees up, they move there. you could use a 'for' or something and stop it when it finds the right one - like the current log in system.
more advanced waiting list: have an array 'waitinglist[queuenumber]' each queue number is their place in the 'waiting line', when theirs equals 1, let them log in, clear that queue space, move 2 to 1, 3 to 2, etc. a structured list. if you wish, specail or staff members can be checked to see if they're in the wiating list and when slot 1 frees up, they move there. you could use a 'for' or something and stop it when it finds the right one - like the current log in system.
paul_one
01 Aug 2005, 18:05Arbutus, please read a message fully before replying.
I explained why I can neither use an array'd index (index[userid]) or a normal variable (index.%userid%).
I did some extra fooling around, and found I can't use both either (having the index[userid] as the main, and having that set a variable named index.%userid%)... This is because Quest either crashes, or doesn't like:
#array[index.%userid%]#
Instead of replacing the %userid% it just treats it as a string, and asks for a variable named "index.%userid%".
I also tried the two methods to get at user properties:
$objectproperty()$ didn't work, it again treated the whole thing as a string and wanted a variable named "$objectproperty(...)$".
I then tried #array[(object):property]# and instead of acting sanely, Quest totally erased "array[" to leave me with "#(object):property]#"... Seems I can't win.
The loop is quite short, and I don't think it'll cause TOO much trouble if you have loads of people on at the same time (seeing as how all the other things are user-specific).
It should just annoy people, say one guy tries to log in, then another shortly after - the loop starts again, then another person = start again... so 5x this will get annoying if the loop takes more than a minute to do.
.... But frankly you need about 1000+ user accounts before it slows down enough.
So I'll just implement it that way.
I explained why I can neither use an array'd index (index[userid]) or a normal variable (index.%userid%).
I did some extra fooling around, and found I can't use both either (having the index[userid] as the main, and having that set a variable named index.%userid%)... This is because Quest either crashes, or doesn't like:
#array[index.%userid%]#
Instead of replacing the %userid% it just treats it as a string, and asks for a variable named "index.%userid%".
I also tried the two methods to get at user properties:
$objectproperty()$ didn't work, it again treated the whole thing as a string and wanted a variable named "$objectproperty(...)$".
I then tried #array[(object):property]# and instead of acting sanely, Quest totally erased "array[" to leave me with "#(object):property]#"... Seems I can't win.
The loop is quite short, and I don't think it'll cause TOO much trouble if you have loads of people on at the same time (seeing as how all the other things are user-specific).
It should just annoy people, say one guy tries to log in, then another shortly after - the loop starts again, then another person = start again... so 5x this will get annoying if the loop takes more than a minute to do.
.... But frankly you need about 1000+ user accounts before it slows down enough.
So I'll just implement it that way.
Elexxorine
01 Aug 2005, 18:14thanls again tron. go on msn!
Arbutus
01 Aug 2005, 21:28I don't know why you're having trouble with this. Both methods work easily for me.
paul_one
01 Aug 2005, 22:22set string <array[1]; woop>
set string <array[2]; poow>
for <index[userid]; 1; 10> {
msg <#array[index[userid]]#>
}
Equal's error 19 or 9 or such.
set string <array[1]; woop>
set string <array[2]; poow>
for <index[userid]; 1; 10> {
set numeric <index.%userid%; %index[userid]%>
msg <#array[index.%userid%]#>
}
Equals a result of nothing printed... Look in the quest log and you'll find "no variable index.%userid% found" or something similar.
How do either of these methods work?
Arbutus
02 Aug 2005, 18:28Ah, I see what you were doing. The FOR loop creates its own counter variable. (If a variable of that name is already defined, the FOR loop will create a duplicate variable.) If you want to use your player-specific variable that already exists, I would use a REPEAT loop like so:
You can also put in some code (to test the array length) so you don't have an underrun error or if you want the code to be more dynamic.
' define your variables somewhere
set string <array[1]; woop>
set string <array[2]; poow>
set numeric <index[userid];1>
' your loop
repeat until ( %index[userid]% = 3 ) {
set numeric <i;%index[userid]%>
msg <#array[i]#>
inc <index[userid]>
}
You can also put in some code (to test the array length) so you don't have an underrun error or if you want the code to be more dynamic.
paul_one
03 Aug 2005, 09:34But then i isn't user-specific... Have more than 2 people going through the loop - or similar loops, at the same time - and 'i' get's changed.
The way I 'worked around' it was to not care about 'index'... It wasn't important, and no REALLY bad errors should occur if multiple people go through the loop because everything else is user-specific.
The way I 'worked around' it was to not care about 'index'... It wasn't important, and no REALLY bad errors should occur if multiple people go through the loop because everything else is user-specific.
Arbutus
03 Aug 2005, 17:29The procedure doesn't actually run more than once at a time. Try it and see if you get an error.
paul_one
03 Aug 2005, 18:12You are quite correct!
I created a test array of 20000 (set string <array[20000]; >). Then looped through it printing off a couple of numbers when it was right (geez, that part went wrong but it wasn't too bad - gave me an idea of where it was in the loop).
Anyway, I had Alice going through one loop, tried to start the loop with Bob and it wouldn't go! It waited for Alice's to stop before Bob's activated!
Then I tried Alice, Bob and Clive all at the same time - nope... Not playing ball.
I wonder if that means two of ANYTHING at the same time - or just the same command :S ..
Gonna try it with two loops I think.
I created a test array of 20000 (set string <array[20000]; >). Then looped through it printing off a couple of numbers when it was right (geez, that part went wrong but it wasn't too bad - gave me an idea of where it was in the loop).
Anyway, I had Alice going through one loop, tried to start the loop with Bob and it wouldn't go! It waited for Alice's to stop before Bob's activated!
Then I tried Alice, Bob and Clive all at the same time - nope... Not playing ball.
I wonder if that means two of ANYTHING at the same time - or just the same command :S ..
Gonna try it with two loops I think.