Vor allem dauert es seine Zeit... mit im 7-Sekunden-Takt die Liste durchalarmieren isses dann auch Essig...
Beiträge von Zp9
-
-
Eigentlich reicht die bisherige Lösung aus. Einsätze verfallen in der Regel in der übernächsten Nacht (24-48h nach Erstellung). Spielt man einen Tag nicht dann sind sie noch da. Da mag man über eine moderate Verlängerung nur der nicht freigegebenen Einsätze diskutieren - etwa 24-28 / 48-72.
Was ich jedoch für völlig daneben halte ist eine Verlängerung für alle Formen von Verbandseinsätzen. Egal ob Event, VGSL oder einfache Freigabe - die sollen auch weiterhin nach spätestens 48 Std weg sein. Gründe siehe oben.
"Hier ist die Feuerwehr..."
"Bei mir brennt es...!"
"Wir sind schon bei nem anderen Einsatz, können sie nochmal nachlegen? "
-
Ne "Ampel" mit rot-gelb-grün wäre ja auch schon was - vielleicht aufgeschlüsselt nach Komponenten.
XY wird die Entscheidung treffen, welche Werte veröffentlicht werden und welche nicht. Das Spannungsfeld zwischen Betriebsgeheimnis, informierter Community und mithelfender Community ist diesbezüglich logisch...
-
Hallo,
damit es keine Missverständnisse gibt:
Die Länderversionen sind alle voneinander getrennt und komplett isolierte Systeme, die nicht mit Leitstellenspiel.de interagieren. Das Leitstellenspiel läuft alleine und auf den gleichen Servern wie bisher auch.
Wir planen jedoch die Server auf eine leistungsstärkere Infrastruktur umzuziehen.
Was ansonsten bisher als "Serverfehler" erkennbar war, sind nach aktuellem Stand mindestens zwei verschiedene Probleme gewesen:
1. Die "Langsamzeiten". Hier sind wir an der Analyse dran und haben viele Monitorings und Logs angelegt. Jedes Vorkommen ist - zumindest positiv betrachtet - ein Puzzle-Stück, das uns bei dem Finden des Problems hilft. Wir sind auch jetzt gerade dabei das heutige Vorkommen zu analysieren und haben weitere Logs ergänzt. Hier machen wir Fortschritte und nähern uns der Problemlösung, aber der heutige "Aussetzer" zeigt natürlich, dass dieses Problem noch nicht vollständig behoben ist.
2. Das "Caching"-Problem, welches sich als verschwundene Gebäude, Serverfehler, Login nicht gefunden, verschwundene Schulungen, etc. gezeigt hat. Dieses Problem (für die Coder, eine sogenannte "Race Condition") hatte definitiv schon lange Potential, war aber unglaublich unwahrscheinlich auszulösen und wenn es auslöste, dann in unkritischen Stellen. Durch eine grundsätzlich harmlose, damit nicht zusammenhängende Codeänderung haben wir die Wahrscheinlichkeit dafür erhöht und den Auslöser in einen kritischeren Teil des Codes verschoben.
Das war natürlich sehr unglücklich und zum Teil dem "Kennenlernen" des komplexen Systems geschuldet.
Dieses Problem sollte mittlerweile behoben sein.
Wir hoffen, damit etwas Klarheit und Transparenz geschaffen zu haben und bedanken uns für die Geduld und das Verständnis.
Habt ein schönes Wochenende!
Genau so macht bitte weiter! Hier im Spiel verteilt hockt etliches Potential an Scriptern, Codern und anderen IT-Fachmenschen. Gebt denen ausführliche Statements an die Hand und sie werden euch helfen - allein, weil sie dann wissen, auf was sie achten müssen.
Und... vielleicht baut ihr mal eine "Status-Seite", eine status.leitstellenspiel.de, wo ihr einige Eckdaten rausgebt. Dinge, die das System eh "weiß", die aber helfen, Engpässe nicht nur zu erdulden, sondern auch zu verstehen. Anzahl eingeloggter User, Anzahl Einsätze pro Minute, alarmierte Fahrzeuge pro Minute, Datenbankdurchsatz , Gesamt-Traffic, (Absolutwert oder Prozent vom bisherigen Spitzenwert) durchschnittliche Alarmierungszeit je Fahrzeug (wenn die hochgeht weiß der Profi gleich "weniger auf einmal alarmieren")... lauter solche Dinge, das Ganze wenns geht noch so, dass man es mit einem externen Skript auswerten und ggf. sogar ein "Warn-Skript" draus machen kann - vielleicht eine Art Lastindex, der von 0 bis 100 geht wobei Werte über 90 dann "hot" und über 95 "kritisch" zu werten wären und ggf. clientseitig bestimmte Aufrufe gezielt verlangsamen... das Feld ist weit...
-
Die Bereitschaftspolizei hat ohnehin einen höheren Radius als Fw, RD und "normale" Pol. Das THW übrigens auch.
-
Oder du liest einmalig die Anforderungen der Standard-VGSL aus und startest sie eben als DIY-VGSL. Die Eingabe der Fahrzeugmengen könnte man ja mit einem Script automatisieren - und beispielsweise falls gewünscht auch anpassen, etwa mehr Verletzte usw. Bei DIY-VGSL kann man den Namen angeben - ein [no ELW2/-23h] sollte dahinter passen...
-
Konfuzius sagt: Jedes Datum ist gültig - wenn man den richtigen Kalender dazu hat.
Muss man eigentlich in Allwetterreifen im Herbst Winterluft und im Frühjahr Sommerluft füllen?
Und: Wo bekommt man die her, wo es doch im Herbst noch gar kein Winter ist...? -
Ebenso, wenn zum Einsatzort keine Route berechnet werden kann. Oder du die Wache "günstig" in einen gesperrten Bereich platziert hast (dann ist zu keinem Ort außerhalb dieser restrict-Zone eine Route berechenbar). Wer sich das im Einzelfall genauer ansehen mag: Open Street Map, Entwicklermodus... da kannst du für jedes Straßenstück die Attribute ansehen (und ändern). Änderungen des Kartenmaterials werden allerdings nur in größeren Abständen ins Spiel übernommen (Offlinekarte) - das können mehrere Monate sein...
-
Oder man schreibt es wie einen Austritt ins Log. Wäre ja sachlich durchaus richtig...
-
Inwiefern gelöscht? Aktuell sollte keiner dieser Einsätze aktiv sein... woran stellst du fest, dass diese "gelöscht" sind?
-
FeuerwehrWupperstadt das hatten wir mal. Das führte dann dazu, dass alle möglichen Grafiken in allen möglichen Größen auf dem Schirm waren, schlimmstenfalls ein Fahrzeug in Übergröße die halbe Karte verdeckte. Daher wurde das wieder geändert und es werden jetzt alle Fz im eigenen Standard-Grafikset (welches auch für die eigenen Fz gilt) angezeigt.
-
Ich denke, es sollten dann doch eher 30 als 20 Betroffene sein. Oder es gibt den Einsatz eben zweistufig (mit 20 / mit 40, je nach Anzahl der Rettungswachen und SEG im Leitstellenbereich).
Fw gehört dazu, allein schon Tragehilfe, ebenso Meßkomponente.
Pol gehört dazu, allein um die Gaffer (sowohl private als auch öffentlich-rechtliche) zu "betreuen". Ebenso gibts durch den Rettungsmittelhalteplatz vor der Tür meist ein gewisses Maß an Verkehrsbeeinträchtigungen.
Wenn wir dann mal ne FGr Beleuchtung bekommen darf auch das THW mitspielen.
Der Hauptanteil an Credits für diesen Einsatz sollte durch den RD generiert werden...
BTW. wir fahren die DIY-GSL schon fast traditionell mit 100 Verletzten - auch die sind ruckzuck bedient. Bei 100% Transport, 66 % NA und 33 % RTHUnd da man ja die gleichen Rettungsmittel mehrfach anfahren lassen kann ist die Anzahl der Betroffenen eigentlich nach oben offen...
-
Aisaka der vServer ist ja vorhanden und wird im Moment nur nicht genutzt (außer nen bischen Backup-Space). Meine Idee wäre jetzt, in "Ruhe" den vServer entsprechend einzurichten, dann ne neue LSSM-Version mit geänderter Adresse auszurollen, wenn alles läuft deinen "Dicken" abzurüsten und umzuziehen - und dann (ggf.) auf deinem Neuen wieder in aller Ruhe einrichten und Folgeversion mit der dann wieder neuen Adressierung ausrollen... so gehen die Ausfallzeiten gegen Null.
In der derzeitigen Config zahle ich 2,64 € im Monat - und wie gesagt, die zahle ich sowieso, egal was auf der Kiste läuft... und da nix wirklich "Wichtiges" drauf ist habe ich auch kein Prob damit, denn root rauszugeben -
Aisaka die Auslastung / Anforderungen würden mich auch mal interessieren, also jetzt "nur" für den LSSM.
Muss es dedicated root sein oder reicht ein vServer? Oder sogar gescheiter Webspace mit PHP&SQL?
Den "kleinen" vServer (VPSID: 11520 | 1 vCores | 1024 MB RAM | 20 GB Storage, signaltransmitter) hab ich im Moment eh nutzlos "rumliegen", ebenso 250 GB Webspace bei AllInkl...
wäre beides für dauerhaft oder für die Umzugsphase problemlos verfügbar... bei Interesse bitte PN -
Argument 2:
Es gibt die Funktion Wachenansammlungen zu erkennen und zu bestrafen - das sagt mir es ist auch nicht gewünscht die vielen Fahrzeuge auf mehrere Wachen am selben Fleck zu stationieren.
Wenn du ansonsten "normal" baust sind drei Wachen an einem Fleck noch kein Problem... zumindest wenn sie halbwegs gut bestückt sind. Ob das System es erkennen würde, wenn jede Wache dann nur zwei Autos hätte... keine Ahnung
-
-
Da war dann ein Bit an der Ecke nen bischen abgenutzt
Solange das nicht ständig passiert - alles gut. Browsergames gehen immer den Grat zwischen Geschwindigkeit und absoluter Genauigkeit bei der Datenübertragung. Man überträgt viele Dinge ohne Bestätigung per UDP einfach weil TCP langsamer ist. Verschluckt sich dann die Leitung (Packet loss), dann ist die Information halt mal nicht synchron. -
Wenn ich aber jetzt für die Feuerwache statt einer Wache fünf Wachen baue,
Dann wird die nächste Feuerwache ja wieder teurer.
Dafür hast du aber auch einen Einsatzslot mehr und zumindest statistisch eine gewisse Häufung von Einsätzen im Bereich deiner Doppelwache.
-
Ist doch ganz einfach:
1. Alarmiere nächstes wasserführendes Fahrzeug
2. Vergleiche Sollmenge mit Istmenge, wenn Soll nicht erreicht gehe zu 1.
3. Fertig
Selbst wenn du jetzt 7950 Liter hast wird er das nächste Fahrzeug in der Liste dazunehmen - ist das dann ein TLF4000 dann hast du eben 3950 Liter Wasser "zuviel".
Tragisch ist das aber nicht wirklich, denn dadurch, dass ja auch mehr Mann vor Ort sind wird der Einsatz ja auch schneller abgearbeitet.
Und wenn dir -egal wann und wo- ein einzelnes "fehlendes" wasserführendes Fahrzeug solche Probleme bereitet, dann hast du vielleicht einfach zu wenige wasserführende Fahrzeuge... -