Beide Fahrer hatten am Ende ein Streckenrekord von 5,760 sec, es wurde aber nur beim Ersten Fahrer so in die Bestenliste eingetragen.
Der Zweite Fahrer hat dort nur seine zweit schnellste Runde hinterlegt.
Ist es möglich das noch zu fixen?
Hey Holger,
Siehst Du das als Bug? Ich würde denken, dass es so richtig ist. Auch in der realen Welt (z.B. in der F1) zählt, wer die Zeit als erstes gefahren ist. Somit ist das Verhalten eigentlich korrekt. Und es wäre ja auch tatsächlich kein neuer Rundenrekord, wenn ein anderer Fahrer die gleiche Zeit nochmal fährt.
Wie siehst Du das?
LG,
Marc
Aber wenn mehrere Fahrer in die Streckendatenbank rein schauen um ihre Bestzeit anzuschauen, sollte doch die von Ihnen beste Runde dort unter ihrem Namen erscheinen.
Findest du nicht?
Hm, ich vestehe, was Du meinst, aber das ist nicht der Zweck der Streckenrekorde. Dort sollen wirklich nur die Rekorde für die jeweilige Strecke angezeigt werden.
Was Du meinst, entspricht vielleicht eher einem neuen Reiter in der Fahrerdatenbank, wo für diesen Fahrer für jede Strecke die jeweils beste Zeit gelistet ist. Könntest Du Dich mit sowas anfreunden?
LG
Ich öffne eine Strecke und schaue mir dort die Bestzeiten der jeweiligen Fahrer an. Soweit ja korrekt. Dann lese ich z.B. Fahrer a 5sec. Fahrer b 5.5sec Fahrers c 5.8 sec und nun kommt z.B. Fahrer d der auch 5.8 sec gefahren ist und der steht dann mit 5.9 sec drin weil das sein Record vorher war. Ich habe deine streckenbibliothek so verstanden dass sich dort jeder seine beste Zeit anschauen kann für jede Strecke und auch sieht wie seine Gegner gefahren sind. Wenn ich dann bei einer Strecke sehe, oh da sind drei Fahrer Zeitgleich dann ist das mehr informativ als da nur den vom Datum ersten Fahrer diese Zeit zuzusprechen. Es geht ja eigentlich nicht um den alleinigen Rubdenrekord sondern auch zu sehen wie die Bestzeit der anderen Fahrer dort ist und wenn da einer zeitgleich ist, dann ist diese eben so.
Ober verstehe ich das total falsch was mit dieser Funktion gewollt ist?
Hm, okay, verstanden. Dann schlage ich vor, es so umbauen, dass gleiche Zeiten ebenfalls bei den Rundenrekorden gespeichert werden, aber ohne dass die Meldung "Neuer Rundenrekord" ausgegeben wird. Wäre das eine brauchbare Lösung für Dich?
LG
Klasse genau so sehe ich das auch! Passt
Gerade noch aufgefallen, dass die gefahrene Bestzeit der anderen Fahrer nicht stimmen die hinter dem Erstplatzierten auftauchen. Kann das sein dass wenn der schnellste Fahrer ein Streckenrekord aufstellt, ab diesem Zeitpunkt die Zeiten der anderen Fahrer nicht mehr richtig erfasst werden und dort gespeichert werden.
Ja, die Rekordliste wird immer nur bei schnelleren Zeiten aktualisiert.
Das ist mir schon klar, aber das muss ja für jeden Fahrer gelten. Gestern bin ich 5.6 sec gefahren und der zweite Fahrer 5.7 sec. Meine Zeit stimmt in der Rekordliste, die des anderen Fahrers nicht. Dort steht 5.9 sec.
Ich glaube, jetzt habe sogar ich das Problem verstanden. So macht es natürlich keinen Sinn, das gebe ich sofort zu.
Ich werde daran nochmal basteln. Melde mich wieder. Danke für's Erklären :-)
LG
Hallo Marc
ich muss Holger zustimmen. Die Hierachie sollte so sein, das pro Strecke es wie auch auf Deinem YouTube-Video genannt pro Fahrer/Fahrzeug eine Streckenrekord gibt.
Bei zwei Fahrern und drei Fahrzeugen sind also sechs Einträge möglich. Dabei ist es unerheblich, in welcher Beziehung die Zeiten der Fahrer untereinander stehen. Es wird stets mit der vorhandenen Fahrer-Fahrzeug-Kombination verglichen. Schnellere Zeit - setzen des Eintrags, wenn nicht - dann nicht. Ein Init-Wert von 1000s sollte wohl reichen :-)
Gruß
Till
Wann kommt endlich ein Update? Seit über 4 Wochen ist jetzt diese fehlerhafte Version draußen. Da wär ich lieber bei der alten geblieben...
Servus Carsten,
Sorry, dass es etwas dauert, aber ich bitte um Verständnis dafür, dass SmartRace nicht meine ganze Zeit in Anspruch nehmen kann (obwohl ich manchmal wünschte, es wäre so). Ich habe ja noch meine Familie, meinen Beruf und viele andere Verpflichtungen.
Außerdem ist es technisch auch nicht ganz einfach, die Sache vernünftig zu implementieren und alles muss auf Herz und Nieren getestet sein. Dann brauche ich lieber länger und veröffentliche eine Version, wo es wirklich so klappt, wie es soll.
Schlussendlich möchte ich auch drauf hinweisen, dass wir hier nicht über einen schweren Fehler reden. Ja, die Funktion ist nicht so, wie es ein Teil der User erwartet - aber für andere ist das kein Problem. Aber wie dem auch sei: Ich habe ja schon weiter oben geschrieben, dass ich es umbauen werde. Und das versuche ich, so schnell wie möglich umzusetzen ohne die Qualitätsansprüche zu verwerfen, die ich selbst habe :-)
LG,
Marc
Gefixt in der 2.0.2. Das war ein harter Brocken. Ich hoffe, es klappt jetzt so, wie man es erwartet.
Release hoffentlich noch diese Woche :-)
Danke für Euer Input! Wirklich genial!
ok, schön! wobei mir nicht ganz klar ist, wo das Problem liegt, eine simple Liste zu verwalten. Das sollte ein Algorithmus mit 5 Zeilen sein...
Wie genau würde denn Dein Ansatz aussehen? Bin sehr interessiert.
Zunächst mal wird pro Fahrer/Fahrzeug ein Schlüssel gebildet. Hashkey oder einfach IDs konkatenieren. Bei jeder Runde (oder bei Rennen/Quali/Training nur die schnellste) wird geprüft, ob die Zeit zu den 20 schnellsten gehört. Falls ja, wird geprüft ob für diesen Schlüssel bereits ein schnellerer Eintrag existiert. Falls ja, muss nichts weiter passieren, falls nein, wird der langsamere gelöscht und der neue richtig einsortiert. Das wars.
Und das bringst Du in 5 Zeilen unter und berücksichtigst dabei, dass die gesamte Datenbankkommunikation (SQLite) naturgemäß asynchron abläuft und zu häufige Datenbankabfragen zur Laufzeit massive Performance-Implikationen haben können und stellst natürlich sicher, dass der Code auf beiden Zielplattformen und verschiedenen Geräten stabil läuft und auch korrekt funktioniert, wenn zur Laufzeit Zuordnungen von Fahrern/Fahrzeugen zu Controllern geändert und/oder Fahrer/Fahrzeuge/Strecken ganz gelöscht werden? Das will ich sehen :-)
Das sind ja nur if-Abfragen und simple array oder vector Operationen. Und natürlich schreibt man das Ganze nicht ständig während einer Rennsession in die Datenbank, sondern hält das nur im Speicher und updated erst am Ende. Während eines Rennens schaut sicher keiner in die Streckenrekorde. Ebensowenig wird während eines Rennens an der Zuordnung was geändert werden - und selbst wenn ist das nur das Anlegen eines neuen Schlüssels. Das einzige was wohl plattformspezifisch sein könnte, ist die DB-Kommunikation - und die sollte keineswegs während einer Rennsession erfolgen (wenn dem aktuell so ist, wundert mich allerdings nicht, dass es die von mir in einem anderen Issue geschilderten Verzögerungen gibt...).
Ich finde es sehr freundlich von Dir, dass Du versuchst, zu helfen. Und ich gehe ganz bestimmt nicht davon aus, dass ich die Weisheit mit Löffeln gefressen habe. Sonst wäre mein Code perfekt und man könnte sich diesen Bugtracker sparen. Aber um es mal deutlich zu sagen: Über den Aufwand von solchen Änderungen zu spekulieren, ohne auch nur eine Zeile des Codes gesehen zu haben, finde ich schon ziemlich anmaßend.
Du schreibst, dass Du die Änderungen nicht während einer Session in die DB schreiben würdest. Wie stellst Du dann die Persistenz sicher? Was, wenn der User die App einfach schließt, ohne die Session ordnungsgemäß zu beenden? Oder der Akku leer ist und sich das Gerät abschaltet? Oder sonstwas passiert? Sind dann die Zeiten aus dieser Session einfach weg? Und der Fall, dass während einer Session Zuordnungen geändert werden, ist absolut normal. Es gibt eine Menge Leute, die Sessions fahren, um Fahrzeuge untereinander zu vergleichen. Dafür würdest Du dann verlangen, eine neue Session zu starten? Ziemlich benutzerunfreundlich, findest Du nicht? Denkst Du nicht auch, dass es vielleicht *etwas* komplexer ist, als ein paar "if-Abfragen und simple array oder vector Operationen"?
Die Verzögerungen haben ihren Ursprung übrigens in der Bluetooth-Kommunikation (nur Android). Unter Android gibt es (anders als unter iOS) kein vernünftiges Queueing für Schreib-/Lesevorgänge auf BLE, was leider zu diversen Problemen führt. Das ist eine weitere Baustelle, die nicht ganz so einfach wegzuräumen ist...
Vielleicht klingt das ja auch anmaßend, aber ich entwickle seit über 40 Jahren Software und für die geschilderte Situation muss man keine Codezeilen sehen, sondern nur wissen, welche Architektur angemessen ist.
Ich glaube, wir verstehen etwas anderes unter "Session". Ich meine damit die Zeit während eine Fahrsituation herrscht (Rennen, Qualifying, Training - die ja alle einen definierten Start und Ende haben). Selbst wenn während eines Rennens die Fahrer gewechselt werden, gibt es dafür genau einen definierten Zeitpunkt und zwar wenn 'OK' im Zuordnungsbildschirm gedrückt wird. Genau dann könnte man Daten ebenfalls persistieren (zusätzlich zum Sessionende).
Wie sind hier auch nicht in der Kernkraftwerkssteuerung. Wenn der Nutzer die App während eines Rennens abschießt oder das Gerät abschaltet, sind die aktuellen Daten halt weg, das kennt der Nutzer schließlich von fast jeder Anwendung. Außerdem bekommt die App einen Schließversuch ja mit. Es macht keinen Sinn wegen eines extrem seltenen Sonderfalls seinen Code unnötig zu komplizieren.
Hallo Marc,
lass dich doch nicht ärgern :-)
Ich freue mich schon auf die Fehlerbereinigte Version diese Woche. Danke dafür !!!
Gruß
Holger
Carsten, wenn Du seit 40 Jahren Software entwickelst, dann dürfte Dir doch bestens bekannt sein, dass es ziemlich schwierig ist, Software in diesem Sinne "von außen" zu beurteilen. Und das, was Du als extrem seltene Sonderfälle bezeichnest sind Dinge, die ich sehr wohl berücksichtigen muss. Die meisten Nutzer von SmartRace sind alles andere als affin und haben keinerlei Verständnis dafür, wenn Dinge passieren, mit denen sie nicht rechnen. Und da es dann schlechte Bewertungen hagelt, muss ich manches berücksichtigen, was ich lieber ignorieren würde. Ich könnte mich jetzt stundenlang darüber auslassen, dass Software, mit der man seine Freizeit gestaltet (wozu SmartRace auch zählt) in vielerlei Hinsicht ein sehr sensibles Thema ist, wenn es um Fehler und Probleme geht. Wenn Du unterm Weihnachtsbaum sitzt und Deine neue Bahn ausprobieren willst, die App aber nicht klappt, steigt der Blutdruck rasant an. Wenn die eigene Freizeit betroffen ist, reagieren viele Menschen deutlich empfindlicher, als wenn im Büro Word mal wieder spinnt und "nur" Arbeitszeit verloren geht...
Aber ich schlage vor, wir belassen es dabei. Es gibt gute Gründe dafür, weshalb ich die Dinge so tue, wie ich sie tue. Und bisher war das ein recht guter Weg. Für konstruktive Vorschläge bin ich immer offen.
@Holger: Ich denke nicht, dass Carsten mich ärgern will. Wenn ich etwas gereizt reagiere, tut es mir direkt wieder leid. Aber ich bin etwas empfindlich, wenn Außenstehende Dinge als Kleinigkeiten abtun, über die ich mir tagelang den Kopf zerbrechen muss, damit sie für alle User zufriedenstellend (und möglichst fehlerfrei) funktionieren (was mir längst nicht immer gelingt, was mir auch bewusst ist und woran ich ständig arbeite). Ich denke, dass keiner sowas gerne hat - egal in welcher Branche ;-)
Ich bin bei alldem sehr froh, dass es Menschen wie Euch gibt, die sich die Zeit nehmen, Fehler hier zu melden und Dinge kritisch zu diskutieren - davon lebt das Produkt und jede Verbesserung daran. Deshalb vielen Dank für Euer Engagement.
You need to be logged in to add a comment.