players in room

[Snakeandy7]

Lol, finally he got it, still chance for you zero.
Anywho you could of done
if (playerenters || timeout){
}
lol, Anywho

[marcoR]

I knew how to make it work, I just didn't know how to do it propperly.

[Snakeandy7]

Originally posted by marcoR
I knew how to make it work, I just didn't know how to do it propperly.

You got there in the end

[Riot-Starter]

Just a side note:
playerscount includes NPCs when used clientside.

[Python523]

Originally posted by Riot-Starter
Just a side note:
playerscount includes NPCs when used clientside.

only showcharacter ones I believe, unless that was changed

[Riot-Starter]

Originally posted by Python523


only showcharacter ones I believe, unless that was changed

I think it is only showcharacters, I just remember problems with gralats causing spar room doors to stay closed.
Although there is an easy fix to determine whether it’s an NPC or player.

[Tseng]

Originally posted by protagonist



It is neater. Read KSI-GS standards thread.

Neater? Subjective. I find it neater to have a balance of lines and lengths. You find it neater to have one check per line. When they are related (as they are in this case), I find it unnecessary to split it up. Perhaps I should paste the first line of the first if check in the hpfunctions subroutine on graal2001, and ask if those shouldn't be split up.

One line of two related checks (an event and a condition) and splitting them up one to each line is the same code - so you can't really argue efficiency or optimization, but only a stylistic choice.

(Additionally, the standards thread does not mention putting an event and a condition on separate lines.

[marcoR]

I'm not a script head, so.. these rules would not be worth remembering, nor practicing.

[protagonist]

Originally posted by Tseng


Neater? Subjective. I find it neater to have a balance of lines and lengths. You find it neater to have one check per line. When they are related (as they are in this case), I find it unnecessary to split it up. Perhaps I should paste the first line of the first if check in the hpfunctions subroutine on graal2001, and ask if those shouldn't be split up.

One line of two related checks (an event and a condition) and splitting them up one to each line is the same code - so you can't really argue efficiency or optimization, but only a stylistic choice.

(Additionally, the standards thread does not mention putting an event and a condition on separate lines.

I also find it more efficient to have one check per line in MOST cases. It adds flexibility to a script. You can add in additional commands and statements very easily as compared to having multiple checks in your if statement.

[osrs]

Originally posted by Riot-Starter

I think it is only showcharacters, I just remember problems with gralats causing spar room doors to stay closed.
Although there is an easy fix to determine whether it’s an NPC or player.

Yep,also these new gralats are showcharacters =p

[Dach]

Originally posted by protagonist


I also find it more efficient to have one check per line in MOST cases

that's not more efficient, it's just your style. dang, that word is getting thrown around to often nowadays

[KainDaMan]

you can solve the problem of it counting npc characters by doing a for statement that includes the playerscount and a check if players[i].id>=0; as -1 = npc character. then if it's true add to a variable. this, however, would require resetting the string every time the event is called. I would go right out and post the script, but I fear it is against the rules of the NPC Scripting Forums

[Tseng]

Originally posted by protagonist


I also find it more efficient to have one check per line in MOST cases. It adds flexibility to a script. You can add in additional commands and statements very easily as compared to having multiple checks in your if statement.

Um, the first 'check' is when the action is called, so that happens regardless. The second 'check', be it on another line or in the same if ( ) statement, will be executed regardless; efficiency is not something you can debate with this.

Very easily? I don't go around putting '&& otherflag==true' for every check I add, but it is arguably easier to type two ampersands than 'if ( ) { }'. That does not make it better, but you are incorrect in saying it's easier.

[Kaimetsu]

It depends on Graal's inner workings. If you're using a literal compiler/interpreter that doesn't make a distinction between & and && then it's more efficient to split up the checks - if you combine them then it'll happily evaluate the whole condition without stopping to check if it's already invalidated itself.

[Tseng]

Originally posted by Kaimetsu
It depends on Graal's inner workings. If you're using a literal compiler/interpreter that doesn't make a distinction between & and && then it's more efficient to split up the checks - if you combine them then it'll happily evaluate the whole condition without stopping to check if it's already invalidated itself.

Well, I think I said it before, but I am only talking about an:

if (event && flag=true) {

compared to:

if (event) {
if (flag==true) {

type situation - if the event occurs, how could it invalidate itself in either?

Or, are you talking about if the event doesn't occur at all? That's the only way I can think that it could be invalidated...