J’ai l’impression d’avoir parlé dans le vent, j’ai répondu à tous les points ce serait poli de faire de même.
Si tu mets ‹ chef › et ‹ orchestre › dans la propriété name ça fonctionne il me semble. Tu aurais un exemple ? Bien sûr si tu mets ‹ chef d’orchestre › dans une propriété name ça ne peut pas marcher vu que c’est plusieurs mots, mais je suppose que ce n’est pas ce que tu fais 
Edit: sinon moi j’utiliserais de toutes façons l’extension adjectifs.h afin de mettre orchestre en adjectif et donner ainsi la priorité à l’orchestre lui-même si le joueur écrit « regarder l’orchestre ». Extension pour I6 : gestion des adjectifs pour le parser
Je pense que la modification est utile, mais pas pour le « chef d’orchestre » d’Otto. C’est utile si on a un personnage qui s’appelle par exemple « G’hadpak », afin que son intégrité soit conservée. En revanche pour chef d’orchestre je persiste : mettre « d’orchestre » dans le name serait au mieux inutile (vu que ça marche déjà), au pire dangereux (si l’auteur oublie de mettre aussi « orchestre » tout seul dans le name). Et puis ça me choque de considérer que « d’orchestre » est un seul mot alors que c’en est deux et donc très logique de les séparer tout le temps (quitte à ensuite ignorer le premier, comme c’est le cas).
Edit : à la relecture, pour les tirets aussi ça pourrait être utile (je le mets au conditionnel), mais de la même manière marginale : pas pour le cas général, comme grand-père, qui est déjà bien géré de toute manière (tant qu’on ne fait pas la bêtise de le mettre dans le name tel quel), mais pour des cas particuliers où le tiret ferait vraiment partie du nom. Et encore, supposons que le personnage s’appelle « G’had-pak », eh bien vous aurez intérêt à mettre dans le name « G’had » et « pak » et pas « G’had-pak » tout seul (sauf si vous tenez absolument à ce que le joueur l’écrive en entier). Cela me semble cependant plus dangereux qu’autre chose. Si quelqu’un avait une implémentation qui par la simple déclaration de « grand-père » serait à même de comprendre à la fois grand-père, grand et père, alors ce serait réellement utile (mais à mon avis ça impliquerait de modifier beaucoup de choses voire même des libs d’inform)
Concrètement : est-ce que quelqu’un a un exemple où ce serait utile dans l’état de la proposition d’auraes (qui je le rappelle consiste à ne pas couper les mots s’ils sont dans le dictionnaire) ?
D’où l’on cause du grand-père…
Fais l’équivalent avec les librairies sans mes modifications : on comparera !
http://auraes.free.fr/inform6/
[code]!% -C1
!% +language_name=nFrench
Include « Parser »;
Include « VerbLib »;
!/*
! Corrigé et ajout de père Noël.
!*/
Object room with description « ROOM » has light;
Class Filiation
with
parse_name [ w n swn;
swn = wn;
while (NextWord() == self.name) n++;
if (n) return 10;
wn = swn;
w = NextWord();
wn–;
while (NextWord() == ‹ arriere › or ‹ grand › or ‹ noel › or ‹ pere ›) n++;
switch (self){
pere: if (n == 1) return 10;
pereNoel: if (n == 2 && w == ‹ pere ›) return 10;
gPere: if (n == 2 && w == ‹ grand ›) return 10;
agPere: if (n == 3) return 10;
}
return 0;
],
description [; "C’est ", (name) self, « . »; ],
has animate male proper
;
Filiation agPere « mon arrière-grand-père » room
with
name ‹ arriere-grand-pere ›,
;
Filiation gPere « mon grand-père » room
with
name ‹ grand-pere ›,
;
Filiation pere « mon père » room
with
!name ‹ pere ›,
;
Filiation pereNoel « le père Nöel » room
with
name ‹ pere-noel ›,
;
! ----------------------------------------------------
[ Initialise;
location = room;
];
! ----------------------------------------------------
Include « FrenchG »;
! ----------------------------------------------------
[/code]
Je vais avoir l’air de le faire exprès, mais je ne comprends pas ce que cet exemple montre comme progrès. Je pense qu’accompagner l’exemple d’une explication serait utile pour moi, mais peut-être aussi pour d’autres.
Edit : quand je disais « Si quelqu’un avait une implémentation qui par la simple déclaration de « grand-père » serait à même de comprendre à la fois grand-père, grand et père » je ne demandais pas une implémentation par des cas particuliers en dur (cf. parse_name dans l’exemple), mais bien une gestion côté lib permettant que « aaa-bbb » soit développé en, au choix de l’utilisateur, « aaa », « bbb » et « aaa-bbb ».
Auraes, par effet de bord, je voulais aussi parler d’une modification du comportement habituel de la bibliothèque, ce qui serait perturbant pour les auteurs voulant recompiler leurs jeux actuels, et qui se retrouveraient avec des soucis qu’ils n’avaient pas auparavant, comme l’a montré Stormi.
On est d’accord : pour le « à », c’est une plaie de devoir taper « a/à » à chaque fois. Mais c’est déjà un comportement habituel, pas un effet de bord lié à une modification d’autre chose. Si ça peut être amélioré, tant mieux.
Pour les tirets, j’avais même oublié qu’il fallait écrire les mots-composés dans 2 mots différents. Si tu as pu améliorer les bibliothèques pour permettre de comprendre un mot composé entré directement dans le code, c’est très bien et ça sera utile à tout le monde, mais en contrepartie, il faudrait que ça puisse garder également la façon de faire précédente, même si elle n’est pas idéale.
Serais-tu donc en train de réaliser un jeu ?
Ces modifications m’intéressent, car ça concerne également inform7, en revanche je pense que ce type de modification devrait être intégré directement dans les bibliothèques générales d’Inform, et non pas faire ça au coup par coup pour chaque langue, il faudrait donc faire un rapport de bogue sur le site d’inform7.
Enfin, pour l’histoire du « d’orchestre », c’est fâcheux de ne pouvoir l’entrer ainsi, parce que justement Inform7 encourage à entrer le nom le plus précis pour l’objet [ici ça serait « The chef d’orchestre is a man in salle de concert »]. Mais ici, on peut interagir avec lui que si on tape « x chef orchestre » ou « x chef ». J’ai donc dû écrire :
The chef is a man in salle de concert. Understand "chef orchestre" or "chef d orchestre" as chef. The printed name of Chef is "chef d[']orchestre".En comparaison pour une viole de gambe is suffit d’écrire « The viole de gambe is in salle de concert »…
Pour l’exemple du grand-père, le fait que cela oblige à coder en dur une définition supplémentaire ne rend pas la chose aisée à utiliser.
De plus en faisant l’essai avec les modif d’Auraes, si j’écris dans un jeu « sous-bock », le joueur ne pourra pas le manipuler s’il tape « > x sous bock » (ce qui est un raccourci facile à faire, pour écrire plus vite)
Dans l’idéal, il faudrait que la bibliothèque permette d’écrire ceci du côté de l’auteur :
Object truc1 "aaa-bbb" Room
with
name 'aaa-bbb'
ou
Object truc1 "aaa-bbb" Room
with
name 'aaa' 'bbb'
et du côté du joueur que cela l’autorise à écrire ces formes :
aaa-bbb
aaa
bbb
aaa bbb
(ceci quelle que soit la forme écrite plus haut par l’auteur)
La lib actuelle le permet déjà, c’est ce que je me tue à vous dire 
Le joueur qui tape « aaa-bbb », eh bien ça le décompose en « aaa » et « bbb », ce qui matche ton objet.
Edit : en relisant je comprends mieux : tu veux donner les deux possibilités à l’auteur. Je suis pas un grand fan de « deux méthodes pour accomplir la même chose », du moins dans le cadre de I6, je trouve ça confusant (et en admettant que ce soit possible, déjà)
Oui, devant autant de réticence… j’avais compris. Mais pour les nouveaux arrivant, c’est pénible.
!? Ah ! Enfin… Il y a aussi ‹ là › et peut être d’autres. C’est une plaie et c’est surtout incohérent.
Je regarde comment adapté inform6 pour un parser de type VERB+NOUN; VERB+NOUN+SECOND c’est trop galère, de mon point de vue, à jouer mais surtout pour concevoir un jeu. J’ai très rarement l’occasion d’être devant un ordinateur - là c’est exceptionnel. Mais pour faire un jeu, un papier et un crayon… Donc, je vais essayer mais avec un parser VERB+NOUN et mes librairies.
Bon, là je comprends pas tout. Je ne connais pas inform7. J’avais regardé le code source de « Le Temple nâga », et c’est étonnement lisible.
Je ne comprends pas bien le problème avec l’apostrophe : S’il n’est pas coupé, dès la saisie, parce qu’il est dans le dictionnaire, tu ne peux pas faire quelque chose comme : Understand « chef d’orchestre » ou Understand « chef d[']orchestre » ?
Mais ça ne t’oblige à rien du tout !!! ? [code]!% -C1
!% +language_name=nFrench
Include « Parser »; Include « VerbLib »;
Object room with description « ROOM » has light;
Object sousbock « sous-bock » room
with
name ‹ sous › ‹ bock › ‹ sous-bock ›
;
[ Initialise; location = room; ];
Include « FrenchG »;[/code]
Mais c’est exactement ce qu’apporte les modifications !?
Au risque de me faire ignorer une fois de plus : non, tout ce qu’apportent les modifications c’est la possibilité de déclarer « sous-bock » seul dans le name et que l’utilisateur puisse taper « regarder sous-bock ». Sauf que ça ne matche ni « sous » ni « bock », donc on doit rajouter « sous » et « bock » dans le name comme avant. Avec la lib actuelle « regarder sous-bock » était déjà reconnu car « sous-bock » était décomposé par le parser en « sous » et « bock », donc au final on ne gagne pas grand chose voire même rien du tout. Ça alourdit même la déclaration.
Essayez donc le même code avec la lib actuelle (y compris le « sous-bock » supplémentaire dans le name si vous voulez, mais il est inutile), le résultat pour l’utilisateur sera identique. Toutes les formes seront reconnues.
Je repose donc ma question : quel gain cette modification apporte-t-elle concrètement ?
Afin de bien me faire comprendre.
Avec la lib actuelle :
!% -C1
Include "Parser"; Include "VerbLib";
Object room with description "ROOM" has light;
Object sousbock "sous-bock" room
with
name 'sous' 'bock'
;
[ Initialise; location = room; ];
Include "FrenchG";La même chose avec la version modifiée :
!% -C1
!% +language_name=nFrench
Include "Parser"; Include "VerbLib";
Object room with description "ROOM" has light;
Object sousbock "sous-bock" room
with
name 'sous' 'bock' 'sous-bock'
;
[ Initialise; location = room; ];
Include "FrenchG";Le résultat est identique dans les deux cas.
pour un auteur, le plus simple est quand même de n’avoir à indiquer que la forme telle qu’on l’écrit d’habitude en français.
Devoir écrire les différentes variantes « sous » « bock » et « sous-bock » pour que cela prennent en compte tout ce que le joueur peut avoir l’idée de taper, c’est fastidieux et inévitablement ça va mener à oublier de le faire à un moment ou un autre.
pas forcément, parce que l’auteur peut prendre la solution qui lui semble la plus logique. Et si on fait abstraction de l’historique de la syntaxe, si on doit en retirer une des deux, la plus logique serait de garder ‹ sous-bock › et de retirer ‹ sous › ‹ bock ›.
Admettons, manque plus qu’une implémentation qui marche et sans effets négatifs
Sauf que tu coupes : ‹ dix-sept › ‹ dix-huit › ‹ dix-neuf ›, ‹ nord-est › ‹ sud-est › ‹ nord-ouest › ‹ sud-ouest ›.
Le fonctionnement de ma routine enleve_tirets() :
– Elle ne coupe pas les mots qui ne sont pas dans le dictionnaire;
– Elle ne coupe les mots du dictionnaire, que si le suffixe est présent le dictionnaire.
‹ grand-père ›, qu’il soit ou pas dans le dictionnaire n’est pas coupé.
‹ donne-lui › est coupé, parce que le suffixe ‹ -lui › est dans le dictionnaire.
Mais ce n’est pas une question de tiret ou pas, c’est une question de cohérence, de compréhension et de lisibilité des librairies.
Ah ! bon !? parce ce que grand-père,en français, tu l’écris grand père !?
Ce n’est pas ce qu’il a dit. Il a dit qu’il faudrait pouvoir ne mettre que ‹ grand-pere › dans la propriété name sans avoir à en plus rajouter ‹ grand › et ‹ pere › pour couvrir tous les cas.
Personnellement, si je peux apporter ma contribution : sachant qu’il ne faut pas pénaliser le joueur si il a la flemme d’écrire les tirets (si le système n’est pas flexible, c’est mort pour attirer plus de monde), et sachant que les bêta-tests sont très longs et éprouvants et qu’on oublie toujours des synonymes évidents, la solution proposée actuellement me va - sauf si quelqu’un trouve un moyen d’implanter l’ajout automatique au dictionnaire et à l’attribut name de l’objet les deux parties séparées par le tiret…
Je comprends que les bibliothèques Inform ne sont peut-être pas optimales et peut-être pas cohérentes (et dans ce dernier cas de figure il faut faire de la doc), mais en tant qu’auteur et en tant que joueur, si ça marche et que la règle est lisible et qu’on peut s’en souvenir rapidement c’est tout ce que je demande !
Rajouter de la doc : il n’y en a pas assez ! Et pour expliquer quoi ?
Que nord-est devient nordest, sud-ouest sudouest…
Qu’il faut éviter de mettre les accents pour les verbes et les mots du dico mais qu’il faut obligatoirement le faire pour ‹ à ›
Que la gestion en interne des quantités de 1 à 20 ne fonctionnera pas pour dix-sept, dix-huit et dix-neuf, parce qu’ils ont été coupés.
Que la table des pronoms est fausse et ne fonctionne pas correctement… (et je n’évoque même pas ‹ luy › !?)
Que 'je 'et effacé en premier mot mais pas ‹ tu › ‹ nous › ‹ vous ›.
Que la possibilité de donner des ordres n’est pas prise en compte dans les bidouillages de la saisie…
Que des fonctions de LanguageLM ont été désactivées…
etc, etc, etc.
Qu’elle est cette logique qui consiste a casser ce qui est correct pour le remplacer par quelque chose qui ne l’est pas !?
si ‹ nord-est › alors ‹ nord › ‹ est › (Ce qui est correct devient incorrect !?)
Pourquoi pas :
Si ‹ nord › ‹ est › alors ‹ nord-est › (Ce qui est incorrect devient correct.)
On trouve aussi ce genre de choses, rien de grave mais symptomatique, tout ce code pour rien, parce que la variable enleveaccents est déclarée mais pas utilisée :[code]global enleveaccents=1;
[ AccentsOnSub;
! enleveaccents=0;
« Les accents ne seront pas éliminés de chaque commande reçue. (fontion désactivée…) »;
];
[ AccentsOffSub;
! enleveaccents=1;
« Les accents seront éliminés de chaque commande reçue, mais seulement pour
les mots qui sinon ne seraient pas compris.(fontion désactivée…) »;
];
Verb meta ‹ accents ›
* → AccentsOn
* ‹ on › → AccentsOn
* ‹ off › → AccentsOff;
[/code]
Je ne sais pas comment vous allez pouvoir faire la transition vers la librairies 6/12, qui pourtant apporte des corrections de bogues et pour le français une bonne gestion de l’article l’ dans les propriètès, qui pour l’instant insère une espace entre l’apostrophe et le mot.
Bon, tout cela n’a pas grande importance, d’autant que je n’utilise pas ces librairies. Mais pensez un peu aux joueurs et surtout à ceux qui voudraient essayer de créer, avec cet outils génial qu’est Inform, sans être rapidement découragés.
La question suppose que quelqu’un aurait fait exprès de créer des bugs. Piètre image des gens que tu as là.
S’il y a des bugs, il faut qu’on les corrige bien entendu. Mais pas sans précautions. C’est très facile, en particulier dans le cadre d’inform, d’introduire des régressions en voulant bien faire. Tu l’as toi-même constaté. Donc si à partir de maintenant la discussion pouvait devenir un peu moins agressive et plus « travail en équipe », je pense qu’on y gagnerait tous.