Bug Bugs & Verbesserungen Community-API (CAPI)

[Jash]

Moin,

hier sollen kurz und bündig, Fehler (Bugs) und Verbesserungsvorschläge zur Community API (kurz CAPI) gemacht werden. 

Beste Grüße

Matthias

EDIT: um eine besser Übersicht zu erhalten und themenspezifisch antworten können, habe ich die Bugs und Feature Requests je in einen eigene Threads gepackt.

–––––––––––

 

[BUG] game_mode Freestyle

–––––––––––

 

[BUG] User-Agent bei iOS und Android unterschiedlich

 

Bearbeitet 5. Juli 2022 von Jash

[Jash]

[BUG] Nach Drift-App-Finish werden weiter Nicht-Finish-Targets-Events gesendet

 

 

–––––––––––

 

[VERBESSERUNG] Rückantworten vom Server in der Drift-App darstellen

 

Bearbeitet 5. Juli 2022 von Jash

[THR3360]

vor 9 Stunden schrieb Jash:

[VERBESSERUNG] Rückantworten vom Server in der Drift-App darstellen

Szenario:
Ähnlich wie beim "PING", wäre es sehr hilfreich, bei Fehlern bzw. Ablehnungungen die der CAPI-Server meldet, diese in der App als Message eingeblendet zu bekommen. Aktuell kann man manchmal ganz schön im dunkeln tappen, warum es zu keiner Verbindung kommt. Hier mal ein paar Beispiel-Response-Objekte:

{
	status: false,
	message: "Rennen wurde beendet. Es kann nicht mehr beigetreten werden."
}
{
	status: false,
	message: "Ein Fahrer mit deinem Namen/ID fährt gerade. Du kannst deswegen dem Rennen nicht beitreten."
}
{
	status: false,
	message: "Der Spielmodus <Fahren> wird von diesem Server nicht unterstützt."
}

Am Punkt /ping sind dem Server UUID, NAME, etc des Fahrers unbekannt

{
    status: false,
    message: "Ein Fahrer mit deinem Namen/ID fährt gerade. Du kannst deswegen dem Rennen nicht beitreten."
}

wird nicht funktionieren.

Besser wäre ein Rückgabewert im Punkt /entry

Oder einen weiteren Anspringpunkt vor /entry, meinetwegen /connect, in dem man die Zugangslogik unterbringen kann und von dort aus per status mitteilt, ob /entry (in der App) angesprungen wird.

Bearbeitet 15. Juni 2022 von THR3360

[Jash]

vor 2 Stunden schrieb THR3360:

Am Punkt /ping sind dem Server UUID, NAME, etc des Fahrers unbekannt

{
    status: false,
    message: "Ein Fahrer mit deinem Namen/ID fährt gerade. Du kannst deswegen dem Rennen nicht beitreten."
}

wird nicht funktionieren.

Besser wäre ein Rückgabewert im Punkt /entry

Oder einen weiteren Anspringpunkt vor /entry, meinetwegen /connect, in dem man die Zugangslogik unterbringen kann und von dort aus per status mitteilt, ob /entry (in der App) angesprungen wird.

Ich meine dass auch für spätere Events (enter, target, start, end), wo der Fahrer bekannt ist, Nachrichten an die App zurücksenden können.

[THR3360]

Das hätte allerdings zur Folge, daß alle Aufrufe per GET Request erfolgen und die Parameter in die URL wandern. (würde ich begrüßen, hab Probleme beim json parsen)

[Jash]

vor 2 Minuten schrieb THR3360:

Das hätte allerdings zur Folge, daß alle Aufrufe per GET Request erfolgen und die Parameter in die URL wandern. (würde ich begrüßen, hab Probleme beim json parsen)

Die Response hat nichts mit GET/POST zu tun. Ich geb aktuell schon diese Messages zurück vom Server. Werden halt nur nicht in der App angezeigt 😉 

[THR3360]

Ich hab da mal ne Frage:

 

/start

 signal_time => "2022-06-15T14:59:52.1009330Z",

 

/target

crossing_time => "2022-06-15T14:59:54.1009330Z",

target_code => 0,

Bedeutet das nicht, dass alle Fahrer auf der Pole sind? 🤔

Bearbeitet 15. Juni 2022 von THR3360

[Jash]

Bitte melde dich an um den Link zu sehen.

Bitte melde dich an um den Link zu sehen.

 Gibt es eigentlich ein Ticket-System für die Drift-App / Community API? Das wird glaub ich die Infos deutlich besser zusammenhalten, als hier im Forum.

[THR3360]

Frage zur UUID:

Wie wird die generiert? Ich ging davon aus, sie setzt sich iwie aus Account und Gerät zusammen und ist unveränderlich. Ich bekomme aber nach einer gewissen Zeit eine neue UUID!?!

[Jash]

Gute Frage, weiß ich aber leider auch keine Antwort drauf. Kannst du die Frage als eigenes Thema unter "Schnittstelle für externe Auswertungs-Software" posten? Hier unter "Bugs & Verbesserungen" passt das nicht so ganz.

Bearbeitet 17. Juni 2022 von Jash

[Zockermichi125]

Bitte melde dich an um den Link zu sehen.

General ist eine UUID ist eine unique Identifier. Das heißt er ist einzigart. Er wird meist anhand zufällig generierten Nummern generierten. Diese ist jedoch abhängig welche Version der UUID Generierung du verwendest. Generell ist die UUID Generierung aber unabhängig von Sturmkind.

Im Fall von Sturmkind wird die von dir angesprochenen UserID in Form einer temporären UUID genutzt. Das heißt dass, x Zeitraum bzw. jedes mal wenn du App schließt und öffnest eine neue UUID generiert wird und als UserID gesetzt wird. Also darfst dir so vorstehen wie eine Session UserID UUID. Das Verhalten hab ich auch schon bemängelt da diese zu vielen Problemen führt. Der beste Case wäre dass ein eindeutiger Identitifer (wie z.B. LizenzID des Users oder die wirkliche interne Sturmkind User ID) mitgeschickt wird. Leider gibt es aber da Probleme bezüglich Datenschutz.

[Decrayer]

Für Bugs sollten wir nen Tracker aufmachen, Verbesserungavorschläge bitte in den anderen Beitrag (Feature Requests) den ich schon erstellt habe. Zu den uuid: Am liebsten hätte ich ja die Sturmkind id gehabt, aber das ging wohl nicht. Deshalb hatte ich vorgeschlagen, eine uuid die jedes Rennen neu generiert wird aber während eines Rennens unveränderlich ist zu nutzen. Aktuell implementiert ist etwas irgendwo dazwischen, ist also aus meiner warte heraus eher ein Bug.

Bitte melde dich an um den Link zu sehen.

 User Agent: Der ist in der API nicht definiert soweit ich weis, darauf solltest du dich also nicht verlassen. Gibt es einen guten Grund wofür du den brauchst? Dann wäre das ein Feature Request.

Bitte melde dich an um den Link zu sehen.

Fehlermeldungen in der App anzuzeigen, können wir unter Feature Requests aufnehmen, erfordert aber GUI Anpassungen und auch erhebliche Vorsicht beim parsen der Inhalte. Die Racing Server können die ja trotzdem verschicken, sieht man ja dann in Netzwerktools wie Wireshark.

Bearbeitet 17. Juni 2022 von Decrayer

[Jash]

vor 5 Stunden schrieb Decrayer:

Gibt es einen guten Grund wofür du den brauchst?

Bitte melde dich an um den Link zu sehen.

 Ich nutz den User-Agent um Anfragen an den Server zu Routen. Somit kann ich die gleiche (einfachen) URL für verschiedene Dinge nutzen. 
 

Ausserdem gibt der User-Agent einen Hauch von Sicherheit, da die Server-CAPI  nicht mit einem anderen User-Agent erreichbar ist. 

[Zockermichi125]

Am 14.6.2022 um 22:37 schrieb Jash:

[BUG] Nach Drift-App-Finish werden weiter Nicht-Finish-Targets-Events gesendet

Szenario:
Wird z.B. ein 10 Runden-Rennen gefahren, so werden nach der letzten Runde ("Finish") keine Ziel-Targets-Events mehr gesendet, jedoch alle andren Targettypen werden bei Überfahrt an den CAPI-Server weiterhin übermittelt

Erwartung:
Es dürften nach dem "Finish" überhaupt keine Target-Events mehr an den Server gesendet werden.

Walkaround:
Alle diese "After-Finish-Target-Events" besitzen den gleiche "Finish-Event"-Crossing-Time-Wert. Damit können diese Events herausgefiltert werden.

 

–––––––––––

 

[VERBESSERUNG] Rückantworten vom Server in der Drift-App darstellen

Szenario:
Ähnlich wie beim "PING", wäre es sehr hilfreich, bei Fehlern bzw. Ablehnungungen die der CAPI-Server meldet, diese in der App als Message eingeblendet zu bekommen. Aktuell kann man manchmal ganz schön im dunkeln tappen, warum es zu keiner Verbindung kommt. Hier mal ein paar Beispiel-Response-Objekte:

{
	status: false,
	message: "Rennen wurde beendet. Es kann nicht mehr beigetreten werden."
}
{
	status: false,
	message: "Ein Fahrer mit deinem Namen/ID fährt gerade. Du kannst deswegen dem Rennen nicht beitreten."
}
{
	status: false,
	message: "Der Spielmodus <Fahren> wird von diesem Server nicht unterstützt."
}

Den Punkt finde ich auch sehr wichtig. Jedoch muss ich noch was anfügen zum Thema "message". So wie du das Objekt momentan zurück gibt's wird eh nicht optimal funktionieren da eine Internationalisieurng innerhalb der Drift APP vorhanden ist. Als müsste man entweder die Lokalisierung im Accept-Language Header mitschicken lassen von der App oder man schickt eine Dictionary was die ganzen Messages mit Übersetzungen hat. Die zweite Lösung ist aber die unvorteilhaftere da wenn z.B. die Drift App mehr Sprachen unterstützt und du nur einen Teil unterstützt bzw. mitschickt, es schwierig wird es zu handeln. Deswegen preferriere ich die Lösung mit dem Accept Language Header da man dann auch beispielsweise User nicht ins Rennen lassen kann wenn man die Sprache z.B. nicht unterstützt.

Auch das Schema des JSON wie du aufgebaut hast ist inkosistent.
Am besten wäre ein Schema wie dieses hier:
 

{
  "status": false,
  "messages": {
    {
		"text": "Das Rennen ist bereits voll. Du kannst nicht mehr beitreten.",
	}
  }
}

 

Ich hätte noch einen anderen Vorschlag. Ich denke den könnte man relativ einfach bauen. Und zwar sollte man die Möglichkeit haben bei einen Rennen die Rundenzahl auf Unlimited zu setzten. Am besten indem das Field "laps_count" im Response Payload einfach auf null setzt.

[Dr!ft-MaBo]

Hey

Bitte melde dich an um den Link zu sehen.

 hier kurz die Beschreibung, die zwar nicht nur mit der API zu tun hat, aber trotzdem interessant fürSturmkind sein könnte:

 

Hat man ein Handy mit WLan verbunden (WLan ist nicht online / sei es absichtlich oder der Provider hat eine Störung) und startet dann die App, dann lädt die DR!FT App NICHT! Der Ladebalken bleibt bei ca. 1/4 stehen und es passiert nichts mehr.

Handy im Offline WLan -> DR!FT App starten -> DR!FT App lädt nicht und der Ladebalken bleibt bei 1/4 stehen

Handy ohne WLan und ohne mobile Daten (komplett offline) -> DR!FT App starten -> DR!FT App lädt und startet ganz normal

 

Anscheinend erkennt die DR!FT App, dass es eine Möglichkeit gibt (wenn mit WLan oder mit mobile Daten verbunden) sich mit Sturmkind zu verbinden, ist man nun aber beim Start der DR!FT App mit einem offline WLan verbunden scheitert dies, hier sollte Sturmkind ggfs. einen Timeout in die DR!FT App einbauen und dann die App so starten, als wäre das Handy "mit nichts verbunden / komplett offline".

 

Das ganze wirkt sich im Endeffekt auch auf die API aus:

Handy im Offline WLan -> DR!FT App starten -> DR!FT App lädt nicht und der Ladebalken bleibt bei 1/4 stehen

Handy ohne WLan und ohne mobile Daten (komplett offline) -> DR!FT App starten -> DR!FT App lädt und startet ganz normal -> nun mit Offline WLan verbinden und ich kann mich mit dem lokal laufenden Server ohne Internetanbindung verbinden

 

Ich hoffe, ich konnte es einigermaßen erklären. 😅

Bitte melde dich an um Bilder zu sehen.