[I7] Multiporte, levier, et objets dans une autre pièce

Bonjour,
ceci est mon tout premier message sur le forum, j’ai découvert Inform7 grâce au tutoriel de farfadin sur le Site du Zéro.
J’ai donc tout naturellement voulu me lancer dans la création d’une fiction interactive. D’abord en bidouillant des choses dans des petits « projets » pas destinés à être aboutis. Mais maintenant que je me suis familiarisé un peu mieux avec le langage (avec l’aide extrêmement utile du Handbook de Jim Aikin) j’ai décidé de me lancer dans un projet sérieux et surtout codé proprement.
Aussi avant de commencer à rédiger l’aspect purement narratif de ma fiction j’ai décidé de poser les mécaniques du jeu et ses aspects techniques. J’ai déjà mis au point avec succès de nouveaux types (kind) d’objets ainsi que de nouvelles actions associées (en respectant la logique des Check, Carry out, Report). Bien entendu je suis confronté à des petits tracas que vous saurez j’espère éradiquer :mrgreen:

Le problème principal, dont j’ai parlé sur le site du zéro (farfadin m’a d’ailleurs répondu je l’en remercie mais ses solutions sont assez lourdes à gérer), concerne la création d’une porte spéciale. J’aimerais créer une porte qui soit présente dans une pièce tout au long du jeu mais qui puisse mener à différents endroits selon l’état de la partie. Qu’à un moment donné elle mène de la pièce A à rien, qu’au suivant elle mène de A à une pièce B, puis ensuite à C, puis de nouveau à A, etc. Cette porte particulière devrait bien entendu être visible dans les deux pièces qu’elle relie.
Farfadin a suggéré la création d’un sous type de background afin de rendre visible à plusieurs endroits un tel objet. Malgré mes efforts je ne suis parvenu à déplacer cette porte sans générer d’erreur.

Voici la définition du type.

A stargate is a kind of backdrop. It has a room called the origine. It has a room called the destination that varies.

(Non je ne fais pas de fiction autour de la série Stargate :laughing: )

A chaque changement de destination d’une de ces portes je comptais faire un « move porte to the destination of porte » suivi d’une mise à jour de la position des décors mais inform me dit que je ne sais pas utiliser les décors correctement. Certes ce n’est certainement pas pour ce genre de choses qu’ils ont été incorporés au langage mais je vois difficilement comment faire.

Mes recherches ont été infructueuses pourtant je ne pense pas être le premier à être confronté à cela.

Mon second problème concerne la création d’un type levier. Voici mon code.

[code]A lever is a kind of thing. It is usually fixed in place. It can be pushed or pulled. It is usually pulled.

Instead of pushing when the noun is a lever :
if the noun is pushed begin ;
say « [The noun] est déjà enfoncé[if the noun is female]e[end if]. »;
stop the action;
otherwise ;
now the noun is pushed;
say « Vous enfoncez [the noun]. »;
end if.

Understand « enfoncer [something] » as pushing.

Instead of pulling when the noun is a lever :
if the noun is pulled begin ;
say « [The noun] est déjà tiré[if the noun is female]e[end if] vers vous. »;
stop the action;
otherwise ;
now the noun is pulled;
say « Vous tirez [the noun] vers vous. »;
end if.
[/code]

Cela fonctionne très bien mais ça ne me semble pas être très propre (utilisation abusive de instead).
Mais si je suis le schéma classique du check, carry out, report. Etant donné qu’un levier est fixé sur place, tirer ou pousser ne va même pas jusqu’au check mais est arrêté avant par le fait que pousser ou tirer, ça ne marche pas pour les objets fixes.

J’ai donc pensé à créer de nouvelles actions pushingL et pullingL, distinctes des pull et push, qui concernent uniquement les leviers. Avec donc des check, carry out, et report.
Et simplement faire des « Instead of pulling when the noun is a lever : try pullingL. ». Comme ça si j’ai des exceptions à faire sur des leviers particuliers je mettrai mes « instead » sur les « pullingL » et non pas sur les « pulling when the noun is a lever ».

Est-ce une solution convenable ? Y a-t-il plus propre ?

Enfin, troisième question. Comment gérer l’affichage de certaines propriétés entre parenthèses du style « boite à questions (ouvert) », « machine à laver (éteint) ». Comment donc pouvoir empêcher leur affichage ou à l’inverse instaurer mon propre affichage (par exemple pour peaufiner mon type levier en indiquant si un levier donné est tiré ou enfoncé).

Voilà. Je pense avoir fait le tour de mes interrogations actuelles (et oui il y en a d’autres auxquelles je ne pense pas à l’instant). En espérant que vous puissiez m’aider et que je puisse affirmer :

Now ma lanterne is lit.

Salut, et bienvenue !

Tout d’abord je tiens à préciser que je ne connais pas forcément tous les mécanismes d’Inform 7, qui permet beaucoup de subtilité. En général j’ai une utilisation assez basique, voire « bidouille ».

Pour les questions pointues, tu peux poser la question (en anglais), sur la liste de diffusion RAIF, où passent des pointures spécialistes de ces sujets :

groups.google.com/group/rec.arts … ion/topics

Pour la première question, je pense qu’il faut oublier l’idée de faire une porte customisée, car les portes ont un style assez précis et cadré, si bien que si tu essayes de les modifier, tu vas te casser les dents dessus. Imagine ta porte comme une boite magique, que tu pourras déplacer à loisir, et dont les propriétés seront modifiées selon le lieu. Le changement de pièce du joueur lorsqu’il entre dans cette porte/boîte pourra être géré par « move player to… »

Pour la deuxième question, je dirais que si cela fonctionne, c’est pas vraiment un problème, et la propreté dépend du point de vue. La première méthode est verbeuse, mais est lisible et claire. La seconde utilise une technique plus évoluée (check, carry out…), mais le verbe pullingL je ne trouve pas cela super propre (selon mes propres critères bien sûr), même si cela semble efficace.

Pour la dernière question, regarde ici :
siteduzero.com/forum-83-4865 … l#r4798337

On gère cela avec la formule « omit contents in listing. » par exemple

Rule for printing the name of the levier: say "[if levier is pulled]Un levier abaissé[otherwise]Un levier[end if]."; omit contents in listing.

(à la réflexion je ne suis pas certain que contents in listing concerne également l’état des objets, mais regarde le chapitre 17.10 et suivant du manuel à ce sujet des personnalisations de l’affichage des objets, à l’occasion je regarderai cela, mais il me semble que les lampes et compagnies n’affichent pas leur état par défaut, comme pour les contenants)

Pour la première question, j’ai trouvé un sujet sur RAIF qui m’a l’air de concerner le même problème. Je ne connais pas Inform 7, je ne peux donc pas juger si ça peut t’aider ou non, mais au cas où…

ils ont l’air d’arriver à la même conclusion :slight_smile:

Pour le type levier ça me semble également un peu dommage de devoir créer une action artificielle. N’y a-t-il pas moyen de dire à Inform d’oublier tout ce qu’il sait sur l’action push et l’action pull lorsqu’il s’agit d’un levier ?
(Si je tiens tant que ça à utiliser des check, carry out, report c’est aussi pour pouvoir continuer de me servir de règles before, after, et des try silently)

Pour ce qui est du omit contents in listing ça fonctionne à la perfection ! Et en mettant un say « [the printed name of the objet] », on peut toujours modifier le nom affiché plus tard. C’est vraiment parfait. Merci.

Enfin pour les portes et bien c’est vraiment dommage qu’il n’existe pas de solution directe. Je vais continuer d’expérimenter des solutions et dès que je trouve mon bonheur je viens vous le dire.

[EDIT]

J’ai vraiment un peu honte. Je viens de trouver la solution à mon problème de porte. Il suffisait simplement de bouger la porte (qui au passage n’en est pas une) puis de bouger le joueur (dans l’autre sens ça ne va pas car la description de la porte n’apparait alors pas puisque le joueur arrive avant elle).

Au final la version brouillon donne ça :

[code]The emptyroom is a room.

PIECEA is a room.
PIECEB is a room.
PIECEC is a room.

A stargate is a kind of thing. It is always fixed in place and pushable between rooms.
A stargate has a room called the origine. The origine of a stargate is usually the emptyroom.
A stargate has a room called the destination. The destination of a stargate is usually the emptyroom.

The pt is a stargate in creation-0. The origine of pt is creation-0. The destination of pt is PIECEA.

Instead of entering a stargate :
if the location is the origine of the noun begin;
move the noun to the destination of the noun;
move the player to the destination of the noun;
otherwise;
move the noun to the origine of the noun;
move the player to the origine of the noun;
end if.

Instead of jumping :
if the location is the origine of the pt then now the destination of the pt is PIECEB.[/code]

Bon maintenant il faut gérer les directions, les ouvertures, fermetures, verrouillages, etc :confused:

Essaye sur la liste RAIF, parce que je n’utilise pas assez check, carry out, report pour voir comment utiliser tout cela ensemble.

Tu peux regarder aussi du côté des rulebooks, ex chapitre 18.7 mais je ne maîtrise pas trop non plus ce sujet.

J’ai trouvé comment faire « oublier » ce qu’on veut quand on veut à Inform. Il suffit de lui dire au moment opportun, par exemple lors du « Check pulling a lever » d’ignorer les règles habituelles par un « ignore the can’t push what’s fixed in place rule ». Pour ma porte interdimensionnelle j’avais besoin que l’action d’entrer (entering) ne fasse pas s’afficher « Vous entrer dans… » lors du report, cette règle d’affichage s’appelle « standard report entering rule », il a suffit de l’ignorer momentanément.

J’espère que ça sera utile à d’autres qui seraient confrontés au mêmes problèmes que moi. J’ai lu la partie de la documentation sur les Rulebooks et les Activities. Ces deux notions ont réellement l’air d’être très puissantes. Dommage qu’elles soient si peu appréhendables, je n’y comprends quasiment rien :neutral_face: c’est très frustrant.

félicitations alors :slight_smile:

Oui, cela me dit quelque chose maintenant, j’avais vu cela vaguement dans les exemples et j’ai dû recopier cela dans un jeu.

J’avais lu en détail le manuel lors de la première version d’Inform 7 il y a quelques temps, et pour les sorties suivantes je suis moins allé dans les détails.

Cela n’a pas tardé. Me voici avec une question encore pire que les précédentes !

Voilà donc ce qui me bloque maintenant. Vous allez finir par croire que je recherche absolument la complexité mais tans pis je me lance :blush:
J’ai mon joueur dans une pièce. Dans une autre pièce il y a des objets. Je cherche à créer une action qui puisse, quand tapée dans la première pièce, reconnaitre les objets de la seconde.
Ce n’est pas du tout pour faire la chose suivante mais cet exemple illustrera mon propos. Imaginons que nous souhaitions gérer une machine dans un aéroport qui nous ramène un bagage donné (une action ramener qui s’applique à un bagage). Les bagages seraient stockés dans une autre pièce, un autre lieu de l’aéroport.
Appelons Terminal la pièce du joueur et Entrepôt le lieu de stockage des bagages.
Tricher en plaçant les bagages dans le terminal et les rendre invisible et inexaminables ne conviendrait pas car il faudrait également que le joueur, plus loin dans la partie puisse entrer en personne dans l’entrepôt.

Ne me tapez pas :smiling_imp:

alors ça c’est relativement facile normalement :

After deciding the scope of the player while in the Aeroport: place the Remise à bagages in scope. 

Après, tu peux rajouter des attributs différents à ces objets, pour par exemple n’autoriser que de les prendre, et pas les toucher, sentir etc.

Par exemple dans un jeu j’ai fait un attribut « reacheable », actif par défaut, et j’avais indiqué ce code :

[code]A thing can be reachable. A thing is usually reachable.

Taking something not reachable is acting OutOfReach. Pushing or pulling or touching or rubbing or turning or tasting or smelling or searching or cutting or switching on or switching off or opening or closing or squeezing or burning or kissing or waving or entering something not reachable is acting OutOfReach.

Instead of acting OutOfReach:
say « C[']est hors de portée. ». [/code]

(tu pourras donc retirer le premier « taking something not reachable… » dans ton cas)

Et quand on sort de la remise à bagage (si on a moyen d’y entrer physiquement, sinon on peut le faire à l’initialisation du jeu) on peut indiquer : « now everything in Remise à bagages are not reachable; » et faire l’inverse quand on sort un tel objet.

Regarde le manuel chapitre 17.27 pour en savoir plus sur ce sujet.

Parfait, ça marche au poil :exclamation: Merci beaucoup.

EDIT : Fausse joie. Je dois faire une fausse manip.
J’ai mon action que l’on va appeler acting (de commande « agir sur »). Une pièce A où je suis, une pièce B où est un objetX.
J’ai mis un « After deciding the scope of the player when acting : place the pieceB in scope. »

Si dans A je fais « agir sur objetX » alors on ne me renvoie aucun refus mais une ligne est sautée, je n’ai pas le texte que j’ai programmé pour s’afficher et ce que l’action est sensée faire n’est pas fait.

Si dans B je fais « agir sur objetX » alors tout fonctionne, j’ai bien mon texte pour l’action et elle fait ce que je lui ai demandé.

Tu devrais montrer ici tout ton code, cela serait plus simple.

C’est pas garanti que cela fonctionne si tu changes la condition (ici tu demandes à mettre en scope quand on fait quelque chose, et même après, donc c’est pas sûr que la mise en scope fonctionne comme il faut). Mais même en indiquant cela, chez moi cela ne place rien en scope. Scope c’est la vue donc, normalement on peut voir, mais rien faire d’autre, sauf à faire une exception.

Et autant placer l’objet en scope dès qu’on entre dans la pièce.

Chez moi ça marche par exemple :

[code]Nest is room.

oeuf is in nest.

Branche is a room. feuille is in Branche. Branche is down from nest.

After deciding the scope of the player while in nest: place branche in scope.
[/code]

mais je peux juste faire « x feuille », les autres commandes me répondent que je ne peux atteindre ce qui est sur la branche.

Finalement je m’en suis sorti autrement. En cherchant sur le Google Groupes que tu m’avais indiqué plus haut je suis tombé sur un message de l’auteur du « Handbook » qui disait qu’une action pouvait s’appliquer à n’importe quoi en dehors du champ de vision pourvu qu’on mette que l’action s’applique à one VISIBLE thing. Et qu’on remplace le « [something] » des understand par des « [any thing] », l’exemple donné est celui d’une action « penser à » qui peut s’appliquer à tous les objets rencontrés en jeu.
Tu as raison ça devait être parce que je souhaitais faire autre chose que regarder. Le scope doit être intimement lié à l’action examining.