Oui, d’où l’avantage des tags 
On peut en faire une archive « à la main ».
Je pense qu’il faut qu’on fige une version 2.3 de la lib francophone pour qu’elle remplace les anciennes versions sur les divers sites où l’on peut télécharger une ancienne version.
Pour cela, il faut :
- reporter les modifications de la version de travail French.h + FrenchG.h vers la version 1PSP (ou mieux, fusionner les deux fichiers)
- reporter les modifications de la version I6 vers la version I7 (dans l’idéal fusionner aussi les versions).
Je vais commencer par essayer de fusionner les deux version I6, Otto peux-tu nous dire ce qu’impliquerait une fusion entre les fichiers pour I6 et I7 ? (à coup de #define et #ifdef etc… j’imagine).
oui je pense que cela se fait avec des #ifdef etc, mais je ne sais pas si cela poserait d’autres problèmes par la suite. Je ne sais pas pourquoi d’ailleurs la version anglaise de I6 n’a pas été mise à jour à partir de la version modifiée, s’ils ont mis des #ifdef c’était bien pour utiliser avec I6, à moins que cela serve pour la seconde phase de compilation, lorsque cela repasse en compilation I6, je ne sais pas trop.
Pour ma part j’ai supprimé le fichier FrenchG1PSP qui était redondant. FrenchG.h devrait fonctionner pour tous les temps et toutes les personnes, il ne contient plus de texte (j’ai déporté les petits bouts de texte qui traînaient vers French.h et French1PSP.h).
Pour ma part je considère la partie « I6 » prête, ne restent que :
- des tests à faire
- éventuellement rendre la version 1PSP plus neutre car là elle est clairement dans la tonalité de lieux communs et pas comme son nom le laisse penser une simple adaptation au passé et à la première personne.
Je n’ai pas encore fusionné les deux fichiers French.h et French1PSP.h (j’ai cependant utilisé meld pour les comparer et reporter ce qu’il fallait de l’un à l’autre, j’espère ne rien avoir oublié) mais à terme c’est ce qui devrait être fait je pense pour en faciliter la maintenance. Déjà la fusion des FrenchG est un bon pas, j’espère qu’on pourra faire de même pour I7.
Dans ce cas il faudra peut-être réorganiser l’archive pour mettre les fichiers I6 et I7 dans le même dossier ?
Cela risque d’apporter de la confusion quand on ne saura plus quels fichiers inclure pour I6 ou I7 si les deux sont mélangés (quoique, avec un bon LISEZMOI…).
En revanche, si on pouvait fusionner FrenchN11.h avec French.h, et FrenchGN11.h avec FrenchG.h, et mettre des liens symboliques à la place dans le répertoire I7 (ou simplement préciser dans le readme que la version I7 requiert les fichiers de la version I6), ce serait plus simple à maintenir.
Je suis en train de comparer les fichiers « N11 » et les fichiers pour I6, mais il y a pas mal de choses que je ne comprends pas donc je préfère ne pas toucher.
Bonjour,
à la place de :
[ LanguageContraction text; !ou version ultérieure
if (text->0 == ‹ a › or ‹ A › or ‹ à › or ‹ À › or ‹ â › or ‹ Â › or ‹ ä › or ‹ Ä ›
|| text->0 == ‹ e › or ‹ E › or ‹ é › or ‹ É › or ‹ è › or ‹ È › or ‹ ê › or ‹ Ê › or ‹ ë › or ‹ Ë ›
|| text->0 == ‹ i › or ‹ I › or ‹ î › or ‹ Î › or ‹ ï › or ‹ Ï ›
|| text->0 == ‹ o › or ‹ O › or ‹ ô › or ‹ Ô › or ‹ ö › or ‹ Ö ›
|| text->0 == ‹ u › or ‹ U › or ‹ û › or ‹ Û › or ‹ ü › or ‹ Ü ›
|| text->0 == ‹ h › or ‹ H ›) return 1;
return 0;
];
pourquoi pas :
[ LanguageContraction text;
if (text->0 >127) rtrue;
if (text->0 == ‹ a › or ‹ e › or ‹ i › or ‹ o › or ‹ u › or ‹ h ›
or ‹ A › or ‹ E › or ‹ I › or ‹ O › or ‹ U › or ‹ H ›) rtrue;
rfalse;
];
Les caractères de la Table 2B (page 519-520 inform6.pdf) sont soit des voyelles accentuées, soit des caractères improbables en début de mot. Dans tous les cas, il est possible de les tester par intervalles, puisque un grand nombre se suivent. C’est probablement mieux que des « or » à la chaîne.
Si cela pose des problèmes il est possible d’affiner et de multiplier les intervalles.
La routine peut être encore plus compacte, mais là n’est pas le propos.
Pour la routine enleve_accents le test de caractère > 127 accélère la routine :
for (i = 2 : i < 2+buffer->1 : i++){
if (buffer->i > 127){
switch (buffer->i){
‹ à ›,‹ â ›,‹ ä › : buffer->i = ‹ a ›;
‹ è ›,‹ é ›,‹ ê ›,‹ ë › : buffer->i = ‹ e ›;
‹ î ›,‹ ï › : buffer->i = ‹ i ›;
‹ ô ›,‹ ö › : buffer->i = ‹ o ›;
‹ ù ›,‹ û ›,‹ ü › : buffer->i = ‹ u ›;
‹ ÿ › : buffer->i = ‹ y ›;
‹ ç › : buffer->i = ‹ c ›;
}
}
}
@tokenise buffer parse;
Plus compacte :
[LanguageContraction text;
return (text->0 >127 || text->0 == ‹ a › or ‹ e › or ‹ i › or ‹ o › or ‹ u › or ‹ h › or ‹ A › or ‹ E › or ‹ I › or ‹ O › or ‹ U › or ‹ H ›)
];
bonjour, et bienvenue 
pour ces questions, je ne saurais répondre, qu’en pense Stormi ?
Hum, pourquoi pas, à condition de commenter avec précision les fonctions en question car ce >127 est très obscur si on ne sait pas à quoi il se réfère. En particulier pour la fonction LanguageContraction, l’équivalence entre « >127 » et « voyelles accentuées ou caractères improbables en début de mot » peut difficilement être devinée.
Il est en effet probable que tout cela accélère certains traitements, mais concrètement il me semble que même dans leur forme actuelle ces fonctions ont une durée d’exécution assez négligeable. LanguageContraction est rarement exécuté plus d’une fois par « tour », de même que EnleveAccents.
Par ailleurs si à l’avenir la table des caractères devait changer (passage en tout utf-8 d’inform par exemple) il ne faudrait pas oublier de revoir tout ça.
En bref, je ne sais pas
Bienvenue sur le forum, auraes !! 
Si jamais tu souhaitais te présenter (dire comment tu as connu l’IF et ce forum, par exemple…), tu pourrais le faire dans ce sujet. Aucune obligation, bien sûr .
Je m’aperçois qu’il y a eu deux autres nouveaux récemment sur le forum auxquels je n’ai pas encore souhaité la bienvenue ; je vais le faire.
bonjour,
En réponse à : (passage en tout utf-8 d’inform par exemple)
Inform supporte l’Unicode unsigned 16-bit. Je vois pas bien le rapport avec l’Utf8.
je ne comprends pas bien la logique du support - ou pas, des accents.
Dans FrenchG.h:
Pourquoi le support de la préposition <à> alors que tous le reste et sans accents.
Verb ‹ sortir › ‹ de › ‹ la ›/‹ là › ! ajout de <là>
support du mot
Verb ‹ fermer › ‹ à ›/‹ a › ‹ cle ›/‹ clef › ! ajout de
Je ne comprends pas le sens de cette expression sans la préposition :
Verb ‹ fermer › noun ‹ à ›/‹ a › ‹ cle › held → Lock
Attention, si les accents sont supprimés avec un <dé> à jouet ou à coudre et une <lé> (largeur étoffe) et autres…
Je ne suis pas sûr que de vouloir tout résoudre par la grammaire (tenter notamment d’être exhaustif au niveau des prépositions) soit la meilleure approche.
Je serais tenté, au contraire de simplifier au maximum la grammaire. Inform veut, au niveau du Parser des information de type :
< Actor (,) Action Noun Second>
les articles, pronoms, prépositions et autres ne font que lui compliquer la tâche - ET CELLE DU CONCEPTEUR DE JEU, et du joueur.
Pourquoi ne pas tenter, au niveau de la fonction "[ BeforeParsing;]; " de lui simplifier au maximum la tâche.
Suppression des articles, gestions des accents, remplacement des pronoms par les noms qu’il représentent, et cætera .
Il est aussi possible de gérer beaucoup d’exceptions, particularités et difficultés de la langues au niveau des Objets.
Bonne remarque. À l’heure actuelle nous sommes obligés de mettre les prépositions sous les deux formes (avec accent et sans accent), et on a tendance à en oublier. L’idéal serait que seule la forme avec accents suffise, mais je ne sais pas comment faire en sorte qu’inform accepte ça sans modifier les libs de base. Si tu as une suggestion je suis preneur !
OK, corrigé sur le svn.
Ok, corrigé sur le svn, avec ajout également de « clé ». Il faut noter que cette ligne de grammaire sert très rarement mais elle ne fait pas de mal là ou elle est.
Moi non plus 
=> Je vire cette ligne inutile.
Je n’ai pas testé mais il y a des chances que tout ne fonctionne pas bien en effet. Si tu as des suggestions…
Là je ne te suis plus. Les articles sont déjà supprimés par LanguageToInformese, il me semble, et les pronoms gérés là aussi (imparfaitement, mais déjà pas mal). Par ailleurs les prépositions, dans la version anglaise aussi, sont parfois indispensables pour différencier différents sens d’un même verbe.
Exemple :
Verb 'repondre' 'dire' 'crier' 'hurler'
* -> ParlerIncorrect ! dire (d'accord mais quoi...)
* creature -> ParlerIncorrect ! dis-lui (d'accord mais quoi...)
* 'à'/'a'/'au'/'aux' creature -> ParlerIncorrect ! dire à toto (d'accord mais quoi...)
* 'de'/'d^' topic -> ParlerIncorrect ! dire de partir (d'accord mais à qui...)
* creature 'de'/'d^' topic -> AskTo ! dis lui de faire ça
* 'à'/'a'/'au'/'aux' creature 'de'/'d^' topic -> AskTo ! dire a toto de faire ça
* creature topic -> Answer reverse ! dis-lui bonjour
* 'à'/'a'/'au'/'aux' creature topic -> Answer reverse ! dire a toto bonjour
* topic '->'/'à'/'a'/'au'/'aux' creature -> Answer; ! dire bonjour à totoSans les prépositions, comment faire la différence entre AskTo et Answer ?
J’avoue avoir du mal à voir ce que cela apporterait concrètement, peux-tu essayer de nous le faire comprendre avec des exemples ?
Ce que je veux dire, c’est qu’il faudrait éviter ça:
Verb ‹ aller › ‹ marcher › ‹ courir › ‹ passer › !! fuir suivre emprunter franchir
* → VagueGo
* ‹ au › ‹ sur › ‹ luy › → GoUp ! « aller au-dessus » → « aller au sur luy »
* ‹ au ›/‹ en › ‹ sous › ‹ luy › → Godown ! « aller au-dessous » → « aller au sous luy »!! entrer ?
* ‹ à ›/‹ a ›/‹ au ›/‹ en ›/‹ vers ›/‹ par › noun=ADirection → Go ! (Go déclenche des bugs sans noun=ADirection)
* ‹ à ›/‹ a ›/‹ au ›/‹ en ›/‹ vers ›/‹ par ›/‹ dans ›/‹ sur ›/‹ sous › noun → Enter
* noun=ADirection → Go
* noun → Enter;
‹ Aller › supporte cinq actions différentes! plus les synonymes. Cela n’a pas de sens. Il faut faire des choix.
Il faut impérativement créer un Manuel/Mode d’emploi/Règles de référence des jeux If-français. Et indiquer d’en l’entête du jeu si il est compatible ou pas avec ce Manuel de référence.
*** LE CONCEPTEUR AINSI QUE LE JOUEUR DEVRONT S’Y CONFORMER. ***
On peut discuter des heures sur l’usage de tell, talk, ask…et leurs ambigüités mais si le joueur (ET LE CONCEPTEUR - j’insiste) savent que pour parler à un personnage je dois saisir :
<parler à < Objet_x >
ou
<parler à < Objet_x > de <…> , cela simplifie grandement les choses.
Jouer ou créer un jeu de fiction interactive Française est très décourageant.
Une règle (norme) pourrait améliorer la situation de manière significative.
( verb ‹ aller › * ‹ à ›/‹ a ›/‹ au ›/‹ en ›/‹ vers ›/‹ par › noun=ADirection → Go (Ne peut-on pas remplacer toutes ces prépositions par ?)
peut être simplifier par :
Si Verbe == ALLER
Si Noun == ADirection
Alors Action == Go
Peut importe, dans ce cas la préposition. Je peux tout effacer.
Les prépositions peuvent êtres gérer au niveau des « grammar tokens » .)
Question : pourquoi ? J’ai du mal à voir où est le problème avec ce verbe (ok, les deux lignes avec luy sont douteuses mais ne font de mal à personne car concernent des formulations rarement utilisées, et on peut utiliser les verbes monter et descendre pour ces actions).
Peux-tu me donner un exemple concret d’une situation (du point de vue de l’auteur et du point de vue du joueur) où cette grammaire va poser problème ?
Et si l’auteur veut ajouter de nouveaux verbes ou de nouvelles formulations il n’est plus compatible ? Le jeu français que j’ai préféré, La cité des eaux, utilise des verbes supplémentaires, mais tout est clair car c’est expliqué dans l’introduction.
Actuellement en quelque sorte le manuel de référence « de fait » c’est ce qu’accepte la grammaire de FrenchG.h, mais n’importe quel auteur a le droit de modifier cela à sa guise. C’est de sa responsabilité si les formulations qu’il a choisies ne sont pas claires pour le joueur (cependant tout jeu qui se respecte se doit d’arriver avec une petite aide qui précise ce genre de choses).
C’est déjà le cas. On peut utiliser ces formulations. Mais on peut en utiliser d’autres aussi. À l’auteur de choisir comment ses personnages réagissent quand on leur parle, et s’il souhaite traiter les actions Answer,Tell,Ask,ParlerSansPrecision (un de nos ajouts, qui n’existait pas dans la version anglaise) de la même manière (rien ne l’empêche d’ailleurs de surcharger la grammaire du verbe parler pour la simplifier s’il le souhaite).
La question du dialogue avec les PNJ est l’une des plus difficiles, quelle que soit la langue. On ne peut pas imposer une manière de faire au détriment des autres. Certains utilisent des menus, d’autres juste la formulation « parler à untel », d’autres (comme ce que j’ai fait dans mon petit jeu « ascenseur ») préfèrent qu’on précise le sujet duquel on veut parler.
En fait tu voudrais que les choses soient plus simples pour le concepteur, mais en simplifiant les choses à l’extrême pour qu’il n’y ait qu’une manière de dire telle ou telle chose. Pour moi le joueur aura encore plus de mal.
Il est toujours possible de faire une proposition, mais j’avoue être dubitatif.
Je t’encourage à tester la grammaire « aller * topic » pour Go. Nombreux bugs en perspective si on ne surcharge pas la méthode « officielle » GoSub…
Il se peut que je sois trop « impliqué » pour être objectif, mais j’ai l’impression que tes propositions vont dans le sens inverse du développement de la fiction interactive actuelle, toutes langues confondues.
Inform est un langage de programmation.
La programmation tend vers une programmation de type P.O.O.
Encapsulation, protections des méthodes et des données…
Bien loin d’un bricolage/bidouillage du code et il y a de nombreuses et bonnes raison à cela.
Voila, c’est tout. Bon courage.
Inform et « implicit taking »:
- Une petite chose étrange:
Je crée un lieu avec un coffre de type container open openable lockable.
je mets la clé qui ouvre le coffre dans ce même coffre et je saisie .
Résultat:
Lock coffre
(with the coffre)
(first taking the coffre)
First you’ll have to close the coffre.
Et me voila avec un coffre dans mon inventaire?
Bon, il est vrai que lock doit être utiliser avec ‹ with ›.
Quoique seul, sans me semble correcte.
2.J’en reviens à ce qu’Inform appelle « implicit taking »:
Si une bannane est dans un lieu et que je saisie ,
si la bananne est « prenable » il la prend implicitement. Et si elle est « mangeable », je la mange. Ok, c’est plutôt logique.
Mais si cela concerne une clef, je trouve cela plutôt ennuyeux.
Si je saisie <déverrouiller coffre avec clef> sans avoir la clef qui est dans ce même le lieu cela fonctionne.
*
2.1 Si je veux ouvrir un coffre qui est verrouillé et si la clef est dans mon inventaire,
je dois: <déverrouiller coffre avec clef> &
Alors que pourrait déverrouiller le coffre implicitement et l’ouvrir puisque j’ai la clef sur moi.
De même pour verrouiller un objet ouvert:
pourrait fermer le coffre implicitement et la verrouiller.
Hé bé, tu sautes d’une idée à l’autre sans transitions, c’est dur à suivre. Quel est le rapport avec les commentaires précédents ?
Juste pour que les choses soient claires, inform ce n’est pas de nous, c’est de Graham Nelson. Nous nous sommes contentés d’adapter inform à la langue française.
Si tu cherches un vrai langage objet je te conseille de t’orienter vers TADS 3 plutôt qu’inform : tads.org/tads3.htm (je suis moi-même en train d’apprendre ce langage qui devrait plus convenir à tes exigences en matière de programmation. La traduction en français reste totalement à faire cependant).
De mon avis, inform n’est pas un langage « moderne », il a de sérieuses limitations dans ses fondements. Cependant il est relativement simple à apprendre et fonctionnel.
Non, pas s’il a les attributs « fixed » ou « scenery ».
Si tu ne peux pas « prendre » la clef cela ne fonctionnera pas, la grammaire définit que l’objet doit être tenu pour pouvoir déverrouiller (held). En fait je n’ai rien compris au problème que tu veux décrire.
Le manuel d’inform traite de ces questions. TADS semble gérer ce genre de choses beaucoup mieux, je crois vraiment que c’est le langage qu’il te faut.
Il me semble que la présence d’un attribut fonctionnel ~fonctionnel (cassé ou pas) serait le bienvenue. Surtout qu’il pourrait intervenir dans de nombreux verbes de base.
Un object de type:
« openable », si cassé ne pourrait être ouvert,
"switchable’, ne pourrait être activé,
"supporter’, si la table est cassé je ne peux rien mettre dessus,
« clothing », déchiré ne pourrait être porté,
« talkable »…
le verbe ‹ réparer › pourrait être ajouté en complément de cette attribut.
Il est bizarre que l’on ne puisse pas <Examiner … >(examiner object avec loupe). Ceci dit, beaucoup de verbes pourraient supporter cette préposition.