[MrPickles]

Hello, I wanted to know if there is a way to obtain the distance between players, I am doing it this way, but since it is done repeatedly, it does not seem very light to me to call the engine twice each time it is executed, is there another way?

PHP Code:

   static Float:OriginPlayer1[3], Float:OriginPlayer2[3], Float:Distance;

   entity_get_vector( Player1 EV_VEC_origin, OriginPlayer1 );
   entity_get_vector( Player2, EV_VEC_origin, OriginPlayer2 ); 

   Distance = get_distance_f( OriginPlayer1, OriginPlayer2 ); 


Solved!( i Think this is better )

PHP Code:

native Float:entity_range(ida, idb); 


[EFFx]

If you are interested, here's this native you've used inside engine.cpp:

static cell AMX_NATIVE_CALL entity_range(AMX *amx, cell *params)
{
	int idxa = params[1];
	int idxb = params[2];

	CHECK_ENTITY(idxa);
	CHECK_ENTITY(idxb);

	edict_t *pEntA = TypeConversion.id_to_edict(idxa);
	edict_t *pEntB = TypeConversion.id_to_edict(idxb);

	REAL fRet = (pEntA->v.origin - pEntB->v.origin).Length();

	return amx_ftoc(fRet);
}

Basically it does the same as the first option you used, but definitely faster.

[MrPickles]

Originally Posted by EFFx If you are interested, here's this native you've used inside engine.cpp: static cell AMX_NATIVE_CALL entity_range(AMX *amx, cell *params) { int idxa = params[1]; int idxb = params[2]; CHECK_ENTITY(idxa); CHECK_ENTITY(idxb); edict_t *pEntA = TypeConversion.id_to_edict(idxa); edict_t *pEntB = TypeConversion.id_to_edict(idxb); REAL fRet = (pEntA->v.origin - pEntB->v.origin).Length(); return amx_ftoc(fRet); } Basically it does the same as the first option you used, but definitely faster.

Thanks! very usefull!, how can i check it for get vector and get_distance_f ? by the way i think entity_range is better than take 2 vectors and use get_distance_f, right?, i need it faster and light, cause i will check it constantly

[fysiks]

Huh? EFFx confirmed that you found the correct function to solve your problem.

[MrPickles]

Originally Posted by fysiks Huh? EFFx confirmed that you found the correct function to solve your problem.

yes i know, i just want to check how entity_get_vector and get_distance_f works, I will definitely use entity range, its just to learn

[EFFx]

There's a lot of informations about how natives looks like inside github. The engine.cpp is the one that you should search about.

static cell AMX_NATIVE_CALL entity_get_vector(AMX *amx, cell *params)
{
	int iEnt = params[1];
	int idx = params[2];
	cell *vRet = MF_GetAmxAddr(amx, params[3]);
	Vector vRetValue = Vector(0, 0, 0);

	CHECK_ENTITY_SIMPLE(iEnt);

	edict_t *pEnt = TypeConversion.id_to_edict(iEnt);

	switch (idx)
	{
		case origin:
			vRetValue = pEnt->v.origin;
			break;
		case oldorigin:
			vRetValue = pEnt->v.oldorigin;
			break;
		case velocity:
			vRetValue = pEnt->v.velocity;
			break;
		case basevelocity:
			vRetValue = pEnt->v.basevelocity;
			break;
		case clbasevelocity:
			vRetValue = pEnt->v.clbasevelocity;
			break;
		case movedir:
			vRetValue = pEnt->v.movedir;
			break;
		case angles:
			vRetValue = pEnt->v.angles;
			break;
		case avelocity:
			vRetValue = pEnt->v.avelocity;
			break;
		case punchangle:
			vRetValue = pEnt->v.punchangle;
			break;
		case v_angle:
			vRetValue = pEnt->v.v_angle;
			break;
		case endpos:
			vRetValue = pEnt->v.endpos;
			break;
		case startpos:
			vRetValue = pEnt->v.startpos;
			break;
		case absmin:
			vRetValue = pEnt->v.absmin;
			break;
		case absmax:
			vRetValue = pEnt->v.absmax;
			break;
		case mins:
			vRetValue = pEnt->v.mins;
			break;
		case maxs:
			vRetValue = pEnt->v.maxs;
			break;
		case size:
			vRetValue = pEnt->v.size;
			break;
		case rendercolor:
			vRetValue = pEnt->v.rendercolor;
			break;
		case view_ofs:
			vRetValue = pEnt->v.view_ofs;
			break;
		case vuser1:
			vRetValue = pEnt->v.vuser1;
			break;
		case vuser2:
			vRetValue = pEnt->v.vuser2;
			break;
		case vuser3:
			vRetValue = pEnt->v.vuser3;
			break;
		case vuser4:
			vRetValue = pEnt->v.vuser4;
			break;
		default:
			return 0;
			break;
	}

	vRet[0] = amx_ftoc(vRetValue.x);
	vRet[1] = amx_ftoc(vRetValue.y);
	vRet[2] = amx_ftoc(vRetValue.z);

	return 1;
}

As you can see in the first case, it converts the pEnt to v.origin, the same thing that happens inside the entity_range().

The get_distance_f() is provided by vector.cpp

static cell AMX_NATIVE_CALL get_distance_f(AMX *amx, cell *params)
{
	cell *cpVec1 = get_amxaddr(amx, params[1]);
	cell *cpVec2 = get_amxaddr(amx, params[2]);

	Vector vec1 = Vector((float)amx_ctof(cpVec1[0]), (float)amx_ctof(cpVec1[1]), (float)amx_ctof(cpVec1[2]));
	Vector vec2 = Vector((float)amx_ctof(cpVec2[0]), (float)amx_ctof(cpVec2[1]), (float)amx_ctof(cpVec2[2]));

	REAL fDist = (REAL) (vec1 - vec2).Length();

	return amx_ftoc(fDist);
}

And here, it does the same too: gets the difference between two points. Not sure about what REAL does, maybe the same goal as the abs().
-

The idea is to make the code the shortest possible, so it is easy to edit, fix or read. Keep in mind that entity_get_vector() wasn't meant just for origin information, as you can see in the code inside engine.cpp. So if your goal was only to get the distance and nothing else, using entity_range() is way faster. Different natives for different purposes.

[fysiks]

Originally Posted by EFFx The idea is to make the code the shortest possible

This statement should never be said in the context of writing code, ever.

[EFFx]

What makes you say that? Why would I write a large code to do something easy, if I can use a smaller one which is faster and easy to understand, but with the same end goal?

[MrPickles]

Originally Posted by fysiks This statement should never be said in the context of writing code, ever.

shortest & fast != less memory used?

[fysiks]

Originally Posted by EFFx What makes you say that? Why would I write a large code to do something easy, if I can use a smaller one which is faster and easy to understand, but with the same end goal?

The length of code has no direct correlation to being "easy to edit, fix or read". You can easily make "short" code that is hard to read, fix, and edit.

Similarly, the length of code, generally, has no direct correlation to any performance metric (execution speed or memory). Also similarly, you can make "short" code that is inefficient.

I made the reply to your post because many new coders get it in their head that "shorter code is better" when they need to, instead, be thinking about how to write coded that is efficient and easy to read/edit.