Ich klinke mich jetzt hier aus - Mir raucht der Schädel von deinem Beitrag - Unnötig, wenn eh immer ein Fahrzeug dablieben soll, sowieso. Warum dann die mühe machen das zu Programmieren?! Ob jetzt 10 Fahrzeuge von einem vor Ort sind oder "nur" eines ist doch egal (Viele Hände - Schnelles Ende) Der Vorschlag macht nur das Verbandsleben kaputt, denn dann kann ich ja gleich alleine Spielen.
Ich bleib dabei dagegen - Auch wenn es ne Option zum Ausschalten gibt.
In diesem Sinne, Thema deabonniert
Folgender Edge-Case klappt nicht: Einsatz benötigt 3 LF. Spieler A hat 2 LF vor Ort. Spieler B hat auch 2 LF vor Ort. Was passiert? Und um es noch schöner zu machen: Beide LF kommen zeitgleich an.
Dazu die Geschichte: Was ist mit
- MTF
- WLF
- GW-Wasserrettung
- MLW V
- Dekon P
? Alles Fahrzeuge, welche nicht direkt benötigt werden, aber einen Mehrwert (Material/Personaltransport/Geschwindigkeitsboost) haben.
Folgender Edge-Case klappt nicht: Einsatz benötigt 3 LF. Spieler A hat 2 LF vor Ort. Spieler B hat auch 2 LF vor Ort. Was passiert?
Erst einmal danke, dass du das Ganze inhaltlich aufgreifst und auch Sonderfälle benennst. So kommen wir am besten weiter. Ich sehe jetzt auch im Nachgang, dass du am LSSM mitwirkst. Umso besser, den benutze ich auch und wir können auf einer technischen Ebene reden, ohne dass sich jemand angegriffen fühlt.
Für den zitierten Fall müsste es sich um zwei Premiumspieler handeln, aber eben weil beide Premium haben, kann der Fall nicht eintreten. Denn dann wären nur 3 LF insgesamt vor Ort. Auch das berücksichtigt der Algorithmus natürlich und ist selbstheilend über Abschnitt 2), falls bei einer Umstellung vom alten auf ein neues System dieser Fall doch für bestehende Einsätze eintrifft. Grenzfälle müssen immer behandelt werden, denn ansonsten wäre eine Lösung keine solche. Aber bei dem geschilderten Edge Case ist bereits die Prämisse ungültig, denn Abschnitt 1) im Algorithmus verunmöglicht diesen Fall. Geh doch einfach mal hin und versuche über Abschnitt 1) jeweils 2 LF von einem Premiumspieler zu platzieren. Nachdem drei da sind wird das vierte zurückgewiesen, es sei denn es ist ein ersteintreffendes Fahrzeug eines weiteren Premiumspielers oder eines von Nichtpremiumspielern.
Hier mal ein paar Szenarien bei denen 3 LF benötigt werden:
1) A und B sind Premiumspieler.
1.1) A hat 1 LF am Einsatzortort und von B treffen weitere ein. Für A bleibt das LF, für B werden 3-1=2 LF behalten, alles weitere zurück geschickt. A=1, B=2.
1.2) A hat 2 LF am Einsatzort und von B treffen weitere 2 LF ein. Eines von B wird behalten, das andere zurückgeschickt. Beachte, dass nur ersteintreffende LF von Premiumspielern behalten werden. A=2, B=1.
1.3) A hat 3 LF am Einsatzort und von B treffen weitere 2 LF ein. Dann wird das zuerst eingetroffene von A zurück geschickt, verbleiben 2. Von B wird nur ein LF behalten, es können also nur Nichtpremiumfahrzeuge und ersteintreffende Fahrzeuge anderer Premiumspieler das zweite LF von A verdrängen. A=2, B=1.
2) A ist Premiumspieler, B und C nicht
2.1) A hat 3/3 LF vor Ort. B und C senden jeweils auch 3 LF's. Dann behält A=1, B=3 und C=3 LF.
3) A und B sind Premiumspieler, C nicht
3.1) A hat 3 LF vor Ort. B sendet 3. Das erste ersetzt ein LF von A, das zweite und dritte LF von B wird zurück geschickt. Also A=2, B=1, C=0. Nun sendet C danach 3 LF. Endet in A=1, B=1, C=3.
3.2) C hat 3 LF vor Ort. A und B senden danach jeweils auch 3 LF. Verbleiben C=3, A=1, B=1 LF.
Man sieht deutlich, dass in jedem Szenario die Fahrzeuge von Premiumspielern auf ein mögliches Minimum reduziert werden. Es wird versucht die Anzahl auf 1 herunter zu drücken.
Und um es noch schöner zu machen: Beide LF kommen zeitgleich an.
Es stellt sich natürlich die Frage nach der vorhandenen Infrastruktur und ob Datenbank oder vielleicht auch Message Streaming parallelisiert ausgeführt werden. Landen eintreffende Fahrzeuge in einer Queue um sequentiell in eine Datenstruktur geschrieben zu werden, so gibt es keine zwei gleichzeitig eintreffende Fahrzeuge in dem Sinne, da jedes einen geringfügig anderen Zeitstempel haben wird. Mit genügend Nachkommastellen lässt sich auch bei geshardeten Datenbanken in der Regel eine Art Erfassungsreihenfolge feststellen, selbst bei mehreren Millionen Schreibzugriffen pro Sekunde.
"Zeitgleich" ist ungünstig ausgedrückt, denn Zeitpunkte werden über reelle Zahlen abstrahiert, und diese können beliebig kleine Nachkommastellen aufweisen. Das ergibt nur unter Kürzung unter festgelegen Schemata und Überführung der Ergebnisse in ein darauf abgestimmtes Intervall einen Sinn. Allgemein ist ein zeitgleiches Ereignis stochastisch unmöglich bei nur abzählbar vielen Ereignissen. Denn in einer überabzählbaren Menge haben einzelne Punkte oder auch Punktmengen eine Wahrscheinlichkeit von null um betrachtungsrelevant zu werden. Zu beachten ist hierbei, dass selbst Milliarden an Ereignissen in einer Millisekunde noch zu wenig sind.
Aber gehen wir davon aus, es wäre möglich, dass zwei LF mit dem gleichen Zeitstempel eintreffen. Dann müssen wir uns eine Kollisionsbehandlung überlegen. Fakt ist, wir legen fest was dann geschehen soll und können es uns aussuchen. Ganz einfach kann man das behandeln indem man beispielsweise beide Fahrzeuge einem Leader-Election-Verfahren aussetzt. Das kann vielfältig umgesetzt werden:
- Geben wir Fahrzeug A das Intervall [1, 50] und B das Intervall (50, 100], beide in den natürlichen Zahlen. Dann brauchen wir nur eine natürliche Zufallszahl zu generieren im Intervall [1, 100].
Für n Fahrzeuge ergeben sich folgende Intervalle:
F_1 = [1, 100/(Anzahl Fahrzeuge)]
F_2 = (100/(Anzahl Fahrzeuge), 2 * 100/(Anzahl Fahrzeuge)]
...
F_n = ((n-1)*100/(Anzahl Fahrzeuge), n*100/(Anzahl Fahrzeuge) = 100]
- Lassen wir mehrere Fahrzeuge einen Wert irgendwohin schreiben. Wer war der schnellste/langsamste?
- Wir haben mehrere Fahrzeuge in einem Array. Welches ist an Stelle 0, welches an n-1?
...
Das klappt auch mit beliebig vielen konkurrierenden Fahrzeugen und es gibt etliche weitere Möglichkeiten von trivial bis hochkomplex. Gleichzeitig ankommende Fahrzeuge sind kein Problem, sondern einfach nur Implementierungsaufwand nebst einer vorhergehenden Entscheidung wie man es löst.
Alles anzeigenDazu die Geschichte: Was ist mit
- MTF
- WLF
- GW-Wasserrettung
- MLW V
- Dekon P
? Alles Fahrzeuge, welche nicht direkt benötigt werden, aber einen Mehrwert (Material/Personaltransport/Geschwindigkeitsboost) haben?
Also ein Dekon-P wird schon benötigt. Aber vernachlässigen wir das und fokussieren uns auf Fahrzeuge die nicht benötigt werden aber einen Material/Personaltransport/Geschwindigkeitsboost haben.
Diese Boosts fallen natürlich weg wenn ein Premiumspieler es vorzieht über die Einstellung seinen Fahrzeugeinsatz minimal zu halten. Das kann jeder entscheiden. Es kommt ja dann gar nicht dazu, dass ein Premiumspieler mehrere dieser Fahrzeuge dort vor Ort hat, da sie bis auf das ersteintreffende Fahrzeug für die Credits, allesamt zurückgeschickt werden. Für Premiumspieler wird nur das ersteintreffende Fahrzeug behalten und weitere die für den Einsatz benötigt werden und noch nicht ersetzt wurden.
Es ist also möglich als First Responder jedes beliebige auch nicht benötigte Fahrzeug zu schicken, also MTF beispielsweise, aber eben nicht, mehrere davon am Einsatzort zu behalten, wenn das transportierte Personal, Pumpleistung, Wasser, etc. nicht benötigt wird. Denn das will der Nutzer des Features nicht.
Wobei ich bei mir im Verband mehrere hundert Einsätze aufhabe. Ob da einer mit oder ohne Boost beendet wurde bekomme ich nicht mit und die meisten wird es nicht interessieren solange die Einsätze abgeschlossen werden.
Ich klinke mich jetzt hier aus - Mir raucht der Schädel von deinem Beitrag - Unnötig, wenn eh immer ein Fahrzeug dablieben soll, sowieso. Warum dann die mühe machen das zu Programmieren?! Ob jetzt 10 Fahrzeuge von einem vor Ort sind oder "nur" eines ist doch egal (Viele Hände - Schnelles Ende) Der Vorschlag macht nur das Verbandsleben kaputt, denn dann kann ich ja gleich alleine Spielen.
Ich bleib dabei dagegen - Auch wenn es ne Option zum Ausschalten gibt.
In diesem Sinne, Thema deabonniert
Es wurde bereits geschrieben, dass niemand erwartet, dass dieser Algorithmus allgemein verstanden wird. Es ging darum für einen Nutzervorschlag eine Lösung zu präsentieren die sich kostengünstig umsetzen lässt und vom Entwicklerteam verstanden werden kann. Unnötig keinesfalls, denn der Algorithmus sorgt erst dafür, dass nur ein Fahrzeug verbleibt, obwohl beliebig viele gesendet wurden.
"Viele Hände - Schnelles Ende": Die Frage ist doch, wie wichtig es ist, ob ein Einsatz etwas früher abgeschlossen wird bei sehr vielen hunderten an denen man teilnimmt. Bekommt ein Spieler das spürbar mit? Unverständlich ist in wieweit das Verbandsleben dadurch kaputt geht, wenn Leute sicherstellen, auch wirklich nur ein Fahrzeug zu schicken, aber für den Fall der Fälle vorsorglich mehrere gesendet haben, bis Verbandskollegen übernehmen. Für Nichtpremiumspieler ändert sich im Großen und Ganzen überhaupt nichts, für Premiumspieler nur die Tatsache, dass sie mehr verfügbare Fahrzeuge haben. Allgemein gäbe es allenfalls einen Nachteil, dass die o.g. Boosts nichts mehr greifen.
Nur weil man gegen etwas ist, bedeutet das nicht, dass andere keinen Nutzen daraus ziehen könnten. Alleine dass ein Thema dazu eröffnet wurde belegt einen Bedarf und auch ich würde diese Neuerung nutzen.
Wie gesagt, es geht nicht darum, dass jemand die technische Komponente verstehen soll. Fakt ist einfach, dass man mit wenig Aufwand diesen Verbesserungswunsch umsetzen kann, da sich nur recht triviale Probleme auftun. Mir persönlich ist es egal ob das umgesetzt wird, ich wollte euch einfach nur an meinen Gedankengängen teilhaben lassen. Eine derartige Lösung lässt sich in einem neu aufgesetzten System binnen einer halben Stunde umsetzen. Wie es aussieht, wenn man auf bereits vorhandenen Code greifen muss, ist davon abhängig wie der Entwickler des Spiels beim Verkauf die Basis hinterlassen hat und kann im schlimmen Fällen Tage und Wochen dauern.
Es gibt auch Lösungen, die Fahrzeuge beliebig untereinander austauschbar machen. Fakt ist einfach, dass es keinerlei technische Hürden in der Umsetzung gibt und sich nur eine Rentabilitätsfrage stellt.
Fall jemand noch Fälle hat, die meinen Algorithmus ins straucheln bringen könnten, immer her damit. Ich meine zwar alle Möglichkeiten abgedeckt zu haben, aber bin dennoch gespannt und an einem Diskurs interessiert. Denn die beste Umsetzung wollen wir alle, falls eine erfolgen sollte.
Gut, Footsoldier beim einfachsten Beispiel lässt sich das rechnerisch darstellen.
Der Erstvorschlag will das aber für alle Fahrzeuge.
Nehmen wir also mal Funkstreifenwagen die ohne DGL gesendet werden um nach dem Einsatz die möglichen Gefangenen abzutransportieren.
Wenn sich die Funktion bei LF nach Deinem Beispiel rechnet, so tut sie es hier schon nicht mehr.
Ich halt die Funktion weiter für nicht relevant.
Die mag in einigen Einzelfällen für kleine Spieler durchaus wertvoll sein.
Im gesamten Spielgefüge schaltet man sie ab Dienstgrad "Stv. Zugführer(in)" ab, da sie keinen Nutzen mehr hat.
"Viele Hände - Schnelles Ende": Die Frage ist doch, wie wichtig es ist, ob ein Einsatz etwas früher abgeschlossen wird bei sehr vielen hunderten an denen man teilnimmt. Bekommt ein Spieler das spürbar mit?
Oh ja, bei einem Dammbruch kann das auch mal ca. 3 Stunden ausmachen
Nehmen wir also mal Funkstreifenwagen die ohne DGL gesendet werden um nach dem Einsatz die möglichen Gefangenen abzutransportieren.
Wenn sich die Funktion bei LF nach Deinem Beispiel rechnet, so tut sie es hier schon nicht mehr.
Ja das stimmt, FustDGL sollte natürlich sendbar sein genau wie auch der ELW1-SEG. Das ist in der If-Abfrage eine kleine Unterabfrage. Danke für den Einwand, ich bin auf diese Fälle nicht eingegangen, aber unter "nötig" könnte man schon auch die Fahrzeuge auffassen die dafür sorgen den Abstransport zu automatisieren.
Es ist aber nicht so, dass jemand Einsätze nicht zufahren kann. Denn jedes benötigte Fahrzeug bleibt am Einsatzort. Sagen wir also benötigt bedeutet alle benötigten + FustDGL und SEG1-ELW. Damit hätten wir die Definition schon verfeinert und keinen Bruch im Algorithmus begangen. Danke dafür.
Ich halt die Funktion weiter für nicht relevant.
Die mag in einigen Einzelfällen für kleine Spieler durchaus wertvoll sein.
Im gesamten Spielgefüge schaltet man sie ab Dienstgrad "Stv. Zugführer(in)" ab, da sie keinen Nutzen mehr hat.
Deine Meinung bezüglich Relevanz. Ich kenne die Dienstgrade nicht, und würde das Feature von Anfang an nutzen. Genauso könnte man argumentieren dass das Feature für die Rückalarmierung des RD nicht notwendig ist. Ist es auch nicht, aber es ist trotzdem gut wenn man es nutzen kann.
Oh ja, bei einem Dammbruch kann das auch mal ca. 3 Stunden ausmachen
Was ändert das wenn man seine Einsätze nicht erst kurz vor knapp schließt? Ich habe persönlich mehr Fahrzeuge als es Verbandseinsätze gibt und ich bin kein großer Spieler. Ich hoffe mal, dass niemand wartend vor einem Einsatz sitzt.
Deine Meinung bezüglich Relevanz. Ich kenne die Dienstgrade nicht, und würde das Feature von Anfang an nutzen. Genauso könnte man argumentieren dass das Feature für die Rückalarmierung des RD nicht notwendig ist. Ist es auch nicht, aber es ist trotzdem gut wenn man es nutzen kann.
Eine Frage des Spielstils. Für kleine Spieler oder Gelegenheitsspieler sicher "ganz nett".
Wer aber nur etwas mehr spielt, der kann mit der "Viele Hände - schnelles Ende" - Strategie mehr rausholen.
Das trifft sehr schnell, ab ca. 10 Mio. erspielter Credits zu, also "Stv. Zugführer(in)".
Was mich sonst noch zweifeln lässt. Die Funktion wäre mit ihren Ausnahmen für vieles als höchst komplex zu bezeichnen.
Wenn man nun weiß, das SHPlay/XYR in den 3 Jahren, auch bei kleinen oder leichten Dingen noch nichts fehlerfrei hinbekommen hat.
Ich parke es für mich daher unter allgem. irrelevant, uninteressant für mich und technisch für den Betreiber nicht leistbar.
Bei der Komplexizität dieser Problemstellung kommen wir bei XYrality qualitativ bei einem Endprodukt auf Level Gebäudekomplex raus.
Allein wenn man sich die technische Ausarbeitung Footsoldier anschaut, übersteigt vermutlich der Aufwand den Nutzen bei weitem.
Worüber man nachdenken könnte, um unnötige Anfahrten zu vermeiden, wäre, bei Premiumspielern gleich ohne Alarmierung und Rückalarmierung alle benötigten Fahrzeuge einzublenden.
Ich sehe daraus auch kein großartiges Pay to Win, da man die Funktion auch recht einfach manuell hat, ist aber in einem anderen Thread besser aufgehoben.
Eine Frage des Spielstils. Für kleine Spieler oder Gelegenheitsspieler sicher "ganz nett".
Wer aber nur etwas mehr spielt, der kann mit der "Viele Hände - schnelles Ende" - Strategie mehr rausholen.
Das trifft sehr schnell, ab ca. 10 Mio. erspielter Credits zu, also "Stv. Zugführer(in)".
Ich bin bei etwas unter 200 Mio und würde es nutzen obwohl es nicht notwendig wäre. Genauso nutze ich die Rückalarmierung des RD. Es gibt doch keinen größeren Luxus als bei einem Einsatz wo man weiß, es können 100 Verletzte auftreten, über die AAO einen Überschuss alarmiert, und dass der Rest zurück geschickt wird.
Ansonsten bin ich aber bei dir. Selbst alarmiere ich im Verband nur ein Fahrzeug, so dass es mir nichts bringen würde. Die Anwendung ist unter der Haube vielleicht hochkomplex, aber das ist jedes Feature das man benutzt. Als Benutzer gilt es nur, das Ganze abstrakt zu betrachten und zu nutzen. Man kann ein Auto nutzen ohne eins bauen zu können und genauso auch ein Handy. Weißt du insgesamt was passiert, wenn du das Licht anmachst, bis ins einzelne Kraftwerk hinein? Abstrahierung ist der Begriff der Leuten darin hilft, Dinge zu benutzen ohne Kenntnis darüber zu haben. Deshalb sagte ich auch, dass es bei Verbesserungsvorschlägen bereits ausreicht eine Richtung anzugeben weil Fachleute den Rest machen.
Wenn man nun weiß, das SHPlay/XYR in den 3 Jahren, auch bei kleinen oder leichten Dingen noch nichts fehlerfrei hinbekommen hat.
Ich parke es für mich daher unter allgem. irrelevant, uninteressant für mich und technisch für den Betreiber nicht leistbar.
Das ist nachvollziehbar. Was wir uns vor Augen führen müssen sind die Entwicklungskosten die ein Betreiber zu tragen hat. Das Feature hier kann je nach Codebasis zwischen 200 Euro und mehreren Tausendern kosten. Wenn man einen Code schreiben will kostet es relativ wenig, soll dieser aber auch getestet sein, bezahlt man ein Vielfaches oder man lässt die Nutzer testen. Es ist auch klar dass es gute Entwickler gibt, denen sofort Lösungen einfallen und andere. Es ist eine Frage der Bezahlung wer am Ende Firmencode schreibt. Ich denke aber dennoch, dass es nicht zu viel verlangt sein kann, ein paar If-Abfragen zu schreiben und entsprechende Reaktionen darauf. Das können Erstsemester. Ich kenne aber nicht den Code um zu beurteilen wie einfach eine derartige Erweiterung umsetzbar ist.
Bei der Komplexizität dieser Problemstellung kommen wir bei XYrality qualitativ bei einem Endprodukt auf Level Gebäudekomplex raus.
Allein wenn man sich die technische Ausarbeitung Footsoldier anschaut, übersteigt vermutlich der Aufwand den Nutzen bei weitem.
Dass der Aufwand den Nutzen übersteigt denke ich auch. Es ist davon abhängig wie schnell man in der Codebasis mit vorhandenem Team etwas implementieren kann und wie viel mehr Premium danach verkauft wird.
Worüber man nachdenken könnte, um unnötige Anfahrten zu vermeiden, wäre, bei Premiumspielern gleich ohne Alarmierung und Rückalarmierung alle benötigten Fahrzeuge einzublenden.
Ich sehe daraus auch kein großartiges Pay to Win, da man die Funktion auch recht einfach manuell hat, ist aber in einem anderen Thread besser aufgehoben.
Wenn man das bei Alarmierung prüft, werden sagen wir mal, fünf unterschiedliche Fahrzeuge geschickt. Vier davon treffen vorher von einem anderen Spieler ein der kein Premium hat. Keines der überflüssigen Fahrzeuge wird nun zurück geschickt. Um das hundertprozentig im Griff zu haben, muss man bei Ankunft überprüfen, denn Nichtpremiumspieler können das Konzept untergraben, indem sie nach der Überprüfung noch Fahrzeuge senden.
Pay to Win sind Leute die Coins kaufen um Wachen usw. zu bauen die sie sonst nicht hätten bauen können. Aber dieses Spiel ist darauf ausgelegt, weshalb es vollkommen in Ordnung ist diese Möglichkeiten zu nutzen. Es geht letztendlich nur um eine Platzierung in einem Highscore und die bedeutet mir persönlich nichts.
t, so tut sie es hier schon nicht mehr.
Ich halt die Funktion weiter für nicht relevant.
Die mag in einigen Einzelfällen für kleine Spieler durchaus wertvoll sein.
Im gesamten Spielgefüge schaltet man sie ab Dienstgrad "Stv. Zugführer(in)" ab, da sie keinen Nutzen mehr hat.
Schaltest du sie ab - nicht man. Ich habe diesen "Dienstgrad" schon lange hinter mich gelassen - ich würde diese Funktion aber sehr gerne nutzen ...
Und was ist jetzt mal als Beispiel vom Dammbruch?
Dann bist du am Arsch, weil du nicht mehr Fahrzeuge vor Ort bekommst um den schneller abzuarbeiten.
Und was ist mit Personal? Es fehlen noch 4 Personen mit Dekon-P und du schickst ein LF welche das Ausgebildete Personal an Bord hat? Wir nach Hause geschickt, weil das Fahrzeug nicht mehr benötigt wird. Das System müsste also auch noch jedes Fahrzeug durch schauen ob Personal darin sitzt, welche noch am Einsatzort fehlt.
Und je mehr wir hier Diskutieren umso mehr fällt uns ein, was an den System nicht funktionieren kann und umso Komplizierter wird das ganze.
Dagegen
Und was ist mit Personal? Es fehlen noch 4 Personen mit Dekon-P und du schickst ein LF welche das Ausgebildete Personal an Bord hat? Wir nach Hause geschickt, weil das Fahrzeug nicht mehr benötigt wird. Das System müsste also auch noch jedes Fahrzeug durch schauen ob Personal darin sitzt, welche noch am Einsatzort fehlt.
Fahrzeuge mit benötigtem Personal zählen als benötigte Fahrzeuge. Natürlich muss das System durchschauen was genau benötigt wird, das betrifft Fahrzeugtypen, Pumpleistung, Personal, Ausbildungen, etc. Es ist ja nicht so, dass man dafür hart arbeiten müsste. Es sind wenige Zeilen Code, die sogar schon an andere Stelle vorhanden sind, da das System genau diese Prüfungen durchführt muss, um zu wissen, ob ein Einsatz als zugefahren gewertet werden kann.
Und je mehr wir hier Diskutieren umso mehr fällt uns ein, was an den System nicht funktionieren kann und umso Komplizierter wird das ganze.
Was kann an dem System denn nicht funktionieren? Zu behaupten, Personenanzahlen würden nicht überprüft, obwohl das zwingend notwendig ist, um darüber ein Nichtfunktionieren des Algorithmus herleiten zu wollen, ist schon seit den Pythagoräern als Scheinargument bekannt.
Bislang hat keiner etwas gefunden was nicht funktionieren würde.
Bislang hat keiner etwas gefunden was nicht funktionieren würde.
Aus Erfahrung mit diversen anderen Änderungen: Das Gamedesign von XYrality.
Bislang hat keiner etwas gefunden was nicht funktionieren würde.
und was noch ein ganz großer Punkt ist - Die Serveranfragen.
Wen bei jedem Einsatz, jedes mal all deine Kriterien abgefragt werden sollen/müssen, minütlich überprüft werden oder wenn ein neues FZ ankommt.
Da freue ich mich schon auf die Ladezeitn/Performance.
Mist jetzt hab ich mich doch wieder hinreisen lassen, was zu schreiben, scheibenkleister aber auch
Bislang hat keiner etwas gefunden was nicht funktionieren würde.
Aufgrund der Turingvollständigkeit der Backendsprache Ruby wird es genau genommen sehr schwer, etwas zu finden, was "nicht funktionieren" (im Sinne von "ist nicht implementierbar") wird 
Auch sollte es bzgl. der Implementierung kein Hexenwerk sein, da einen Algorithmus mit akzeptabler Speicher- & Laufzeitkomplexität zu entwickeln (in der Theorie).
Meine persönliche Meinung zu diesem Vorschlag:
Ich brauch es nicht, aber wenn es jemand unbedingt nutzen möchte: Why not?
Bei eigenen Einsätzen ist es mir eh schnuppe, wer wie viel sendet. Wenn man dann halt lange warten muss, weil der Einsatz mit Minimalressourcen halt lange braucht => Bitte, aber dann bitte nicht jammern
Bei Verbandseinsätzen & geteilten Einsätzen sehe ich auch erstmal kaum ein Problem, solang es nur eigene Fahrzeuge sind, die rückalarmiert werden:
Schicke ich ein noch benötigtes Fahrzeug und das ist bei Ankunft weiterhin benötigt, wird das Fahrzeug am Einsatzort bleiben.
Ist das Fahrzeug bei Ankunft nicht mehr benötigt, dann wäre das unfair, dass es dann rückalarmiert wird, besonders wenn man damit dann nichts mehr vor Ort hat.
Kompromiss-Vorschlag:
* In den Einstellungen gibt es einen neuen Haken "Eigene Fahrzeuge bei Ankunft automatisch rückalarmieren, wenn diese nicht benötigt werden, mindestens jedoch ein Fahrzeug bei Verbandseinsätzen vor Ort lassen."
* Die Aktivierung dieser Einstellung / dieses Features ist nur mit Premium möglich Das ist mir egal, ob Premium oder nicht, ich brauchs eh nicht
und was noch ein ganz großer Punkt ist - Die Serveranfragen.
Wen bei jedem Einsatz, jedes mal all deine Kriterien abgefragt werden sollen/müssen, minütlich überprüft werden oder wenn ein neues FZ ankommt.Da freue ich mich schon auf die Ladezeitn/Performance.
Serveranfragen: Keine. Läuft alles Serverseitig. Der Server kommuniziert nur mit sich selbst. Das ganze über den Client zu steuern wäre extrem dämlich und unnötig viel Aufwand.
Ich denke, das dürfte kein großer Performance-Killer sein. Ich kenn natürlich keinen Internen Code des Spiels, aber so ungefähr wie hier beschrieben stelle ich mir das vor.
Im Prinzip müsste man die Funktion erweitern, die eh schon ausgeführt wird (nach einem Stapel von Fahrzeugen, wenn ich das richtig beobachtet habe), um zu prüfen, ob alles vor Ort ist:
1. Wenn Einstellung aktiv, dann mach weiter ansonsten überspring alle folgenden Punkte.
2. Wenn der Einsatz gerade erst in den "wird abgearbeitet"-Modus gewechselt ist, gehe einmal "rückwärts" (zuletzt angekommenes zuerst, zuerst angekommenes als letztes) durch alle Fahrzeuge und alarmiere zurück, wenn der Einsatz ohne diesem Fahrzeug auch abgearbeitet werden würde.
3. Sonst-Wenn der Einsatz bereits abgearbeitet wird/ist, alarmiere die in diesem Stapel frisch angekommenen Fahrzeuge wieder zurück.
In Code sind das dann paar Zeilen mehr, aber wie gesagt: Dürfte meiner Meinung nach kein Hexenwerk sein.
Das wäre so mal meine auch eher technisch angeheiterte Sicht auf diesen Vorschlag.
Den Faktor Mensch / Game-Design können wir alle nicht einschätzen, aber man kann nur hoffen, dass bei einem scheinbar so simplen Vorschlag nicht sooo viel Falsch gemacht werden kann.
Aber vielleicht bekommt man am Ende ja noch einen Bestätigungsdialog, mit dem man bei jedem Fahrzeug einzeln sagen kann, ob die automatische Rückalarmierung für diesen aktuellen Einsatz durchgeführt werden soll oder nicht /s
Aus Erfahrung mit diversen anderen Änderungen: Das Gamedesign von XYrality.
Die haben den Klumpatsch ja von jemandem gekauft. Ich denke einfach, dass man sich damals keine Gedanken darüber gemacht hat, was passiert wenn viele Spieler auftreten. Es wird auch immer über einen Server gesprochen. Normalerweise hätte man viele Server. Scheinbar kann man nur vertikal skalieren wenn es wirklich nur einen Server gibt und das ist verdammt teuer und darüber hinaus auch limitiert.
Wen bei jedem Einsatz, jedes mal all deine Kriterien abgefragt werden sollen/müssen, minütlich überprüft werden oder wenn ein neues FZ ankommt.
Da freue ich mich schon auf die Ladezeitn/Performance.
Diese Anfragen laufen nicht zusätzlich ab, sondern müssen von Haus aus getätigt werden, um zu wissen, ob der Einsatz vollständig angefahren wurde. Die Erweiterung handelt sich um neu zugefügte Methoden-/Modulaufrufe, die innerhalb bereits vorhandener Verzweigungen ausgeführt werden. Was an Rechenaufwand hinzukommt ist relativ marginal, da es eigentlich nur Verzweigungen mit Methodenaufrufen sind.
Allgemein habe ich in diesem Forum öfter etwas über Serverlast gelesen und dass deshalb Features nicht umgesetzt werden sollten. Alles was zur Funktionsweise einer Anwendung beiträgt verursacht Serverlast. Würde man so argumentieren, hätte man am Ende nur ein minimal laufendes Spiel. Eine if-Abfrage kann mehrere Milliarden Mal pro Sekunde verarbeitet werden durch eine moderne CPU. Ein Server hat viele CPU's mit darüber hinaus mehreren Kernen. Ob die Abfragen mit dabei sind oder nicht, ist im Gesamtkonstrukt nicht mehr erkennbar. Je mehr eine Anwendung sowieso bereits leistet, umso weniger fällt ein neues Feature ins Gewicht.
Aufgrund der Turingvollständigkeit der Backendsprache Ruby wird es genau genommen sehr schwer, etwas zu finden, was "nicht funktionieren" (im Sinne von "ist nicht implementierbar") wird
Auch sollte es bzgl. der Implementierung kein Hexenwerk sein, da einen Algorithmus mit akzeptabler Speicher- & Laufzeitkomplexität zu entwickeln (in der Theorie).
Dein Beitrag klingt recht fundiert und ich denke, du hast auch die notwendige Ahnung um das zu beurteilen.
Welche Programmiersprachen sind denn nicht turingvollständig? Implementierbar sind die Sachen theoretisch alle, dennoch es gibt Algorithmen die einfach schlecht sind und die Funktionalität nicht fehlerfrei implementieren oder nur mit langer Bearbeitungszeit. Ich kenne mich mit Ruby nicht aus, aber denke, dass man damit ordentlich genug programmieren können sollte, um einfache Entwürfe einigermaßen stolperfrei umzusetzen. Wir reden hier nicht über einen Bau der Notre Dame sondern das, was Programmierteams täglich machen.
Ich vermute ja, dass durch die Lösung nur wenige MB an RAM überhaupt zeitgleich belegt werden. Die Laufzeiten sind durch die Architektur bestimmt und die paar Abfragen sollten den CPU's keine Probleme bereiten. Die Implementierung ist sowieso trivial, wenn man nicht anfängt, Fahrzeuge untereinander austauschbar zu machen. Selbst dann ist sie trivial, aber fängt an, lästig zu werden, da man ein paar Listen mehr braucht. Mit einem Austausch der Fahrzeuge hat man einen guten Kompromiss zwischen dem am günstigst Umsetzbaren und dem Bestmöglichen.
Ist das Fahrzeug bei Ankunft nicht mehr benötigt, dann wäre das unfair, dass es dann rückalarmiert wird, besonders wenn man damit dann nichts mehr vor Ort hat.
Kompromiss-Vorschlag:
* In den Einstellungen gibt es einen neuen Haken "Eigene Fahrzeuge bei Ankunft automatisch rückalarmieren, wenn diese nicht benötigt werden, mindestens jedoch ein Fahrzeug bei Verbandseinsätzen vor Ort lassen."
* Die Aktivierung dieser Einstellung / dieses Features ist nur mit Premium möglich Das ist mir egal, ob Premium oder nicht, ich brauchs eh nicht
Ich weiß nicht warum du es Kompromissvorschlag nennst, denn das von dir Geschriebene beinhaltet genau das, was bereits besprochen wurde. Ein Fahrzeug wird bei meiner Lösung nicht unfairerweise zurück alarmiert. Es verbleibt immer mindestens ein Fahrzeug.
Im Prinzip müsste man die Funktion erweitern, die eh schon ausgeführt wird (nach einem Stapel von Fahrzeugen, wenn ich das richtig beobachtet habe), um zu prüfen, ob alles vor Ort ist:
1. Wenn Einstellung aktiv, dann mach weiter ansonsten überspring alle folgenden Punkte.
2. Wenn der Einsatz gerade erst in den "wird abgearbeitet"-Modus gewechselt ist, gehe einmal "rückwärts" (zuletzt angekommenes zuerst, zuerst angekommenes als letztes) durch alle Fahrzeuge und alarmiere zurück, wenn der Einsatz ohne diesem Fahrzeug auch abgearbeitet werden würde.
3. Sonst-Wenn der Einsatz bereits abgearbeitet wird/ist, alarmiere die in diesem Stapel frisch angekommenen Fahrzeuge wieder zurück.
Ja, im Prinzip genau so. Du hast bei 2) zwar LIFO gewählt, ich FIFO. Aber die Reihenfolge ist egal, denn der Entwickler setzt die Regeln. 3) ist nicht notwendig, denn Fahrzeuge werden bereits rückalarmiert, bevor ein Einsatz zugefahren wird. Aber grundlegend spiegelst du den Vorschlag und meinen Entwurf darauf wieder.
Das ganze über den Client zu steuern wäre extrem dämlich und unnötig viel Aufwand.
Jein, wenn man eine vertikal skalierbare Anwendung hat, ist es besser Berechnungen auszulagern und nur 2 HTTP-Operationen für das Management zu verarbeiten, die Aufträge senden und Ergebnisse entgegen nehmen. Wenn wir uns beispielsweise Skripte vom LSSM 4.0 ansehen, so zeigt sich dort auch, dass die Operationen auf der Clientseite erfolgen, von denen der oder die Server (gegendert, je nach Skalierbarkeitsart [horizontal oder vertikal]) nichts mitbekommen. Es ist in dem Fall oftmals günstiger, Entwickler zu bezahlen, als auf Dauer eine ruckelnde Anwendung zu haben und diese mit neuester und teuerster Hardware optimieren zu müssen. Auch bei horizontal skalierbaren kann man aus Kostengründen den Anwendern Berechnungen aufs Auge drücken. Man muss immer nur die Verhältnismäßigkeit wahren, dass kein Client überfordert wird und man selbst am wenigsten zahlt.
Aber vielleicht bekommt man am Ende ja noch einen Bestätigungsdialog, mit dem man bei jedem Fahrzeug einzeln sagen kann, ob die automatische Rückalarmierung für diesen aktuellen Einsatz durchgeführt werden soll oder nicht
Den erhoffe ich mir auch, nebst einer Funktion, diese Meldungen deaktivieren zu können. Denn es können hunderte werden. Aber es ist einfach umzusetzen und jemand der informiert werden will, wird seine Freude daran haben.
