[Sire Pom-pom]

On peut utiliser le mot clé const pour avoir un mode de débuggage pour son module. Dans l’état actuel des choses, il est conseillé d’utiliser le compilateur de Torlack, pour plusieurs raisons.

C’est très simple, vous créez un fichier include, appelons le interface.nss, qui pour une fois sera un véritable fichier d’entête. Pour ce mode de débuggage nous n’avons besoin que d’une seule ligne de code :

Code:

const int _DEBUG_ = TRUE ;

Et vous incluez ce fichier dans tous les scripts que vous incluez. Pour ceux qui diraient "mais si je m’en sert pas dans un fichier et que je l’inclus quand même ça fait de précieux bits de perdus", la réponse est non, dans tous les cas, que ce soit avec le compilateur de Bioware où avec celui de Torlack une variable "const" ne prend de la place dans le code que quand on l’appelle, et même dans ce cas là, pas toujours, pour ce qui est du compilateur de Torlack en mode -co.

Ensuite à chaque fois que vous avez du code de débuggage vous écrivez :

Code:

if(!_DEBUG_)
{
    ActionDoCommand(SetLocked(OBJECT_SELF,TRUE));
	...
}

Dans ce cas, la porte dont il est question ne se verrouillera qu’en dehors du mode débuggage.

Ou encore

Code:

if(_DEBUG_)
{
	string sCount = "nCount  = "  + IntToString(nCount) ;
	SpeakString(sCount);
}

Pour qu’un NPC vous donne la valeur d’une variable uniquement en mode débuggage.

C’est une des deux raisons d’utiliser le compilateur de Torlack plutôt que celui du toolset. En mode -co, si vous avez défini
cons int _DEBUG_ = FALSE ;
Le compilateur verra que if(_DEBUG_) ne peut jamais être vérifié, par conséquent il supprimera tout simplement le "if" et tout ce qui se trouve entre accolades ; s’il y avait un "else" il le compilerait évidemment, sans condition. C’est l’optimisation basique, malheureusement, après vérification, le compilateur Bio ne le fait pas.
L’autre raison c’est que quand vous voudrez changer de mode, il vous faudra changer le "FALSE" de interface.nss en "TRUE" ou vice versa, sauvegarder le fichier, puis recompiler tout les scripts . Modifier un fichier include ne fait rien en soi : il faut recompiler pour que le changement soit pris en compte dans les scripts qui le référence.

Un chti problème : les fonctions de débuggage.
Quand vous définissez une fonction, que ce soit à l’intérieur du script lui-même ou dans un fichier include qu’il référence, son code sera toujours inclus à la compilation, que la fonction soit effectivement utilisée ou pas. Dans le cas qui nous intéresse, si vous définissez des fonctions que vous n’utilisez qu’en mode débuggage, les appels étant tous contenus dans des if(_DEBUG_){...} , vous les traînerez en dehors de ce mode. Cela n’influence pas directement les performances : l’appel n’aura jamais lieu. En revanche cela augmente la taille du script, et donc du module, proportionnellement à la taille de la fonction, et si elle a été définie dans un include proportionnellement au nombre de scripts référençant ce dernier.

Avec le compilateur de Torlacken en mode -co, il est donc intéressant de définir les fonctions de débuggage ainsi :

Code:

void AlertAlreadyLocked(object oObject)
{
    if(_DEBUG_)
    {
        if(GetLocked(oObject))
        {
            SendMessageToPC(GetFirstPC(), "vérouillage: tout va trop vite!");
        }
    }
}

Une fois compilée avec _DEGUG_ = FALSE cette fonction fera deux lignes - et ceci quelque soit le code - c’est donc une perte de place minimale. Si vous avez des fonctions de débuggage spécifique à un script, pour la même raison, mettez les dans le script lui-même, pas dans un include général. Ne définissez pas de fonctions dans interface.nss, n’y mettez que des const.

Interface.nss peut servir à bien d’autre chose que les débuggage. Encore une fois les const ne prennent de la place dans un script après compilation que si elles sont utilisées. Vous pourrez donc mettre tous les paramètres et toutes les constantes nommées de votre module dans ce fichier, pour des sorts que vous avez créés par exemple. C’est une question de goût : préférez vous un seul include, qui peut finir par ressembler à une usine à gaz dans des modules très complexe (cf nwscript.nss) ou un fichier par fonctionnalité, à vous de voir, après compilation cela ne change rien.

Une remarque sur les fichiers d’include, d’après ce que nous avons vu de la compilation des fonctions, c’est une mauvaise idée de s’en servir comme fourre-tout. Si vous avez un include de 6000 lignes, quand bien même vous n’utiliseriez qu’une seule fonction dans un script donné toutes les fonctions y seront ajoutées et compilées. Si vous vous servez souvent de cet include - et par définition plus il y a de chose dedans plus l’on s’en sert souvent- l’augmentation de la taille de votre module sera non négligeable, même si les performances ne seront pas directement affectées (un gros script est tout de même un peu plus long à charger qu’un petit par exemple).