[vukhacson0809]

Do you know how to make people glow for all alive players like in the death cam mode? That would help even more for anti-camp plugin.

Anyway, thanks for sharing !

[Chdata]

Here's a small thing I use.

PHP Code:

#define DOWHILE_ENTFOUND(%1,%2) %1 = -1; while ((%1 = FindEntityByClassname2(%1, %2)) != -1) 


Example:

PHP Code:

    new ent;

    DOWHILE_ENTFOUND(ent, "func_breakable")
    {
        decl String:tName[32];
        GetEntPropString(ent, Prop_Data, "m_iName", tName, sizeof(tName));
        if (StrEqual(tName, "medic_car_break", false))
        {
            SetVariantInt(20000);
            AcceptEntityInput(ent, "SetHealth");
        }
        else if (GetEntProp(ent, Prop_Data, "m_iHammerID") == 3513)
        {
            AcceptEntityInput(ent, "Break");
        }
    }

    DOWHILE_ENTFOUND(ent, "item_ammopack_small")
    {
        SetEntProp(ent, Prop_Send, "m_iTeamNum", Enabled?OtherTeam:0, 4);
    } 


[11530]

Originally Posted by Chdata Here's a small thing I use. PHP Code: #define DOWHILE_ENTFOUND(%1,%2) %1 = -1; while ((%1 = FindEntityByClassname2(%1, %2)) != -1)

Can we stop this habit please?

[Chdata]

Not without any explanation of why not.

[11530]

Originally Posted by Chdata Not without any explanation of why not.

Since the macro is making a direct substitution, you are prone to making errors which would be avoidable had you used a standard function, or otherwise, to do the job. This could also lead to unexpected results. Take, for example, the following which I copied from an article on secure coding.

#define unsafe(i) ( (i) >= 0 ? (i) : -(i) )

Looks benign enough until you realise that calling new ans = unsafe(x++); will increment x twice, instead of once as intended. Similarly, creating a macro with an if-statement or one with multiple lines/blocks might yield syntax issues - especially with your curly brackets intentionally left out of the macro. This is forgetting the fact that there is no type-checking done in a macro and will be expanded regardless of whether or not it's syntactically correct.

Your answer may be that you'll just be super careful and won't do these things but it's better to prevent these errors completely through prudent programming than attempt to avoid them with each use.

[Chdata]

Well, I use it in the same exact way every time, so as you said, I guess that's the same as saying 'I'll be super careful'.

[hleV]

There's something weird about Math_Min() and Math_Max() functions.

PHP Code:

/**
 * Sets the given value to min
 * if the value is smaller than the given.
 * 
 * @param value            Value
 * @param min            Min Value used as lower border
 * @return                Correct value not lower than min
 */
stock any:Math_Min(any:value, any:min)
{
    if (value < min) {
        value = min;
    }
    
    return value;
}

/**
 * Sets the given value to max
 * if the value is greater than the given.
 * 
 * @param value            Value
 * @param max            Max Value used as upper border
 * @return                Correct value not upper than max
 */
stock any:Math_Max(any:value, any:max)
{    
    if (value > max) {
        value = max;
    }
    
    return value;
} 


They don't return the min/max value of the two parameters provided, but rather expects the 1st parameter to be the value and the 2nd the lower/upper border. So if I have an x and an y and want to get the min/max value of them, Math_Min()/Math_Max() may return the wrong value (for instance, Math_Min(16000, 5000) will return 16000).

It should work like min()/max() functions in AMXX (or hell, in C++ even), which compare the two provided parameters and return the lower/upper value.

[Powerlord]

It's... not like min or max are difficult functions to write...

PHP Code:

new min = a < b ? a : b;
new max = a > b ? a : b; 


[berni]

Originally Posted by hleV There's something weird about Math_Min() and Math_Max() functions. PHP Code: /**  * Sets the given value to min  * if the value is smaller than the given.  *   * @param value            Value  * @param min            Min Value used as lower border  * @return                Correct value not lower than min  */ stock any:Math_Min(any:value, any:min) {     if (value < min) {         value = min;     }          return value; } /**  * Sets the given value to max  * if the value is greater than the given.  *   * @param value            Value  * @param max            Max Value used as upper border  * @return                Correct value not upper than max  */ stock any:Math_Max(any:value, any:max) {         if (value > max) {         value = max;     }          return value; }  They don't return the min/max value of the two parameters provided, but rather expects the 1st parameter to be the value and the 2nd the lower/upper border. So if I have an x and an y and want to get the min/max value of them, Math_Min()/Math_Max() may return the wrong value (for instance, Math_Min(16000, 5000) will return 16000). It should work like min()/max() functions in AMXX (or hell, in C++ even), which compare the two provided parameters and return the lower/upper value.

The functions are supposed to clamp the value and not return the lowest or highest.
The function names and documentation might be a bit confusing tho.

[friagram]

Just use ternary operators. That's what they are for.
a > b ? a : b

Well shit, powerlord posted the exact same thing.
Virtually all of the stuff in smlib is like this.
If you can't write the functions yourself, you probably should not be using them.
This goes for almost anything. They're there for convenience, but you should always read the include so you know it does exactly what you need. More often, you should read it's source, so you know how it works and if there are any situations i which it won't work right (undefined, unpredictable, or erroneous results).