code to get the illumination at any point on the map

[KWo]

OK. The podbot_mm_i386.so file loads on my linux virtual PC correctly and bots are using flashlights correctly now (so it means they know where is a dark area and Your code works also on linux)!

Now back to the second problem - about running Your function on other bots (CZERO bots and metamod bots). If the function pfnRunPlayerMove (called i.e. for other bots) function resets their pEdict->v.light_level, I believe - if we are setting their v.light_level in StartFrame function, everything should work. Except one thing. There are some plugins (written in PAWN - C similar language) they are using fake bots to prevent i.e. the round to be ended (if all players and "normal" bots are dead). I'm not sure if AMXMOD X creating such type of bots is adding the flag FAKECLIENT. I'm also not sure if calling that function for such type fake bots doesn't do any side-effects. Another thing - I'm not sure if CZERO bots have the FAKECLIENT flag set. I need to do more tests then.

[Immortal_BLG]

I'm sorry, I seem to have deceived you, the function "RunPlayerMove" does not change the value of the variable "entvars_t::light_level", moreover, this value seems to be that NEVER changes for the bot!
I set some nonzero value and killed a bot, did round restart - value didn't change. I even kick a bot, and then connect new bot, which occupied entity of kicked bot, and so, the new bot used value of this variable, from the kicked bot!!!

So that method with setting this value in a function "StartFrame" in the loop for all clients, which have flag FL_FAKECLIENT - probably the most correct....

I would also like to recommend to reset the value of this variable when creating a new bot, how you do it, for example for the variable entvars_t::frags.

Originally Posted by KWo

I'm not sure if CZERO bots have the FAKECLIENT flag set. I need to do more tests then.

no doubt on account of this - CSBot sets this flag on each spawn....

[KWo]

Originally Posted by Immortal_BLG

I set some nonzero value and killed a bot, did round restart - value didn't change. I even kick a bot, and then connect new bot, which occupied entity of kicked bot, and so, the new bot used value of this variable, from the kicked bot!!!

Well - I'm not surprised by this at all. Long time ago I had to be in contact with AMX /AMX X developers, because users have had troubles with admin priviliges. After kicking the bot and enetering the user-admin - he couldn't get his access rights because... these mods where thinking he is still a bot! I have to re-search what was the remedy for this. I'm not sure if they haven't had even to do something with FAKECLIENT flag, then we probably had to add it each frame. It will take me some time to check that.

Anyway - that (what You wrote) means I have to reset v.light_level also at Client_Disconnect, but I'm not sure if that function gets called in my dll for other mm bots (metamod is blocking some messages coming from other its plugins - not sure if this one is blocked or not). I'll try to test it somehow with podbot mm and yapb (2.30). Did You check if v.light_level for the real player (human) is cleared (0) after the player gets killed (is dead)? I feel I have to add more code in some places I didn't think of them yet before... But the work is still in progress - so probably during few days the new build of podbot mm will be released.

[Immortal_BLG]

Originally Posted by KWo

Did You check if v.light_level for the real player (human) is cleared (0) after the player gets killed (is dead)?

Checked already, and the answer is NO.
When the real client dies and he is not in "First Person" spectating mode - the value of the variable "light_level" does not changes, otherwise, he "takes" the value of player, which he sees.

By the way I'm not exactly sure but I think in general the engine and game DLL (CS) never uses the variable "light_level"....

[KWo]

Originally Posted by Immortal_BLG

BTW at the expense of function "GetModuleHandle". Once again I was wrong in my last post, because if there is no listen servers for LINUX, then the function "GetModuleHandle" for LINUX does not need, in addition, ".DLL" extension on LINUX, it does not exist, there ".SO".

So you should use: (without GetModuleHandle for LINUX)

inline const bool IsSoftwareDrawingMode (void)
{
    #ifdef _LINUX
        return true;    // Always software rendering mode....
    #else    // ifdef _LINUX
        static const bool isSoftwareDrawingMode (IS_DEDICATED_SERVER () || GetModuleHandle ("sw.dll") != NULL);

        return isSoftwareDrawingMode;
    #endif    // ifndef _LINUX
}

Actually I don't understand at all how this can work. I mean how the function IsSoftwareDrawingMode (void) can get a call for it-self inside it - isSoftwareDrawingMode (IS_DEDICATED_SERVER () || GetModuleHandle ("sw.dll") != NULL) - to give the right result. Can You re-write it to the way I'm used (I mean - first the declaration, then the usage - without recursion)?

[Immortal_BLG]

This function is not recursive, since the compiler is case sensitive, so "IsSoftwareDrawingMode" - the name of the function, "isSoftwareDrawingMode" - is a global constant, which is computed only once (at the first call of the function that contains this variable - "IsSoftwareDrawingMode") and serves as the return value. You can rename the variable "isSoftwareDrawingMode" at will and it will not change anything. Why static? Because of speedup. I have already written above that the result will be calculated only once - it's what we want....

[KWo]

Do You mean this function can be written so:

inline const bool IsSoftwareDrawingMode (void)
{
    #ifdef _LINUX
        return true;    // Always software rendering mode....
    #else    // ifdef _LINUX
        static const bool KWoMode = (IS_DEDICATED_SERVER () || GetModuleHandle ("sw.dll") != NULL);

        return KWoMode;
    #endif    // ifndef _LINUX
}

and it will work the same? So what was the reason it was named the same inside as the global inline const? Just to confuse a noob in C++ programming?

[Immortal_BLG]

Originally Posted by KWo

Do You mean this function can be written so:

inline const bool IsSoftwareDrawingMode (void)
{
    #ifdef _LINUX
        return true;    // Always software rendering mode....
    #else    // ifdef _LINUX
        static const bool KWoMode = (IS_DEDICATED_SERVER () || GetModuleHandle ("sw.dll") != NULL);

        return KWoMode;
    #endif    // ifndef _LINUX
}

and it will work the same?

YES.

Originally Posted by KWo

So what was the reason it was named the same inside as the global inline const? Just to confuse a noob in C++ programming?

because in fact the variable "isSoftwareDrawingMode" also itself a function "IsSoftwareDrawingMode", but the only reason why I have not written just code:

inline const bool IsSoftwareDrawingMode (void)
{
    #ifdef _LINUX
        return true;    // Always software rendering mode....
    #else    // ifdef _LINUX
        return IS_DEDICATED_SERVER () || GetModuleHandle ("sw.dll") != NULL;
    #endif    // ifndef _LINUX
}

, because as I wrote before that check must be executed only once for the economy of the CPU speed.....

[KWo]

Originally Posted by Immortal_BLG

YES.
because in fact the variable "isSoftwareDrawingMode" also itself a function "IsSoftwareDrawingMode", ...

For linux it is not... The static part (calling once the function) I understood before. Anyway - thanks for the explanation.

[KWo]

Well, me and some users are experiencing a crash since the last podbot mm update. I'm getting this error:
FATAL ERROR (shutting down): New message started when msg '35' has not been sent yet

I googled a bit and I found this answer:
http://www.mail-archive.com/hlcoders.../msg18419.html

Two situation can cause that error: 1) Calling MESSAGE_BEGIN while another message is being written. 2) Forgetting to call MESSAGE_END and the end of a message you send. It appears you are calling callback functions during MESSAGE_BEGIN, MESSAGE_END, WRITE_BYTE (and many others). If any of these callback functions call a MESSAGE_BEGIN you will get that error (since you would be calling MESSAGE_BEGIN a second time before the first message ended). There is no native queuing mechanism in the SDK, since this is only an issue for plugins trying to intercept events. It is pretty easy to write your own queuing mechanism. You can create an abstract class that can be a int, float, vector, or string. Then use std::vector to hold the instances of the abstract class. (If you plan to port to Linux you can run into library dependency issues using the std library.)

Well - what exactly is the message number 35? If I know this I can narrow down the function calling it. It looks like I still need your help.