[aron9forever]

Originally Posted by baneado (Engine Stocks, it's practically the same as fakemeta util...) http://amxmodx.org/doc/index.html?pa...ser_button.htm (Engine Stocks, it's practically the same as fakemeta util...) http://amxmodx.org/api/engine_stocks/get_entity_flags (Fun) http://www.amxmodx.org/doc/index.htm...r_maxspeed.htm Yes, help him of course, but teach him the best method.

need the velocity because those functions are being used for wallclimb
I could of course port it all to engine

Originally Posted by hornet Given the fact that your using Fakemeta Utility shows that you really don't have a great deal of knowledge in this area. Also I can't understand why you would be comparing anything to engine module forwards since they are ( to be quite blunt ) useless because they cannot be unregistered or disabled when they're not in use.

Well obviously there are an infinite number of cases in which either one is better for the job. I was speaking in a general manner comparing engine speed to fakemeta.

The fact that I use fakemeta_util, well, all I can say is that the wallclimb part that uses it, I just copy pasted it from another script I wrote almost 2 years ago, which was also mostly copy pasted from somewhere.

I am just pissed of right now because I've emulated a cursor in counter strike and originally used fakemeta to get / set entity angles and it was stuttering on a clean server on a machine that(for counter stike) can be considered as unlimited resources. I've also had much more trouble with fakemeta than with any other module, but as long as something's not broken, I don't fix it.

[Nextra]

Originally Posted by hornet Also I can't understand why you would be comparing anything to engine module forwards since they are ( to be quite blunt ) useless because they cannot be unregistered or disabled when they're not in use.

Not generally true. If you are in a situation where you can't disable fakemeta forwards in any meaningful way engine forwards are superior.

Originally Posted by baneado Some engine stocks are practically the same as fakemeta util... the difference isn't high.

The difference is big. That's exactly the point people are making in this thread.

fakemeta_util was born out of a completely unnecessary quest to ditch the engine module for some imagined performance benefit. That is a notion that still causes too many members of this community to make misjudged and inappropriate "optimizations" to their code to get rid of the supposed "devil" that is engine.

Almost all of the fakemeta_util stocks need several fakemeta functions to copy the behavior of a single engine call (or in the case of fm_user_kill even a core AMXX function!). This is a completely unnecessary overhead of native calls, and there are plugins where this can and does matter, all the while providing absolutely no benefit to readability or convenience. Using fakemeta_util is in the absolute majority of cases a net performance loss, the complete opposite it was originally made for, and contrary to the reason many people still blindly use it.

If you ever "ported" code from engine to fakemeta without functional changes, undo it. Examine code you copy from others and move it back to engine as per your judgement. Usually it's a matter of removing a couple of "fm_" prefixes and adding the <engine> include.

[hornet]

Originally Posted by Nextra Not generally true. If you are in a situation where you can't disable fakemeta forwards in any meaningful way engine forwards are superior.

Of course, but how many situations are there where you could possibly need to have a function like PreThink() running the whole time? Very few. In such a case you would write a module to handle that functionality.

[aron9forever]

Originally Posted by hornet Of course, but how many situations are there where you could possibly need to have a function like PreThink() running the whole time? Very few. In such a case you would write a module to handle that functionality.

well on a furien server I need pre and post to be running constantly because furiens are always wallclimbing and it would be retarded to disable and enable it every time someone stop climbing / climbs

I'll have a look and get rid of fm_util in the week-end.
As far as I saw the ones I posted are nothing else than engine stocks.

[baneado]

Originally Posted by Nextra The difference is big. That's exactly the point people are making in this thread.

really???

take a look to fm_set_rendering and set_rendering (are the same)
fm_set_entity_visibility and set_entity_visibility
fm_get_entity_visibility and get_entity_visibility
fm_set_user_velocity and set_user_velocity

......

of course you can see the BIG difference on fm_give_item and give_item, fm_find_ent_by_owner and find_ent_by_owner, fm_strip_user_weapons and strip_user_weapons, etc.

[HamletEagle]

You don't take in account that a module runs on a faster layer than a plugin.

[Nextra]

Originally Posted by baneado really??? take a look to fm_set_rendering and set_rendering (are the same)

The function prototypes are equivalent, and they functionally do the same thing - I know and I said as much. And then take a look at the implementation and realize that fm_set_rendering uses 8 separate natives to achieve wat set_rendering does with 1.

[baneado]

Originally Posted by Nextra The function prototypes are equivalent, and they functionally do the same thing - I know and I said as much. And then take a look at the implementation and realize that fm_set_rendering uses 8 separate natives to achieve wat set_rendering does with 1.

one native? Are you sure?

/*  Set rendering of an entity */
stock set_rendering(index, fx=kRenderFxNone, r=255, g=255, b=255, render=kRenderNormal, amount=16)
{
    entity_set_int(index,EV_INT_renderfx,fx);
    new Float:RenderColor[3];
    RenderColor[0] = float(r);
    RenderColor[1] = float(g);
    RenderColor[2] = float(b);
    entity_set_vector(index,EV_VEC_rendercolor,RenderColor);
    entity_set_int(index,EV_INT_rendermode,render);
    entity_set_float(index,EV_FL_renderamt,float(amount));

    return 1;
}

8, the same as in fakemeta

Really I don't know why they use float native instead to put a decimal number on the parameter :S

[Nextra]

Sorry, you're right. I only had set_ent_rendering - introduced with 1.8.3 - and set_user_rendering in mind:

//engine.inc
native set_ent_rendering(index, fx = kRenderFxNone, r = 0, g = 0, b = 0, render = kRenderNormal, amount = 0);

//fun.inc
native set_user_rendering(index, fx = kRenderFxNone, r = 0, g = 0, b = 0, render = kRenderNormal, amount = 0);

[Drago36]

Not helping. I will only ask for transforming the code, I do not want any theory.