Issue Information
-
#005780
-
0 - None Assigned
-
Fixed
Issue Confirmations
-
Yes (0)No (0)
0
Well I do think it is kind of funny that the description's content is similar to my one, without providing the functionality that is stated within.
post:9231
Just in case I got it wrong, the documentation says:
If no Party ID is given the party of the currently attached player will be used.
But the corresponding part in script.c says that if the party ID is not given, the script shall return 0.
So either way please change either the documentation or the line in script.c
Also I think the check within the for loop with min and max is a little bit itchy since the function breaks the loop through a return 0 instead of only not increasing c.
Anyways I think it's kind of unneeded that the party ID is a must have parameter since in 99% of the cases the player that will call the check is the party leader and so we could use his party ID anyways. So I would suggest to put the party ID as the last parameter and to default to the attached players party ID.
Here's a patch to fix the functionality as stated in the doc files.
oops..sorry didn't read thoroughly what Masao gave to me...
for my algorithm its better to break the loop if the condition is already satisfy..because it is non sense to continue if its already proved...Also I think the check within the for loop with min and max is a little bit itchy since the function breaks the loop through a return 0 instead of only not increasing c.
as Masao suggest to indicate the id...for me its better to be generic because and as you said 99% is pleased so how about the 1%...Anyways I think it's kind of unneeded that the party ID is a must have parameter since in 99% of the cases the player that will call the check is the party leader and so we could use his party ID anyways. So I would suggest to put the party ID as the last parameter and to default to the attached players party ID.
I don't really get what kind of algorithm is behind checking a player and the first player that doesn't fit the requirements, terminates the loop, but maybe you could explain a little bit more in detail what you did there or what you tried to do.for my algorithm its better to break the loop if the condition is already satisfy..because it is non sense to continue if its already proved...
Yeah but I would say you should keep in mind for which sake you implemented this behavior and that is only for the reason to check the instance leaders party for a certain criteria and that only happens if the party leader is allready attached to the npc that runs the check. But that one isn't really the problem here, the real problem is that the documentation is wrong. The thing with the party ID is just a matter of design.as Masao suggest to indicate the id...for me its better to be generic because and as you said 99% is pleased so how about the 1%...
hmmm...here I will give a real time situation..I don't really get what kind of algorithm is behind checking a player and the first player that doesn't fit the requirements, terminates the loop, but maybe you could explain a little bit more in detail what you did there or what you tried to do.
Example: if your mother ask you to check your brothers that if one of them is not yet done changing clothes then came back to her to report..and your brothers have their own room...
so if you will check them one by one but your mother told you that if 'one of them' so is that kinda tedious??
loop(bothers){
if(not yet done changing clothes)
report to mom. //terminate loop
}
1 loop done and more faster than checking them one by one(if only if condition satisfied)..
so less resources used...^^
Well i'll move this to documentation bug report section since this isn't really a source issue cause i wanted it that way.
I'll remove the part then where it states that "If no Party ID is given the party of the currently attached player will be used." within my next commit.
Except malufetts decides to change the script command so that also the Party ID is an optional parameter, so it would probably end up looking like this in the script:
if(!instance_check_party()) {
bla bla;
else{
blabla;
}
close;
i guess.
hmmm...here I will give a real time situation..Example: if your mother ask you to check your brothers that if one of them is not yet done changing clothes then came back to her to report..and your brothers have their own room...so if you will check them one by one but your mother told you that if 'one of them' so is that kinda tedious??loop(bothers){ if(not yet done changing clothes) report to mom. //terminate loop}1 loop done and more faster than checking them one by one(if only if condition satisfied)..so less resources used...^^I don't really get what kind of algorithm is behind checking a player and the first player that doesn't fit the requirements, terminates the loop, but maybe you could explain a little bit more in detail what you did there or what you tried to do.
Ok seems like I got the idea wrong there. When I played the Nidhoggur Instance on fRO the check was only whether there are enough players and if there are enough with the corresponding level. I also had my slave character in the party that was far below the required level and I could simply enter the dungeon. Sorry my bad then, thanks for your explanation.
Still leaves the wrong documentation though.
well..I think I will just leave the decision to the scripters since they will be the one who will utilize it for better performance...if there is something to change just bug me..
Fixed in [rev=16136] .
