[mahnsawce]

While, by no means am I bothered by the choices to leave certain features of the ns2amx module out of the amxx port, I have one question...

About the exclusion of things like "register_touch", and "register_think", in exchange for static forwards such as "pfn_touch(id)" and "pfn_think(id)". Why?

I was always under the impression that AMX and AMXX were meant to be easy to use while still providing powerful control over the game server. To me, having a static call of "pfn_touch()" "pfn_think()" etc just do not seem very easy to use, or user friendly.

I only ask this, because.. well.. if you're doing this because string comparisions are not an expensive task, then why not just unchain "register_clcmd", and just forward "ClientCommand()" calls with support for calling CMD_ARGV() and CMD_ARGC()? Also, why is there register_event(), when every call to message_begin / write_byte / write_short / write_string / write_coord / write_angle / write_long / write_entity / message_end could just be called?

Some forwards, such as PlayerPreThink/PlayerPostThink seem logical to simply forward the actual call. However, forwards such as Touch and Think, which are pretty much guaranteed to have a check for the classname done as the first comparision called in the touch/think functions, it just seems to be more logical to have the module do this comparison so the author doesn't have to worry about this when they create the plugin.

This is the main reason why I had originally switched from the static forwards I had once had in ns2amx (ns2amx_think,ns2amx_touch) and I was quite happy with the results. It seems very easy to pick up on this method, while still providing full control over the engine calls.

Pev() being excluded doesn't bother me. While I like my method of entvar retrieval 10x more than what is currently in AMXX, there are many many more people who are currently used to the current method than there are people used to my implementation of it. Although I would like to point out that this nice naming standard is not currently present in all of your natives. Read_data(), which is where I got the idea for my pev() from, would be my main example of this.

[QwertyAccess]

I was starting to like pev , Also any info on whats going to be forward changelevel's future?

[AssKicR]

i think register_touch & register_think should be added also

[BAILOPAN]

I have decided to move non-blocking forwards to Post calls for a possible speed increase.

I will add registers for use, touch, think, and impulse.

I have also added, mahnsawce, your very cool engfunc and dllfunc natives as well as framewait.

I still haven't gotten around to making backward compatible stocks though

[mahnsawce]

Nice

I've since patched the source to ns2amx to fix a minor typo in dllfunc() -- DLLFunc_Touch/DLLFunc_Block take the same parameter (param[2]) twice in it's evaluation, instead of param[2] and param[3]. (Though now that I think about it, I forgot to update the source in the distribution src.zip. Woops.)

Basically (same snip of code for both):

  	                 cRet = MF_GetAmxAddr(amx,params[2]);
  	                 index=cRet[0];
  	                 CHECK_ENTITY(index);
  	                 cRet = MF_GetAmxAddr(amx,params[2]);
  	                 indexb=cRet[0];
  	                 CHECK_ENTITY(indexb);

Should be

  	                 cRet = MF_GetAmxAddr(amx,params[2]);
  	                 index=cRet[0];
  	                 CHECK_ENTITY(index);
  	                 cRet = MF_GetAmxAddr(amx,params[3]);
  	                 indexb=cRet[0];
  	                 CHECK_ENTITY(indexb);

I was pulling my hair out last night trying to figure out why touch was all of a sudden broken, and found that.

So far that's been the only issue with the new natives I've added that I've noticed.

Also, in ns2amxhelpers.inc, there are backwards-compatibility stocks included. They should work with engine as well (if you intend on turning the natives to stocks which call engfunc()/dllfunc(), as I have done).

[lart2150]

is it just me or is the module nolonger in the cvs at least I cant find it

http://www.amxmodx.org/cgi-bin/viewcvs.cgi/amxmodx/ns/ gives me
http://www.amxmodx.org/cgi-bin/viewcvs.cgi/amxmodx/ns/

that makes me think that either the user for cvs does not have access or it's been moved

[CheesyPeteza]

It was moved here:

http://www.amxmodx.org/cgi-bin/viewc...ls/ns/ns2amxx/

[BAILOPAN]

gcc caught another bug I think mahnsawce:

diff -u -r1.4 -r1.5
--- amxmodx/engine/engine.cpp	2004/06/26 22:46:54	1.4
+++ amxmodx/engine/engine.cpp	2004/06/29 06:26:56	1.5
@@ -2040,7 +2040,7 @@
 		return gpGamedllFuncs->dllapi_table->pfnPM_FindTextureType(temp);
 
 	case	DLLFunc_RegisterEncoders:	// void )	( void );
-		gpGamedllFuncs->dllapi_table->pfnRegisterEncoders;
+		gpGamedllFuncs->dllapi_table->pfnRegisterEncoders();
 		return 1;
 
 	// Enumerates player hulls.  Returns 0 if the hull number doesn't exist, 1 otherwise

[BAILOPAN]

I changed most stocks to natives because, in general, stocks for things that a)reference other modules and b)could change in the future are a bad idea, for recompiling reasons.

I also added a somewhat backwards compatible stock which wraps most of the NS2AMX natives except the tricky ones.

[mahnsawce]

Thanks for the bug fix.

I've also found two other issues (fixed in my ns2amx):

DLLFunc_Use has the same issue DLLFunc_Touch/DLLFunc_Block had, just change the one param[2] to param[3], though I didnt notice it when originally fixing.

DLLFunc_ClientConnect should be called like this:

		iparam1 = MDLL_ClientConnect(INDEXENT(index),STRING(ALLOC_STRING(temp)),STRING(ALLOC_STRING(temp2)),temp3);
		cRet = GET_AMXADDR(amx,params[6]);
		SET_AMXSTRING(amx,params[5],temp3,cRet[0]);
		return iparam1;

(I just caught the returning of iparam1 while posting this, instead of a constant 1, this isnt fixed in ns2amx yet.)

I guess writing two extremely repetitive, boring, and long natives while having little sleep yields a few bugs.


I understand your changing most stocks to natives, but my main reason for doing stocks in ns2amx is that it's easier for me when something major needs changing. It's commonly good practice to recompile scripts between updates, so I just make my users on modns recompile each update.

Edit: Since I dont think you've seen this yet, I've got another bug fix in engfunc()

Old:

		temp = MF_GetAmxString(amx,params[3],0,&len);
		temp2 = MF_GetAmxString(amx,params[4],0,&len);

New:

		temp = MF_GetAmxString(amx,params[3],0,&len);
		temp2 = MF_GetAmxString(amx,params[4],1,&len);

(Yeah, I made the stupidest mistakes in those two natives )