Dword

Was für ein blödes Spiel. Mehr fällt mir dazu nicht ein.

Wenn du keine Antwort hast ist das Tablett eher bleiern, weil gelogen. Und das wiederrum schreckt vom Lesen ab.

Mach deine Beiträge doch bitte interessant indem du eine Antwort auf meine Frage gibst. Ich möchte keine 681++ Beiträge durchmischt mit Off-Topic Inhalten für eine kurze Information durchsieben.

Na dann bitte ich um Aufklärung. Was für grundlegende Daten gibts noch bis auf Alter und Trefferhäufigkeit?

Ja - neue Idee in der Verarbeitung, oder der Datenerfassung. Und in der Datenerfassung gibts doch prinzipiell nur die beiden, oder liege ich da falsch?

Ja, aber worauf sollen diese Ideen denn beruhen? Die erhobenen Daten für ein KG-fremdes System sind doch Alter und Trefferhäufigkeit. Ich habe mir auch den Kopf zerbrochen was man da noch sammeln könnte, lande aber am Ende immer bei diesen beiden.

Hallo sachse, 1. Was ist an der Messung des Kessel so schwierig? Die wechselnden Farbwerte der Pixel in den Griff zu kriegen. Sie sind nicht immer gleich, sondern wechseln sich ab. Haben Hoch-, Tief- und zwischenwerte. Stell es dir bitte so vor, dass ich eine Flut an Daten (Pixelposition und -farbe) in bestimmten Zeitabständen sammle und anhand der Unterschiedlichen Farbwerte einordnen muß was das alles in der Summe zu bedeuten hat. Da die Messung der Rotorgeschwindigkeit mit der Messung der Kugel verwand ist und eigentlich die Vorstufe dazu darstellt (keine relative Veränderung der Position der Fächer zur Mitte des Rads), bezeichne ich sie als leicht. Die Kugel verändert die Position, weswegen da ein aufgezeichneter Strich notwendig ist und nicht nur ein Pixel, wie beim Rad. Zur Veranschaulichung möchte ich ein sehr vereinfachtes Beispiel bringen, in dem die Aufzeichnungsrate eines Pixels 1/4 Sekunden beträgt. Farbe 1: 0 Farbe 2: 1 Daten: 1 0 0 0 0 0 0 1 In der ersten Sekunde befand sich die Farbe 2 an Position 1/4 Sekunden. In der zweiten Sekunde an Position 4/4 Sekunden. Jetzt muß man aus diesen Daten ermitteln was passiert ist, wozu ich einfach noch kein Gedankengebäude habe. Ich betrette hier Neuland mußt du wissen. Das ich scheitern werde ist eine Möglichkeit. Deswegen ja auch erstmal kleine Gehversuche und kein großartiger Hirnschmalz, den ich investiere, bevor ich keine Bestätigungen erhalte. Gruß, Dword

Hallo elementaar, gut, kein Problem. Das dürfte genau so wie die Kugelgeschwindigkeit leicht sein. Im Prinzip sogar einfacher, weil sich die Position der Fächer relativ zur Mitte hin nicht verändert. Ich würde in dem Fall einfach einen einzigen Pixel nehmen und die wechselnden Farben mit einer Rate von 1/1000 Sek. aufzeichnen, was den kleinsten Abstand der Timer in meinem Werkzeug darstellt. Mal schauen. Gruß, Dword

Das stimmt. Das liegt an der schwankenden Framerate IMO. Mal schneller, mal langsamer. Ob man das kompensieren kann weiß ich nicht, da ich bisher keine Erfahrung darin habe. Wäre auch ein Test für die Käfig-Software, ob sie die korrekte Position des Rotors vorhersagen kann. Die Framerate des Streams zu messen vermag ich leider nicht, wegen des feinen rauschens. Ich arbeite mit dem Zugriff auf die Darstellung des Bildschirms durch das Betriebssystem, weswegen auch die Verabeitungsgeschwindigkeit so langsam ist bei hoher Pixeldichte.

1. Die Absagen, die ich beobachtet habe, erfolgten etwa 5 Kugelrunden vor Fall der Kugel. Bei der schnellen Rotorgeschwindigkeit ist das für erfolgreiches KG zu früh. Aber nicht jede Runde hat eine hohe Rotorgeschwindigkeit. Wäre somit ein Kriterium für Ausschluß der gespielten Runden. 2. Das Bild ruckelt und der Kessel ist nicht vollständig zu sehen. Das das Bild ruckelt ist mir echt nicht aufgefallen... man könnte das aber nachmessen, sobald die Käfig-Software steht. Das der Kessel nicht vollständig zu sehen ist halte ich für einen guten Test der Glaubwürdigkeit der Software. Wenn sie die Position der Kugel, sobald sie wieder sichtbar wird, korrekt berechnet, ist es ein gutes Zeichen IMO. 3. Der Laden gefällt mir ohnehin nicht, weil sie mir, als ich dort war, gleich nach der ersten Auszahlung keine Einsätze von mir mehr angenommen haben. Das ist etwas anderes. Echter Käse...

Guten Abend, heute habe ich ein meines Wissens nach neues Angebot gefunden, das ich sogleich in diesem Spiel hier ausprobiert habe. -> www.globallivecasino.com/de/game/portomaso-live-roulette-1/fun/ Das Ergebnis lautet 143 Stücke plus. Es dauerte 104 Coups, bis die 12 gefallen ist und das Spiel beendete. Stop, Graph und Schnappschuß aus dem letzten Coup liegen bei. Gruß, Dword

& @sachse Ich habe jetzt ein meines Wissens nach neues Angebot entdeckt und es heute Abend wegen meines anderen Spiels ausprobiert. Würdet ihr beide es euch bitte anschauen und eure Meinung zu den dortigen Bedingungen abgeben? Die Absage findet - zumindestens im Fun-Modus - nach mehreren Kesselrunden der Kugel statt. -> www.globallivecasino.com/de/game/portomaso-live-roulette-1/fun/ Wegen meiner Software: Ich arbeite gerade an einem Käfig, der nicht jeden nötigen Pixel erfasst. Die Verarbeitungsgeschwindigkeit schwankt. Was ich davon halten soll weiß ich noch nicht, ich müßte erst einen Test im Kasino machen.

Ich habe jetzt mal einen Test der mir vorschwebenden Erfassungs- und Verarbeitungssoftware gemacht, weil ich zum einen neugierig war und dies zum anderen neben dem Sinn des ersten Versuchs auch ein Kriterium Pro/Kontra ist und muß leider schlechtes berichten. Das ganze ist einfach viel zu langsam... Um ein gutes Ergebnis zu bekommen ist schon eine bestimmte Auflösung nötig und die vielen Pixel sind dann doch zuviel für die Verarbeitungsroutinen, die ich einsetze... Tja - ab in die Schublade mit dem Projekt, bis ich dafür eine Lösung finde.

Ich würde sagen, dass es sich dabei um kleine Unterschiede in der Geschwindigkeit der Kugel handelt. Gehört zu den Dingen, über die ich mir erst Gedanken machen möchte, wenn der Versuch positiv gelaufen ist. Bis dahin möchte ich noch kein Gedankengebäude aufbauen.

Das erste liesse sich vielleicht unter Toleranz verbuchen. Immerhin ist für den ersten Versuch ein ziemlich großes Landungsfeld vorgesehen. Das zweite wäre der Todesstoß, der aber erst bestätigt werden muß.

Bitte: 1. Meinst Du die OCs haben nur auf Dich gewartet??!! Dazu habe ich keine Meinung. 2. Wieviele Stunden hast Du schon Roulette gespielt, am Kessel gestanden???? Zuviele. 3. Hast noch nie was von chaotisch werfenden Croupiers gehört???? Das ist irrelevant, weil ich die Geschwindigkeit der Kugel im Live-OC messen könnte. 4. Oder hats Du sie schon in Echt gesehen???? Ja.

Ich glaube auf die Fragen eingegangen zu sein und beschrieben zu haben, wie das ganze ablaufen würde...

Kennst du einen Fall wie den meinen, der würde mich nämlich interessieren. Bilderkennungssoftware in einem Live-OC...

Ich denke KG sei der Königsweg...

Jep, alles Unbekannte, die du auflistest. Das bescheidene Ergebnis würde eine Bestätigung darstellen. Es wäre die erste Sicherheit, die ich für mich im Roulette-System gefunden hätte. Der normale, störungsfreie Lauf der Kugel und die Formel dafür wären Ausgangspunkt für weitere Lösungen. Wenn ich ein wenig phantasieren soll würde ich sogar soweit gehen von einem virtuellen Käfig für den Kessel zu sprechen, den ich über die Aufnahme legen könnte um alle Bewegungen der Kugel festzuhalten und so Schritt für Schritt die Eigenschaften des Systems zu erfassen.

Nun, laut Versuchsaufbau ist der rotierende Kessel nicht nötig. Ich weiß nicht was bei dem Versuch heraus kommen wird, denke aber auch, dass gleiche Geschwindigkeiten wenn, dann nur sehr selten in die Daten einfliessen würden. Vielleicht gibt es aber Übergänge. Man würde es sehen. Die Erkenntnis würde mir eine Bestätigung geben und weitere Mühen rechtfertigen. Sie wäre der Grund für alles kommende. Die störenden Rauten... tja - vielleicht läßt es sich später eine Lösung dafür finden, wenn die Bestätigung weiteren Hirnschmalz rechtfertigt.

Hallo elementaar, 1. geht es um reinen Erkenntnisgewinn, oder ist eine mögliche praktische Anwendung mitgedacht? Im letzteren Fall muß der Absagezeitpunkt mit einfließen. Bei dem beschriebenem Versuchsaufbau, den ich zunächst umsetzen möchte, geht es erstmal nur um den Ekenntnisgewinn. Ich erhoffe mir eine statistische Bestätigung, dass eine bestimmte Geschwindigkeit sehr wohl mit dem Fall der Kugel in einem bestimmten Sektor zu tun hat. Für weiteres wäre es nämlich IMO nötig zusätzlich den Winkel zu erfassen, in dem das geschah, was der Identifizierung der Fächer dienen würde. Was meinst du mit Absagezeitpunkt? 2. das Vorhaben ist arbeits- und zeitintensiv, und weil man bei manchen Live-OCs vom Tisch verbannt wird, wenn man einige Zeit nicht setzt Das stimmt. Es spricht aber nichts dagegen sich wieder einzuloggen, nachdem das passiert ist. Der Versuch muß sowieso bemannt stattfinden, weil meine Software noch nicht die Unterscheidung zwischen links und rechts rum gedrehten Coups beherrscht. Desweiteren müßen chaotische Coups markiert werden um mögliche, statistische Abweichungen von vorn herein als solche zu kennzeichnen. 3. - evtl. Identifizierung des Croupiers vorsehen. Das ist leicht machbar, jedoch für den Erstversuch IMO nicht notwendig, da die erhobenen Daten noch zu grober Natur sind. Ich möchte ja erstmal nur wissen ob und was für eine eine Häufung es bei welchen Geschwindigkeiten in den starren Sektoren gibt. Später wird das wichtiger, wenn ich zusätzlich den Winkel des Falls erfasse, um die Gewohnheit des Croupiers einzugrenzen. 4. etliche Live-OC bieten keinen ungeschnittenen Blick über den ganzen Zeitraum Abwurf-Treffer-Ort, manche auch keine unveränderte Umschnittroutine bei jedem Coup (warum wohl?). Korrekt. Das Live-OC in dem ich es vorhabe unterteilt das in 2 Szenen. Frage ist, ob man auf die ersten Paar Augenblicke verzichten kann, oder ob ich für beide Szenen seperate Versuchsaufbauten benötige, was die Sache später verkomplizieren würde, jedoch machbar wäre. 5. Bei dem bewußt einfach gehaltenen Aufbau Deines Versuchs, ist das Problem gewiß lösbar, aber so ganz einfach zu programmieren wird es auch nicht sein. Das Programm würde zunächst nur die Geschwindigkeit selbstständig festhalten und das ist ein leichtes. Bei weitem schwieriger wird es sein die Spirale der Bahn nahtlos zu erkennen und noch schwieriger der Software beizubringen den richtigen Winkel festzuhalten, wenn die Kugel fällt. Deswegen ja auch erstmal die Hoffnung auf Bestätigung im einfachen Versuchsaufbau, bevor ich mich daran mache. @MarkP. 1. LAAAAACH Na, wenigstens habe ich dich zum Lachen gebracht! Aber im Ernst. Ich erhoffe mir genauere Ergebnisse als im richtigen KG, das du empfiehlst... Gruß, Dword

Und warum? Um eine Prognose auf eine Zahl machen zu können braucht man zusätzlich das drehende Rad in der Mitte. Man braucht es aber nicht, wenn man nur wissen möchte wo die Kugel absolut landet. EDIT: Zumindestens so mein Ansatz... wie ich ihn mir vorstelle.

Hallo hermann, tschuldige die Verwirrung. Ich meine mit starrer Einteilung des Kessels, die sich nicht bewegt, die Einteilung des Bildschirms. Ich lege sozusagen 4 unbewegte Quadrate auf den drehenden Kessel und schaue in welchem der Quadrate die Kugel gefallen ist. Es ist erstmal irrelevant welche Zahl getroffen wurde. Wichtig wäre mir nur in welchem Sektor des Bildschirms das geschah. Ich bin beides - Theoretiker und Praktiker. Schau: Wenn sich ein Zusammenhang zwischen der Geschwindigkeit und den Treffern in den Sektoren abzeichnen würde, so hätte man vielleicht bei genügend gesammelten Daten die Basis für eine Formel, die eine Norm für den Kessel, an dem erfasst wird, darstellen würde, die wiederrum natürlich nicht immer stimmen würde, da statistische Abweichungen inform chaotischer Ereignisse nun mal auch vorkommen. Ich denke schon zu wissen worüber ich rede, nur bringe ich es scheinbar nicht klar genug rüber. Verstehst du jetzt ein wenig mehr? Wenn nicht, dann frag ruhig. Gruß, Dword EDIT: Nur noch mal kurz, weil das LC erwähnt wurde. Der Vorteil des Live-OCs ist IMO, dass ich hier mit Bilderkennungssoftware arbeiten kann und deswegen genauere Daten erhalten könnte, als es in einem LC möglich wäre. Ich bin nicht Crack genug es direkt aus dem Stream zu entnehmen, jedoch denke ich, dass der Ansatz, den ich in meinem Bot benutze, der sowohl die Permanenz erfasst, als auch alleine spielen kann, dafür vollkommen ausreichend ist. Man könnte theoretisch die Spirale der Kugel aufzeichnen und sie vielleicht mit der Geschwindigkeit der Kugel inform einer Formel kombinieren. All das aber ist Arbeit, die ich erst dann machen möchte, wenn sich ein Funke Hoffnung am Horizont abzeichnet und zwar inform der Bestätigung, dass da ein Zusammenhang besteht. Eine grobe, leicht zu realisierende würde vollkommen ausreichen. Deshalb das hier vorgestellte.

Servus hermann, 1. Zwischen welchen Zahlen findet die Einteilung statt? Zwischen garkeinen. Ich stelle es mir so vor, dass ich den Bildschirm in 4 Sektoren einteile und im Moment des Einschlags den Sektor festhalte, in dem das stattfand. 2. Wird Rechtslauf und Linkslauf getrennt aufgeschrieben? Ja. 3. Allerdings nur beim selben Croupier. An der Geschwindigkeit der Kugel ändert doch aber auch ein anderer Croupier nichts, oder? Ich stelle mir ein mögliches Ergebnis so vor, dass ich sowas wie einen fließenden Übergang zwischen kleinen Geschwindigkeitsunterschieden als Ergebnis bekomme, natürlich auch mit statistischen Abweichungen. 4. Oder wird von jeden Sektor die Treffer gezählt? Erstmal geht es nur darum die starren Sektoren auszuwerten um zu schauen, ob sich da etwas erkennen läßt, da die Einprogrammierung des drehenden Rads eine Spur mehr Arbeit bedeutet. Ich möchte mal gucken, ob sich das überhaupt lohnt, genau so, wie ich den Gedankengang hier zur Diskussion stelle. Gruß, Dword