[Nur56]

Sweet 2 year bump, COMPLETE re-code, edited first post, uploaded new sma(15kb up from 5kb). Contacted an approver to move this to new submissions.

a bit late, I know

[Arkshine]

re-submit it on author's request.

[Arkshine]

- The messages are still not cached.
- About get_maxplayers(), It doesn't change the fact it has to be cached.
- About GameDesc(), you still supercede all the time...
- To retrieve pointer from external cvars, use get_cvar_pointer, something you should cache also.
- fm_* functions are for most of them conversions of fun functions. So include fun, and remove fm_ and you have your functions. fm_ functions are less efficient then the ones from the fun modules. Remember : the less natives you call the more efficient your plugin will be.
- About get_players. You do something wrong. mPlayers will contain a list of player's index, and since it's stored in an array, index starts to 0. So your loop should look : for(i = 0; i < mCount; i++ ), then you can remove your "fix". Also, cache the player's index, i.e: id = mPlayers[i]
- Setting all the time the money to 0 is really a poor way. If you want to disable the ability to buy, use info_map_parameters entity.

Probably others things to say, start to fix what it has been said.

[Nur56]

Originally Posted by Arkshine - The messages are still not cached. - About get_maxplayers(), It doesn't change the fact it has to be cached. - About GameDesc(), you still supercede all the time... - To retrieve pointer from external cvars, use get_cvar_pointer, something you should cache also. - fm_* functions are for most of them conversions of fun functions. So include fun, and remove fm_ and you have your functions. fm_ functions are less efficient then the ones from the fun modules. Remember : the less natives you call the more efficient your plugin will be. - About get_players. You do something wrong. mPlayers will contain a list of player's index, and since it's stored in an array, index starts to 0. So your loop should look : for(i = 0; i < mCount; i++ ), then you can remove your "fix". Also, cache the player's index, i.e: id = mPlayers[i] - Setting all the time the money to 0 is really a poor way. If you want to disable the ability to buy, use info_map_parameters entity. Probably others things to say, start to fix what it has been said.

-

PHP Code:

new gHF[] = "^x04[HomeFree]" //msg index

ColorChat( id[0],BLUE,"^%s^x01 Type ^x03/help ^x01if you need help!",gHF ) 


But if that isn't caching then tell me because I don't know what it is
-Cached maxplayers in the function ColorChat uses
-FMRES_IGNORED now
-Done for sv_maxspeed & mp_freezetime( gSvMSpeed and gFrzTime )
-Removed all fm_ funcs, added fun module funcs instead
-Did that and it gave me a player out of range error, obviously because cs_get_user_team won't work with ID 0, id = mPlayers[i] is there now
-Thought about that when I removed PreThink, now I simply blocked buy function.


Added 2 commands, +sprint/-sprint and +slowfall/-slowfall
SlowFall is a bit more realistic now, you fall faster.
figured it's the only way to get rid of using PreThink(looking at you, connor)

updated src

[Arkshine]

- I was talking about the events : SayText, TeamInfo. Such message index are static and won't change in-game, therefore that's something you could cache one time.
- You still keep mPlayers[i] == 0 check. It doesn't make sense and can't happen.
- The blocking of "buy" is wrong. You can buy with others ways. So... again, see info_map_paramters entity. Easy and efficient way.
- Why you don't hook SendAudio or TextMsg to know what team has won ?
- AFAIK changing the return of a FM forward, you need to supercede. I did not say you to remove this return, but to move it in the check, which should be logic.

I have others things to say, but for now, fix again your plugin.
I'm starting to wonder if you can really support this plugin.

[Nur56]

Originally Posted by Arkshine - I was talking about the events : SayText, TeamInfo. Such message index are static and won't change in-game, therefore that's something you could cache one time. - You still keep mPlayers[i] == 0 check. It doesn't make sense and can't happen. - The blocking of "buy" is wrong. You can buy with others ways. So... again, see info_map_paramters entity. Easy and efficient way. - Why you don't hook SendAudio or TextMsg to know what team has won ? - AFAIK changing the return of a FM forward, you need to supercede. I did not say you to remove this return, but to move it in the check, which should be logic. I have others things to say, but for now, fix again your plugin. I'm starting to wonder if you can really support this plugin.

-Done( I think? )
-Removed and doing i = 0 actually worked this time
-Done that, had to include engine but oh well
-Hooked using TextMsg
-Didn't understand you in the beginning, fixed now with an IGNORE outside the check

I've worked hard for this plugin, I would hate for it to go to waste

(updated src, removed +/-sprint and +/-slowfall and replaced them with +/-homefree)

[Arkshine]

- You don't understand the caching thing.
That : get_user_msgid("SayText"), it returns an unique number which won't change in-game. Since static, and since it will be called more than one time, it would be appropriate to cache its value into a global variable one time, in plugin_init for example.
- Same for get_maxplayers(). You save the value before, it's better, but it will still be called each time the function will be run, and the returns value won't change in-game.
- Why are you using register_message for TxtMsg ? There is not reason to hook the message as pre, you don't want to modify its params, right ? You can simply use 2 register_event. It will be more efficient.
- What are you trying to delete the entity in the player's spawn ? How you can expect you find such entity when Ham_Spawn is registered with "player" ? Really doesn't make sense what you do. Search you will find snippet for that.

It does not really matter you have worked hard. Look, each time there are many things to say, it proves simply you need to learn more. Nothing wrong with that, you should just aware of your own limit. That's not the scripting section. You are supposed to know what you're doing. That's why I've said I was wondering if you can support really your plugin. You have some potential for sure, but you will understand it starts to be boring to correct you each time because our job is not to teach you how to code.

Anyway for now, it seems you can follow, fix your plugin, and really please, test your plugin before releasing.

[Nur56]

Originally Posted by Arkshine - You don't understand the caching thing. That : get_user_msgid("SayText"), it returns an unique number which won't change in-game. Since static, and since it will be called more than one time, it would be appropriate to cache its value into a global variable one time, in plugin_init for example. - Same for get_maxplayers(). You save the value before, it's better, but it will still be called each time the function will be run, and the returns value won't change in-game. - Why are you using register_message for TxtMsg ? There is not reason to hook the message as pre, you don't want to modify its params, right ? You can simply use 2 register_event. It will be more efficient. - What are you trying to delete the entity in the player's spawn ? How you can expect you find such entity when Ham_Spawn is registered with "player" ? Really doesn't make sense what you do. Search you will find snippet for that. It does not really matter you have worked hard. Look, each time there are many things to say, it proves simply you need to learn more. Nothing wrong with that, you should just aware of your own limit. That's not the scripting section. You are supposed to know what you're doing. That's why I've said I was wondering if you can support really your plugin. You have some potential for sure, but you will understand it starts to be boring to correct you each time because our job is not to teach you how to code. Anyway for now, it seems you can follow, fix your plugin, and really please, test your plugin before releasing.

-Cached vars in plugin_init(), including getmaxplayers
-registered 2 events, 1 for CT win and 1 for T win, using TextMsg
-It worked fine for me but I agree, it wasn't really effective. changed to use only fakemeta.


I really hope I did it right this time, I do know what I'm doing I just didn't find this amount of optimization really necessary(until now).

and I really do test my plugin before I release it

[Arkshine]

changed to use only fakemeta.

That's not an optimization... Look, because of that now, instead of DispatchKeyValue (one native), you call SetKeyValue (5 natives!). Guess what is the most efficient ? Of course here, it would be called one time, but it won't always the case. You should use intelligently the existing natives/forwards whatever the modules. Remember calling a native cost cpu, that's why there is no reason to use the fakemeta version here.

- You create the entity info_map_parameters, but you forget the situation where the map has already such entity. Since you create in precache time, the entity of the map is not created yet, that's why you need to hook FM_Spawn after creating your entity to block its spawn (the entity integrated to the map). Again, there is snippet about that.
- You call 2 times cs_get_user_team( id ). You should cache the value and you should understand checking 2 times the team is quite pointless. Use simply a switch.
- Oh inside the switch, instead of writting 1 and 2, some defines exist for that, CS_TEAM_CT and CS_TEAM_T, just use them.
- When you do checks, you should make testing first the variables. Like gNewR should be check before get_pcvar_num. You filter better to avoid to check natives.
- You should avoid to make multiple if() when you could do if( condition1 && condition2 && etc.. ). The compiler is idiot and won't optimize. By doing that you will generate less code.
- Your motd is static, therefore it would be appropriate to generate it one time.
- In the player's spawn, is a task really need ? 0.2 is fairly unnoticeable and I'm not how it would be useful.
- I see you use a var to pass the player's id, but as tip, you can pass directly the player's id as the task id. And it will avoid each you use id[0] (where here that's something you should cache from the start hehe)

- A word about readability : please avoid to glue all together. It won't hurt to make some white-spaces. People who will read your code will be happy. For example logevent_round_start, you can make make a new line after the var, cvar, colorchat.
- Just for your information. I see most of time your explicit the return of a function (PLUGIN_CONTINUE, etc..). When no specific value has to be returned, the value by default is anyway the PLUGIN_CONTINUE, or FMRES_IGNORED, etc.., therefore you don't need to explicit the return. It's fine if you do too and it won't matter if you want to keep it, but personally I see no point to explicit, it eats one line for nothing.