• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

[Urwigo] Best Practice

daKnut

Geocacher
Ich plane einen Wherigo zu erstellen bei dem der Spieler möglichst viele Entscheidungen treffen kann. Dazu gucke ich mir gerade den URWIGO Builder etwas genauer an. Wie es oft so ist führen auch dort viele Wege nach Rom. Ich habe im Titel kein konkretes Problem genannt da ich plane, sofern das ok ist, hier für Standard Elemente ein kleines Brainstorming zu "Best Practice" Lösungen zu starten. Würde mich freuen wenn sich User mit Interesse beteiligen und die andern keine Troll Beiträge verfassen ;)
 
OP
D

daKnut

Geocacher
Ich hab auch direkt eine Frage. Ich möchte dem Spieler die Möglichkeit geben innerhalb der Zone in der er sich befindet aufzunehmen bzw. abzulegen.

Dazu habe ich mir schon 2 Lösungswege überlegt.

Das Aufnehmen ist dabei jedesmal gleich:
file.php

Damit kann der Gegenstand egal in welcher Zone er liegt aufgenommen werden.

Beim Ablegen habe ich nun zwei Ideen. Die eine funktioniert leider nicht. Die andere scheint mir nicht wirklich gelungen.

Version mit Fehler:
Hierbei ist der Befehl mit keinem Objekt verknüpft.
file.php
Legt der Spieler einen Gegenstand ab soll dieser anschließend in der Zone liegen in der sich der Spieler befindet. Dazu wollte ich das Element "Aktuelle Zone" nutzen. Leider bekomme ich dabei einen Fehler:
file.php

Version 2:
Ich verknüpfe den Befehl "ablegen" mit allen Zonen. Frage dann das Befehlsziel in einer Wenn/Dann über alle Zonen ab und agiere entsprechend. Meiner Meinung nach nicht besonders schön. So müsste ich auch abfangen das der Gegenstand nicht abgelegt wird wenn das Befehlsziel nicht die Zone ist in der sich der Spieler befindet. Außerdem finden sich dann bei den Gegenständen unter dem Befehl alle Zonen und unter der Zone auch die abzulegenden Gegenstände.

Mischung:
Möglich sehe ich auch eine Mischung. In dem ich in Version 1 nicht "bewegen in Aktuelle Zone" verwende sondern erst den Namen der Zone auslese(AktuelleZone.Name) und daraufhin wieder eine große Wenn/Dann. Wenn AktuelleZone.Name = Zone1 Dann bewegen nach Zone 1 usw.

Lässt sich Version 1 umsetzen? Wie bekomme ich den Fehler weg? Gibt es noch weitere evtl. einfachere Wege auf die ich bisher nicht gekommen bin?

Freue mich auf euer Feedback.
 

Anhänge

  • Gegenstand aufnehmen.PNG
    Gegenstand aufnehmen.PNG
    22,9 KB · Aufrufe: 1.413
  • Gegenstand ablegen mit Fehler.PNG
    Gegenstand ablegen mit Fehler.PNG
    23,6 KB · Aufrufe: 1.413
  • Fehler.PNG
    Fehler.PNG
    42 KB · Aufrufe: 1.413

jonny65

Geomaster
Mmmhh, da fehlt mir jetzt der Sinn einen Gegenstand "irgendwo" abzulegen und "irgendwo" zu nehmen. Wenn ich in einer Werkstatt(zone) bin, nehm ich die Taschenlampe und benutz sie in der Zone "Brunnenschacht". Wieso sollte ich die jetzt irgendwo ablegen, v.a wenn ich sie erst noch benutzen muss ? Die verschwindet zwecks Übersicht beim Zonenexit des Brunnens wenn man hier die Aufgabe gelöst hat. Also ich kann dazu nix sagen, weil ichs so nie gemacht habe. Was ist "Aktuelle Zone" und was weist du der zu ?
Aber wenn du sinnvolle Beispiele hast, die auch 100% funktionieren, kannst du sie im Wherigo Handbuch platzieren (www.das-wherigo-handbuch.de) Das ist ja u.a auch dafür gemacht um genau das zu verhindern, daß im Forum zig unauffindbare zerfledderte Beiträge mit Beispielen rumschwirren.
Wir könnten noch ne Kategorie "Praxisbeispiele" aufmachen, wo jeder gute Module aus seinen Wherigos einstellen kann. Die jetztigen sind ja in erster Linie Basis/Grundwissen/-elemente.
 
OP
D

daKnut

Geocacher
Der Sinn
Meine Idee dahinter ist, dass a) der Spieler viele Freiheiten hat. Er kann verschiedene Aktionen ausführen die nicht alle zielführend sind. Kein Klick-und -Go Wherigo. b) auf der programmier Seite vermeiden große Wenn/Dann Funktionen zu schreiben die ich bei neuen Zonen wieder anpassen muss. c) Ein wildes Userinterface vermeiden die druch Objektverknüpfungen entstehen können.

Über das Objekt "Aktuelle Zone" weiß ich nicht besonders viel. Es gibt dazu einen kurzen Eintrag in dem von dir erwähnten Handbuch. Über das Objekt kann ich zb. den Namen der Zone abfragen in der sich der Spieler befindet. Weiter habe ich noch nichts getestet.

Anbei noch ein Bild von weitern Objekten dieser Klasse:
file.php
 

Anhänge

  • Aktuelle Objekte.jpg
    Aktuelle Objekte.jpg
    26,3 KB · Aufrufe: 1.330

WhitePawn

Geocacher
daKnut schrieb:
Der Sinn
Meine Idee dahinter ist, dass a) der Spieler viele Freiheiten hat. Er kann verschiedene Aktionen ausführen die nicht alle zielführend sind. Kein Klick-und -Go Wherigo. b) auf der programmier Seite vermeiden große Wenn/Dann Funktionen zu schreiben die ich bei neuen Zonen wieder anpassen muss. c) Ein wildes Userinterface vermeiden die druch Objektverknüpfungen entstehen können.
....

Versetze Dich doch mal in die Lage des Spielers: Er hat in der Werkstatt eine Taschenlampe aufgenommen (um mal das Beispiel von Johnny65 aufzugreifen). Wir er sie ablegen, wenn er sie bisher nicht benötigt hat bzw. durch die Geschichte in irgendeiner Form dazu veranlasst wird? Ich glaube nicht.
Nach der Beschreibung bisher, wird es wohl darauf hinaus laufen, daß der Spieler ein recht großes Inventar mit sich rumschleppt. Denn wozu sollte ich einen Gegenstand ablegen wollen, wenn ich ihn später evtl. noch brauche.

Ich versteh natürlich den Wunsch nach einem möglichst freien Spiel, hätte aber an Deiner Stelle Bedenken, daß der Schuß nach hinten losgehen kann. Wenn man dann im Brunnenschacht ist und die Lampe bräuchte, sie aber vorher abgelegt hat, kann das sehr ärgerlich sein - besonder wenn man danach schon mehrmals gespeichert hat.
 

bodenseepingu

Geomaster
Hallo,

kann es sein, dass der Absturz dann auftaucht, wenn der Spieler noch nicht in einer Zone war - ich hab ja den Beitrag im Wherigo-Handbuch zum Thema Aktuelle Zone geschrieben - das was im LUA-Code passiert ist, dass die globale Variable "aktuelle Zone" beim Enter in jede Zone gesetzt wird. Wenn natürlich der Spieler noch nie in einer Zone war ist die Variable "nil" - dass da dann ein LUA Fehler kommt überrascht mich nicht.

Abhilfe könnte evtl. eine Initialisierung sein, dass "aktuelle Zone" bei Spielstart einfach mal auf irgendeine Zone gesetzt wird.

Ansonsten - Urwigo-Cartridge bzw. extrahiertes Beispiel anstatt Screen-Shots hier zu publishen hilft ein bisschen mehr, wenn der ein- oder andere reinschauen will - die Screenshots neigen meist dazu, dass man die falschen Stellen sieht - und man kann sich das generierte LUA nicht anschauen.

Ich weiss jetzt nicht, ob aktuelleZone beim Exit auf nil gesetzt wird...also irgendeine Fehlerbehandlung muss da rein - und wenn es nur die Überprüfung ist, ob aktuelle Zone nil ist oder nicht
 

bodenseepingu

Geomaster
....ja - das Verhalten ist Interessant...

Man kann ohne Probleme aktuelleZone benutzen und den Namen der Zone verwenden, aber
es scheitert im Moment daran, tatsächlich einen Gegenstand dort abzulegen...muss ich mir
noch näher anschauen...
 
OP
D

daKnut

Geocacher
Philosophisch:
Es müsste natürlich sichergestellt werden, dass etwas wichtiges wie eine Taschenlampe ohne die ich nicht weiter komme nicht abgelegt wird. Anders sehe ich dies aber mit Dingen die den Wherigo nur ausschmücken. Ich kann mir allerdings schon vorstellen das es Spieler gibt die auch eben eine Funktion nutzen "nur weil es sie gibt".
Sicher ist das "zurücklassen" von Gegenstände nicht die beste Art ein Spiel frei zu gestalten und ich habe auch kein konkretes Beispiel in dem ich dies zwingend benötige. Könnte mir aber das ein oder ander schon vorstellen. Es muss sich auch niemand gezwungen fühlen an einer Lösung mitzuarbeiten wenn er das ganze nicht für sinnvoll hält. Ich danke aber auch für die Warnungen die irgendwo dahinter stecken Müll zu programmieren. Ich wüsste aber gerne wie ich es realisieren könnte wenn ich einen sinnvollen Einsatz finde!

Fachlich:
Ich habe ein paar kleine Test gemacht und habe folgendes Verhalten festgestellt.

Aufbau:
2 Zonen.
Spieler bei Start in keiner der Zonen.
Spieler hat Gegenstand mit dem AktuelleZone.Name ausgegeben wird.

Versuch1:
Führe ich die Abfrage direkt nach dem Start aus(Spieler nicht in Zone) wird der Name der Zone ausgegeben die ich zuerst angelegt habe(Zone1)!
Führe ich die Abfrage aus wenn ich in der Zone1 bin bekomme ich Zone1 ausgegeben.
Gehe ich in Zone2 bekomme ich weiterhin Zone1 ausgegeben.

Das Objekt AktuelleZone wurde also scheinbar am Anfang mit der zuerst erstellten Zone initialisiert. Wird aber nicht beim betreten einer Zone neu definiert.

Versuch2:
Ich habe hinter dem globalen OnEnter hinterlegt das eine Nachricht("Zone betreten") ausgegeben wird.

Führe ich die Abfrage direkt nach dem Start aus(Spieler nicht in Zone) wird der Name der Zone ausgegeben die ich zuerst angelegt habe(Zone1)!
Gehe ich in Zone1 bekomme ich die Meldung "Zone bereten". Führe ich anschließend meine Abfrage aus bekomme ich den Namen der Zone in der ich bin(Zone1).
Gehe ich nun zur Zone2 bekomme ich beim betreten wieder die Meldung "Zone betreten". Führe ich anschließend die Abfrage aus bekomme ich Zone2 als antwort. Also die Zone in der ich gerade wirklich bin.

Die Zone wird also neu definiert wenn ein Event von ihr ausgelöst wird.

Dies weicht allerdings von deinen ersten Erfahrungen ab bodenseepingu!

Ein Test Cartridge lade ich später noch hoch!
 

bodenseepingu

Geomaster
Also ich mach das so, dass ich für solche Fälle in LUA reinschaue.

Da wirds dann interessant...

folgendes steht bei meiner Test-Cartridge drin:

Code:
function objAktuelleZone:OnStart()
end
function objAktuelleZone:OnRestore()
end
function objTestzone1:OnEnter()
	currentZone = "objTestzone1"
	_Urwigo.GlobalZoneEnter()
end
function objTestzone1:OnExit()
	currentZone = "objTestzone1"
	_Urwigo.GlobalZoneExit()
	objTestgegenstand1:MoveTo(objTestzone2)
end
function objTestzone2:OnEnter()
	currentZone = "objTestzone2"
	_Urwigo.GlobalZoneEnter()
end
function objTestzone2:OnExit()
	currentZone = "objTestzone2"
	_Urwigo.GlobalZoneExit()
	objTestgegenstand1:MoveTo(objTestzone1)
end
function objTestgegenstand1:Oncmdablegen(target)
	objTestgegenstand1:MoveTo(currentZone)
end
function objTestgegenstand1:Oncmdaufnehmen(target)
	objTestgegenstand1:MoveTo(Player)
end
function _Urwigo.GlobalZoneEnter()
	_Urwigo.MessageBox{
		Text = "Du betrittst jetzt die Zone: ".._G[currentZone].Name
	}
end
function _Urwigo.GlobalZoneExit()
	_Urwigo.MessageBox{
		Text = "Du verlasst jetzt die Zone: ".._G[currentZone].Name
	}
end

Was man deutlich sieht, wenn man über Urwigo auf den Namen der aktuellen Zone zugreift, dann
erzeugt Urwigo ein Konstrukt _G[currentZone].Name.


currentZone ist gemäß obigem Code ein String und nicht das Zonen-Objekt, das genau ist das Problem.

Die Lösung des Problems ist allerdings auch angegeben - die Zone muss mit _G[currentZone] angesprochen werden können - also muss hier vermutlich ein LUA benutzerdefinierter Ausdruck her...
wo auch immerdie Table _G herkommt, das hab ich jetzt noch nicht herausfinden können...

...und da wirds auch gleich problematisch - Urwigo frisst beim MoveTo keinen benutzerdefinierten Ausdruck - da wird man über ne LUA-Zeile arbeiten müssen...d.h. dem Gegenstand eine Kennung verpassen und das Move-Statement selber schreiben...
 
OP
D

daKnut

Geocacher
Ich habe zwar auch kleine programmier Kenntnisse aber bei LUA bin ich noch nicht soweit das ich dort etwas verstehe.

Auch mit benutzerdefinierten Ausdrücken in URWIGO habe ich mich noch nicht beschäftigt. Hast du dazu evtl. einen Artikel für mich?

Vielen Danke für deine genaue Analyse!
Damit hat sich das für mich wohl erstmal erledigt. Wirft aber auch die Frage auf ob URWIGO bei allen AktuellenObjekten so arbeitet. Allerdings ist das auch noch ein großes Kapitel für sich. Damit beschäftigen werde ich mich sicher noch. Anschließend berichte ich hier gern!
 

bodenseepingu

Geomaster
Für alle anderen aktuellen Objekte habe ich noch nicht richtig einen Sinn gesehen - wann gibts denn einen aktuellenItem, aktuellenCharacter etc. das ganze ist noch nicht so richtig durchdacht...

Vermutlich kann man dieses Verhalten als "Bug" von Urwigo einstufen - es könnte sich schon lohnen, den Entwickler daraufhin anzusprechen - Urwigo müsste den korrekten Code generieren genauso wie es beim Zugriff auf die Attribute Namen etc. funktioniert.

Also abhaken würde ich es nicht - wenn man den Entwickler anschreibt und ihm die Problematik schildert bzw. eine Urwigo-Testcartridge schickt, dann wäre es schon denkbar dass er - sagen wir mal binnen 3...4 Wochen ein Urwigo-Update erstellt...vielleicht gehts auch schneller.

Erfahrungsgemäß dauert das Erstellen einer Wherigo-Cartridge ja auch etwas....
 
OP
D

daKnut

Geocacher
Ok hätte ich sonst auch mit begonnen aber du kannst dich da sicher noch besser ausdrücken.

Wie hast du dir denn den LUA Code anzeigen lassen?

Konntest du reproduzieren das AktelleZone sich nicht geändert wenn eine Zone nur betreten wird ohne das Code ausgeführt wird?
 

bodenseepingu

Geomaster
Wenn du ein gwz-File erzeugst, kannst du das entpacken - ggf. umbenennen in .zip - da steckt ne _cartridge.lua drin - das ist der generierte LUA-Code.

Du hast das Problem denke ich noch nicht verstanden. Schau dir im generierten Code den Unterschied an, wenn man auf den Namen von aktuelleZone zugreift und wenn man versucht, einen Gegenstand in die aktuelleZone zu moven - das kann nicht gehen.

Für mich also ein echter Bug in Urwigo - ich nehm an, dass es der Entwickler von Urwigo genauso sieht....
 
OP
D

daKnut

Geocacher
Das ich es noch nicht 100% verstanden habe kann ich bestätigen. Würde ich aber gern wenn du ein paar Erklärungen nicht müde bist.

Bei den verschiedenen Events(OnEnter,OnExit...) wird die Variable currentZone immer mit dem Wert des Zonen Names belegt.
_G ist eine Art Array. Dort wird zu dem in currentZone genannten Objekt für .Name zb. der Name "nachgeschaut".

Habe ich das soweit richtig verstanden?

PS: Ich habe auch mal versucht bei verknüpften Objekten MoveTo(Befehlsziel) zu verwenden. Dies ließ der Builder aber garnicht erst zu.
 

bodenseepingu

Geomaster
ja, du hast das in etwa verstanden es dürfte aber nicht der Zonenname sein, sondern die Zonenvariable (in Urwigo bei Kennung automatisch normalerweise obj<name> - ggf. wenn das nicht eindeutig ist noch ne Nummer)- die Art Array heißt in LUA table - die kann man mit numerischen Indizes oder mit benamsten Indizes verwenden - in diesem Fall sind
die Zonenobjekte - warum auch immer unter _G mit dem benamsten Index der Zonenvariable abgelegt - ich hab das Konstrukt _G noch nirgendwo beschrieben gesehen - mag sein, dass das Wherigo-Innereien sind..

Vielleicht kann Krolock damit mehr anfangen oder kann eine Erklärung liefern.
 

keogarl

Geocacher
servus mitanand!
nachdem ich schon soviel geschnorrt habe (sprich mitgelesen), melde ich mich auch mal zu Wort.

Ich finde das Thema "currentwasauchimmer" sehr spannend, das eröffnet viele Möglichkeiten. Bei der Philosophie bin ich ganz bei daKnut. Deswegen hab ich nochmal rumprobiert...

konkret:
Ich habe 4 Zonen und 4 Charaktere. Der Spieler soll die freie Wahl haben welche Zone er zuerst angeht, trifft dort aber auf alle Fälle Charakter1 (er selbst glaubt natürlich, das wäre Zufall, hehe...)
so, jetzt wirds ein wenig wirr:
-Variable läuft parallel mit, so dass das Programm weiß, welcher Charakter als nächstes dran ist
- Sobald Spieler irgendeine Zone betritt taucht Charakter1 auf
-Dabei funktioniert folgender Trick:
es wird nach dem aktuellen Zonen-Image gefragt, um die aktuelle Zone zu identifizieren
also: if/ compare currentzone.image=bild1 ; if/ compare currentzone.image=bild2; usw.
- dementsprechend wird der Charakter dann verschoben.

denke das sollte auch mit Gegenständen funktionieren..

Vielleicht hilfts ja jemand..
karl
(der übrigens ausschließlich in Urwigo programmiert und sonst keinen blassen Schimmer von dem lua-dingens hat..)

PS: Nachtrag: wurde übrigens erfolgreich mit Oregon und Android im Feld getestet
 

Red_Family

Geocacher
Ebenfalls philosophisch.
Man könnte sich eine Cartridge vorstellen in der man verfolgt wird. Nun legt man in der aktuellen Zone eine Mine von vielleicht mehreren und wenn der von der Cartridge per Zufall geschickte Agent die betritt hat man gewonnen.
Sozusagen Minesweeper umgekehrt.
 
Oben