[naris]

Originally Posted by berni Did you actually test it or do you just think so ? I just tried it out for you: Compile time with includes: 1.00 seconds Compile time without: 1.00 seconds

Did you try modifying and including only 1 of the includes, such as #include <smlib/world> or are you continually including EVERYTHING by using #include <smlib>?

Did you try this using a large system where multiple source files need 1 or 2 functions from 1 or 2 files instead of everything? I do not have time to test this at the moment, especially since this is Month End, but I will get back to you when I do.

Originally Posted by berni Also wrong, Functions of <sourcemod> and <sdktools> (fake included in smlib.inc) are used in almost every include file. Again, they aren't really included for the compiler as it will cancel before in smlib.inc.

So, #include the files required for those functions (<sourcemod> & <sdktools> and whichever <smlib/*> files that might be required, as you almost did in smlibs/clients.inc (instead of the generic <smlib> include), it's not that difficult.

Originally Posted by berni SourcePawn just isn't C++, so we have to take what we get.

While it's true that SourcePawn isn't C++, the basic concepts are the same and are still applicable.

[FaTony]

The preprocessor include system is almost the same in both languages.

[berni]

Originally Posted by naris Did you try modifying and including only 1 of the includes, such as #include <smlib/world> or are you continually including EVERYTHING by using #include <smlib>?

You should have read the latest update changes, this doesn't need to be discussed anymore.

Originally Posted by berni Redesigned the smlib includes to allow including of single smlib includes and save some milli seconds.

And no, I thought he is talking about just removing #smlib out of every include file, and still use #include <smlib> in the plugin.

[naris]

Doh!

Sorry about that, Indeed I should of read the last update changes

[berni]

By the way, the sourcemod compiler automatically includes <sourcemod> (with all its 60 subincludes), even if you don't have it specified in your plugin.
If you want to complain, I would start there

[naris]

This function needs to be fixed:

PHP Code:

/**
 * Returns whether the entity has specific Spawnflags.
 *
 * @param entity            Entity index.
 * @param flags                Flags value.
 * @return                    True if the entity has the spawnflags set, false otherwise.
 */
stock bool:Entity_HasSpawnFlags(entity, flags)
{    
    return Entity_GetSpawnFlags & flags;
} 


[naris]

Originally Posted by berni By the way, the sourcemod compiler automatically includes <sourcemod> (with all its 60 subincludes), even if you don't have it specified in your plugin. If you want to complain, I would start there

Yeah, that's true -- but those are mostly native declarations and not so many stocks.

Also, you usually need to use parts of most of the sourcemod includes in any given plugin while many of the smlib includes are more stand-alone without really needing the others.

[naris]

The Entity_Flags look suspect, are EFL_KEEP_ON_RECREATE_ENTITIES and EFL_HAS_PLAYER_CHILD both supposed to be bit 4?

PHP Code:

enum Entity_Flags
{
    EFL_KILLME =                            (1<<0),    // This entity is marked for death -- This allows the game to actually delete ents at a safe time
    EFL_DORMANT    =                            (1<<1),    // Entity is dormant, no updates to client
    EFL_NOCLIP_ACTIVE =                        (1<<2),    // Lets us know when the noclip command is active.
    EFL_SETTING_UP_BONES =                    (1<<3),    // Set while a model is setting up its bones.
    EFL_KEEP_ON_RECREATE_ENTITIES =         (1<<4), // This is a special entity that should not be deleted when we restart entities only

    EFL_HAS_PLAYER_CHILD=                    (1<<4),    // One of the child entities is a player.

    EFL_DIRTY_SHADOWUPDATE =                (1<<5),    // Client only- need shadow manager to update the shadow... 


Also, you might want to define it as

PHP Code:

enum Entity_Flags (<<= 1)
{
} 


instead of specifying the value for each bit.

[berni]

Originally Posted by naris This function needs to be fixed: PHP Code: stock bool:Entity_HasSpawnFlags(entity, flags)

Originally Posted by naris Also, you usually need to use parts of most of the sourcemod includes in any given plugin while many of the smlib includes are more stand-alone without really needing the others.

Like you say, only parts, I use ~20% of all sm includes in plugins.

Originally Posted by naris The Entity_Flags look suspect, are EFL_KEEP_ON_RECREATE_ENTITIES and EFL_HAS_PLAYER_CHILD both supposed to be bit 4? Also, you might want to define it as PHP Code: enum Entity_Flags (<<= 1) { }  instead of specifying the value for each bit.

It looks suspect to me too, I also wondered back then, but we copied it straight from Valve's hl2sdk and it's used there widely,
so I'm quite sure it's correct
I think it's ok like it is now.

[zeroibis]

I just wanted to note that using:
stock Client_GiveWeapon(client, const String:className[], bool:switchTo=true);

will override any restrictions that other mods may have on the weapon.

For example you can use this command to give a zombie weapons in a ZR server. I do not know if this was intended or not. Note however that the normal GivePlayerItem command does not allow zombies to get weapons.