Beiträge von Zp9

    Da wäre dann wieder interessant, im "Close Laptop" Fall das Panic-Skript auszulösen und den Rechner danach in Suspend zu schicken...

    CmdKleiner woher soll das Spiel dann wissen, ob ich einfach das nächstliegende KH vollknalle oder ob ich wesentlich großräumiger jeweils nur 3...4 Betten je KH belege und dann wieder das nächste nehme? Strategisch ist es ja eh besser, auf möglichst viele KH zu verteilen und das geht eh nur händisch gescheit. Und noch mehr Optionen, wo man dieses Verhalten des ELW-SEG dann einstellen kann?

    Ich könnte mich eher mit der dynamischen Lösung anfreunden: Das System nimmt einfach nicht mehr die Liste aller KH sondern die Liste aller KH, in denen noch mindestens soviele Betten + 1 frei sind, wie der ELW-SEG als Mindestfreiwert eingestellt hat. Also einen einstufigen Filter davor. Dann wird die Liste erst eng, wenn wirklich kein KH mehr diese Kriterien erfüllt... bei "0 freilassen" sind dann wirklich alle KH belegt.

    Weiß jetzt nur nicht, wieviel mehr an Zeit je Patienten die Filterung benötigt, ob das serverlastrelevant wäre... denke, das braucht weniger Last wie die Sprechwunschgenerierung und Anzeige der Zuweisungsliste beim Spieler...

    Ich will das mal von der anderen Seite sehen... ist es nicht irgendwann auch genug Automatisierung?


    Ich nutze ELW-SEG auch recht exzessiv, bei jedem RD-Einsatz fährt einer mit. Aber das Problem, dass er keine KH mehr zuweisen kann weil die ersten 30 voll sind ist mir bisher genau 2x untergekommen. Dann kommt eben die 5 und man weist per Hand zu... ihr wollt nicht wissen, was ein Leitstellendisponent im RL in solchen Momenten für ein Problem hat...


    Wir können nicht auf der einen Seite ständig über Serverprobleme meckern und auf der anderen Seite Funktionserweiterungen fordern, die das Rechen- und Datenvolumen vergrößern.


    Wieviele KH sollen denn gecheckt werden? 40? 50? Seid ehrlich, wenn ihr die Infrastruktur gescheit ausgebaut habt dann kriegt ihr keine 30 KH voll. Das passiert euch nur, wenn ihr sinnfrei alle KH mit massig Betten ausgebaut habt, anstatt ein zweites oder drittes Bettenhaus danebenzustellen. Wenn ihr in ländlicheren Regionen spielt und nur Realstandorte genommen habt - dann habt ihr das gleiche Problem wie der echte RD draußen auch, klar. Aber selbst dann kannst du 3-4-5 KH an einen Fleck stellen und nennst sie "XY-Klinik, Chirurgie - XY-Klinik, Innere - XY-Klinik, Uro&Gyn" usw... zack, schon werden 3 pro Std entlassen und nicht nur einer...


    Gerade für die "großen" Spieler ist ein weiteres KH doch nun wirklich kein unerreichbarer Kostenfaktor...

    Grundsätzlich haben gerade langsamere PC/Laptops Probleme, die Grafik flüssig darzustellen, wenn die Anzeige der Routen und / oder der Gebäude fremder Spieler aktiviert ist. Das Abschalten dieser beiden Optionen bringt einen erheblichen Performancegewinn...

    Diesen Vorschlag gab es schon mehrfach - Suchfunktion benutzen.


    Aktuell kannst du am Standort des Krankenhauses eine RD-Kleinwache bauen und dort das NEF stationieren.


    Den Notarzt bildest du an der Rettungsdienstschule aus.

    Ich denke, der für alle tolerierbare Weg führt über weitere SEG-Gruppen. Es spricht schließlich nichts dagegen, der SEG-Betreuung auch nochmal einen RTW zuzuordnen.



    Da ansonsten der KTW-B im Zusammenspiel mit dem GW-San in fast allen Fällen einen RTW ersetzt - dagegen.


    Der KTW-B ist schließlich auch im BBK-Konzept als "RTW light" für den KatS/MANV-Einsatz konzipiert worden. Man muss nur für je 5 Patienten einen GW-San mitschicken, dann werden auch alle sofort behandelt (der GW-San kann nur 5 Pat gleichzeitig für den Transport mit dem KTW-B vorbehandeln).


    Übrigens generiert eine SEG doch prinzipiell Einsätze - nämlich zwei verschiedene Sicherheitswachen, für die dann aber auch nur SEG-Fahrzeuge benötigt werden.

    Neben der von CmdKleiner schlüssig vorgerechneten extremen Creditgenerierung (bei 200 RTH-pflichtigen Pat. kannst du dir Credits pro Coin schon ausrechnen) dürfte auch die Unwägbarkeit der Einsatzhäufigkeit eine Rolle gespielt haben. Aus den Performanceproblemen seinerzeit (die dann durch die Patientengruppierung erstmal gelöst wurden) wissen wir, dass Patienten einen Gutteil der Serverlast ausmachen. Wenn diese "Unmengen" nun nur serverseitig (und nicht spielerseitig) generiert werden können, dann kann das System bspw. die Generierung von MANE-Einsätzen aussetzen (zeitweise blocken), wenn die Serverlast sehr hoch ist... einem Spieler die 10 Coins abzuziehen und das Fenster "Der Einsatz wird aufgrund der aktuellen Serverlast zu einem späteren Zeitpunkt generiert" aufpoppen zu lassen dürfte genauso unbefriedigend sein, wie einfach die Patientenzahl stärker als bisher zu begrenzen.

    Ich gebe zu bedenken:


    DIY-GSL werden völlig zufällig durch Spieler gestartet. Die Wahrscheinlichkeit steigt mit der Anzahl anwesender Spieler. Und zur "besten Sendezeit" gleich nochmal. Das ist aber auch die Zeit, in der die Server regelmäßig an ihre Grenzen kommen.


    Die "neuen" MANE-Einsätze werden vom Server generiert. Es ist technisch kein Problem, die Anzahl gleichzeitig laufender solcher Einsätze zu begrenzen bzw. die Neugenerierung von der aktuellen Serverlast abhängig zu machen.


    Insofern hat ein MANE-Einsatz weniger Chance, den Server zu "sprengen" als eine DIY-GSL. Die Erhöhung der Patientenzahl beim DIY wäre eigentlich auch mein Wunsch... aber dann müsste die Zufallssteuerung noch mehr eingreifen und bei hoher Serverlast entsprechend Patienten "weglassen". Ziemlich unbefriedigend, wenn einer 10 Coins ausgibt, weil er den RD mal auslasten will und statt der eingestellten 250 kommen doch nur 80... weil die Serverlast zu hoch ist und damit "abgeregelt" wird.