bei meinem aktuellen WIG erstaunlich oft Oregon-Abstürze?

[keogarl]

Habe bei meinem aktuellen WIG erstaunlich oft Oregon-Abstürze (ohne erkennbares System) zu vermelden. Ansich ist er sauber programmiert (glaub ich zumindest ), da er aber recht "aufgeblasen" ist, gehe ich davon aus, dass das Oregon einfach überfordert ist (wahrscheinlich auch vom Benutzer, aber der lässt sich ja nicht austauschen..)

Deswegen werfe ich mal ein paar "globale" Thesen/Fragen in den Raum, um Eure Meinung zu hören. Die bekannten Programmier-Fehler will ich mal aussen vor lassen, das ist ja schon viel besprochen worden.

1. Was beansprucht Rechenleistung? Sind es Bilder? Die Timer? Wie schauts aus mit Variablen? Zuviel Text? die Befehle an sich? etc...
2. Ist es von Vorteil, wenn der Speicherplatz nicht komplett belegt ist? Gibt es sowas wie "Arbeitsspeicher"?
3. Macht es einen Unterschied, ob das Wig auf dem Gerät oder auf der Speicher-Karte hinterlegt ist?
4. Habe von der Theorie gelesen, dass es ungünstig sei, wenn die Trackaufzeichnung angeschalten ist? Gibts da Erfahrungen?
5. Was wird beim Speichern alles abgespeichert? Die Bilder immer wieder neu? oder gibt es sowas wie einen Container?
6. Prüft das Oregon jede Proximity, auch wenn nichts passiert? Wäre es evtl. eine gute Idee die Proximity auf 0 zu setzen?
7. Sonstiges?

noch was "nicht globales":
a. Ich hatte an einer Stelle reproduzierbar (allerdings nicht auf jedem Oregon) einen Absturz beim Betreten ein inaktiven (!) Zone, kann das sein?

Da ich, sobald der Wig einigermassen stabil läuft noch eine englische Version draufpacken will (über Variablenabfrage in Urwigo), stellt sich für mich die Frage, ob es nicht besser wäre, gleich eine 2. extra Kartusche anzulegen, dass die eine nicht noch umfangreicher wird.

Danke schon mal für Euren Senf
keogarl

 

[Charlenni]

Also zu allem kann ich nichts sagen, aber zur Aufklärung des einen oder anderen kann ich beitragen.

1. Rechenleistung beanspruchen die Updates der Position. Alles andere dürfte so neben her gehen.
2. Klar gibt es so etwas wie Arbeitsspeicher. Wie groß der allerdings beim Oregon ist, ist mir nicht bekannt.
3. Ich nehme an, dass der WIG am Anfang komplett in den Speicher gelden wird. Und wenn nicht, dann wenigstens das Programm und die Bilder werden bei Bedarf geladen. Eine Cartridge besteht aus
- allgemeinen Daten
- Tabelle mit Zeigern für die Medien
- das eigentliche Programm als Lua binary Chunk
- alle Medien, so wie sie aufgerufen werden.
4. Trackaufzeichung braucht natürlich Rechenzeit. Kann also zu Problemen kommen, glaube ich aber nicht.
5. Beim Abspeichern werden nur die Objekte mit ihren Einstellungen abgespeichert. Beim Laden wird die Cartridge normal geladen (mit Programm und Medien) und anschließend werden alle Objekte mit ihren alten Einstellungen überschrieben. Dabei werden Tabellen rekursiv abgespeichert.
6. Beim Oregon wird die Routine Player.ProcessLocation() mit neuen Koordinaten aufgerufen. Diese macht nichts anderes, als sich die aktuelle Zeit in Player.LastLocationUpdate zu merken und dann Player.RefreshLocation() aufzurufen, welches dann die Koordinaten überprüft. Diese holt sich alle Zonen und überprüft, ob die Zone aktiv ist und Points ~= nil wahr ist. Wenn ja, dann wird überprüft, ob sich der Spieler in der Zone befindet. Das dürfte dann auch die meiste Rechenzeit benötigen. Ist der Spieler nicht drin, dann wird der Abstand zur Zone ermittelt und entsprechend ausgewertet. Dies erfolgt mit der Funktion VectorToZone(). Braucht sicher auch nochmals Rechenzeit. Danach kommen nur noch Abstandsvergleiche. So gesehen bring Proximity auf 0 zu setzten nichts. Nur die Anzahl der Zonen und dort wiederum die Anzahl der Punkte ist für die Rechenzeit entscheidend. Deshalb werden die Garmins auch bei vielen Zonen so träge oder machen gar nichts mehr, nämlich dann, wenn die Koordinatenupdates schneller kommen, als die alten berechnet werden. Kann man dort nur umgehen, wenn man Player.RefreshLocation() selbst erstellt.

Alles in allem glaube ich eigentlich nicht, dass es eine zu "umfangreiche" Cartrtridge ist.

 

[WhitePawn]

Mich würde mal interessieren, wie viel Bilder du in der Cartridge hast bzw. wie viel Speicherplatz die in Summe (kB) belegen. Die Anzeige grafische Element ist generell etwas ressourcenhungrig.
Ich hatte an der Ecke allerdings bisher noch nie Probleme und für mich gehören einfach viele Bilder in einen WIG.
Ich vermute mal, daß auch die Bilder nur bei Bedarf geladen werden, alles andere würde keinen Sinn machen (zumindest hoffe ich, daß es so ist ).

 

[keogarl]

dank euch schon mal...

2. Klar gibt es so etwas wie Arbeitsspeicher.

Die Frage wäre, ob der eh "reserviert" ist, oder ob der vom allgemeinen Speicher abgezwackt wird.

3. Ich nehme an, dass der WIG am Anfang komplett in den Speicher gelden wird.

Dann wärs ja egal, wo er abgespeichert wird. hmm. die .gws und .gwl wird aber trotzdem da abgespeichert, wo die Cartridge ist..

5. Dabei werden Tabellen rekursiv abgespeichert.

Wie schaut denn so eine Tabelle aus? steht da z.b. der ganze Text drinnen? oder ist das quasi nur ein "Verweis" auf den Text. Kann man die irgendwo sehen, die Tabellen? Sorry, ich hab keine Ahnung wie man sich das so vorstellen kann..

6. Beim Oregon wird die Routine Player.ProcessLocation() ...

Ahh, super Infos! Echt interessant, was das Gerät eigentlich so treibt. Danke

Mich würde mal interessieren, wie viel Bilder du in der Cartridge hast bzw. wie viel Speicherplatz die in Summe (kB) belegen.

Also es sind 193 Bilder (230 breit), davon aber 30 icons. Insgesamt haben die Bilder eine Speicher von 2,63mb.

Hm, nun gut. Ich denke ich werde es bei Gelegenheit mal austesten, ob es einen Unterschied macht, was meine Überlegungen angeht. Einmal mit Trackaufzeichnung an, Cartridge auf proppevoller SDKarte und dann nochmal mit aufgeräumten sparsamen Gerät. Ich finds halt komisch weil ich bei meinem anderen WIG, der verhältnismässig "schlampig" programmiert wurde (weil erstes Werk) so gut wie nie Abstürze bei den Garmins gemeldet werden. Irgendwo muss ja ein Unterschied sein, mein "Programmierstil" ist ja der gleiche..

Karl

 

[Charlenni]

dank euch schon mal...

Die Frage wäre, ob der eh "reserviert" ist, oder ob der vom allgemeinen Speicher abgezwackt wird.

Ich nehme an, dass da immer ausreichend ist. Wenn Du nämlich die Cartridge in de Speicher laden kannst, dann ist schon das meiste passiert. Du erzeugst ja während des Spiels nicht so viele neue Objekte. Also: Cartridge lässt sich ohne Probleme laden -> Speicher reicht aus.

Dann wärs ja egal, wo er abgespeichert wird. hmm. die .gws und .gwl wird aber trotzdem da abgespeichert, wo die Cartridge ist.

Ist es auch. Wo die GWS Datei liegt ist völlig schnuppe. Liegt nur beim Garmin dort, wo die Cartridge liegt. Wichtig ist nur zu wissen, dass die Cartridge geladen wird, also alle Dinge in der Lua Datei außerhalb einer Funktion abgearbeitet werden. Danach wird die GWS Datei geladen und anschließend OnResume aufgerufen. Deshalb funktioniert auch die GWS Datei nur mit genau der Version der Cartridge, von der sie stammt.

.

Wie schaut denn so eine Tabelle aus? steht da z.b. der ganze Text drinnen? oder ist das quasi nur ein "Verweis" auf den Text. Kann man die irgendwo sehen, die Tabellen? Sorry, ich hab keine Ahnung wie man sich das so vorstellen kann.

Pech gehabt, Du hast gefragt und nun bekommst Du es auch

Save File Data Format Emulator (GWS File)
                
                 Signature: 02 0A 53 59 4E 43 00
                 Length of header in bytes: 4 byte
                 Name of cartridge as zero terminated string
                 Date of creation of cartridge: 8 byte (long in seconds since 2004-02-10 01:00)
                 Name of downloader? as zero terminated string
                 Name of device as zero terminated string
                 Name of player? as zero terminated string
                 Date of saving the cartridge: 8 byte (long in seconds since 2004-02-10 01:00)
                 Name of the save file as zero terminated string
                 Latitude: 8 byte (double)
                 Longitude: 8 byte (double)
                 Altitude: 8 byte (double)
                
                 Number of objects + 1 (#AllZObjects + 1 for player): 4 byte
                
                 For number of objects
                   Object name length: 4 bytes
                   Object name: length byte
                 End
                
                 Start of table (05)
                   Player as ZCharacter
                 End of table (06)
                
                 For number of objects
                   Object name length: 4 bytes
                   Object name: length byte
                   Start of table
                     Data for each object
                   End of table
                 End
                
                
                 Type of entry (first byte):
                
                 01: bool + 1 byte (0 = false / 1 = true), also nil as false (01 00)
                 02: number + 8 Byte for value (double)
                 03: string + 4 byte length + characters without \0
                 04: function + 4 byte length + bytes of dump
                 05: start of table
                 06: end of table
                 07: reference + 2 byte for ObjIndex
                 08: object + 4 byte length of type name string

Also es sind 193 Bilder (230 breit), davon aber 30 icons. Insgesamt haben die Bilder eine Speicher von 2,63mb.

In der Größenordnung sind meine Cartridges auch. Und die laufen eigentlich am Besten auf Garmins

Hm, nun gut. Ich denke ich werde es bei Gelegenheit mal austesten, ob es einen Unterschied macht, was meine Überlegungen angeht. Einmal mit Trackaufzeichnung an, Cartridge auf proppevoller SDKarte und dann nochmal mit aufgeräumten sparsamen Gerät. Ich finds halt komisch weil ich bei meinem anderen WIG, der verhältnismässig "schlampig" programmiert wurde (weil erstes Werk) so gut wie nie Abstürze bei den Garmins gemeldet werden. Irgendwo muss ja ein Unterschied sein, mein "Programmierstil" ist ja der gleiche.

Da bin ich mal auf Deine Ergebnisse gespannt.

Viele Grüße
Dirk

 

[jonny65]

Jaja, die jungen Wilden aus dem Süden, poste doch mal deine schlampigen Sourcen

The more points in a given zone, the more memory it takes. Finally, remember that all text (for example, descriptions) is also held in memory.
The more active zones you have, and the more complex they are, the less likely the GPSr is to get everything done in time.

On the bright side, media (pictures and sounds) are not stored in active memory. The definition of the media object itself uses some memory, but it does not include the actual picture or sound file.

Quelle : http://wherigobuilder.wikispaces.com/Limitations

Die Anzahl aktiver Zonen sind das Hauptübel, wenn dazu noch Timer laufen mit kleinem Zyklus, dann verstopft das Oregon förmlich. Neulich hatte ich einen Betatest, bei dem ein Timer lief, der jede Sekunde die Itemdescription aktualisierte und somit die Restzeit anzeigte. Mit Start des Timers war keine Eingabe mehr möglich, nicht mal mehr zurück ins Hauptmenü. Sogar ausschalten war nicht möglich, man musste tatsächlich die Batterien rausnehmen. Der Effekt war 100% nachvollziehbar und trat IMMER auf. Erhöhung des Timers auf 5 Sekunden und Anzeige der Restzeit im 5 Sekunden Takt 60...55...50 war dann die Lösung.

Und noch ein reproduzierbarer Absturz war drin : Ein SaveGame, während im Hintergrund ein weiterer kurzzyklischer Timer wuselte. Ein SaveGame Kommando also nur ausführen, wenn nichts läuft.

Absturz beim Betreten einer inaktiven Zone, sag ich jetzt mal : Ist unmöglich, zumal ich doch gar nicht weiß ob ich sie betrete wenn sie nicht da ist Oder meinst nicht sichtbar, aber aktiv ?

Ansonsten glaub ich nicht, daß eine Cartridge zu groß sein kann, als daß sie auf Garmin nicht laufen könnte. Es kommt nur auf die augenblickliche Ressourcenverteilung an.

Ich hab mal dein Pumuckl aufgemacht, diese "Servicehotline" : Genial :/

 

[keogarl]

Pech gehabt

ok,ok ich habe schon verstanden! Werd in Zukunft genau überlegen, was ich wirklich wissen will Danke Trotzdem für den Einblick...

poste doch mal deine schlampigen Sourcen

nö du, dann wird dann bloss wieder abgeschrieben

Der Auszug aus dem englischen bringst eigentlich auf den punkt, auch wenn ich das mit den vielen Punkten einer Zone nicht ganz bestätigen kann. Habe bei dem 1. WIG einen Abschnitt da sind 5 Zonen gleichzeitig, eine mit 25 und eine 40 Punkte. Da gibts so gut wie nie Garminprobleme.
Aber sehr gut zu wissen, dass die Bilder und Sounds definitiv "ausgelagert" sind.

Beim Neuen habe ich nur einen Timer an einer Stage, wos bisher keine Abstürze gab.

Oder meinst nicht sichtbar, aber aktiv ?

Du Meister, bin zwar noch nicht ausgelernt, aber der Unterschied ist sogar mir klar
Ist aber nicht auszuschliessen, dass das nur Zufall ist und es einen anderen Grund gibt, dass es genau diese Stelle ist.

"Servicehotline"

Ja die Hotline, wenn die nicht mal Grund allen Übels ist

Da bin ich mal auf Deine Ergebnisse gespannt.

Werde Bericht erstatten.

 

[jonny65]

Bezüglich den Zonen steht ja da, daß die Performance sinkt (wie wir alle wissen), sei es durch die Anzahl der Zonen als auch durch ihr Form bzw. Anzahl der Zonenpunkte. Von Absturzgefahr ist ja nicht direkt die Rede. Spiel mal im Inventar rum, wenn so 4 oder 5 Zonen aktiv sind, wie laaaaaaaaaang da die Reaktion eines Klicks dauern kann. Auffällig auch, wenn Inputs verarbeitet werden und danach einiges passiert. Hier besteht akute Absturzgefahr, wenn der Spieler aus Ungeduld (weil nix passiert) das panische Klicken anfängt.
Aber dürfte nur bei Anfängern passieren, die meisten wissen ja "Dem Gerät Zeit geben..."

Die Fehlersuche gestaltet sich schwierig bis unmöglich, wenn nicht JEDES Garmin an der GLEICHEN Stelle abstürzt. Sonst fällt es unter die Kategorie "Sporadischer-" oder "Anwenderfehler". Hier kann man höchstens mal nachfragen beim Spieler, ob und was er vor dem Absturz gemacht hat (am Gerät natürlich, nicht daß er sich grad ne Ziggi angezündet hat )

 

[GeoMagician]

Eventuell ist es hilfreich zu erfragen, wie groß der Textanteil (oder die Anzahl der Items, Character) des fraglichen Cartridge ist.

Meine eigenen Erfahrungen beruhen auf einem Garmin Colorado, sie sind also auf Oregon nicht unbedingt übertragbar.

Mein aktuelles Cartridge konnte ich vor einiger Zeit scheinbar nur durch Reduktion des Speicherbedarfs wieder auf meinem Colorado spielbar bekommen. Zuvor zeigte das Cartridge das extrem zähe Verhalten, wie es von Jonny bezüglich Zonepoints/Zones geschildert wurde. Zeitweilig verweigerte das Garmin mal früher, mal später an verschiedenen Stellen komplett die Zusammenarbeit. Da ich aber momentan nur 1,6 MB nutze (vor der Löschaktion ca. 2.3 MB), kann es eigentlich nicht direkt am Speicherplatz gelegen haben. Immerhin haben eure Cartridges ja 1 MB mehr Speicherbedarf.

Auffällig (besonders?) bei meinem Cartridge ist, dass ich unter anderem viel Wert auf eine umfassende Story gelegt habe. Grob überschlagen kommen so etwa 30k Text zustande. Bei den in http://wherigobuilder.wikispaces.com/Limitations erwähnten 64k Adressraum habe ich das Garmin vermutlich durch den großen Textumfang ins Abseits getrieben.

Zur Speicherreduktion habe ich damals etliche Bilder/Media (nebst deren Aufrufen im Cartridge) gelöscht. Danach war das Cartridge ohne weitere Eingriffe wieder auf Garmin (Colorado) spielbar. Ich nehme daher nach erneuter Lektüre des von Jonny zitierten Beitrags ...

Complex objects such as zones, characters and items are of particular concern. But all objects consume memory. There are no hard and fast upper limits on any given object. However, there are tradeoffs. If you define only a few items and characters, you can have more zones. If you define many, many items, you will be limited to fewer zones. Zone complexity is also a factor. The more points in a given zone, the more memory it takes. Finally, remember that all text (for example, descriptions) is also held in memory.

... an, dass die Anzahl der gelöschten Media Objekte nebst deren Programmcode mein Problem gelöst hat.

Die Abstürze habe ich übrigens bei meinen Betatests selbst beobachtet. Wildes Klicken o.Ä. kann ich also ausschließen. Anzahl der aktiven Zonen max. 3 oder 4.

 

[keogarl]

Eventuell ist es hilfreich zu erfragen, wie groß der Textanteil (oder die Anzahl der Items, Character) des fraglichen Cartridge ist.

wie bekommt man den Textanteil raus? in kbs?
ich habe in derCartridge:
15 Character
33 Items
24 tasks
44 Variablen
30 Inputs
92 functions
und 66 Zonen, soviel zu:

the lackeys recommend using no more than 10 zones in a single cartridge

Also was die das vorschlagen ist ja süß! 10 Zonen? Kein Wunder dass die amis soviele Wherigos aus dem Boden stampfen, wenn die alle so klein sind
So gesehen läuft mein WIG ja echt geschmeidig!
Wie aktuell dieser Eintrag wohl ist?

64k Adressraum

Was hats denn damit aufsich? Wo sehe ich, wie groß dieser Adressraum ist?

 

[GeoMagician]

wie bekommt man den Textanteil raus? in kbs?

Ich habe bei meiner Rechnung nur grob die Zeichen pro Zeile gezählt und dann mal eine Abschätzung der mitleren Dialoglänge vorgenommen. Genauer geht es sicherlich im Lua code. Da war ich aber zu faul

Also was die das vorschlagen ist ja süß! 10 Zonen? Kein Wunder dass die amis soviele Wherigos aus dem Boden stampfen, wenn die alle so klein sind
So gesehen läuft mein WIG ja echt geschmeidig!
Wie aktuell dieser Eintrag wohl ist?

Ich befürchte auch viele deutsche Wherigos werden über 10 Zonen nicht hinauskommen. Bezüglich der Aktualität vermute ich mal, dass er für Garmin Geräte zutreffend ist. Die Garmin Wherigo Software ist so (stein)alt wie der Beitrag

64k Adressraum - Was hats denn damit aufsich? Wo sehe ich, wie groß dieser Adressraum ist?

Das ist was für ganz alte Programmierer. Sehen kannst du das nicht (eventuell kann man das mit etwas Phantasie aus der *.gwc Datei ableiten). Ich gehe davon aus, dass ein Wherigo Cartridge nach dem Compilieren auf einem Garmin Gerät maximal 64k Speicher nutzen kann (Steinzeit halt). Wenn die Summe aus Programmcode und Text dieses Limit sprengt, bekommen wir Probleme. Zum Glück sind Bilder davon ausgenommen.

Ich werde für meine nächsten Cartridges mal die Episodenvariante versuchen.

 

[Charlenni]

Ich nehme an, dass sich das mit den 10 Zonen auf die Anzahl der gleichzeitig aktiven bezieht und nicht auf die angelegten.

Von der 64 kB Grenze wusste ich bisher nichts. Kann aber natürlich sein.

Um den Speicherverbrauch zu bestimmen bietet sich die GWS-Datei an. Diese enthält alle Objekte mit den entsprechenden Daten und alle Funktionen. Was nicht enthalten ist, sind freie Funktionen, also solche, die nicht zu einem Objekt gehören, und globale Varianlen, die nicht zur Cartridge gehören. Für eine grobe Abschätzung des Speicherverbrauchs also einfach die Cartridge abspeichern und alle freien Funktionen mit dem Lua-Compiler compilieren lassen. Beide Werte addiert ergibt dann den voraussichtlichen Speicherbedarf.

Und dass es in den USA so viel mehr Cartridges gibt als in Deutschland stimmt nach der letzten Auswertung von Jonny65 auch nicht. Es sind nur 3 Stück mehr bei insgesammt jeweils über 1000 Stück.

 

[keogarl]

Bzgl. Speicherplatz:
Hab gerade Feedback bekommen von einem Cacher. Dessen Oregon ist durchgekommen ohne Absturz. Er hatte die Cartridge auf dem Gerät nicht auf der Sd-Karte! Seiner Meinung kann das auch einen Unterschied machen, weil der eingebaute Slot einfach lahm ist (merkt man auch, wenn man Kartenmaterial drauf schieben will, geht viel schneller per Adapter am PC, als über USBKabel am Garmin direkt).

Es war allerdings so, dass er es richtig gemerkt hat, dass das Gerät immer langsamer wurde gegen Ende der Runde. Na da sammelt sich halt viel an..

Ich bin mir inzwischen sicher, dass es schlau ist, für die Englische Version eine neue Cartridge anzulegen. Ist halt nicht so pflegeleicht (weil Änderungen doppelt gemacht werden müssen), aber vielleicht ein wenig stabiler..
Eine Episodenversion geht von dem her schlecht, weil viele "Variablen" von Anfang an mitgeschleppt werden, dafür ist die Runde nicht linear genug..

 

[jonny65]

Wie ist denn das eigentlich mit dem internen Speicher und der SD Karte. Ich schließ mein Oregon an den PC an und bekomme 2 Wechsellaufwerke angezeigt. Auf dem einen ist der ganze Garmin Summs drauf inklusive (!) dem Wherigo Verzeichnis, auf dem andren Laufwerk sind die Maps. Heißt ja ich hab die Wherigos auch im internen Speicher. Und ich wüsste auch nicht, wie ich die verschieben könnte auf die SD Karte. Das Wherigo Verzeichnis einfach moven wird ja wohl kaum klappen. Die "GarminDevice.xml" macht zwar den Anschein, daß man hier was konfigurieren und andere Pfade mappen könnte, aber da fehlen die Angaben der Volumes, da stehen nur relative Pfade drin.

Ich glaub aber eher, daß es egal ist, wo was liegt. Der Speicher selber ist sicher noch zigmal schnell genug, der Prozessor lahmt. Ist so wie mit einem Pentium 133 MHz und großem und schnellen Speicher Streetview in Googleearth machen zu wollen.

 

[keogarl]

Das Wherigo Verzeichnis einfach moven wird ja wohl kaum klappen.

Doch genauso gehts. Ordner "Wherigo" im Hauptverzeichnis und rein mit den Kartuschen!

Inzwischen ist die "Speicherplatz-Frage" persönlich geworden, ich werde dem auf den Grund gehen, bzw. ich lasse meine Cacher dem auf den Grund gehen, hehe..

 

[Charlenni]

Dann hilft Dir vielleicht folgender Link: http://luatut.com/collectgarbage.html. Super erklärt und mit der Möglichkeit des sofortigen Tests versehen. Sehr schön gemacht. Wie ich gerade bemerke, leider in Englisch.

Dort wird beschrieben, wie man die Größe des augenblicklich verwendeten Speichers (siehe "count") in kB ermitteln kann. Mal 1024 ergibt dann Bytes.

print(collectgarbage("count") * 1024)

zeigt den Speicherbedarf in Bytes an. Um nun immer informiert zu sein, wie es mit dem freien Speicher abwärts geht, bietet sich die LogMessage Funktion an. Diese muss man nur durch eine eigene ersetzen. Könnte dann so aussehen:

OldLogMessage = Wherigo.LogMessage
Wherigo.LogMessage = NewLogMessage

function NewLogMessage(arg1, arg2)
  local message, level = nil, nil
  if type(arg1) == "table" then
    message = arg1.Text or nil
    level = arg1.Level or LOGCARTRIDGE
  else
    message = arg1 or nil
    level = arg2 or LOGCARTRIDGE
  end
  if type(message) == "string" then
    message = "(" .. tostring(collectgarbage("count") * 1024) .. " Bytes) " .. message
  end
  OldLogMessage(message,level)
end

Einfach den Code in die Author Scripte einfügen. So, wenn das dann ohne Probleme läuft ( ps: ), dann sollte vor jeder Textausgabe in der GWL-Datei der Speicherverbrauch in Bytes in Klammer stehen. Damit dürfte sich dann über ein Spiel nachvollziehen lassen, wie es mit dem Speicherverbrauch aussieht und ob es deshalb knallt.

Viel Glück!
Dirk

PS: Obiger Code ist leider nicht auf einem Garmin getestet. Könnte also auch Probleme machen
PPS: Ich bin sehr an den Ergebnissen interessiert .

 

[keogarl]

Einfach den Code in die Author Scripte einfügen.

äh, ich bin was diese ganzen scripte angeht vollkommen blank. verstehe ich das richtig, dass ich das (in Urwigo) in die "lua user functions" reinkopieren soll? Hab ich grad gemacht, bekomme aber vom Emulator nach dem Start die Ansage: "Error Message. Lua error Wherigo.lua:1041: 'attempt to call global logmessage (a nil value)"

Bin gerne bereit was auszuprobieren, allerdings brauch ich dann eine Anleitung für DAP (Dümmste anzunehmende Programmierer)

Soll(kann) dieser Code dann dauerhaft drinbleiben, oder gehts da eigentlich nur um die Betatests? Reicht es nicht das im Emulator durchzuspielen um auf den Speicherverbrauch zu kommen?

 

[Charlenni]

Tut mir leid. Heute ist eigentlich Mac-Tag, aber ich habe trotzdem mal die Windows-Kiste angeworfen

Wieder mal zu kurz geschossen. Also richtig ist:

function NewLogMessage(arg1, arg2)
  local message, level = nil, nil
  if type(arg1) == "table" then
    message = arg1.Text or nil
    level = arg1.Level or LOGCARTRIDGE
  else
    message = arg1 or nil
    level = arg2 or LOGCARTRIDGE
  end
  if type(message) == "string" then
    message = "(" .. tostring(collectgarbage("count") * 1024) .. " Bytes) " .. message
  end
  OldLogMessage(message,level)
end

OldLogMessage = Wherigo.LogMessage
Wherigo.LogMessage = NewLogMessage

Der Unterschied ist klar: Beim vorherigen wurde Wherigo.LogMessage vor der Definition der Funktion gesetzt und war damit nil. Jetzt wird sie nachher gesetzt und zeigt damit auf die Funktion.

Den Code fügst Du einfach in die Sektion "Lua Benutzer Funktionen" (so heißen sie, wenn Du Dein Urwigo auf Deutsch eingestellt hast) ein und startest Deine Cartridge. Im entsprechenden Verzeichnis (liegt dort, wo auch Deine Cartridge liegt und beginnt mit "run-") sollte nun eine Datei mit der Endung GWL erzeugt werden. Diese enthält alle mit der Funktion LogMessage ausgegebenen Einträge. Sieht dann in etwa so aus:

20131030123012|0.00000|0.00000|0.000|0.000|(212370 Bytes) Engine Version 2.11, Player Name: Mr. Smith, Device ID: Desktop
20131030123012|0.00000|0.00000|0.000|0.000|(212636 Bytes) ZCartridge:Start - Downloaded Wed Oct 30 12:30:09 2013
20131030123016|51.47810|0.00000|0.000|1.000|(222555 Bytes) ShowScreen - Details for Name
20131030123019|51.47810|0.00000|0.000|1.000|(232639 Bytes) ShowScreen - Details for Name
20131030123022|51.47810|0.00000|0.000|1.000|(243758 Bytes) MessageBox:Show - OnClick gedrueckt
20131030123023|51.47810|0.00000|0.000|1.000|(246263 Bytes) MessageBox:Callback - [Button1] No script to execute

Nach Datum und Uhrzeit (bis zum ersten "|") kommen Latitude, Longitude, Altitude und Accuracy. Und nun der für Dich interessante Teil: In der Klammer ist der aktuelle Speicherverbrauch der Cartridge zu sehen. Hier in diesem Beispiel ist zu erkennen, dass allein das Starten der Cartridge ca. 10 kB Speicher verbraucht. Ebenso der Aufruf von ShowScreen. Eine einfach MessageBox brauch dagegen nur ca. 3 kB beim Anzeigen.

Du kannst das eigentlich immer drin lassen, braucht halt wieder Zeit und Speicherplatz

Ich hoffe, jetzt ist es etwas klarer. Wenn Du noch Fragen hast, der Windows PC ist jetzt an

 

[keogarl]

Ich hoffe, jetzt ist es etwas klarer.

Jawoll! Jetzt geht's.
Was ich gemacht habe: ich habe in der momentan (auf wherigo.com) aktuellen Version schon das Grundgerüst für die Übersetzung angelegt, sprich u.a. bei jeder message eine if/else Sprachabfrage mit tw. schon übersetzt.
Das habe ich jetzt alles mal rausgeworfen. (in der Urwigo-Datei ca. 350kb weniger, immerhin).
Jetzt habe ich mal beide Versionen im Emulator angespielt mit deinem Code drauf. -> von Anfang an ist der Speicherbedarf der überarbeiteten Version 100-500kb niedriger. (ca. 1,9-2,5 mb)
Das heißt also, er läd alles rein, selbst wenn es noch nicht "aktiviert" wurde. Gut ist jetzt nicht soo erstaunlich, bestätigt mich aber eindeutig in der Entscheidung, für die englische Ver. eine eigene Cartridge anzulegen.

So, das hat jetzt aber nichts mit den von GeoMagician erwähnten 64kb zu tun, kanns ja nicht oder? mit 2,5mb wär ich da ja viel zu weit drüber. In der 1. Version sogar an die 4mb (und man darf ja auch nicht vergessen: bei einigen Garmins klappts ja anstandslos..)

Ich werde demnächst die ausgemistete Version vom Stapel lassen und hoffe, dass sich das dann auch bemerkbar macht. Nichtsdestotrotz habe ich ins Listing geschrieben, dass ich Garminnutzern rate, die Cartridge aufs Gerät zu speichern und den Track auszuschalten.

Danke jedenfalls Dirk für den Code, ich werd da noch weiter rumspielen, vielleicht find ich noch was raus und das wird natürlcih umgehend herausposaunt

Gruß karl

 

[jonny65]

Cooles Teil Dirk :/
Mit etwas Nachbehandlung des Logs bekommt man sogar ne Grafik raus.


@Karl : Wegen Wherigo Verzeichnis auf internem Speicher oder SD Karte. Geht tatsächlich. Es muss nur im Root stehen und "Wherigo" heißen. Ich habs spasseshalber mal "Hurzelfurz" genannt, dann wurden die Cartridges auch im Menü angezeigt (!!!), aber gleichzeitig wird ein neues Verzeichnis "Wherigo" im Root angelegt, in dem dann die SAVs und Logs gespeichert werden. Was passiert ist klar, das Spiel aus Hurzelfurz wird aufgerufen, ich speichere und die SAV landet in \wherigo\saves. Will ich einen Restore ausführen, geht das nicht, weil die GWC im übergeordneten Verzeichnis von Saves liegen muss. Egal, auf jeden Fall kann man die GWCs hier oder dort ablegen (Speicher oder Karte). Ich dachte, die Location ist statisch auf dem "Hauptlaufwerk". Manchmal soll man halt nicht denken.