[Request] a consistent, convenient and reliable way to iterate over all connected clients

[Martin-H2]

what we got:

for ( i = 1; i <= g_Engine.maxClients; i++ )
{
    @pPlayer = g_PlayerFuncs.FindPlayerByIndex( i );
    if ( pPlayer !is null && pPlayer.IsConnected() ) 
    {
        // do things
    }
}

suggestion:

foreach ( Player p : Server.GetPlayers() ) {
    // do things
}

and maybe:

foreach ( Player p : Server.GetLivingPlayers() ) {
    // do things
}

** Server.GetPlayers() being an immutable list, which is never generated or copied, when this call occurs

[Martin-H2]

ah, i forgot to post the problems i see:

• the API-user needs to care about indices, that's not his concern & you should not work with magic numbers
• the API-user needs to know the lower, allowed bound: 1
• the API-user needs to know the upper, allowed bound: g_Engine.maxClients
• the API-user needs to find the hidden, magic constant g_Engine.maxClients in a helper class, which is not sufficiently documented
• the API-user needs to find and use the g_PlayerFuncs.FindPlayerByIndex( i ) function, which is which is not sufficiently documented (and causing problems which are fixed now ?)
• the API-user needs to introduce another local variable @pPlayer
• the API-user should not be required to perform sanity checks ( pPlayer !is null && pPlayer.IsConnected() )
• the iteration over the full range of maxclients, producing null-pointers for not used server slots is not very reasonable

[fnky]

This is more of a language feature, rather than API feature.

Seen as AngelScript lacks foreach as well as the notion of iterables and enumerables, I don't expect the SC team to add this as part of the SC API. Even if they did, they'd have to provide documentation that points out the difference between SC AngelScript and the original AngelScript.

[Martin-H2]

Yes that may be right.

Lets see what the JavaScript (ES6? ES7?) introduction brings us ? I always was an JS opponent, but now i'd really REALLY prefer it over AngelScript. AS is very limited and inconvenient. The biggest disappointment until now, was the lack of lambda-function support. (lambda-functions, which actually can see objects from the same scope)

[fnky]

AFAIK JS would only be introduced when they implemented the HTML5 engine for displaying HUD/GUI on screen and not to replace server-side/client-side scripts for what AS is used for now.

I agree that AngelScript is very limited and would have loved something else in place which had better documentation and acknowledgement from a wider community, but I don't believe that is going to change anytime soon.

[baso88]

The way it works now closely matches HL SDK. The existing AS API was designed and implemented with that idea in mind... to make life easier to people familiar with HL code.

This will likely stay as it is at least until we rework/replace the API somewhere in the future.