Beiträge von FloFrankfurt

Login über das Spiel

Die Foren Zugänge sind mit den Spiel-Accounts verknüpft.
Bitte nutze daher die Anmeldung über das Menü im Spiel.
Durch eine technische Anpassung wurden alle Spieler im Forum abgemeldet und müssen es einmalig neu über den ReSi öffnen.

  • Gerätewagen Verpflegung [GW-V] | Gerätewagen Küche [GW-K]

    Ich muss ehrlich sagen, dass ich in dem aktuellen Konzept für mich keinerlei Nutzen für den GW-Küche sehe. Ich soll jedes Mal 500 Münzen dafür zahlen, dass das Fahrzeug die Einsatzdauer um 20% zu reduziert. Die Einsatzdauer kann ich aber um bis zu 50% reduzieren, indem ich mehr Fahrzeuge als nötig zum Einsatz schicke.


    Warum sollte ich also 500 Münzen für etwas zahlen, dass ich kostenlos haben kann? Überschüssige LF habe ich als großer Spieler alleine schon genug und da ich meine Großeinsätze freigebe, kommen noch die Fahrzeuge der Verbandskollegen dazu. Da fehlt mir komplett der Anreiz den GW-Küche einzusetzen (für's Bauen ist der Anreiz auch nur da, weil ich Realbauer bin und den Haken in der Liste setzen will).


    Mal ganz davon abgesehen, dass wir nirgendwo anders im Spiel Betriebskosten jeglicher Art haben. Warum also hier auf einmal?




    Ich würde daher mit der Verpflegungskomponente (unabhängig ob FW oder SEG) in die genau gegenteilige Richtung gehen. Dafür sehe ich spontan 3 Optionen:


    1. Eine optionale Entsendung zu Großeinsätzen ab Größe/Einsatzdauer X. Wenn hier eine Verpflegungskomponente vor Ort ist, erhält jeder, der beim Einsatz vor Ort ist, einen kleinen Bonus auf die Vergütung. Dieser ist nur einmal pro Einsatz möglich, mit 2 Verpflegungskomponenten gibt's keinen doppelten Bonus. Hier könnte man sich überlegen ob dieser Bonus ein fixer Wert ist oder prozentual nach dem Einsatzverdienst geht.


    2. Eine zwingende Anforderung bei Einsätzen, wie mit jedem anderen Fahrzeug auch. Hier müsste man sich überlegen, ob man die Anforderung an die Größe/Dauer des Einsatzes oder an das jeweilige Einsatzszenario koppelt.


    3. Eine Mischung aus beiden Optionen. Manche Einsätze brauchen zwingend eine Verpflegungskomponente (entweder aufgrund Größe/Einsatzdauer oder Szenario) und beim Rest (kleinere/mittlere Einsätze ausgenommen) gibt's einen Bonus, wenn sie vor Ort ist. Zusammengefasst hieße das z.B.:

    • bis 10 min Einsatzdauer -> Verpflegung bringt nichts
    • 11 bis 20 min Einsatzdauer -> Verpflegung ist freiwillig und bringt kleinen Bonus
    • 20+ min Einsatzdauer -> Verpflegung ist verpflichtend und wird wie alle anderen Fahrzeuge in der Berechnung der Vergütung berücksichtigt
    • Das Einsatzszenario macht unabhängig von der Einsatzdauer eine Verpflegung notwendig -> Verpflegung ist verpflichtend und wird wie alle anderen Fahrzeuge in der Berechnung der Vergütung berücksichtigt

    Ein solches Szenario für die verpflichtende Anforderung unabhängig der Einsatzdauer könnte z.B. die Versorgung von evakuierten Personen im Rahmen einer Bombenentschärfung sein.



    Bitte beachtet, dass mein Vorschlag hier nur eine sehr grobe Idee ist und sicherlich noch einiges an Feintuning braucht.

  • GW-A/Strahlenschutz

    Zitat von GregorPaul

    Ich wollte lediglich anmerken das die A/S Komponente 1. nirgendwo voll angerechnet werden kann im Einsatz da es ja ein Mischkonzept ist und hier sogar mehr als 2 Komponenten gemischt werden und 2. der A/S überdies auch von unterschiedlichen Wehren unterschiedlich ausgerüstet wird. Womit er auch nicht überall gleich eingesetzt werden kann.

    Eben weil die Wehren die Fahrzeuge unterschiedlich nutzen, habe ich mich in meinem Vorschlag - quasi als Mindestnenner - auf das Baublatt des GW-A/S in Bayern bezogen. Das ist im Vorschlag auch entsprechend verlinkt.

    Zitat von GregorPaul

    Das wären mal so kurz gefasst die Mindest Änderungen ohne mich weiter eingelesen zu haben.

    Dann lies dich bitte ein, bevor du hier weiter diskutierst und mangels Informationen falsche Behauptungen aufstellst. Dann würdest du unter anderem sehen, dass die Fahrzeuge kein Material zum Abdichten, Auffangen, Umpumpen und Sichern von Gefahrstoffen verlastet haben, wie es beim GW-G der Fall ist. Auch mit der Dekon-Ausstattung sieht's eher mau aus. Es gibt zwar kleinere Überschneidungen mit der Beladung von den Fahrzeugtypen, allerdings ist das bei mehreren Fahrzeugen für den ABC-Einsatz nicht verwunderlich.


    Ich habe mir vor dem Posten meines Vorschlages die Mühe gemacht und die Beladungslisten vom GW-A/S in Bayern und vom GW-A in Hessen abgeglichen. Es gibt ein paar kleinere Abweichungen, mal zugunsten des GW-A/S und mal zugunsten des GW-A. Was allerdings identisch ist, ist die Mindestanzahl an PA und Filtermasken. Für die Messausstattung habe ich dasselbe mit der Beladungsliste vom ABC-Erkunder gemacht. Auch hier gibt es ein paar kleinere Abweichungen, allerdings kann der GW-A/S auch hier das volle Spektrum an Messungen abdecken.




    Was ich hingegen für einen berechtigten Einwand halte, ist das Thema Messfahrten mit dem AB-A/S. Das kam beim AB-Analytics bzw AB-Mess auch schon auf. Das wäre m.M.n. ein Punkt, den man je nach Einsatz individuell in den Anforderungen betrachten müsste. Beim klassischen Gasaustritt im Heizungskeller sehe ich z.B. keine Probleme.

  • GW-A/Strahlenschutz

    Zitat von GregorPaul

    Frag zum RTH. Warum soll der mit dem aktuellen Patientensystem nicht funktionieren???? Das NEF tut es doch auch!!! Das ist jetzt nen Witz oder? Am Ende ist der RTH nix anderes als ein NEF nur in der Luft halt. Also wenn ihr ernsthaft behaupten wollt das läge am Patientensystem dann frag ich mich wie das NEF funktioniert. 🤣

    Der Teil ein Fahrzeug Luftlinie fliegen zu lassen ist tatsächlich kein großes Problem. Nur ist ein RTH eben kein fliegendes NEF, sondern eher ein fliegender NAW, weil er einen Patienten transportieren kann. Und genau an der Stelle liegt bei der momentanen Patientenlogik das Problem. Der Code gibt es schlichtweg nicht her, dass ein Fahrzeug, das den Notarzt zubringt, gleichzeitig auch den Patienten transportieren kann. Aus diesem Grund gibt es im ReSi auch noch keinen NAW. Uns ist durchaus bewusst, dass das suboptimal ist, der Fall wurde bei der Umsetzung der NEF aber schlichtweg nicht berücksichtig.


    Wenn man dann noch Patienten haben möchte, die zusätzlich zur Notarztanforderung auch noch eine RTH-Anforderung haben, wird's richtig kompliziert. Oder wenn man dem Spieler die Entscheidung geben möchte, ob der Patient in Notarztbegleitung im RTW oder im RTH transportiert werden soll.


    Die aktuelle Codestruktur macht in dem Fall so viele Probleme, dass ein Fahrzeug was ihr als "mal eben so machbar" wahrnehmt tatsächlich eher mehrere Monate in der Umsetzung brauchen würde. Was inzwischen an so vielen Stellen der Fall ist, dass das Rework aus technischer Sicht die sinnvollste Lösung ist und bleibt.


    Zitat von GregorPaul

    Es ist halt alles bissel merkwürdig. 2021 wurde sich das Fahrzeug A/S gewünscht. Dann war hier 3 Jahre Ruhe. Keiner hat mehr was dazu geschrieben. 2024 schreibt ein ReSi Team Mitglied das es diese Art von Fahrzeugen benötigen würde. Und Zack auf einmal ist das Label „in Arbeit“ am Thread. Und das interessanteste ist da gibt es Wünsche die deutlich mehr diskutiert und ausgearbeitet wurden. Diese werden aber ignoriert. Schade ehrlich gesagt.

    Im Discord wurde inzwischen mehrfach der Wunsch geäußert, dass wir in der Wartezeit bis das Rework fertig ist, trotzdem noch neue Inhalte bringen sollen. Deswegen haben wir Ende März/Anfang April im Team nochmal sämtliche noch offenen Fahrzeugvorschläge im Forum hinsichtlich ihrer aktuellen Umsetzbarkeit überprüft. Die meisten Vorschläge scheitern an der Stelle leider am nötigen Aufwand in der Umsetzung.


    Unter diesen Vorschlägen war auch der GW-A/S, wobei mir persönlich der ursprüngliche Vorschlag von der Ausarbeitung zu dürftig war. Deswegen habe ich als Privatvergnügen meinen o.g. Vorschlag gepostet. Das hatte zum damaligen Zeitpunkt allerdings keine Auswirkungen, weil wir lediglich eine aktuelle Bestandsaufnahme der Vorschläge gemacht haben, ohne uns auf ein oder mehrere bestimmte Fahrzeuge festzulegen.


    Als vor ein paar Wochen das Thema eines Zwischenupdates im Discord wieder aufkam, haben wir die Fahrzeugvorschläge im Forum dann schlichtweg nach Reaktionen sortiert und die bereits umgesetzten Vorschläge rausgefiltert. Wenn in einem Thread mehrere Ausarbeitungen für ein Fahrzeug vorhanden waren, haben wir jeweils den Vorschlag mit den meisten Reaktionen aus dem Thread genommen. Ich habe das für die ersten acht Feuerwehrfahrzeuge hier nochmal gemacht und die Vorschläge jeweils mit einer kurzen Anmerkung bezüglich der Umsetzbarkeit versehen.


    GW-Logistik14 Reaktionengrößerer Aufwand, weil ein komplett neues System für die Beladung nötig ist
    FR bzw. HvO8 Reaktionengrößerer Aufwand, weil das Anbehandeln von Patienten nötig ist
    GW-A/S8 Reaktionentechnisch ohne Probleme und mit geringem Aufwand umsetzbar
    GW-WR7 ReaktionenProbleme mit Anhängern; wurde ohne Anhänger im Discord zur Diskussion gestellt; im Forum negatives Feedback zu diesem Vorschlag
    PKW7 Reaktionentechnisch ohne Probleme und mit geringem Aufwand umsetzbar; Mehrwert ggü. MTW?
    VRW6 Reaktionengenaue Einbindung ins momentane TH-Konzept im Vorschlag offen
    GW-Verpflegung6 ReaktionenWie sinnvoll ohne gleichzeitige Einführung bei SEGen?
    RW-G5 Reaktionen technisch ohne Probleme und mit geringem Aufwand umsetzbar


    Beim Rettungsdienst sind die Top-Vorschläge NAW, ITW, RTH und KTW. Aller vier lassen sich momentan aber nur mit einem Aufwand von mehreren Monaten umsetzen.


    Bei der Polizei macht eine Erweiterung des Fuhrparks aus fachlicher Sicht erst mit einem Gefangenensystem wirklich Sinn. Auch hier reden wir von einem Aufwand von mehreren Monaten. Und nein, Copy + Paste vom Patientensystem klappt nicht.


    Bei den sonstigen Fahrzeugvorschlägen ist der Top-Vorschlag der Zoll. Eine sinnvolle Umsetzung ohne geplante Einsätze ist hier nicht möglich.



    Damit ist der GW-A/S der Fahrzeugvorschlag im Forum mit den meisten Reaktionen, der zum jetzigen Zeitpunkt ohne erheblichen Aufwand umsetzbar ist. Deswegen wurde die Entscheidung getroffen diesen zuerst umzusetzen. Diese Entscheidung liegt letztlich aber bei Tute und nicht bei uns Contributoren.

  • GW-A/Strahlenschutz

    Zitat von GregorPaul

    Dieser AB und GW wird immer weniger da man immer öfter auf reine Fahrzeuggattungen anstatt Mischfahrzeuge setzt.

    In den letzten 5 Jahren finde ich auch mit nur kurzer Suche diverse Neuauslieferungen und auch laufende Ausschreibungen. Tatsächlich werden gerade AB-A/S bei der Umstellung auf WLF-Systeme gerne gekauft. In der Regel vor dem Hintergrund, dass man im ABC-Einsatz normalerweise beide Komponenten benötigt und auf die Art nur eins statt zwei Fahrzeugen kaufen, unterhalten und besetzen muss. Das Thema ist in Thüringen nach wie vor relevant genug, dass man erst Ende Januar diesen Jahres das entsprechende Baublatt aktualisiert hat.


    Mal ein paar Beispiele der letzten 5 Jahre:

    Hechingen - 1x AB - BJ 2020

    Lkr. Neustadt Aisch-Bad Windsheim - 1x AB - BJ 2020

    Schwäbisch Hall - 1x GW - BJ 2020

    IBK Heyrothsberge - 1x GW - BJ 2021

    Lkr. Erlangen-Höchstadt - 1x AB - BJ 2021

    Greussen - 1x GW - BJ 2021

    Bochum - 2x GW - BJ 2021

    Schwandorf - 1x AB - BJ 2021

    Rems-Murr-Kreis - 1x GW - BJ 2022

    Kronberg - 1x GW - BJ 2022

    Enzkreis - 1x AB - laufende Ausschreibung

    Kronach - 1x GW - laufende Ausschreibung

    Lkr. Greiz- 1x GW - laufende Ausschreibung


    Bei der Anzahl der Auslieferungen sollte man allerdings beachten, dass Sonderfahrzeuge im Schnitt auf 30 Jahre ausgelegt sind und z.T. nur 1x pro Lkr./Stadt vorgehalten werden. Wenn man diese 30 Jahre auf die dutzenden Bestandsfahrzeuge mit Baujahren von 2005 bis 2015 rechnet, dürften es in den nächsten 10 bis 20 Jahren auch erstmal nicht weniger Fahrzeuge werden.

  • GW-A/Strahlenschutz

    Der Hersbrucker AB-Atemschutz/Messtechnik ist meines Wissens vom Freistaat Bayern als AB-A/S gem. Baublatt gefördert worden. Man hat das Ding von Seiten der Wehr einfach nur anders benannt.

  • Sammelthread für kleine Fragen

    Es generieren nur Wachen Einsätze, auf denen mindestens ein Fahrzeug (Status egal) steht.


    Beim Generieren prüft die generierende Wache, ob die für den zu generierenden Einsatz benötigten Fahrzeuge im Umkreis von 50 km vorhanden sind. Dabei zählt der Standort der Heimatwache vom Fahrzeug und nicht die tatsächliche Position vom Fahrzeug auf der Karte. Fahrzeuge im Status 6 werden allerdings nicht als vorhanden gezählt.

  • Außerhalb der Karte

    Kurz zur Aktualität des Kartenmaterials:

    - Die alte Karte unter https://rettungssimulator.online/ ist optisch der Stand von 08/22.

    - Die neue Karte unter https://rettungssimulator.online/?map ist optisch der Stand von 04/24.


    Was die Karte optisch anzeigt und was technisch in der Datenbank im Hintergrund läuft sind aber zwei unterschiedliche Dinge. Das ist in etwa vergleichbar mit den Fahrzeuggrafiken im ReSi. Wenn ich meiner Drehleiter die Grafik von einem HLF 20 gebe, fährt für mich auf der Karte optisch ein HLF 20 durch die Gegend. Das ändert technisch aber nichts daran, dass es eine Drehleiter ist, die unterwegs ist.


    Die Karte im Spiel funktioniert sehr ähnlich. Es gibt die Karte, die man als Spieler sieht (quasi unsere Fahrzeuggrafik) und es gibt die Datenbank im Hintergrund, die dafür sorgt, dass die Karte mehr ist als nur eine Grafik (quasi der hinterlegte Fahrzeugtyp). Diese Datenbank im Hintergrund wird im ReSi deutlich häufiger aktualisiert, als die Grafik der Karte. Das liegt daran, dass unsere Karte als Grafik aufgrund der Fläche verdammt groß ist, weswegen das letzte Update der Kartengrafik auch mehrere Tage gedauert hat. Änderungen an den Daten der Datenbank sind im Vergleich dazu sehr klein und schnell durchführbar. Wir beziehen diese Datenbank allerdings nicht direkt von OSM, sondern über einen Dienstleister, der diese aus OSM spiegelt und zur Verfügung stellt. Dadurch kann es sein, dass der Datenstand, der über https://www.openstreetmap.org/ abrufbar ist, nicht dem im ReSi verwendeten Datenstand entspricht.


    Auf unser Beispiel mit den Fahrzeuggrafiken bezogen hieße der OSM-Vandalismus, dass unser Fahrzeug die Drehleiter-Grafik behalten hat, aber durch die Änderungen in der Datenbank fälschlicherweise zu einem ELW1 mit Drehleiter-Grafik umgeschrieben wurde und keine Drehleiter mehr ist.




    Die Tatsache, dass du nur an einer Ecke vom Gebäude auf der Karte deine Wache im Spiel bauen kannst, liegt an der Struktur der Datensätze in OSM. Die sind nämlich auf ganz viele Rechtecke aufgeteilt. Angenommen die roten und grünen Rechtecke in meiner Skizze, stellen diese Datensätze dar. Der rote Datensatz ist vandaliert und denkt deswegen, dass er in Timbuktu und nicht in Deutschland sitzt, während die grünen Datensätze fehlerfrei sind und in Deutschland sitzen. Das schwarze Rechteck ist das Gebäude, was du auf der Karte siehst. Setzt du deinen Bau-Marker innerhalb des roten Datensatzes auf das Gebäude, denkt der ReSi aufgrund des kaputten Datensatzes, dass du versuchst in Timbuktu zu bauen was nicht zulässig ist. Setzt du den Marker hingegen in einen der grünen Datensätze, gibt es keine Probleme, weil erkannt wird, dass du in Deutschland baust. Dadurch gibt beim Bauen im ReSi auch nicht flächendeckend Probleme, sondern nur stellenweise.



    Dass die Auffälligkeit erst seit Einführung der neuen Karte auftreten, ist fürchte ich einfach Pech. Der erste offizielle deutschsprachige Mitteilung zum aktuellen OSM-Vandalismus ist vom 16.05.2024. Die neue Karte haben wir am selben Tag wenige Stunden zuvor in den öffentlichen Test genommen, nachdem wir vorher intern schon über mehrere Tage hinweg einige Tests durchgeführt und keine Probleme mehr gefunden haben.



    Dadurch, dass die Datenbank im ReSi regelmäßig automatisiert geupdatet wird, sollten die Fehler im Laufe der nächsten Tage nach und nach weniger werden. Das hängt hauptsächlich davon ab, wie schnell man die Fehler in OSM korrigiert, bzw. alte, richtige Datenbankstände wiederherstellt. Bis das passiert, können wir von ReSi-Seite leider nichts machen.





    Zum Thema LSS verweise ich darauf, dass es dort grundsätzlich sehr ähnliche Probleme mit entsprechenden Fehlerthreads im Forum gibt. Dadurch, dass dort Kartendaten anders verarbeitet und geupdatet werden, kann es natürlich Abweichungen darin geben, in welcher Ausprägung und wo auf der Karte die Probleme auftauchen.

  • Außerhalb der Karte

    Zitat von GregorPaul

    Das ist doch ein ganz anderes Problem. Das Problem muss bei ReSi liegen. Wenn ich das Gebäude ganz an den Rand der Wache schiebe geht es ja. 🤷🏼‍♂️

    Nein, es ist eben kein anderes Problem. Ich versuche das mal stark vereinfacht zu erklären.


    Der Marker beim Bauen gleicht seine Koordinaten mit den Werten aus der OSM-Datenbank ab. Diesen Koordinaten sind in der OSM-Datenbank verschiedene Daten, wie z.B. Adressen, Nutzungen, Gebäudetyp, etc. zugeordnet. Ist den Koordinaten von deinem Bau-Marker eine Adresse innerhalb der DACH-Region zugeordnet, kannst du dein Gebäude bauen, andernfalls bekommst du die Fehlermeldung, dass du außerhalb des baubaren Gebietes unterwegs bist.


    Das Problem ist jetzt, dass durch den Vandalismus zum einen Datenwerte (hauptsächlich Straßennamen) verfälscht wurden und zum anderen die Verknüpfungen von Koordinaten und Datenbankeinträgen durcheinandergewürfelt wurden. Das führt dann dazu, dass eine Koordinate, die eigentlich in Deutschland liegt, laut OSM-Datenbank in z.B. England ist. In so einem Fall bekommst du dann eine falsche Fehlermeldung, dass du versuchst außerhalb zu bauen, obwohl das eigentlich nicht der Fall ist.


    Wenn du deinen Baumarker jetzt ein paar Meter verschiebst, ändert sich die Koordinate. Wenn die geänderte Koordinate richtig verknüpft ist, kannst du ganz normal bauen. Dadurch können Konstellationen entstehen, durch die z.B. nur Teile von Gebäuden oder einzelne Hausnummern einer Straße richtig erkannt werden.

  • Einsatz teilweise auf Russisch daher kann ich keinen erstellen

    Ist ein bereits bekanntes Problem aufgrund eines größeren Fall von Vandalismus in den OSM-Daten. Von ReSi-Seite können wir da leider nichts machen, allerdings werden die OSM-Daten nach und nach korrigiert und dann auch vom Spiel übernommen. Der Fehler sollte innerhalb der nächsten Tage verschwunden sein.


    Die Adresse zu kopieren und dann im Adressfeld einzufügen müsste fürs Anlegen trotzdem funktionieren.