Bekannte Dinge die den Wherigo Ablauf negativ beeinflussen ?

Hallo *.*

Ich frag mal in die WIG Expertenrunde, ob es Dinge gibt (bekannt sind) die den Ablauf einer Cartridge negativ beeinflussen. Hintergrund ist der, daß eine meiner Cartridges zwar zu so 90-95% von den Spielern erfolgreich durchgespielt wurde und das mit verschiedendster Hardware, aber ich bin auf Ursachenforschung, woran es bei den andren 5-10% hängt, daß die Cartridge abschmiert. Dabei muss ich erwähnen, daß Abstürze NICHT zu immer dem gleichen Event eintreten, sondern ganz unterschiedlich. Mal beim Zone betreten, mal beim Input oder auch beim Aufruf eines Tasks. Absolut nicht nachzuvollziehen oder einzuordnen. Dann wärs ja einfach, Code umschreiben, probieren, fertig. Mit "Naja, ab und zu kanns schon mal sein, daß ein WIG abstürzt" bin ich nicht so zufrieden.

Jetzt wollte ich eben mal tiefer stöbern. Zum Beispiel könnte es doch sein, daß ein Gerät instabil läuft, wenn dieses mehr als 1000 Waypoints geladen hat oder mehr als 50 Tracks oder der magnetische Kompass an ist oder oder oder...
Gibts Dinge die ihr schon nachvollziehen und sicher zuordnen konntet ?
Um beim Beispiel zu bleiben :
Ein Oregon hat 700 Cachelistings geladen und stürzt regelmäßig bei WIGs ab. Sind nur 50 geladen, läuft es immer und problemlos. DANN könnte man den Fehler zuordnen.
Und solche Punkte suche ich, wisst ihr da welche ?

Edit : Ahja, bekannt sind solche Dinge wie OnClick Events die nicht funktionieren oder mehr als 7 sichtbare Zonen. Aber ich bin mir sicher, da gibts noch einiges mehr...Cartridge nicht größer als 4 Gigabyte, nicht mehr als 1024 Bilder usw usw

Grüße
Jonny

Jonny65 schrieb:

Edit : Ahja, bekannt sind solche Dinge wie OnClick Events die nicht funktionieren oder mehr als 7 sichtbare Zonen.

Zum Vergrößern anklicken....

Hey,

die Sichtbarkeit von Zonen ist, soweit ich weiß, furzegal. Es sollten nur nicht mehr als 7 (oder sogar nur 5) Zonen aktiv sein.
Aber zum Thema: Aus eigener Erfahrnung kann ich sagen, dass man oft selbst Abstürze durch zu schnelles "Klicken" verursacht. Gerade auf den Garmins oder älteren Telefonen (ich hatte bis vor kurzem ein Nokia 5800 XM und da war es auch so), die nicht genug Rechenpower haben, dauert es oft relativ lange, bis "was passiert", also bis z.B. die nächste MsgBox etc. angezeigt wird. Wenn man dann anfängt, wie wild rumzuklicken, schmiert die Cartridge schon mal ab. Wie gesagt, das ist meine Erfahrung.
Weiß nicht, wie es mit Sound aussieht, aber ich vermute mal, dass es da auch zu Problemen kommen kann, wenn man auf einem Gerät spielt, das das nicht unterstützt.

Gruß

Die iPhone/iPad Software hat/hatte ein massives Problem mit Umlauten bei Inputs. Ich kann es selber nicht testen, da ich so ein Gerät nicht besitze, bei einem Bekannten ist der Player reproduzierbar abgestürzt.
Einen Sound abzuspielen, wenn noch ein anderer Sound läuft, führt zumindest unter Windows Mobile zum Absturz.

Vielleicht sollte dieses Thema angepinnt werden, es könnte eine hilfreiche Sammlung entstehen.

Naja, mit wissenschaftlicher Arbeit hat das nichts zu tun - vielleicht mit Statistik oder Vermutungen.

Insofern meine Erfahrungen - auch aus meinen Listings

• Aktivierung der Stromsparfunktion (Bildschirm aus) während aktiver Eingabe bringt einen Oregon (oder manche) reproduzierbar zum Absturz, nach Deaktivieren der Stromsparfunktion lief die Cartridge stabil (Krolocks Asbacher Runde)
• Verhalten des Spielers: Anstatt an Zonenrändern rumzueiern bis das Gerät Null zeigt lieber zügig in die Zonen gehen (die meisten sind ja groß genug) --> mir wurde von ein- und demselben Spieler das geschildert, daß die Cartridge stabil war, wenn er sein Verhalten geändert hat. --> d.h. die meisten nehmen an, daß man bei 0 mitten in der Zone ist und vermuten daß die Zonen klein sind.
• Überlastung des Geräts - z.b. kommt ein Garmin an die Grenzen, wenn zu viele Dinge gleichzeitig passieren --> ich mache oft Cartridges mit schnelleren Timings (z.B. 1 sec) --> für Garmins brachte es weitaus stabileres Verhalten, wenn das Timing mit 2 sec gemacht wurde und/oder nicht alles bei jedem Timer-Tick gemacht wurde - d.h. dass explizit verschiedene Dinge abwechselnd bei verschiedenen Timer-Ticks gemacht wurden - naja sind hier natürlich bewegliche Zonen - das fordert sicher einen Garmin (siehe Cartridges Catch me if you can, sowie einen neuen der noch nicht veröffentlicht wurde)
• Ressourcen wurden schon angesprochen --> hier zählen aber die Gesamten Ressourcen - d.h. Anzahl Gegenstände, Character, Zonen, Medien, eine Obergrenze kann nicht so einfach angegeben werden - u.a. ist auch die Zonenform entscheidend - einfache drei- oder viereckige Zonen sind wesentlich günstiger zu berechnen als komplexe Zonenformen. Übrigens hab ich auch schon über Probleme bei 128 Bildern a 1kB gelesen - an den 1024 zweifle ich.
• es gab auch schon Posts mit reproduzierbaren Abstürzen -z.b. Anzahl der Kommandos

...andere Posts gibts hier ja, was man im Moment bei verschiedenen Playern beachten muss - das sind in der Regel aber reproduzierbare Abstürze - heir sind mehr die nicht so ganz klaren oder evtl. auf manchen Geräten reproduzierbaren Abstürze gefragt.

Danke schon mal für die ersten Tips.
Ja so ein Sammelsurium wäre echt ne ziemlich nützliche Angelegenheit. Man könnte dann
a) "drumrum" programmieren, also Workarounds machen
b) im Listing drauf hinweisen auf dieses und jenes zu achten ("geht beim Betreten einer Zone noch ein paar Schritte weiter")

Mag sein, daß das in X Threads schon angesprochen wurde, aber weit verstreut und meist wohl nur immer zu einem Gerät ("Mein iPhone stürzt ab wenn ich von Zone 1 in Zone 2....")

Heute ein Fehler beim Oregon 450 reproduziert :
An der vorletzten Stage bekommt der Spieler einen "Spoilomat" der Infos und Bilder zum Final enthält. U.a einen 4 seitigen Dialog. Mit Betreten der Finalzone, kommt eine Message alla "Finalzone erreicht...bla bla bla". Hat der Spieler gerade z.b die 2. Seite des Dialogs offen und betritt die Zone spuckt das "OnEnter" Event rein und schießt die Cartridge hab. Habs jetzt gefixt, indem ich die Spoilomat Kommandos erst aktiviere, wenn die Finalzone betreten wird.

Bei viele Items, Charakter, Kommandos usw. kann ich mir Instabilität auf jeden Fall vorstellen. Wer kennt schon die Speicherverwaltung ?

http://www.geoclub.de/viewtopic.php?f=74&t=51671

Ja ansatzweise ist der Inhalt ganz nützlich, aber sehr viel Luft dazwischen. Was ideal wäre alles zusammenzutragen...SACHLICH und nach Hardware zu sortieren. "Known Bugs und Workarounds beim Gerät XY ...."
Oben geschildertes Symptom lässt sich übriges 100% auch im Emulator provozieren. Ich hab an einer Stage auch noch mit einem Workaround gearbeitet : Ein Kommando löst einen Input aus, DABEI wird eine Variable "InputActive" auf true gesetzt. Bei den OnEnter und OnExit Events der Zone wird vorher InputActive abgefragt. Steht sie auf True, erscheint keine Message wie "Du hast Zone 1 betreten/verlassen..." Vermeidet somit erfolgreich den Absturz, sollte sich der Spieler WÄHREND eines Inputs in oder aus der Zone bewegen und es kommen bei diesen Events Messages.

Jonny65 schrieb:

Ja ansatzweise ist der Inhalt ganz nützlich, aber sehr viel Luft dazwischen. Was ideal wäre alles zusammenzutragen...SACHLICH und nach Hardware zu sortieren. "Known Bugs und Workarounds beim Gerät XY ...."
Oben geschildertes Symptom lässt sich übriges 100% auch im Emulator provozieren. Ich hab an einer Stage auch noch mit einem Workaround gearbeitet : Ein Kommando löst einen Input aus, DABEI wird eine Variable "InputActive" auf true gesetzt. Bei den OnEnter und OnExit Events der Zone wird vorher InputActive abgefragt. Steht sie auf True, erscheint keine Message wie "Du hast Zone 1 betreten/verlassen..." Vermeidet somit erfolgreich den Absturz, sollte sich der Spieler WÄHREND eines Inputs in oder aus der Zone bewegen und es kommen bei diesen Events Messages.

Zum Vergrößern anklicken....

Absturz ??? Oder einfach aus dem Input geflogen - großer Unterschied - glaub ich jetzt nicht, daß der Emulator bei dem Verhalten abstürzt.- der Oregon - ja kann sein - vielleicht auch nur ein Folgefehler.....Beim Design muss man ja schon drauf achten, daß während eines Inputs nicht andere Meldungen kommen können - das ist dann eher eine Frage, ob ein Input ausgelöst wird, wenn man eine Zone betritt, oder ob ein Input durch ein Kommando z.b. in einem Item ausgelöst wird.

Wenn der Input designtechnisch durch die Zone ausgelöst wird, sollte man halt zumindest bei dieser Zone auf On Enter und on Exit-Meldungen verzichten - wenn der Benutzer einfach aus Spass bei aktivem Input meilenweit durch die Gegend stiefelt, ist er halt auch selbst schuld.

OK - die Spoilomat Geschichte war am Anfang vielleicht auch unglücklich programmiert - wozu braucht der Benutzer einen Spoiler, wenn er noch nicht in der Nähe des Finals ist...

Übrigens: Es sind nicht alles Player-Fehler - vieles ist auch dem ungewohnten Umgang mit eventgesteuerter Programmierung geschuldet...

Bin im amerikanischen Geoclub-Forum auf einen Thread gestossen, der im Zusammenhang mit der Dialog / Message / Input-Geschichte interessant ist:

http://forums.groundspeak.com/GC/index.php?showtopic=214105&st=0&p=4145010&#entry4145010

Durch Einfügen des dort aufgeführten Codes kann man offensichtlich das Verhalten von Messages, Dialogen und Inputs so verändern, dass die Meldungen nacheinander kommen - könnte also gut für die Stabilität sein.



....siehe unten...bereits im Urwigo implementiert (gepufferte Dialoge, die nicht sofort angezeigt werden...)

ÄÄÄÄHHHHMMMM......

Urwigo hat diese Funktionalität bereits eingebaut. Hinter der klitzekleinen unscheinbaren Checkbox "gepuffert" bei Dialogen versteckt sich diese Funktionalität.

Wenn man "gepufferte" Dialoge verwendet, werden diese erst bei der nächsten Messagebox oder Input-Dialog angezeigt....und zwar nacheinander....

War eigentlich klar, dass das eingebaut sein muss, weil vom Autor von Urwigo genau dieser Thread stammt......

bodenseepingu schrieb:

Absturz ??? Oder einfach aus dem Input geflogen - großer Unterschied - glaub ich jetzt nicht, daß der Emulator bei dem Verhalten abstürzt.

Zum Vergrößern anklicken....

Also Stack Overflow klingt schon heftiger als nur ein rausfliegen aus dem Input ;-)
Beispiel siehe im Anhang. Zone betreten, Zahlenschloss aufrufen, "Code eingeben" klicken, aber dann NICHTS eingeben, sondern einfach aus der Zone rausgehen.
Nach den übersprungenen Messages (Code falsch/Du hast ie Zone verlassen) dann OK klicken und den Bluescreen (im Emulator) bewundern.

bodenseepingu schrieb:

Beim Design muss man ja schon drauf achten, daß während eines Inputs nicht andere Meldungen kommen können - das ist dann eher eine Frage, ob ein Input ausgelöst wird, wenn man eine Zone betritt, oder ob ein Input durch ein Kommando z.b. in einem Item ausgelöst wird.

Zum Vergrößern anklicken....

Ja kommt eben zwangsläufig wenn die Enter/Exit Events mit Messages versehen sind, man in einem Input ist und die Zone verlässt (sei es durch aktives rausgehen aus der Zone oder sprunghaften Koords). In dem Fall lösen Items den Input aus, nicht das Enter/Exit, siehe Beispiel.

bodenseepingu schrieb:

Wenn der Input designtechnisch durch die Zone ausgelöst wird, sollte man halt zumindest bei dieser Zone auf On Enter und on Exit-Meldungen verzichten - wenn der Benutzer einfach aus Spass bei aktivem Input meilenweit durch die Gegend stiefelt, ist er halt auch selbst schuld.

Zum Vergrößern anklicken....

Ich habs eingebaut um dem Spieler zu melden, daß er nun die Zone erreicht hat (kommt besser und deutlicher als "Location / here") und beim Zone verlassen, wenn er was vergessen hat. In einer Zone muss er 3 QTAs beantworten, hat er 1 vergessen und verlässt die Zone, kommt halt "Upps, du hast was vergessen ..."

bodenseepingu schrieb:

OK - die Spoilomat Geschichte war am Anfang vielleicht auch unglücklich programmiert - wozu braucht der Benutzer einen Spoiler, wenn er noch nicht in der Nähe des Finals ist...

Zum Vergrößern anklicken....

Um sich schon mal schlau zu machen, den Spoilertext zu lesen oder die Spoilerbilder anzuschauen. Der Spoilomat hat abnehmend schwierige Hints, also je nachdem wie schwer es der Spieler haben will, klickt er Hint 1, sucht bissl...dann Hint 2, dann ein Bild , dann noch eins.

bodenseepingu schrieb:

ÄÄÄÄHHHHMMMM......

Urwigo hat diese Funktionalität bereits eingebaut. Hinter der klitzekleinen unscheinbaren Checkbox "gepuffert" bei Dialogen versteckt sich diese Funktionalität.

Wenn man "gepufferte" Dialoge verwendet, werden diese erst bei der nächsten Messagebox oder Input-Dialog angezeigt....und zwar nacheinander....

War eigentlich klar, dass das eingebaut sein muss, weil vom Autor von Urwigo genau dieser Thread stammt......

Zum Vergrößern anklicken....

Ah jetz ja, da muss ich mal bissl rumspielen...man entdeckt doch immer mal wieder ein hidden feature. Danke

UPS - ich sehe im Moment da auch keine Möglichkeit als nur bei den "nächstegelegenen" Meldungen (Zone betreten, Zone verlassen) eine Meldung zu verhindern wie du es gemacht hast..

Der gepufferte Dialog hat einfach den Nachteil, daß er später erscheint, der hilft nicht wirklich weiter...

Und auf den Ziel-Geräten gibt's auch nen Crash ? Zumindest auf Garmin?

bodenseepingu schrieb:

Und auf den Ziel-Geräten gibt's auch nen Crash ? Zumindest auf Garmin?

Zum Vergrößern anklicken....

Crash auf dem Oregon 100% nachvollziehbar. Das Display verschwindet langsam und keine Eingaben (Touchscreen) sind mehr möglich. Da hilft nur dann noch ausschalten.

Gleiches Script anbei, doch jetzt mit der InputActive Variable. Da passiert nix mehr.

Kann ja mal jemand real probieren (mit einem andren Gerät). Dazu halt einfach den Startpunkt und die Zone anpassen.

Weiß hier eigentlich jemand, wie man zum Urwigo-Entwickler Kontakt kriegt.

Dieses Problem mit Input und Messages sollte man dem Entwickler doch mal mitteilen, vielleicht hat er ja ein Interesse, einen Workaround einzubauen - das müsste für ihn ja relativ einfach sein, da Urwigo die Wherigo-Aufrufe zuerst mal kapselt. Er könnte relativ unproblematisch sich einfach merken, wenn ein Input aktiv ist und bei aktivem Input entweder den Input sauber beenden (falls das technisch überhaupt möglich ist) oder neue Textmeldungen unterdrücken...

Damit würden alle Cartridges, die neu compiliert werden stabiler werden, wenn sie aufgrund dieses Problems gelegentlich oder reproduzierbar abschmieren...

Hallo,

bodenseepingu schrieb:

Weiß hier eigentlich jemand, wie man zum Urwigo-Entwickler Kontakt kriegt.

Zum Vergrößern anklicken....

Ja: [email protected]

VG

Sven

okay, Anfrage läuft mit Verweis auf diesen Thread, weiß aber nicht ob der Autor von Urwigo (tolle Software !!!) gut genug Deutsch spricht um hier mitzulesen).

Hallo,

hab eine Antwort vom Urwigo-Entwickler, die ich hier mal poste

Hi Andreas,
I do not understand German, but with description you gave me I have been
able to recreate the problem. It does indeed seem this is a player issue.
I will try to produce a workaround in Urwigo, but I am currently very busy
at work, it may take a while.
Thanks for your help and would you please keep me informed about any other
problems that you may find?
Happy coding,
Pavel (YourSelf)

Cool, da geb ich doch glatt paar von meinen WIG Favouritenpunkten an den Entwickler ab :/
Bzgl. Nachbarthread hätte ich da schon ne Idee für eine weitere Problembeschreibung. Man verpasst Items Prioritäten (z.b 1-9) ... so werden sie dann auch in der Zone oder im Inventar angezeigt.

Das mit den 'Prioritäten' ist grundsätzlich eine gute Idee. Dumm nur, das auf der Seite des Players z.B. Im Garmin diese 'Priorität' nicht beachtet würde weil sie dort ja nicht implementiert ist.