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...

    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...

    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...

    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 % RTH ;-) Und 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.

    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...