Servereinstellungen von SE.de - warum ist XYZ eigentlich verboten/deaktiviert?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Servereinstellungen von SE.de - warum ist XYZ eigentlich verboten/deaktiviert?

      Guten .. *auf Uhr guggt* .. schonwieder Mitternacht o.O,

      nach dem Multiplayer-Update 1.187 läuft der Dedicated Server von Space-Engineers.de nun bereits wieder einige Wochen. Ich möchte das zum Anlass nehmen, ein wenig über die bisher gesammelten Erfahrungen damit auf dem Server zu teilen und auf einige Fragen einzugehen, die von unseren Spieler immer wieder mal gestellt werden - sei es zu Einstellungen des Servers (insbesondere deaktivierte Features), als auch administrativen Maßnahmen auf Grundlage des Regelwerkes.

      Entscheidungsgrundlagen
      Wann immer wir auf dem Server Maßnahmen setzen - Features ein- und ausschalten, Regeln verändern, leider auch Spieler maßregeln oder gar abstrafen - beruht dies in der Regel auf zwei sich meist gegenüberstehenden Aspekten: Wie beeinflusst eine Einschränkung den Spielspaß (und wer wäre betroffen) und stabilisiert sie nachhaltig die Perfomance (bzw. wieviel). Aus Leistungssicht wäre es simpel: einfach alle Spielmechaniken abdrehen, alle Spieler rauswerfen, keine Probleme mehr - is' dann halt a bissal langweilig... Also einfach mal alles aufrehen? Leider haben sich einige Spieloptionen als so schädigend erwiesen, dass die Deaktivierung das kleinere zweier Übel darestellt, wenn dafür die Spielgeschwindigkeit (einigermaßen) oben bleibt.

      Was leider zu oft gerade bei Wünschen oder Beschwerden vergessen wird: Der Server hat (derzeit) 25 Slots. Was wir einem Spieler ermöglichen bzw. durchgehen lassen, muss für alle gelten und ist dann ein 25x so großes Problem, wenn doch etwas schief geht. Dies ist auch der Hauptgrund, weswegen wir z.B. Limits auf eine Reihe von Blöcken setzen und nur aktiven Spielern durch das Ökonomiesystem die Möglichkeit bieten, diese zu überschreiten - SE ist unter anderem ein Bauspiel, leider ist das Bauen aber auch eins seiner langfristig größten Schwächen.

      Aber nun ein paar praktische Beispiele (Ähnlichkeiten mit realen Vorfällen sind natürlich rein zufällig...):

      "Warum nur 10 Bohrer?" / "Darf ich mehrere Bohrschiffe mit je 10 Bohrern kombinieren?"
      Ein Bohrer deformiert Voxel (also Gestein) und erzeugen damit eine große punktuelle Rechenlast auf dem Server. 10 Bohrer erzeugen - richtig geraten - die 10fache Last. Das Limit ist ein Kompromiss zwsichen Leistungshunger und Spielspaß. Gleichzeitig können wir damit das Wachstum der Spieler zumindest geringfügig bremsen und ein Maß an Langzeitmotivation erzeugen.
      "Aber 1 Bohrschiff mit 20 Bohrer wäre doch sicher nicht schlimmer als 2 Bohrschiffe mit je 10 Bohrern?"
      Doch. Zum einen würden die 20 Bohrer immer synchron arbeiten und damit exakt gleichzeitg mehr Voxel deformieren, zum anderen steht bei meheren Bohrern der eine oder andere schonmal still = Leistungsersparnis. Außerdem erzeugt das verbinden von Schiffen zusätzlichen physikalischen Berechnungsaufwand - von glitches durch Serverlatenz mal ganz abgesehen.
      Ähnliches gilt naheliegender Weise auch für Waffen(türme).

      "Warum sind Raffinierien so teuer?"
      Kurz: Damit nicht zuviele gleichzeitig in Betrieb sind. Jeder Produktionsblock (Raffinierie, Montageanlage, Vaporizer, sogar Reaktoren), der Inventar bewegt, sucht ständig in seinem Grid nach Rohstoffen, verschiebt diese, verarbeitet sie und schickt sie dann wieder in einen Container - zu jedem (!) Spieltick (!!). Zur Übersicht: Der Server beherbergt derzeit etwa 450 Raffinierien, 350 Assembler, 1100 Reaktoren, dazu zig Sortierer, O2/H2-Generatoren, Verbinder und unzählige Förderbandleitungen. Nein, eine Raffinierieanlage alleine macht noch nichts aus. Aber alle zusammen nutzen bereits den Großteil der verfügbaren Rechenzeit des Servers aus, bevor auch nur der erste Spieler mit dem Server verbunden ist und "spielen" (fliegen, bauen, kämpfen, ..) will.
      Der Umgang mit Produktionblöcken, insbesondere deren Menge pro Spieler / Fraktion / Grid ist wohl derzeit der größte Diskussionspunkt im Adminteam und wird sehr warscheinlich bald Änderungen erfahren (müssen).

      "Warum macht mich der Admin wegen der paar fallengelassenen Steine blöd an?"
      In meinem Fall, weil ich gerne den Dicken markie... nein, Blödsinn: Weil der Simspeed unmittelbar davon betroffen ist. Jeder fallengelassene Stein (wie auch jeder Barren, Baukomponente, Werkzeug, ...) ist ein "physikalisches Objekt", heißt: er bewegt sich, wird von Gravitation beeinflusst, kann kollidieren und abprallen, kann Blöcke sogar beschädigen. Bei einem Stein ist das nicht weiter tragisch - bei 30 Stück nach 10 Sekunden Bohren, in der Schwerkraft der Erde, in einem engen Loch, wo alle miteinander und einem Raumfahrer kollidieren, steht jedoch der Server im schlimmsten Fall still.
      "Warum dreht ihr dann nicht einfach die 'Floating Objects' ab?"
      Weil es jedem von uns schonmal passiert ist, versehentlich ein volles Inventar wezuflexen und wir anschließend froh waren, dass wir das Limiterium, die Space Coins, das Uran, den letzten Elite-Schweißer oder einfach nur den Rucksack des toten Astronauten (alles solche Objekte!) noch einsammeln konnten, bevor der Server sie gefressen hätte.

      "Ich möchte ein Schiff mit 10.000+X Blöcken bauen - warum habt ihr ein Blocklimit?"
      Leider beeinflusst die Größe eines Grids direkt die Leistung - Für jeden gebauten Block muss überprüft werden, ob irgendwann irgendwas mit ihm kollidiert. Je größer das Schiff/die Station, umso mehr gleichzeitige Abfragen fallen an - 10.000 ist ein weiterer Kompromiss. Darum sind wir auch nicht sonderlich glücklich, wenn dieses Limit umgangen wird, indem 2 Stationen knapp unter 10k Blöcken einfach nebeinander platziert werden - der Rechnaufwand steigt trotzdem, wird durch die Trennung sogar eher noch höher.

      "Könnt ihr Luftdichtheit einschalten?"
      Cooles Feature, solange jeder Raum dicht ist. In der Leistung katastrophal, sobald irgend etwas leck schlägt - und das tut es viel zu offff-f-f--f.. Da SE konstant die Dichtheit von Räumen überprüft und dies bei größeren oder gar offenen Räumen enorm Leistung frisst, ist dieses Feature deaktiviert. Keen selbst bestätigt: Eines der leider am schlechtesten optimierten Systeme im Spiel und damit hoch experimentell (siehe z.B. youtu.be/L_gZtOHkVKo?t=30m45s).

      "Aber Piraten / Drohnen / Zufällige Gegner / Megatron / das Krümelmonster könntet ihr doch aktivieren?"
      Könnten wir, aber: Zum einen würde es die Ökonomie auf den Kopf stellen (mit geringstem Risiko 100e Blöcke abfarmen), zum anderen sind dies PvE-Inhalte, die ihr ebensogut im Singleplayer bewältigen könnt - am Server kostet es die Geschwindigkeit aller, damit ein einzelner Spieler 5 Minuten Abenteuer genießen kann. Warum nicht stattdessen einen wirklich herausfordernden Kampf mit einer Fraktion starten.. so richtig PvP ;) ?

      "Darf ich das Skript ABC von XYZ betreiben?"
      Programmierbare Blöcke sind wohl die herausragendste Möglichkeit, das Spiel um eine ganze Palette an zusätzlichen Möglichkeit zu erweitern. Leider aber auch, dass ein Server bei Fehlbedienung augeblicklich in die Knie geht. Jede Zeile Code im PB muss sequentiell in der Spielsimulation am Server mitausgeführt werden. Braucht das Skript viel Rechenzeit durch viele Kommandos, häufige (langsame) Zugriffe auf komplexe Datensätze oder lange Schleifen, fehlt diese Zeit dann zur Ausfühunrg anderen Teile des Spiels - die Simulationsgeschwindigkeit wird (für alle) gedrosselt (siehe auch github.com/malware-dev/MDK-SE/wiki/Do's-and-Don'ts ).

      Zwar sind die meisten bekannten Skripte (MMaster LCD, TIM, MissleGuidance, ...) weitestgehend optimiert und auf Leistungsschonung getrimmt - falsch angewandt erzeugen sie jedoch trotzdem eine unnötige Mehrlast auf Kosten essentieller Systeme. Außerdem machts hier die Menge: Lassen wir ein Skript zu, müssen wir dies jedem einzelner Spieler zugestehen - dann wird es schnell mehrere dutzend mal ausgeführt, selbst wenn der Besitzer nicht online ist.

      "Ich seh aber garnicht, dass der SimSpeed sich ändert, wenn ..."
      Auch hier nochmal: Die Menge machts! Ein Programm, ein abgestürztes Schiff, ein Boherer, ein fallengelassener Stein.. ist für den Server in der Regel keine Herausforderung. Aber mit dir sind noch 24 andere Spieler online, die jeder auf seine ganz eigene Art und Weise die Hardware (über)fordern.
      "Im Singleplayer funktioniert das aber problemlos!"

      .. weil du keine Internetleitung mit Verzögerung ("Latenz"/"Ping") in der Kommunikation zwichen Client und Server hast und auch nicht 25 Spieler zugleich auf deinem Rechner spielen, oder?


      "Euer Server ist halt einfach sch...lecht."

      Mit Verweis auf die Server-Specs: Nein. Momentan rattert der Kasten mit maximal 15% seiner CPU Leistung für SE und benötigt nur rund 4 seiner 32 GB Ram. Space Engineers kann aber nur einen der 8 Prozessorkerne nutzen, weswegen nicht mehr geht, als was EIN Intel i7-6700k-Kern bei 4,0 GHz hergibt. Dafür könnten wir aber 8 gleichwertige Instanzen parallel betreiben -.- ...

      "Server abc schafft das aber mit Option 123 aktiv!"
      Aber hat Server abc auch 25 Spieler online? Über 400 dauerhaft aktive Grids? Keine Wipes alle 2 Wochen? Einen spielbaren Simspeed? Wenn du zumindest diese Fragen ausnahmslos mit JA beantworten kannst, bitte gib uns den Kontakt zu dem Severbetreiber von abc weiter - wir lernen gerne dazu, um unseren Server zu verbessern!


      Unser vorrangiges Ziel ist, euch ein lustiges Spielen mit möglichs wenig Problemen zusammen mit möglichst vielen anderen Speilern zu ermöglichen - im Falle von Space Engineers ist dies leider immer wieder mit Kompromissen verbunden, die wir eingehen müssen. Nicht jede Entschidung ist auf den ersten Blick nachvollziehbar, nicht jede Beschränkung offensichtlich notwendig - aber wir enstscheiden nicht leichtfertig. Manche Mechaniken von SE sind auch nach 5 JAhren Entwicklung bestenfalls suboptimal für den Multiplayermodus und wir möchten euch bitten, zwei Dinge im Hinterkopf zu behalten:
      • Ihr seid nicht alleine auf dem Server, nur wenn sich alle verantwortungsbewusst handeln, kann der Server funktionieren und jeder Spaß haben.
      • Und: SE ist immer noch eine Beta - in vielen Bereichen über die Jahre verbessert, aber bei weitem nicht perfekt. Wir versuchen zwar, dies weitestggehend zu kompensieren, trotzdem können wir nur mit dem arbeiten, was Keen bereitstellt - und manchmal hilft nur der Ausschalter.
      Ich hoffe, ihr konntet hiermit einen Einblick in Entscheidungen rund um Space-Engineers.de erhaschen - falls ihr fragen habt, versuchen ich und sicher auch die anderen Admins, nach besten Wissen diese zu beantworten! Auch für Feedback und konstruktive Kritik sind wir dankbar!

      Jedenfalls wünschen wir euch weiterhin viel Spaß beim Spielen!
      Scytero für das Adminteam von Space-Engineers.de
      Former Councelor of the United Factions Space Council (R.I.P.)
      Architect of the Orion Tech Syndicate
      Mastermind of future empires

      "He who stays in the footsteps of others cannot improve."

      ______________________________________________________________________________________________________