Beiträge von RumBugen

    Es liegt höchstwahrscheinlich an den Parent Entities (Weihnachtshüte) und irgendwie lösen sie einen Pointer aus, der nicht existiert. Zumindest ist es das, was ich rauslesen kann. Wir sind dran, dass es nicht mehr crasht. Wir haben jedoch den Auslöser noch nicht gefunden. Es liegt aber nicht an den Rentieren, weil die keine Parent Entities besitzen und auch nicht am Schnee (der ist clientseitig, da würde dann das Spiel der Leute crashen und nicht der Server).

    Version 3.0.2

    [tabmenu]

    Den gibt es schon seit einigen Tagen immer wieder. Das liegt daran, dass beim Client der eigene Spieler manchmal nicht ankam (Networking). RaphaelIT7 hat ein paar Fixes gemacht, sodass es morgen besser funktionieren sollte.

    Auch ich sehe diese Änderung nicht als notwendig an.


    Ich kann das hier wiederholen, da es auch meine Sichtweise gut widerspiegelt:

    Wissenschaftler haben bereits das Glück so gut wie keine Ausgaben auf dem Server zu haben, um ihren Job richtig nachzugehen.

    Tests benötigen, in der Regel, keine besonderen Gegenstände, da haben es MTF und CT um einiges unangenehmer mit ihren Recontainmethoden.

    Dinge die du kaufst sind eine Investition welche du tätigst um irgendwann mal zu testen und keine regelmäßigen Pflichtkäufe, daher finde ich diese Änderung nicht nötig.

    Daher ist es auch nicht geplant.

    Ich habe schon oft darüber nachgedacht, wie ich SCP-3199 ändern könnte, da es nicht der erste Vorschlag ist und ich auch sehe, dass die Breaches meistens sehr schnell vorbeigehen. Wir haben noch einige Features geplant. Bei den kurzfristigen Änderungen beim Rebalancing habe ich ähnlich gedacht und viel mehr Fokus auf die Eier gesetzt. Er kann auch schon jetzt bis zu sechs Eier legen, entscheidend ist der vergleichsweise hohe Cooldown. Dazu habe ich bereits einige Änderungen vorgenommen, die noch nicht veröffentlicht wurden. Grundsätzlich ist der Kernpunkt der Änderung, mit den Eiern, bereits verändert geplant. Bei manchen anderen Punkten hatte ich jedoch andere Vorstellungen.


    Zwei Aussagen möchte ich korrigieren:

    Bin mir gerade nicht sicher ob 3199 bei einem Fehlschlag ein anderes Ei aussuchen kann, aber dieser Change setzt das vorraus

    Nehmen wir an man hat 2 Leute erwischt, wurde durchgecallt und inzwischen schon Terminiert. Normalerweise wär es das, aber jetzt kannst du auf deinen Respawn Timer warten wärend MTF/CT Eier sucht, zerstört was sie können und vielleicht eine Stellung auf baut um dich abzufangen sollten sie Eier übersehen haben. Du respawnst und hast Glück, MTF hat die Stellung am falschem Ort, abhauen und neue Eier verteilen bis du gefunden wirst und ein neuer Kampf beginnt.

    Nach dem Respawn siehst du alle Eier und kannst selbst auswählen, wo du spawnen möchtest und wo nicht. Du würdest auch sehen, wo eine MTF-Stellung ist, bevor du schlüpfst, und kannst dir entsprechend aussuchen, bei welchem Ei der beste Ort zum Ausschlüpfen ist.

    Das liegt an deinem Reconnect-Skript. Keines unserer Systeme versucht dich automatisch direkt neu zu verbinden. Es könnte jedoch sein, dass ein Teammitglied es versucht hat. In beiden Fällen handelt es sich nicht um einen Bug.

    Wenn wir mehrere vergangene Maps "sperren", landen wir bald bei einer festen Map-Rotation, dann können wir direkt auch das Mapvote-System abschaffen.

    Zusätzliche Einschränkungen in diese Richtung bringen keinen echten Mehrwert. Wenn nun mal diese Maps beliebter bzw. häufiger gespielt werden, sollte man das nicht weiter einschränken.


    Wir haben schon durch eine Änderung verhindert, dass eine Map viermal hintereinander drankommt und die Stimmzahlen versteckt für Spieler.


    Ich überlege schon seit einiger Zeit, ob man auch diese Änderungen rückgängig macht und nur noch zulässt, dass zweimal hintereinander dieselbe Map dran genommen werden kann. Am Ende soll es ja ein Mapvote-System sein, bei dem die Spieler frei wählen können, welche Map ihnen am besten gefällt. Es gibt auch andere Möglichkeiten, unbeliebtere Maps wieder ins Leben zu rufen.


    Im Highteam gab es bereits einen ähnlichen Vorschlag: „Sobald eine Map gevotet wurde, sollte diese aus dem Map-Pool entfernt werden, bis alle Maps mindestens einmal gewählt wurden.“

    Dieser wurde auch abgelehnt, und ich denke nicht, dass man da erst einmal etwas ändern sollte.


    Es wird immer beliebte und unbeliebte Maps geben, und wenn man Personen irgendwann zu einer anderen Auswahl zwingen möchte, ist es auch kein Mapvote-System mehr. Da kann man gerade andere Modelle nehmen, wie: ein Monat Map A, ein Monat Map B usw., oder dass die Map jede Woche komplett zufällig gewählt wird.

    Wie schon erwähnt, denke ich nicht, dass das Mapvote System geändert werden sollte in so eine Richtung. Weshalb dieser Vorschlag in dieser Form auch nicht geplant ist.

    Version 3.0.1


    [tabmenu]

    Das ist ein Duplikat, die Begründung hat sich nicht verändert. Es gibt genug andere Prioritäten. Anstatt alle paar Monate den Vorschlag zu machen, wäre es sinnvoller, einfach zu schauen, wie viele Forum-Vorschläge bearbeitet werden. Es sind immer noch sehr viele als „Geplant/Verschoben” gekennzeichnet. Ich möchte nicht am Ende 20 SCPs „versprechen”, die dann aus verschiedenen Gründen eventuell gar nicht erscheinen können oder weil zum Zeitpunkt der Annahme ein paar Aspekte nicht durchdacht wurden.


    Außerdem finde ich das SCP immer noch ein wenig zu unüberlegt. Seine Spezialfähigkeit ist bereits für SCP-3199 geplant.

    Vielleicht fällt mir was ein zu einem späteren Zeitpunkt und wenn wir auch nicht so viele geplante Inhalte haben ein.