Autor |
Nachricht |
< Licht_in und die Geografie... |
|
Verfasst am:
So, 23 Feb 2003 - 10:50
|
|
|
Kompassleser
Anmeldungsdatum: 25.08.2002
Beiträge: 142
|
|
Liebe TAG-Leute...,
in "HDRaum"-Klasse-Räumen wie der fiktiven "Grotte" unten hängt der Name anscheinend nicht davon ab, ob Licht in _diesem_ Raum ist, sondern ob Licht "beim" Spieler ist (in Form einer getragenen Lampe). Wenn die Lichtquelle abgelegt wird, funktioniert es wie gewünscht.
Beispiel:
- Der Spieler trägt eine Lampe, ist südlich der Grotte und rennt gegen eine Wand, worauf die möglichen Ausgänge aufgelistet werden.
- Der Ausgänge-Auflister (zu 99% aus ausgang.adx übernommen) schreibt "Du kannst hier nur nach Norden (".
- Dann belegt er lraum mit dem "Nordraum", also der Grotte, und gibt ihren Namen aus.
- Dieser ist ein Ausführungsblock in der Raumklasse HDRaum, der die Aktion lichtTest aufruft, um in Erfahrung zu bringen, welchen Namen er ausgeben soll.
- lichtTest benötigt lraum, um zu wissen, in welchem Raum "Licht getestet" werden soll. Und jetzt kommt das Problem: Im Raum-mit-Spieler-drinne ist Licht, in der Grotte (bzw. dem "Nordraum" bzw. lraum bzw. xxx in der Ausgangliste-Aktion) nicht. Trotzdem wird in der Grotte "Licht gefunden" und dann natürlich der falsche Name ausgegeben.
Was hab ich diesmal übersehen? Fällt da jemandem was ein oder auf?
Code: | Aktion *
Ausf
sei lraum araum
EndeAusf
RaumKlasse HDRaum ! Klasse für halbdunkle Räume
Name Ausf
! hier kommt lraum von "außen" (Aktion * oder Ausgang-Lister),
! daselbst hier sowieso ungültig?! (versteh ich nich)
Ausf lichtTest
wenn (lFlag) dann
text 1 &lraum
sonst
text 2 &lraum
ende
EndeAusf
Besch Ausf
sei lraum daselbst
ausf lichtTest
wenn (lFlag) dann
text 3 &lraum ! Textblock für Besch's bei Licht...
sonst
text 4 &lraum ! ...und im Halbdunkel
ende
EndeAusf
Attr halbdunkel
! ...etc...
Raum Grotte (HDRaum)
! ...etc...
Aktion lichtTest
Ausf
lösche lFlag
wenn (lraum halbdunkel) dann
! Licht_in hält halbdunkel für "nicht dunkel", also
! produzieren wir (TAG-)Dunkelheit, um in ihr nach
! Lichtquellen suchen zu können:
attrHin lraum dunkel
wenn (Licht_in lraum) setze lFlag
attrWeg lraum dunkel
ende
EndeAusf
Aktion AusgangListe
Ausf
lokale ritgVar r
lokale raumVar xxx
lokal i nn
! ......snipsnap......
schleife r minRitg maxRitg
seiRaum xxx aRaum r
wenn (xxx > 0) dann
! ......snipsnap......
sei lraum xxx
wenn (r > NW) dann
Text 'nach [r] ([xxx])/'
sonst
Text 'nach [R] ([xxx])/'
Ende
Ende
Ende
! ......snipsnap......
EndeAusf
block 1 | Raumnamen bei Licht
1 'Erleuchtete Grotte/'
! ...etc...
block 2 | Raumnamen im Halbdunkel
1 'Finstere Grotte/'
! ...etc...
block 3 | Raumbeschreibungen bei Licht
1 'Du bist in einer supertollen, erleuchteten Grotte.'
! ...etc...
block 4 | Raumbeschreibungen bei Halbdunkel
1 'Du steckst in einer finsteren Grotte.'
! ...etc... |
|
|
|
|
|
|
Verfasst am:
Di, 25 Feb 2003 - 11:55
|
|
|
Kompassleser
Anmeldungsdatum: 25.08.2002
Beiträge: 142
|
|
Ally hat folgendes geschrieben: |
in "HDRaum"-Klasse-Räumen wie der fiktiven "Grotte" unten hängt der Name anscheinend nicht davon ab, ob Licht in _diesem_ Raum ist, sondern ob Licht "beim" Spieler ist (in Form einer getragenen Lampe). Wenn die Lichtquelle abgelegt wird, funktioniert es wie gewünscht.
|
Ach, ist ja auch egal. Lass ich das Programm halt erst dem Spieler heimlich seine Beleuchtung klauen, dann die Raumnamen ausgeben, dann die Lichtquellen zurückgeben. Blöder Workaround, naja. |
|
|
|
|
|
Verfasst am:
Di, 25 Feb 2003 - 12:34
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
So wie du das beschreibst scheint mir Licht_in nicht richtig zu funktionieren, weil es immer denkt, der Spieler sei im passenden Raum.
Das muss ich mal checken. Da zeigt sich wieder der Nachteil, dass viele Dinge einfach so 'fest verdrahtet' sind. (Und nicht genügend geprüft.) _________________ Every silver lining has a cloud. |
|
|
|
|
|
Verfasst am:
Di, 25 Feb 2003 - 13:01
|
|
|
Kompassleser
Anmeldungsdatum: 25.08.2002
Beiträge: 142
|
|
Martin hat folgendes geschrieben: | So wie du das beschreibst scheint mir Licht_in nicht richtig zu funktionieren, weil es immer denkt, der Spieler sei im passenden Raum.
Das muss ich mal checken. Da zeigt sich wieder der Nachteil, dass viele Dinge einfach so 'fest verdrahtet' sind. (Und nicht genügend geprüft.) |
Mach dir nichts draus, sowas passiert immer, wenn ich ein neues Autorensystem ausprobiere... kann natürlich auch sein, daß ich Licht_in nicht kapiert habe. |
|
|
|
|
|
Verfasst am:
Di, 25 Feb 2003 - 13:53
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
Ally hat folgendes geschrieben: | Mach dir nichts draus, sowas passiert immer, wenn ich ein neues Autorensystem ausprobiere... |
Du darfst in Zukunft alle neuen Releases testen...
Ally hat folgendes geschrieben: | kann natürlich auch sein, daß ich Licht_in nicht kapiert habe. |
Ich glaube immer noch, dass Licht_in einfach falsch ist. Im Moment wird es an einer Stelle verwendet, bei der mir der Fehler nie aufgefallen ist: Wenn der Spieler von einem Raum in den anderen geht, muss mindestens einer der beiden Räume hell sein. Das wird mit Licht_in geprüft. Ist der jetzige Raum hell, in dem der Spieler ist, ist es aber egal, ob die Dunkelheit im zweiten Raum richtig oder falsch ausgewertet wird. Ist es im momentanen Aufenthaltraum dunkel, hat der Spieler keine Lampe bei sich und die Auswertung im Zielraum wird korrekt durchgeführt.
Licht_in wird auch im "Raum, der in der Mitte ein Gitter hat" (Handbuch, Kap. 14.3) verwendet. Dort müsste man die Fehlfunktion eher sehen können. _________________ Every silver lining has a cloud. |
|
|
|
|
|
Verfasst am:
Di, 25 Feb 2003 - 18:32
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
Genau, Licht_in macht Murks, wie du schon vermutet hattest. Ich habe mal den folgenden Test in Karn eingebaut:
Code: |
Bef lumen
Name 'Lumen'
Verb 'lumen'
Ausf
lokale Raumvar xRaum
Schleife xRaum
Text '[xRaum]:'
wenn (Licht_in xRaum) dann
Text 'hell[x]'
sonst
Text 'dunkel[x]'
Ende
Ende
EndeAusf
|
Dann wird deutlich, dass die Besitztümer des Spielers in jedem Raum mitgezählt werden. Ich habe es (hoffentlich) gefixt:
http://www.martin-oehm.de/tag/tam20.zip _________________ Every silver lining has a cloud. |
|
|
|
|
|
Verfasst am:
Di, 25 Feb 2003 - 19:36
|
|
|
Kompassleser
Anmeldungsdatum: 25.08.2002
Beiträge: 142
|
|
Hmm... leider bleibt es diesmal _dunkel_, wenn der Spieler die Lichtquelle trägt. Erst, wenn sie abgelegt wird, wird es hell. Immerhin gilt das jetzt unabhängig davon, ob der Spieler im "lichtgetesteten" Raum ist oder nicht.
Ich habe mal einen ganz "normal" dunklen Raum eingebaut, sowie dein lumen-Verb.
Code: |
raum testraum2
name 'Testraum2'
besch 'Bist im zweiten Testraum.'
std keinweg
w testraum
attr dunkel
>nimm lampe
Du hast nun die Lampe.
>lumen
...
Testraum2: dunkel
>lege lampe ab
Du hast die Lampe hingelegt.
>lumen
...
Testraum2: hell
|
Trotzdem kann man auch dann, wenn der Raum angeblich dunkel ist, mit L die Besch abfragen und herumspazieren, ohne die "Du stolperst umher"-Nachricht zu kriegen.
In halbdunklen Räumen bekommt man die "halbdunkle" Besch, solange man die Lampe nicht ablegt. |
|
|
|
|
|
Verfasst am:
Di, 25 Feb 2003 - 23:10
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
O.K., der Quickfix war wohl etwas vorschnell. Das Problem ist erkannt, aber noch nicht gelöst. Da ist wohl noch etwas Überlegung notwendig. So ein Mist! Naja, immerhin wieder was gelernt: Schnelle Lösungen sind meist nicht von Dauer.
Ich hab die alte Version wieder hochgeladen. _________________ Every silver lining has a cloud. |
|
|
|
|
|
Verfasst am:
Mi, 26 Feb 2003 - 6:15
|
|
|
Kompassleser
Anmeldungsdatum: 25.08.2002
Beiträge: 142
|
|
Danke für die Bemühungen jedenfalls. Wenigstens kann ich so davon ausgehen, daß es nicht (nur) an meinem Code liegt... |
|
|
|
|
|
Verfasst am:
Do, 6 März 2003 - 22:41
|
|
|
Experte
Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München
|
|
Ich habe gerade eine neue Version der T.A.M. hochgeladen, die den Licht-Bug (hoffentlich) fixt. Das Lumen-Beispiel hat bei mir jedenfalls in Karn funktioniert. Außerdem ist der Vokabular-Bug, der in Tanans Namens-Thread angesprochen wurde, repariert:
http://www.martin-oehm.de/tag/tam20.zip _________________ Every silver lining has a cloud. |
|
|
|
|
|