06.02.2010, 22:15
Right, sorry about that. I'll edit the post to avoid confusion.
I understand what you mean about statically allocating yet more things in your script that could be done dynamically in the plugin, but I think that adding a lot of unnecessary optional parameters will just complicate usage of the natives and callbacks. Also, the PAWN bit is actually not as bad as you might think if you just look at what your code is doing:
That creates an array 1024*2*4 bytes big (8192 bytes, or 8 KB). Granted, the size of the array would be cut in half if the enum wasn't there, but you aren't wasting any space. There's no performance trade-off in doing this—the only thing that really happens is the size of the .amx increases.
However, this is feasible (I actually didn't think about adding an extra enum value until just now, but it is a much better idea):
I'll most likely put that in v2.3.6. Thanks for the suggestions.
I understand what you mean about statically allocating yet more things in your script that could be done dynamically in the plugin, but I think that adding a lot of unnecessary optional parameters will just complicate usage of the natives and callbacks. Also, the PAWN bit is actually not as bad as you might think if you just look at what your code is doing:
pawn Код:
#define MAX_STREAMED_PICKUPS (1024)
enum
E_PICKUP
{
E_PICKUP_EXTRA_ID,
E_PICKUP_REAL_ID
}
new
gPickups[MAX_STREAMED_PICKUPS][E_PICKUP];
However, this is feasible (I actually didn't think about adding an extra enum value until just now, but it is a much better idea):
pawn Код:
Streamer_SetIntData(STREAMER_TYPE_PICKUP, gPickup, E_STREAMER_EXTRA_ID, 1);