[Le grognon]

Citation :

I think some of you misread my above post.

Ok (because it uses constant values):

int nTest=1; // ok, but consider using the const keyword
string sTest = "123" // ok, but consider using the const keyword
const int iTest = 1;

void main()
{

}


Not Ok (because it is using functions):

int nTest = StringToInt("1");
string sTest = GetName(GetFirstPC());
const int iTest = GetCalendarDay());

void main()
{

}

We are NOT removing the ability to use global variables, they are still there. We are removing the ability to initialize global variables from functions, because that was never supported correctly by our compiler.

And NO, using native functions that way is not save.
Maybe Tim's compiler supports this, not sure about it, but it would be bad style to force people using a third party compiler when compiling your scripts.

Not related to this but a clarification: You should always use the const keyword if you are declaring global variables that do not change value when they are used. Its more efficient.
_________________
georg zoeller
technical designer

le marrant la dedans, c'est que 80 % des modules utilisent les fameuse initilisations de variables par fonction (classique : object oTruc = GetObjectByTag("machin") ; ) et qu'ils vont tous exploser lors de la mise en place de HoU...

qui c'est qui est content ? les PW vont adorer cette modification de la gestion du code interne... pire que le probleme de padding des 2DAs ça...

*ca devoir fouiller tous son code pour les corrections *

[Tulkas]

Tristesse...

[eMRaistlin]

si j'ai bien suivi, ce qui est dit, c'est que les

object oObject = GetObjectByTag("...");

devront etre remplacé par des

object oObject;
oObject = GetObjectByTag("...");

parceque l'initialisation des variable ne peut etre fait que si c'est initialise par une constante.

C'est bien ca ?
(et ce, pour toutes les fonction / variable? )



*urg*, j'ai beau être matinal... j'ai mal..

[Le grognon]

ouep tu as bien compris...

la declaration d'une variable (object otruc; ) doit etre independante de son initialisation ( otruc= Get.... )

et quand une variable est constante et ne sera pas modifiée , il est conseillé de la declarer

"const int iTest"
au lieu d'un bête "int iTest"

mais ceci n'est qu'a l'usage d'optimisation pour le compilateur.. le plus important etant la difference declaration/initialisation

dans l'absolue, tous bon programmeur se doit de programmer comme ça... mais entre le "doit" et "ce qui est fait" quand on a la flemme....

[gaeriel/nekresh]

Citation :

*urg*, j'ai beau être matinal... j'ai mal..

Matinal ?? 10h20 ?

Citation :

dans l'absolue, tous bon programmeur se doit de programmer comme ça... mais entre le "doit" et "ce qui est fait" quand on a la flemme....

En effet mais c'est beaucoup plus propre. Par contre, en faisant cela, ils se rapprochent de certaines particularites du C quand aux variables presque constantes mais non en fait

[B L I N G !]

c'est vrai que ca fera plus propre
d'ailleurs je me suis toujours demander pourquoi cela n'était en natif dans beaucoup de languages.

c'est quand même un peu c.. de dire de faire d'abord des déclarations et ensuite les initialisations quand le language permet de faire les 2 en même temps ! non !


en tous cas tant mieux ca va peut être accélérer leur moteur cette histoire.....*suspense*

[Le grognon]

CORRECTION


une precision qui change le probleme

Citation :

The only thing that will change is that you will not be able to initialize global variables declared outside a function context from a function.

fine:

void main()
{
int i= GetHitDice(GetEnteringObject());
}



not fine:

int i= GetHitDice(GetEnteringObject());

void main()
{

}
_________________

pour ceux qui veulent plus de detail la source

[Jedaï]

Si il y a suffisamment de personne qui en ont besoin (et si ça n'a pas déjà été fait ) je peux faire un script en Perl qui règle "automatiquement" ce problème, c'est à dire qui fait la chose suivante :
[list=1][*]Analyse un script[*]Repère les initialisations globales incorrectes[*]les supprime[*]puis les recopie dans le corps des fonctions qui utilisent cette variable
[/list=1]

Cependant je ne pense pas que ça sera facile, il est peu probable que ça marche à 100% et de plus ça risque d'être assez lent... (Et il faudra avoir Perl pour l'utiliser, sauf si une bonne âme réussit à en faire un exécutable)

[Cheyenne]

Je pense que tout ceci est un peu comme le bug de l'an 2000, à savoir pas mal d'exagération pour ce qui, *à mon humble avis*, sera suffisamment rapide à corriger par tous les builders.

Si c'est codé proprement, toutes les constantes globales se trouveront toujours en entête des scripts, donc assez rapides à répérer.

Ensuite, les constantes globales qui dépendent implicitement d'une fonction sont, encore une fois à mon humble avis, assez rares. Ceci étant dit, je ne peux pas parler des colosses type HCR ou CNR, puisque je ne les utilise pas... et je peux pas non plus dire que tous les builders (moi y compris) codent toujours proprement.

En définitive, il me reste quand même l'impression qu'étant donné le cadre assez restrictif, cela aura un faible impact... contrairement aux nombreux bugs/incompatibilités avec des fonctionnalités NWN base/SOU à attendre.

Quelqu'un se souvient de la galère des waypoints quand nous sommes passés de NWN à SOU ? C'est ce debuggage là qui va être marrant

[eMRaistlin]

Citation :

Quelqu'un se souvient de la galère des waypoints quand nous sommes passés de NWN à SOU ? C'est ce debuggage là qui va être marrant

oO pb de waypoint ?

[Cheyenne]

Voui :

http://nwn.bioware.com/forums/viewto...59755&forum=47

[Taern]

En fait le problème est vraiment bénin.
Il y aura simplement impossibilité d'assigner une valeur globale à une variable à l'aide d'une fonction.

Vous pouvez même faire :

Code PHP:

int i =10;
void main()
{

} 

si ça vous chante. Simplement, dans ce cas-là, l'utilisation de "const" sera plus efficace (puisque la valeur de i sera directement remplacé dans le code à la compilation, alors que sinon i reste une variable comme une autre)

[Cheyenne]

Les informaticiens et -ciennes (!) aiment bien jouer à se faire peur

[KzimiR666]

C'est pas si grave que ça... Puisque en fait c'est uniquement l'affectation de variables en dehors des focntions qui devra être revue... Donc il n'y aura pas beaucoup de mofifications à faire.

[Prince Nexus]

juste une question :
aura t on tjs le droit de faire des constantes du type :

Code PHP:

// en tete d'include :
int DEBUG_MODE = 0;
int PLAYER_NUMBER = 50;
...
// reste du script avec des fonctions employant ces constantes 

ou pas. Si ce n'est plus le cas, c'est une véritable catastrophe, et qd à ceux qui prétendent que ça ne les affectera pas, cela signifie pour leurs modules qu'ils ne sont pas très développés.

Prince Nexus, concepteur d'un module comportant plus de 100.000 lignes de code

[Jedaï]

Non, ça y a pas de problème, ça continuera à marcher, encore qu'il vaudra mieux mettre const devant, pour améliorer les performances.
Tu pourras même les utiliser dans les switch...case maintenant que les constantes sont implantées !

[RAT]

Même si ce n'est pas super grave, je trouve que de plus en plus, qu'ils oublient un peu les builders, scripteurs, etc... Ce qui est gênant je trouve.

Ils font des modifs sans penser aux conséquences qu'il va arriver.

C'est tout de même dommage non?

[Taern]

En fait, c'est pas un changement totalement arbitraire.
Jusque là, le compilateur acceptait l'appel de fonctions en dehors du bloc main, mais d'après Georg Zoeller il ne les gérait "pas bien". D'où ce changement, qui est plus une sécurité qu'autre chose.
Personnellement j'avais déja eu à utiliser des appels de fonctions en dehors d'un bloc de fonction, et je n'avais pas constaté de problème. Les fonctions sont rééxécutées à chaque fois qu'on inclus le script en question (et donc les valeurs des variables sont à chaque fois recalculées) mais tout semblait bien marcher.
Enfin, on peut difficilement faire autrement que croire ce que dit bioware

Sinon il reste toujours le compilateur de Torlack

@ Prince Nexus : utilise le mot-clé "const", ça évite de créer une nouvelle variable sur la pile. Ca risque pas de changer grand chose au niveau performance, mais c'est plus propre et plus sûr.

[Cheyenne]

Citation :

Même si ce n'est pas super grave, je trouve que de plus en plus, qu'ils oublient un peu les builders, scripteurs, etc... Ce qui est gênant je trouve.

Ils font des modifs sans penser aux conséquences qu'il va arriver.

C'est tout de même dommage non?

Je suis d'accord avec toi, RAT

Certains fichiers 2DA avaient été modifiés à la hussarde entre la version 129 et 130 il me semble, et cela a entrainé plein de complications pour les builders puisque les HAK refusaient tout simplement de fonctionner correctement

Aussi, il faut voir que sortir un module "sérieux" de nos jours implique un certain suivi dans les versions, sous peine d'une forte perte de crédibilité. Suffit plus de se dire que puisque ca marche un jour (avec une version de NWN), ca marchera forcément avec la version suivante : il faut s'en assurer, ce que Bioware nous facilite vraiment pas la tâche avec leur patch messages laconiques

Bioware essaie de faire des progrès de ce côté là je pense, mais ils n'y sont pas encore tout à fait...

[RAT]

Oui, c'est vrai.

Pour vous dire à ma grande honte lol , je n'ai toujours pas acheté SOU. Et je ne sais même pas si je l'acheterai.

Alors pour l'autre ADD On je ne vous parle même pas .

Quand je vois le soucis pour certains de réactualiser tous leurs modules, voir revoir tous les scripts. (comme j'ai connu qd la db bioware est arrivé). Je trouve qu'à force les personnes vont en avoir marre, ou même à se lasser du jeu.

Mais ce n'est qu'un avis

[KzimiR666]

Citation :

Provient du message de Prince Nexus
Si ce n'est plus le cas, c'est une véritable catastrophe, et qd à ceux qui prétendent que ça ne les affectera pas, cela signifie pour leurs modules qu'ils ne sont pas très développés.

Prince Nexus, concepteur d'un module comportant plus de 100.000 lignes de code

Tu fait un module de 100 000 lignes de code et tu déclares tes constantes avec "int", "string", etc.... ???
Comme dit plus haut, "const" est un bien meilleur choix ! C'est du C ça, et ça ne viens pas de Bioware ce genre de rigueur importante dans un langage de programmation...

[Jedaï]

@ KzimiR666 > Tu ferais mieux de te renseigner un peu avant de t'attaquer comme ça à un "vétéran" du forum : le mot-clé const était illégal en NWScript avant la version 1.30 ou SOU...
De plus je te signale que en C on utilise plutôt le préprocesseur pour faire tout ça.

[KzimiR666]

Je n'attaque personne et je ne vois pas ce que ça fait que Prince Nexus soit vétéran ou non du Forum !
Cependant, je ne savais pas que const était illégal avant la 1.30, je fait donc mes plus plates excuses...

[Cheyenne]

Comme dans toute communauté "virtuelle", il y a des "casefait" et "casefaitpô" vis à vis de personnes qui "fréquent les lieux" depuis plus ou moins longtemps.

Sans vouloir en faire plus que nécessaire, puisque Kzimi s'est excusé, je pense que "Prince Nexus", même et surtout en tant que vétéran du forum, aurait pu donner un meilleur exemple :

Citation :

ou pas. Si ce n'est plus le cas, c'est une véritable catastrophe, et qd à ceux qui prétendent que ça ne les affectera pas, cela signifie pour leurs modules qu'ils ne sont pas très développés.

Prince Nexus, concepteur d'un module comportant plus de 100.000 lignes de code

1/ Prince Nexus n'avait pas compris en quoi consistait le problème au moment de son "post", la preuve en est qu'il pose la question
2/ Au lieu d'en rester à une simple demande de confirmation, il suggère implicitement que les personnes ayant postées avant lui puissent avoir tort (pourquoi pas après tout)
3/ Pour conclure, et comme pour donner plus de poids à sa critique, il "placarde" son "badge de concepteur de module de plus de 100 000 lignes", ce qui est ridicule, et plutôt... vain de sa part, sachant qu'il est toujours dans le doute lui-même.

Je ne suis pas de nature très susceptible, donc je n'y ai pas répondu. D'aucuns ont pu se sentir froissés par une telle attitude. Je me permets de répondre maintenant parce que je crois en les valeurs de courtoisie, et de tolérance, même sur des forums qui traitent de questions aussi banales que la conception d'un module NWN

Si Kzimi a fait une erreur, c'est de ne pas avoir su que l'on ne pouvait pas instancier une constante avec le mot clé "const" avant la version NWN 130. Le rappeler à l'ordre parce qu'il s'est étonné (à juste titre) d'une dérogation aux règles habituelles de tout développement structuré, surtout après que un "vétéran" du forum se soit montré discourtois en premier, me parait un peu (beaucoup) exagéré. Mais bon, à chacun son opinion...

PS : La petite histoire ne nous dit pas combien de lignes de code sont à mettre au crédit du "vétéran" du forum, et combien proviennent d'un bon vieux "copier/coller" .

[Sire Pom-pom]

Salut, un message histoire de dire que je suis toujours vivant

Citation :

De plus je te signale que en C on utilise plutôt le préprocesseur pour faire tout ça.

Jedaï a raison, le mot clé "const" existe en C mais il n'a pas le même sens. Il indique qu'une variable ne peut pas être modifiée après initialisation, aucune optimisation n'est garantie et certaines sont impossibles: une variable const est une variable au sens plein, i.e elle a une adresse, etc (ce n'est pas le cas en NWscript, un entier const est simplement "collé" dans le bite-code à chaque fois qu'il en est fait mention). En C, l'utilité de ce mot clé est donc de se prémunir contre des erreurs de programmation, essentiellement dans les prototypes de fonctions. Le "const" de NWscript est plus proche de celui du C++.