Urwigo/Wherigo indirekte Itemmanipulation

Hi....

Fraaaaaaage: Ich würde aktuell am Urwigo basteln (wenn mir wer sagt dass es im OriginalWherigo einfacher ist, probier ichs zähneknirschend dort nochmal)

Aufgabe: Ich habe ein Item... einen "Scanner"

Dieser Scanner kann verschiedene Items die in verschiedenen Zonen sind "scannen".

Wenn ich jetzt im Scanner auf ein Item scanne... möchte ich, dass das ausgewählte Item disabeld wird, aber wie geht das? Wenn der scanner scanned, kann ich nur die Eigenschaften des Scanners ändern?

Als variante würde mir auch reichen die Zone zu disabeln/unsichtbar machen in der die ganze Aktion stattfindet. Aber irgendwie ist mir das nicht möglich?

help appreciated!!

Hintergrund: Wayne's interessiert:

Ich möchte zu einigen Zonen führen und völlig unabhängig der Reihenfolge soll einfach beim Xten mal scannen aktion Y ausgeführt werden. -> also beim scannen zähle ich einen counter hoch und mach ein Modulo. Natürlich wäre es fad (=beschi**) wenn man einfach das selbe Item mehrmals scanned.

Hallo,

im Script für das Kommando 'scannen' kannst du einfach die Aktion 'Move zitem, zcharacter to zcharacter, zone, zitem, player, nil,' mit dem Parameter 'nil' aufrufen (z.B.: 'Move DeinItem to nil') und dein Item ist vom Spieler weg.

Du kannst es aber auch das Item einfach unsichtbar machen wenn du nur verhindern willst dass man das Item sieht. Benutze dazu 'Set zobject.property, variable equal to zobject.property, value' (z.B.: 'Set zItemDeinItem.visible' equal to 'false').

Problem gelöst?

Jein... ich probiers aber aus. Wenn ZITEM das passive Objekt beschreibt (also das Objekt dass ich scanne) dann ja, wenn ZITEM das aktive Objekt ist (das Objekt das Scanned) dann nein.
dank derweil

Hallo,

wieso zitem = Scanner

genau das ist das Problem...

Scanner scannt ein Item Wasserquelle1.

Wenn wasserquelle1 gescanned wird, soll ER disabeld werden.

Ich will mit dem Scanner 10 Quellen scannen und jede quelle soll danach disabeld werden. Nicht der Scanner.


Und das wäre halt praktisch wenn das der Scanner könnte, dann müßte ich EINMAL code programmieren und nicht 10 mal.

Hallo,

melde mich heute Abend, habe jetzt keine Zeit, ist aber kein Problem.

Hallo,

nun nochmal langsam:

Du hast ein Item 'Scanner' mit dem du die 10 Quellen scannen willst. Jede Quelle soll man nur einmal scannen können. Soweit klar. Ich würde die bereits gescannten Quellen aber nicht verschwinden lassen, in der Realität wären die Quellen auch noch da wenn ich wiederkomme - dein WiG braucht sie doch nur einmal zählen.

Bevor wir hier weiter machen lies bitte auch das hier: http://www.geoclub.de/viewtopic.php?f=74&t=49199. Da habe ich schon ne Menge zu deinem Thema drin.

Also los gehts:

1) Erstelle deine Items 'Quelle1' bis 'Quelle10'. Wie du diese in die Zonen bekommst ist klar?

2) Lege bei deinem Item 'Scanner' ein Benutzerkommando 'scannen' an und setze die Option das es dazu bestimmt ist mit einem anderen Item zu funktionieren. Setze die Option 'Works with a List of Objects' und füge dieser Liste die bereits erstellten Items 'Quelle1' bis 'Quelle10' hinzu.

3) In der Ereignisbehandlungsroutine 'scannen' benutzt du dann 'if the targetobject is item or character' um passend zu reagieren, z.B.

If target is zItemQuelle1 then
if zItemOuelle1.opened
(Mitteilung "Quelle wurde schon gescannt")
else
Set zItemQuelle1.opened equal to true
(deinen Zähler für die Anzahl der gescannten Quellen hochsetzen und was sonst noch gemacht werden soll)
end
end
If target is zItemQuelle2 then
if zItemOuelle2.opened
(Mitteilung "Quelle wurde schon gescannt")
else
Set zItemQuelle2.opened equal to true
(deinen Zähler für die Anzahl der gescannten Quellen hochsetzen und was sonst noch gemacht werden soll)
end
end

...usw. bis

If target is zItemQuelle10 then
if zItemOuelle1.opened
(Mitteilung "Quelle wurde schon gescannt")
else
Set zItemOuelle10.opened equal to true
(deinen Zähler für die Anzahl der gescannten Quellen hochsetzen und was sonst noch gemacht werden soll)
end
end

So, damit sollte es funktionieren, ohne die Quelle nach dem scannen 'wegzuschmeißen' oder unsichtbar zu machen.

ich habs befürchtet. Rein EDV-Technisch FURCHTBAR ;-)

thx

ah... viel weniger Code und geht... (weil die 10 Items waren nur hypothetisch... werden so 40-50 ;-) )

Move Command target to NONE

eh voilat

Ja, dass die Quelle an sich ja immer noch da ist nach dem Scannen ist mir schon klar, aber es geht hier nicht um Realismus, es geht hier um FAULHEIT ... äh... effizientes Programmieren ;-)

PS: Wenn ich das noch irgendwie auf targetitem.opened.false umbiegen könnte hätt ich schon eine Freude... aber ich seh noch nicht wie und ein 50fach geschachteltes if ... da hab ich mitleid mitm GPS ;-)

Hallo,

HowC schrieb:

Move Command target to NONE

Zum Vergrößern anklicken....

Nun, diese Syntax kannte ich vom originalen Wherigo-Builder nicht. Mag sein, das Urwigo sowas kennt, keine Ahnung.

Wie siehts dann mit der Kompatibilität zum Player des Oregon aus? Aber das wirst du ja vor Veröffentlichung testen... Wie die einzelnen Player 50 Zonen handeln hast du auch bedacht, oder? Komm nur nicht auf die Idee die alle gleichzeitig aktiv und sichtbar halten zu wollen....

du lachst... aber genau DAS habe ich vor.

Und darin ist auch ein Teilproblem enthalten:
Oregon kann 7 Zonen offen halten. Also meines ist schon lange hinüber.

Aber mit meinem Android-Handy ist das alles kein Problem. Die 50 Zonen sind aktiv und werden bei Annäherung auf 100 bis 150 Meter visible.

Übernächste Woche organisier ich das iPhone eines Freundes (da gibts ja auch schon einen Player hab ich gerade über dieses Forum entdeckt).
Dann werfe ich noch meinen alten Dell Axim PDA an. Schaun wir mal....

Und ansonsten verleih ich halt mein Handy an interessierte cacher ;-)

HowC schrieb:

Oregon kann 7 Zonen offen halten. Also meines ist schon lange hinüber.

Zum Vergrößern anklicken....

Schreib dann bitte ganz Fett in der Beschreibung, dass man mit Oregon keine Chance hat, sonst gibt es böses Blut

Nun, diese Syntax kannte ich vom originalen Wherigo-Builder nicht. Mag sein, das Urwigo sowas kennt, keine Ahnung.

Zum Vergrößern anklicken....

Schau Dir doch den Urwigo mal an, kostet nichts

Gruß Sebastian

izaseba schrieb:

HowC schrieb:

Oregon kann 7 Zonen offen halten. Also meines ist schon lange hinüber.

Zum Vergrößern anklicken....

Schreib dann bitte ganz Fett in der Beschreibung, dass man mit Oregon keine Chance hat, sonst gibt es böses Blut

Nun, diese Syntax kannte ich vom originalen Wherigo-Builder nicht. Mag sein, das Urwigo sowas kennt, keine Ahnung.

Zum Vergrößern anklicken....

Schau Dir doch den Urwigo mal an, kostet nichts

Gruß Sebastian

Zum Vergrößern anklicken....

Nearly finished. bin so bei 60 gleichzeitig aktiven stages. Angezeigt werden natürlich viel weniger, sonst hält es ja keiner aus.

bisher mit android nur gute erfahrungen, iphone wird noch getestet. pocketpc mit winmobile auch noch. also es gibt eh eine gute bandbreite.

Das so ein cache wahrscheinlich keine 2 stelligen fundzahlen in der ersten woche hat ist mir sogar mehr als recht. Da kann man dann wieder mal STOLZ auf seine Leistung als Finder sein.

Und ja, die Oregon-fraktion tut mir eh leid

Also ich weiß ehrlich gesagt nicht, warum 60 Zones gleichzeitig aktiv sein müssen, und nicht alle angezeigt werden
Kann man das nicht so machen, daß z.B. 5 Zones aktiv sind und je nachdem wie man sich bewegt mit on Exit und on proximity events nächseten Zonen aktiv und die weiter Entfernten deakiviert werden?

Und ja, die Oregon-fraktion tut mir eh leid

Zum Vergrößern anklicken....

Danke für Dein Mitleid :/

Gruß Sebastian

Ömmm... gute Frage, ich dachte wenn die Zone nicht aktiv ist, gibts auch kein On Proximity?

Es gibt ja auch kein OnEnter an einer inaktiven zone....

Wenn das geht, könnts doch noch was mitm Oregon werden.

Das ist richtig, wenn Zonen die nicht aktiv lösen keine Ereignisse aus. Du könntest aber ein paar unsichtbare "Überzonen" einführen, die jeweils ein paar deiner Zonen überdecken. Wenn du diese betrittst könntest du die überdekcten Zonen aktiv schalten und die restlichen auf inaktiv setzen.

ja, hab selbst noch mal kurz nachgelesen wegen onproximity und active. Hätt mich jetzt gewundert wenn das anders wäre.

Ja, die Idee der Übersichtszonen hatte ich auch, aber... Oregon kann 7 Zonen aktiv halten.

Was bringt mir das?
sagen wir ich hätte 5 Übersichtszonen, dann müßte ich die alle aktiv halten und könnte in jeder 2 weitere Zonen haben. Dann hab ich effektiv 10 Zonen.
4 Übersichtszonen a 3 caches...12 Zonen...so wirklich weit komm ich damit nicht.

Ich hab auch überlegt ob ich Übertretungszonen mache....

zB 5 SpielZonen und eine Umgebende Zone. so als würdest eine Grenze überschreiten... aber dann hatte ich wieder eher das Problem dass ich nicht weiß in welche richtung die Grenze überschritten wird.... und.... es ist mit android sooooo schön simpel...........

Seufz. so ich muß noch zonen adden. ;-)
Proceed to next level sozusagen ;-)

Ich meinte eher mit onExit einer Zone weitere Zonen aktivieren, dabei müsste man aber wissen in welche Richtung der Cacher läuft, wenn die Richtung nicht vorgegeben ist
War aber nur so eine Idee meineseits...

Ich weiß aber ganz sicher, daß unser Projekt auf möglich allen Devices laufen soll, will ja niemanden ausgrenzen.

Gruß

Sebastian

Sagen wir du hast 7 Übersichtszonen, diese sind Anfangs alle aktiv. Jede dieser Zonen enthält 6 weitere Zonen, die inaktiv sind. Beim betreten einer Übersichtstzone schaltest du alle anderen Übersichtszonen inaktiv und die inneren Zonen aktiv. Beim verlassen schaltest du wieder die Übersichtszonen aktiv und die inneren Zonen inaktiv. So kommst du schonmal auf 42 Zonen.

Wenn das Gelände es hergibt, so das man die Zonen linear hintereinander aufreihen koennte, kannst du auch folgendes machen.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x Z1 x Z2 x Z3 x Z4 x Z5 x Z6 x
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

betreten einer Zone schaltet alle anderen inaktiv
verlassen von Z1 schaltet Z2 aktiv
verlassen von Z2 schaltet Z1 und Z3 aktiv.
usw.