PAWN compiler

[Lorenc]

Hello, can the old version of PAWN be compatible towards scripting stuff, I'm not familiar with the new version of pawn, { 128 } is ment to be a string size :O ?

Thanks, what I mean by the old version of PAWN is the one before the major update.

[Lorenc]

The current version is 64 bits, the other old one is 32, this is why I'm saying this. I perfer 32 over 64 :L

Bump

[foxtacles]

No it's not backward compatible (but it shouldn't be too hard to recompile and change a few things). There is a compile.bat file which comes with the revision 145 package which you can use to compile your PAWN scripts. The curly braces now relate to packed strings:


new pstr{128};

You can (and should) use this syntax instead of


new pstr[128];

Due to the PAWN cell size now being 64bit, this would mean an insane amount of wasted memory (8 byte per 1 byte char). Use packed strings shown above to store 128 characters efficiently ;) The reason I switched to 64bit cell size is that game object IDs are 64bit long.

[Lorenc]

No it's not backward compatible (but it shouldn't be too hard to recompile and change a few things). There is a compile.bat file which comes with the revision 145 package which you can use to compile your PAWN scripts. The curly braces now relate to packed strings:


new pstr{128};

You can (and should) use this syntax instead of


new pstr[128];

Due to the PAWN cell size now being 64bit, this would mean an insane amount of wasted memory (8 byte per 1 byte char). Use packed strings shown above to store 128 characters efficiently ;) The reason I switched to 64bit cell size is that game object IDs are 64bit long.


I haven't tried though the char array can be used for 8 bit arrays, how ever the method to use this array has to be in a simular style to the packed string thing.



#if !defined MAX_PLAYERS
#define MAX_PLAYERS 24
#endif

new pLevel[ MAX_PLAYERS char ]; // Instead of a 64 bit, maybe a 8 bit :D


How ever I do need to investigate a bit more on this new pawn version.