Originally Posted by rjjj

Bem, vou lhe explicar como que ocorre, assim entenderб e seu problema serб resolvido, claro, se estiver disposto .




Os "dados" que sгo processados quando o GM й rodado no host, sгo, dentro do AMX, chamados de cells.




Obs: 1 "Cell de uma Array" equivale б 1 Cell do AMX, isso devido ao mesmo peso de 4 bytes .




Todas as variбveis, funзхes, callbacks, entre outros (ou seja, todo o cуdigo Pawn ), apуs a compilaзгo, ganham cells correspondentes no AMX .




Vale ressaltar que, as cells nгo sгo o ъnico fator que influencia no "tamanho do AMX", hб tambйm o tamanho do texto (cуdigos) digitado pelo programador no pawno, etc .




Bem, agora veja sua imagem:







E, o termo em vermelho, corresponde ao tamanho de cells do AMX que seu GM produz.





Aн que estб , quando a quantidade de cells que seu GM produzirб chega perto do "tamanho do total de cells para que nгo haja risco de excesso", o compilador comeзa a mostrar a quantidade de cells , que й o que estб acontecendo com vocк, Chefгo .




Se me lembro bem, esse "tamanho prуximo ao tamanho para que nгo haja risco de excesso" й de 14653 bytes .



A diretiva #pragma dynamic define esse tamanho .







Por fim, como evitar que o tamanho de cells produzidas chegue prуximo desse limite ? :





Resposta: Evite o a criaзгo desnecessбria de cells de arrays, exemplo:



Nгo hб necessidade de usar o sнmbolo/macro MAX_PLAYERS (que equivale б 500) se seu servidor tiver apenas 50 slots por exemplo .


Como otimizaria nesse caso:




Outro Exemplo:



Para que criar uma string de 128 cells quando a string tem apenas 3 caracteres ? .



Como otimaria nesse caso:




Fazendo essas otimizaзхes, o o GM/FS a mensagem desapacerб da melhor maneira .



Ou, se preferir, use #pragma dynamic para forзar o compilador б nгo evidenciar o problema, que nгo й a melhor opзгo devido aos problemas que podem acontecer, como citei antes .




Espero ter ajudado .