Author Topic: Finding all clients in a server  (Read 1307 times)

I need to know how to get all the clients in a server, and do something to them. In essence, it works like the messageAll function.

%cnt=clientgroup.getcount();
for(%i=0;%i<%cnt;%i++)
{
    %cl=clientgroup.getobject(%i);
    %cl.dostuff();
}

Instead of using messy stuff like above, use this:

Code: [Select]
%c = clientGroup.getCount();
for(%a = 0; %a < %c; %a++)
{
    %cl = clientGroup.getObject(%i);
    %cl.dostuff();
}

Couldn't you just do

Code: [Select]
for(%i = 0; %i < clientGroup.getCount(); %i++)
{
    %c = clientGroup.getObject(%i);
    //blah blah blah
}

?

Couldn't you just do

Code: [Select]
for(%i = 0; %i < clientGroup.getCount(); %i++)
{
    %c = clientGroup.getObject(%i);
    //blah blah blah
}
The way we did it is the properly efficient way, but same thing

Couldn't you just do

Code: [Select]
for(%i = 0; %i < clientGroup.getCount(); %i++)
{
     %c = clientGroup.getObject(%i);
     //blah blah blah
}

?
uses more cpu cycles to call the function once for every client. Torque is stuff, and efficiency is everything.



Kalphiter and blocki's are identical, but kalphiters looks better. Use his.


That's less efficient, because it calls getCount every time it goes to the next client instead of just once

The way we did it is the properly efficient way
uses more cpu cycles to call the function once for every client.
That's less efficient, because it calls getCount every time it goes to the next client instead of just once

okay

Theory: define an array of clients for even more efficiency instead of calling ClientGroup.getObject(); every time


Thoughts?

Theory: define an array of clients for even more efficiency instead of calling ClientGroup.getObject(); every time


Thoughts?
Doubt it, you now have to keep that up to date (if someone (dis)connects your data will be outdated). And seriously, even with 99 players this kind of optimization doesn't really matter in this case unless you're doing it in an extremely tight loop.

Doubt it, you now have to keep that up to date (if someone (dis)connects your data will be outdated). And seriously, even with 99 players this kind of optimization doesn't really matter in this case unless you're doing it in an extremely tight loop.
Yeah, agreed, it's pointless. Assuming that Torque implements SimGroups as a linked list like they should, it won't bring much optimization to the table.

Yeah, agreed, it's pointless. Assuming that Torque implements SimGroups as a linked list like they should, it won't bring much optimization to the table.
I don't think having it in a linked list would give a very big benefit if the API is that of an array.

Code: [Select]
%c = clientGroup.getCount();
for(%a = 0; %a < %c; %a++)
{
    %cl = clientGroup.getObject(%i);
    %cl.dostuff();
}

%c = clientGroup.getCount();
for(%a = 0; %a < %c; %a++)
{
    %cl = clientGroup.getObject(%a);
    %cl.dostuff();
}

I don't think having it in a linked list would give a very big benefit if the API is that of an array.
How is having O(1) pushing and popping not important for a sim group?

How is having O(1) pushing and popping not important for a sim group?
That's great, sure, but I for this you're going to have fairly small sets which aren't changed a lot, but you're going to read it pretty much all the time. I'd say O(1) seeking is much more important for this (especially as you don't have access to the nodes themselves, which would reduce that problem a lot).