Raised This Month: $ Target: $400
 0% 

Automaton or native to disable forward & OT discussion about detecting ground touch


Post New Thread Reply   
 
Thread Tools Display Modes
Author Message
Astro
Member
Join Date: Jul 2011
Old 04-17-2013 , 18:11   Re: Automaton or fakemeta?
Reply With Quote #1

I would need to adjust mp_freezetime for each map to fit the time before players reach the ground which is something I am not looking for because I have team of admins that change the maplist quite often but are not allowed to change server CVars. I could even use a set_task for that, I've already considered these options but it's unbearably time-consuming to maintain the individual settings for each map…

Edit: I've added Ham version to the first post. I'm interested in the answer to the detecting player touch ground "event", but also in the pure theory, but I'm not sure whether joaquimandrade reads Scripting Help. :D
Edit2: Following are not solutions to my problem:
  1. Hooking Ham_TakeDamage, disabling and returning HAM_SUPERCEDE after first hit // because in some cases player gets more than one hit before reaching the ground
  2. Hooking Ham_TakeDamage, disabling and returning HAM_SUPERCEDE after DMG_FALL // because in some cases player doesn't fall but gets damage differently
  3. Using set_task or any equivalent // because there would have to be per-map configs which would take much time to test, setup and maintain (as gravity and therefore time to fall can differ)
  4. (Can't remember more, but I've tried more)

Last edited by Astro; 04-17-2013 at 18:49.
Astro is offline
Backstabnoob
BANNED
Join Date: Feb 2009
Location: Iwotadai Dorm
Old 04-18-2013 , 08:26   Re: Automaton or native to disable forward & OT discussion about detecting ground tou
Reply With Quote #2

There's not much to learn about automatons, they're relatively easy to understand (from your code you already know how to use them).

As for efficiency, automatons basically decide which "version" of the function will be called. There's no difference in efficiency between those two:

Code:
public some_function( ) < clients_in_game > { // ... } public some_function( ) < > { }

Code:
public some_function( ) {    if( clients_in_game )    {       // ...    } }

Because both ways work exactly the same. However, automatons would be probably better if you use more than one state.

As for your example, you're basically saving a native call since you're not unregistering the forward.
However, automatons or not, if you use the standard client_PreThink forward, it will still be called each frame for each client in the server. Therefore, the result will be exactly the same for these two:

Code:
public client_PreThink( ) < PreThink: enabled > { // ... } public client_PreThink( ) < PreThink: disabled > { } public client_PreThink( ) < > { }

Code:
public client_PreThink( ) {    if( something )    {       // ...    } }

So your question is which PreThink forward is the most efficient, rather than automaton/fakemeta version.
Backstabnoob is offline
Astro
Member
Join Date: Jul 2011
Old 04-20-2013 , 10:30   Re: Automaton or native to disable forward & OT discussion about detecting ground tou
Reply With Quote #3

Thanks to all of you! :)

Looks like I have last question to understand it completely (enough to use it in my code). Is it correct that checking for automaton state does affect the performance equally as performing the if(something) statement in the last block of code?

When a function is called, is there always a check for automaton state? If there is, I think that the automaton version must be slightly faster because there would be two checks: first for automaton (there is none but does the program know that?) and second for value of "something" (inside the if statement).
Astro is offline
Backstabnoob
BANNED
Join Date: Feb 2009
Location: Iwotadai Dorm
Old 04-20-2013 , 11:11   Re: Automaton or native to disable forward & OT discussion about detecting ground tou
Reply With Quote #4

Quote:
Looks like I have last question to understand it completely (enough to use it in my code). Is it correct that checking for automaton state does affect the performance equally as performing the if(something) statement in the last block of code?
Most likely and if not, the difference would be trivial.

Quote:
When a function is called, is there always a check for automaton state? If there is, I think that the automaton version must be slightly faster because there would be two checks: first for automaton (there is none but does the program know that?) and second for value of "something" (inside the if statement).
I think the automatons are checked only if state is used somewhere in the code.


Automatons should be a LITTLE faster because when the plugin sets its state, there is no longer a need to check which function should be called. It doesn't check what the expression returns unlike if does each time, it just finds the function with the state that's already set in the memory.

However, the difference would be most likely unnoticeable and there's a good chance many of other users reading your code won't understand it. You should chose wisely - don't care only about efficiency especially when it's absolutely trivial, readability should be the winner in this case.

By the way, you can replace this:
Code:
if(something) {     state PreThink:enabled; }

with this:

Code:
state (something) PreThink: enabled;

Last edited by Backstabnoob; 04-20-2013 at 11:18.
Backstabnoob is offline
Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 10:45.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode