Zuweisung von Zielen bei Objekten in Urwigo

[jonny65]

Es gäbe also nur 2 Möglichkeiten.
1. Workarounds wie hier schon sinnvolle vorgeschlagen wurden

Also ich sehe es eigentlich nicht (nur) als Workaround an, sondern als wirkliche Lösung
Es ist etwas mehr Aufwand, klar, aber auf jeden Fall übersichtlicher und man hat v.a den Überblick, so daß keine ungewollten und dann unsinnige (Überkreuz) Verküpfungen entstehen und am Ende weiß man gar nicht mehr, warum jetzt der Apfel mit "Anzünden" verknüpft ist.

Noch dazu bin ICH der Auffassung : Den Wherigo schreib ich nur 1 mal in meinem Leben, da darf der Aufwand ruhig größer sein, v.a auch im Fehlerhandling (ist aber andres Thema), wo es bei den meisten Wherigos ziemlich hapert.

 

[Team Bush-Rescue]

So, hier nochmal ein Update.
Multiple-Choice-Auswahl dynamisch erstellen klingt sehr interessant!
Ich werd mir mal die DEBUG nochmal ansehen (hatte ich schon, aber damals vielleicht noch nicht genug Verständnis was da passiert).

Ich war allerdings ungeduldig und wollte weiterkommen, weswegen ich die Auswahl jetzt mit Meldung und Buttons gemacht habe, da zufälligerweise nie mehr als drei Personen in einer Zone sind, also es nur zwei Ziele geben kann.
Das war zwar ziemlich riesig, aber der Umbau ist komplett.

In der Zwischenzeit war ersthelfer auch so zuvorkommend, den Programmierer anzuschreiben.
Antwort war
"Hello,
the problem you describe is sadly a known issue of the Wherigo player (including the emulator). The Wherigo player simply sees two characters, each with its own “Gib” command, so it displays the command twice if you look at any of the affected items – one “Gib” for each character. Urwigo can’t solve this problem, since it just prepares information for the player and it is the player that interprets it this way.

One way of solving this is to further describe the command, so there is something more meaningful displayed than just two commands with the same name. For example a command “Give” for an item “Apple” can be named “Give Apple”. So if there is another item like “Carrot” there will be two commands “Give Apple” and “Give Carrot” for a character, instead of two “Give” commands that can’t be differentiated.

I hope I have helped.
Happy coding,
YourSelf"

Tja, das hatten wir ja schon selber festgestellt, aber nun wissen wir, dass nicht nur wir das Problem kennen und keinen Ausweg kennen.
Aber wir Ihr schon gelesen habt, ich habe ja inzwischen umgebaut und die Zielzuweisung komplett entfernt.

Beim Fehlerhandling hoffe ich auch gründlich gewesen zu sein Selbst bei Items, die man dem Spielablauf gar nicht mehr haben sollte, habe ich für den Fall gesorgt, dass sie einer hat und benutzt. Die Charaktere sind entsprechend "entsetzt" und "erfreut" dass der Spieler einen Glitch gefunden hat

 

[daKnut]

Ich versuche gerade mir Wissen zu Wherigos anzueignen. Ich habe die Beiträge gelesen und bin mir nicht sicher ob ich alles verstanden habe.

Ein Objekt hat einen Befehl und dieser hat bei einer Verknüpfung verschiedene Ziele.
Ein Apfel hat den Befehl gib und dieser hat die Ziele Affe und Pferd.

Dies wird im Player auch richtig angezeigt. Wählt man den Apfel gibt es den Befehl und darunter die Ziele.

Der Interpreter(Player) macht aber den Fehler das er zu den Zielen auch Rückwärts anzeigt welche Gegenstände zu den Befehlen gehören die auf sie zeigen. Dabei kann es aber immer nur einen Gegenstand geben weil ein Befehl immer genau einem Gegenstand zugeordnet ist. Daher macht diese Sichtweise keinen Sinn.

Habe ich das Problem so richtig verstanden?

 

[Team Bush-Rescue]

Ich antworte sozusagen mit einer Gegenfrage

Ein Objekt hat einen Befehl und dieser hat bei einer Verknüpfung verschiedene Ziele.
Ein Apfel hat den Befehl gib und dieser hat die Ziele Affe und Pferd.
Dies wird im Player auch richtig angezeigt. Wählt man den Apfel gibt es den Befehl und darunter die Ziele.
Der Interpreter(Player) macht aber den Fehler das er zu den Zielen auch Rückwärts anzeigt welche Gegenstände zu den Befehlen gehören die auf sie zeigen.

Bis hierhin ja. Der nächste Satz aber nicht mehr.
Ein Befehl ist immer einem Gegenstand zugeordnet ja, aber warum sollte es nur einen Gegenstand geben dürfen? Ob die Verknüpfung auch andersrum Sinn macht hängt von Item und Ziel ab.

Hast Du einen Apfel, einen Affen und ein Pferd, macht sowohl
Apfel --> gib --> Pferd als auch Pferd --> gib --> Apfel Sinn.
Willst Du aber mit einem Schwert ein Seil zerschneiden lassen macht
Schwert --> zerschneide --> Seil sehr wohl Sinn. Es würde aber auch gleichzeitig
Seil --> zerschneide --> Schwert angelegt (ohne Dein Zutun) was weniger Sinn macht.

In meinem persönlichen Fall störte mich nicht, dass die Verknüpfungen in beide Richtungen angelegt werden, sondern dass sie sich nicht zusammenfassen.
Nun die Gegenfrage: War das die Antwort auf Deine Frage?

 

[daKnut]

Ja ich denke ich habe es verstanden.

Ein Befehl ist immer einem Gegenstand zugeordnet ja, aber warum sollte es nur einen Gegenstand geben dürfen?

Es KANN nur einen Gegenstand geben. Den unter den man den Befehl angelegt hat. Man kann also vom Gegenstand über den Befehl viele Ziele sehen. Von den Zielen aus über den Befehl aber immer nur den einen Gegenstand.

Ob die Verknüpfung auch andersrum Sinn macht hängt von Item und Ziel ab.

Ja es kann aus Sicht des Spielers auch Sinn machen. Von der Programmlogik her aber nicht.
Ich wähle ein Ziel(Pferd). Wähle einen Befehl(gib) der auf das Pferd zeigt und bekomme wieder eine Auswahl. Diese kann aber immer nur einen Gegnstand zeigen. Den der den Befehl enthält.

 

[Team Bush-Rescue]

Es KANN nur einen Gegenstand geben. Den unter den man den Befehl angelegt hat. Man kann also vom Gegenstand über den Befehl viele Ziele sehen. Von den Zielen aus über den Befehl aber immer nur den einen Gegenstand.

Entweder, wir reden aneinander vorbei, oder das stimmt so nicht. Natürlich kann mein WIG so viele Gegenstände haben, wie ich möchte. Jeder Gegenstand bekommt seine eigenen Befehle zugewiesen. Wenn ich das so möchte bekommt halt jeder Gegendtand auch einen gleichlautenden Befehl (in meinem WIG kann man alle Gegenstände anschauen und geben, mit einigen noch anderes).
In dem Fall, dass Du nur einen Gegenstand betrachtest ist das, was Du sagst natürlich richtig. Aber das ist zirkuär

Ja es kann aus Sicht des Spielers auch Sinn machen. Von der Programmlogik her aber nicht.

Wohl wahr. Einer der Gründe, weswegen es als "nicht funktional" eingestuft ist

Ich wähle ein Ziel(Pferd). Wähle einen Befehl(gib) der auf das Pferd zeigt und bekomme wieder eine Auswahl. Diese kann aber immer nur einen Gegnstand zeigen. Den der den Befehl enthält.

Äh nein.
Du weist einem Gegenstand einen Befehl zu, das ist auf Programmiererseite. Du kannst dem Befehl Ziele zuweisen, das ist auch auf Programmiererseite (aber wir haben in diesem Thread gelernt, warum man das nicht machen sollte). Auf Userseite kannst Du nur Tasten drücken und in dem Falle entweder den Apfel auswählen und bekommst alle (!) ihm zugeordneten Befehle angezeigt (im Beispiel halt nur geben). Du drückst geben und kannst (wenn Du mit Zielzuweisung gearbeitet hast) die Ziele auswählen, die vorher definiert worden sind (also hier meinetwegen Affe und Pferd).
Du kannst aber sehr wohl nun auch noch ne Banane haben, für die dasselbe gilt.
Wenn Du dann nicht vom Gegenstand aus, sondern vom Pferd aus auf den Befehl geben klicktst, bekommst Du alle (!) Gegenstände angezeigt die als Ziel Pferd haben.

Zusammengefasst also: Klar, wenn Du nur ein Objekt im Spiel hast, hat auch nur ein Objekt einen Befehl und nur ein Objekt Ziele und daher die Ziele auch nur ein Objekt.
Da beißt sich der Hund in den Schwanz. Natürlich kannst Du auch zwei Objekte haben, die jeweils ein und nur ein Ziel haben. (Banane nur Affe und Apfel nur Pferd) aber dann würde es kaum Sinn haben die Zielzuweisung zu benutzen.

 

[Team Bush-Rescue]

Mir ist gerade aufgefallen dass ich Deinen Einwand vielleicht besser verstanden habe. Vielleicht sage ich es besser so:

Ich wähle ein Ziel(Pferd). Wähle einen Befehl(gib) der auf das Pferd zeigt und bekomme wieder eine Auswahl. Diese kann aber immer nur einen Gegnstand zeigen. Den der den Befehl enthält.

Nein. "Ich wähle ein Ziel" heißt übersetzt: Du befindest Dich in Deinem Rucksack und wählst ein Item an. Es hat den Befehl geben, was Du anwählst. Nun kommt die Auswahl der Ziele, in Deinem Beispiel steht da vermutlich nur Pferd, weil es nur ein Ziel gibt. Danach ist diese Aktion beendet. Es gibt keine weitere Auswahl. Es wird die Aktion ausgeführt, die Du für dieses Szenario programmiert hast, also zum Beispiel den Apfel von deinem Rucksack zum Pferd verschieben, oder einen Dialog ausgeben oder was auch immer.

Du vermischst es mit dem umgekehrten Szenario:
Du klickst auf das Pferd, bekommst Aktionen zur Auswahl (in diesem Fall vermutlich nur geben) und bekommst daraufhin alle Gegenstände zur Auswahl, die geben mit Ziel Pferd haben. Sobald Du auf einen der Gegenstände geklickt hast ist diese Aktion beendet, es gibt keine weitere Auswahl es wird die Aktion ausgeführt *blabla siehe oben copy paste*

 

[daKnut]

Wir gehen ja in beiden Fällen davon aus das der Behel "geben" unter dem Gegenstand programmiert ist und nicht unter dem Pferd. So jedenfalls in dem Fall den ich meine.

Du klickst auf das Pferd, bekommst Aktionen zur Auswahl (in diesem Fall vermutlich nur geben) und bekommst daraufhin alle Gegenstände zur Auswahl, die geben mit Ziel Pferd haben.

Genau! Diese Richtung macht in meinen Augen aber keinen Sinn. Die Auswahl von Gegenständen "die geben mit Ziel Pferd haben." ist doch überflüssig da ich zuvor eine Aktion(geben) gewählt habe die nur zu genau einem Gegenstand gehört.

Dem Spieler fällt das im ersten Moment nicht auf. Da beiden logisch erscheint. Sobald es aber nur in eine Richtung Sinn macht(Beispiel: schneiden) oder mehrere Befehle "geben" gibt wird es unlogisch. Wie ja auch glaube ich dein anfängliches Problem war.

 

[Team Bush-Rescue]

Diese Richtung macht in meinen Augen aber keinen Sinn. Die Auswahl von Gegenständen "die geben mit Ziel Pferd haben." ist doch überflüssig da ich zuvor eine Aktion(geben) gewählt habe die nur zu genau einem Gegenstand gehört.

Dem Spieler fällt das im ersten Moment nicht auf. Da beiden logisch erscheint. Sobald es aber nur in eine Richtung Sinn macht(Beispiel: schneiden) oder mehrere Befehle "geben" gibt wird es unlogisch. Wie ja auch glaube ich dein anfängliches Problem war.

Dass die Richtung (manchmal) keinen Sinn hat, will ich gar nicht diskutieren, da bin ich voll Deiner Meinung! Deswegen wäre es ja nett gewesen, wenn man das bei Bedarf abstellen kann. Kann man aber nicht, das war das Ergebnis der vorhergehenden Posts.

Eine zweite Sache ist aber, dass ich (wegen dem ersten Absatz) immernoch das Gefühl habe wir redeten aneinander vorbei. Für den Fall dass Du auf das Pferd klicken würdest, hättest Du ja vorher nirgendwo eine Aktion gewählt? Der Unterschied zwischen Apfel Pferd geben und Pferd Apfel geben ist, dass Du das eine vom Apfel aus machst (im Inventar) und das andere vom NPC aus (in "du siehst").

und was

Wir gehen ja in beiden Fällen davon aus das der Behel "geben" unter dem Gegenstand programmiert ist und nicht unter dem Pferd. So jedenfalls in dem Fall den ich meine.

angeht: Ja, das tun wir, das geht schließlich auch nicht anders. Schade, aber ist so :/

 

[daKnut]

Ich glaube so langsam auch das wir an ein ander vorbei reden. Wobei ich glaube mir meinen beide sogar das selbe sehen es nur von einer andern Sichtweise bzw. drücken uns anders aus.

Eine zweite Sache ist aber, dass ich (wegen dem ersten Absatz) immernoch das Gefühl habe wir redeten aneinander vorbei.

Das geht mir auch so aber ich bin zuversichtlich

Für den Fall dass Du auf das Pferd klicken würdest, hättest Du ja vorher nirgendwo eine Aktion gewählt?

Nein nur beim anklicken des Pferdes noch nichts. Das meinte ich aber auch nicht.

Der Unterschied zwischen Apfel Pferd geben und Pferd Apfel geben ist, dass Du das eine vom Apfel aus machst (im Inventar) und das andere vom NPC aus (in "du siehst").

Da stimmte ich dir zu das ist ein Unterschied. Für den Spieler ist dabei die Richtung egal. Vom Aufbau der Verknüpfung her gibt es aber noch einen ganz wesentlicheren Unterschied und auf den will ich hier hinaus.

Ich versuche mal so zu verdeutlichen was ich meine. Wir haben folgende Herachie:

• Apfel(Gegenstand)
  • geben(Befehl)
    • Pferd(Ziel)

Um zu verdeutlichen was ich meine müssen wir das ganze etwas erweitern:

• Apfel
  • geben(Befehl von Apfel)
    • Pferd
• Birne
  • geben(Befehl von Birne)
    • Pferd
    • Esel
  • zeigen(Befehl von Birne)
    • Pferd
    • Esel

Man sieht, hoffe ich, das einem Gegenstand ein oder mehrere Befehle zugeordnet sind und diesem wieder ein oder mehrere Ziele. Das ist der eine Weg wie von dir schon Beschrieben. Dabei haben wir im Player verschiedene Auswahl Sequenzen die dem Spieler gezeigt werden.

1. Wähle ein Gegenstand aus dem Inventory(Auswahl der Gegenstände)
2. Wähle einen Befehl des gewählten Gegenstandes(Auswahl der Befehle)
3. Wähle ein Ziel für den Befehl(Auswahl der verknüpften Gegenstände)

Gehen wir vom NPC aus würde unsere Herachie wie folgt aus sehen:

• Pferd
  • geben(Befehl von Apfel)
    • Apfel
  • geben(Befehl von Birne)
    • Birne
  • zeigen(Befehl von Birne)
    • Birne
• Esel
  • geben(Befehl von Birne)
    • Birne
  • zeigen(Befehl von Birne)
    • Birne

Hier sehen wir jetzt beim Pferd auch schon dein Problem vom Anfang des Threads und wir sehen auch warum. Es ist der Befehl je Gegenstand aufgeführt. Ist ja auch nur logisch. Befehle stehen für URWIGO in keiner Beziehung.

Jetzt wird auch der Ablauf der Sequenzen ab einem gewissen Punkt überflüsslig:

1. Wähle ein Ziel(NPC). (Auswahl eines Ziels)
2. Wähle einen Befehl der auf das Ziel verweist(Auswahl der Befehle)
3. Wähle den Gegenstand des Befehls.(Auswahl Gegenstand)

Hier ist der Punkt 3 überflüssig. Nachdem ich einen Befehl, z.B. den Befehl "zeigen"(von Birne) ausgewählt habe. Kann ja nur noch die Birne kommen.

PS: Ich finde es sehr nett mich mal mit jemand über solche Wherigo Sachen zu "unterhalten". Im "Gespräch" lernt man häufig gut dazu.

 

[Team Bush-Rescue]

Da stimmte ich dir zu das ist ein Unterschied. Für den Spieler ist dabei die Richtung egal. Vom Aufbau der Verknüpfung her gibt es aber noch einen ganz wesentlicheren Unterschied und auf den will ich hier hinaus.
Ich versuche mal so zu verdeutlichen was ich meine. Wir haben folgende Herachie:
...

Yeeehaa! Ich hab jetzt verstanden was Du sagen wolltest. Gemeint habe ich das seit meinem ersten Eintrag hier und dann auch später immer wieder Ich habe nur nicht geschafft es so vortrefflich zu beschreiben wie Du. Vielleicht wäre ich dann früher verstanden worden.

Um dann inhaltlich nochmal drauf zurück zu kommen Ja, ich finde das auch äußerst nervig. Ich hatte mich dann damit abgefunden, dass es eben drei Tiefen gibt sozusagen, weil es vielleicht nicht schick ist, aber man damit klarkommt.
Meine Lösungsideen waren eben "Befehl vom NPC aus ausschalten" bzw "ungewollte Verknüpung entfernen" aber das ging nicht.

Du wolltest mit Deinem Beispiel verdeutlichen, dass der dritte Schritt der Auswahl bei Birne überflüssig ist. Sehe ich ganz genauso. Aber das hatte mich in meinem speziellen Beispiel nicht gestört, da es bei mir so viele Objekte gibt, dass eigentich immer mehrere Sachen da stehen. Schlimmer fand ich, dass ich dann gib (von Apfel) und gib (von Birne) hatte, was dem Spieler unmöglich macht zu sehen, was was ist. Man sieht ja erstmal nur zwei (bei mir dann ggf 12) mal "gib". Dahinter steckte meine Frage nach "kann man die Befehle nicht stacken, also zusammenfassen?" Das ging aber auch nicht.

Mein nächster Lösungsversuch war, die Befehle auch so zu benennen also der Befehl von Apfel hieß "gib Apfel" und der von Birne "gib Birne". Das löste das Prolem dass man in der Auswahlliste zig Befehle hat insofern, dass man erkennen konnte, welchem Objekt der Befehl galt, aber der dritte Schritt war davon immernoch nicht weg. Semantisch gelesen also nachher "NPC --> gib Apfel --> Apfel" was auch dämlich war.

Letzten Endes habe ich eingesehen, dass diese Zielzuweisung in ihrer jetzigen Form irgendwie Käse ist. Es hat mich ein bisschen geschmerzt darauf zu verzichten, aber ich habe es nun wie folgt gelöst:

*Fanfaren*
Jeder Gegenstand hat seinen Befehl "gib", keine Zielzuweisung. Wenn der Befehl angewählt wird, geht's richtig rund. Zuerst frage ich ab, in welcher Zone der Spieler ist. Das ergibt einen achtarmigen if/else Zweig schonmal es bewirkt aber, dass es nicht vorkommen kann, dass man jemandem was geben kann, der nicht in derselben Zone ist (und verhindert, dass man schon in der ersten Zone alle NPCs in der Auswahl lesen kann).
Dann werden entsprechend der Zone die NPCs zur Auswahl gegeben und per Input abgefragt. Ich hatte das Glück, kein Multiple Choice bauen zu müssen, sondern Meldungsknöpfe verwenden zu können, da nie mehr als drei Personen inkl. des Spielers in der Zone sind (ansonsten wäre das aber auch ein bisschen zu viel geworden...).
Viele der Charaktere reagieren dann mit weiteren Abfragen zum Beispiel "hast Du die und die Aufgabe schon hinter Dir, dann beziehen sie sich darauf, sonst geben sie Tipps". Meistens ist das nur für Gag - so grummelt Dich die Schwertmeisterin halt heftiger an, wenn sie schon besiegt wurde.

Die Änderung hat mich "nur" Änderungen an insgesamt 300 Stellen im Spiel gekostet, die ich aber noch mit viel copy/paste machen konnte (Abfrage der Zonen zum Beispiel). Mit einem extra dafür angelegten multiple choice input wäre es ungleich mehr geworden, das hätte ich wirklich nicht durchgehalten

Ich finde es sehr nett mich mal mit jemand über solche Wherigo Sachen zu "unterhalten". Im "Gespräch" lernt man häufig gut dazu.

Das geht mir genauso! Ich glaube ich habe schon bei diesem einen Teil ziemlich viel gelernt, aber so trefflich wie Du im obigen Beitrag die Hierarchie geschildert hast, war mir das noch nicht gelungen.
Ich freue mich gerade auch sehr über die Erfahrung, im grünen Forum ohne geflame zu posten _obwohl_ sich hier missverstanden und korrigiert wird *staun*

Ich vermute, einiges war darin begründet, dass ich bei Dir nach einer Frage gesucht habe, weil ich dachte, es sei bereits alles beantwortet worden was offen war

 

[daKnut]

Die von dir Beschriebene Lösung klingt sehr gut. Der Aufwand ist zwar hoch aber ich habe das Gefühl das ist beim Wherigo immer so

Das schöne an deiner Lösung ist ja das man nicht die NPC sieht die später im Spiel noch vorkommen.

Ich kann mir vorstellen in LUA pur gibt es eine super einfache Lösung. Die Hoffnung daran ist jedenfalls mein Grund dafür, dass ich mich damit noch irgendwann mal auseinander setzen möchte.

Bisher kann ich weder in LUA programmieren noch weiß ich überhaupt wie die Einbindung über ÜRWIGO Funktioniert.

 

[Team Bush-Rescue]

Danke Nach all dem Hin und Her und den ganzen Problemen und dem, was ich alles erstmal verstehen musste, um zu verstehen, wie ich mein Problem nicht lösen kann, bin ich auch recht stolz drauf. Ich kann es sowas von nicht erwarten, bis er online geht
Und nun scheitert es an sowas wie Finale ist noch nicht gebaut, zugehöriger Mystery noch nicht zu Ende erdacht, Outdoor Betatest verschiebt sich immer wieder.. Ich bin so hibbelig!

Die Hoffnung auf LUA pur hatte ich auch. Ich werde schon seit einer Weile gedrängelt, mal gemeinsam eine Scriptsprache zu lernen. Bisher war der Favorit C++, aber nun habe ich triftige Gründe für LUA
Allerdings geht's mir da genau wie Dir.

Schade ist dann zu allerletzt auch, dass der Player die Möglichkeiten ja auch einschränkt. Ich habe mir sagen lassen, dass man mit LUA eigentlich so viel mehr könnte. So wie Videosequenzen und komplexere Aktionen. Ich weiß also selber gar nicht, welche Grenzen die Sprache und welche der Player auferlegen.

 

[bodenseepingu]

Also ich könnte mir durchaus vorstellen, die Problematik mit LUA relativ elegant zu lösen.

Die IF-Bedingungen um zu entscheiden, welche Objekte überhaupt sichtbar sind, die dürften über LUA in Griff zu bekommen sein - teilweise habe ich ja auch schon damit experimentiert (Koffer-Beispiel)

Eine Multiple-Choice Auswahl zu bauen über LUA, die dann genau diejenigen Items/Character anbietet, die entweder im Inventar sind oder sichtbar sind ist auch kein Problem.

D.h ich glaube durchaus daran, daß man mit Hilfe einer Handvoll von LUA-Funktionen die Objektverknüpfung quasi nachbauen kann, so dass sie dann unidirektional ist und die Objekte korrekt in einer Auswahl-Eingabe angezeigt werden.

Grundsätzlich bringt die Auslagerung von Teilen nach LUA m.E. bei komplexeren Dingen einfach enorme Aufwandseinsparung - z.b. dadurch, dass man komplexere Datenstrukturen verwenden kann, parametrisierte Funktionen hat (im Gegensatz zu den unparametrisierten in Urwigo) und an Informationen sowie Wherigo-Funktionen rankommt, die über Urwigo nicht freigeschaltet sind - viele Dinge stehen hierzu unter den LUA-Anteilen im Wherigo-Handbuch

 

[daKnut]

function PlayerZones()
	for aZone in Player.InsideOfZones do
		strZonen = strZonen  .. " " .. aZone.Name
	end
	return strZonen
end

Ich habe mal weniger aus Bedarf und mehr als "Lernprojekt" versucht die Funktion in Lua zu schreiben. Angefangen bin ich mit einer Funktion die mir die aktuelle Zones des Players wiedergeben soll. Da ich gerade erst Anfange wollte ich noch nicht das Objekt der Zone übergeben sondern erstmal nur den Namen der Zone. Ausgegeben bekomme ich leider nur

function: 0A83E918

.
Was habe ich falsch gemacht? Ich habe diese Codes schonmal irgendwo gesehen. Die Seite habe ich leider nicht wiedergefunden.

 

[bodenseepingu]

Ich würds anders machen. Player.InsideOfZones ist ja eine Table mit allen Zonen, in denen sich der Player befindet...

  for i = 1, #Player.InsideOfZones,1 do
     strzonen = strzonen .. Player.InsideOfZones[i]
  end

 

[daKnut]

Damit bekomme ich auch "functions ..." zurückgegeben. Allerdings mit einem andern Code!

 

[bodenseepingu]

sry ...natürlich noch .Name hinten dran....der Zugriff ist ja eine Zone und du willst
ja den Namen haben...

 

[daKnut]

function PlayerZones()
	strZonen = ""
	for i = 1, #Player.InsideOfZones,1 do
     		strZonen = strZonen .. Player.InsideOfZones[i].Name
  	end
	return strZonen
end

Klappt! Mit Name habe ich selber noch angefügt. Bekam dann noch einmal eine Fehlermeldung. Nachdem ich dann " strZonen = "" " eingefügt habe gings. Lag sicher daran das ich den Wert vorher nicht im Catridge initialisiert habe.

Kannst du erklären warum es mit einer For Each Schleife nicht klappt?

 

[bodenseepingu]

Die andere Methode wäre

<code>
for key, value in pairs(table)....
</code>

Die genaue Notation müsste ich jetzt nachschauen - frag mich nicht nach dem Warum - wenn du das genau wissen willst, warte ob Krolock auf den Thread reagiert - er kann dir sicher alle Möglichkeiten nennen, wie du das hinkriegst - ich nehm immer nur die, von denen ich weiß dass sie sauber auf allen Geräten funktionieren...