Beas absolut subjektive Chucklefishschau


Recommended Posts

CF hat tatsächlich vor Ewigkeiten mal gesagt, nach 1.0 würde es keine Wipes mehr geben; das ist in der Tat keine Garantie; allerdings sollte für dieses Update auch kein Wipe nötig sein. An den Planeten selbst scheint sich ja nichts zu ändern; nur die Darstellung auf der Karte ist anders. Soweit ich das sehe ist das einzige neue in den Saves Raumstationen; diese könnten entweder nachträglich in bereits generierten Systemen erzeugt werden, oder sie tauchen einfach nur in neu generierten Systemen auf. Die NPC Schiffe scheinen ja nicht an ein System gebunden zu sein.

Link to post
vor 19 Stunden schrieb Gin:

Die Hoverbikes und Boote haben schon genug Probleme. Ich will gar nicht wissen wie sehr das Reiten von Tieren laggen würde.

 

Etwas Off-Topic und eher für die Nerds unter uns, aber grob zu "Lags": Dieser Artikel zum Thema TCP vs UDP ist ganz interessant. Starbound verwendet TCP, was auch ein Grund für Verzögerungen sein könnte, um es vorsichtig auszudrücken. Auf dieser Seite geht es oben nochmal um das gleiche Thema, außerdem gibt es dort Videos, wo man den Einfluss von Paketverlust und hoher Latenz sehr schön sehen kann, leider sind die Videos momentan nicht verfügbar.  - Die Videos funktionieren jetzt wieder.

 

Edit: Die Videos zeigen allerdings so ziemlich den 'worst case', normalerweise würde man die Verzögerungen durch Inter- / Extrapolation ausgleichen.

Link to post

Ich versuche mal, das einfach zu erklären (sorry für die Wall of Text :S):

Nehmen wir an, wir haben zwei Rechner / Benutzer A und B. Wenn eine TCP-Verbindung zwischen A und B aufgebaut wurde, können Daten ähnlich wie beim Schreiben / Lesen einer Datei übertragen werden. A kann Daten schreiben, B kann diese Daten auslesen. Das Schöne daran: Genau wie bei einer Datei werden bei TCP alle Daten in genau der Reihenfolge bei B gelesen, in der sie von A geschrieben wurden. Außerdem ist garantiert, dass alles, was gesendet wird, auch ankommt. Es kann zwar passieren, dass Daten von A gesendet werden und auf dem Weg zu B verloren gehen oder beschädigt werden, das wird aber automatisch erkannt, A sendet diese Daten automatisch nochmal (ohne dass man sich als Programmierer darum kümmern muss). Die Daten werden also in fester Reihenfolge und verlässlich gesendet / empfangen.

 

Obwohl (auf einer technischeren Ebene) alle Daten in Form von Paketen versendet werden, arbeitet man bei TCP mit einem "Stream" (ohne gegebene Unterteilungen). TCP kümmert sich darum, die gesendeten Daten in einzelne Pakete zu unterteilen, beim Empfänger wird dieser Stream aus den Paketen wieder zusammengesetzt.

 

TCP klingt eigentlich sehr schön: Alles, was gesendet wird, kommt auch an (bzw. werden verlorene Daten automatisch erneut gesendet), außerdem kommt alles in der Reihenfolge an, in der es gesendet wurde. Der Preis dafür ist: Wenn Daten verloren gehen, muss gewartet werden, bis sie erneut gesendet und erfolgreich angekommen sind (da die Reihenfolge der Daten ja beibehalten werden soll). Es kann durchaus sein, dass inzwischen schon neuere Pakete empfangen wurden, allerdings muss erst auf die verlorenen Pakete gewartet werden - und das kann leider etwas dauern.

 

-----

 

Bei UDP werden die Daten nicht in einem Stream gesendet, sondern in einzelnen Paketen. Es kann auch hier passieren, dass Pakete auf dem Weg zum Empfänger verloren gehen oder beschädigt ankommen, solche Pakete werden aber einfach verworfen, ohne dass der Empfänger etwas davon erfährt. Die einzige Garantie ist: Wenn ein Paket ankommt, dann ist es vollständig und fehlerfrei. Allerdings ist nicht garantiert, dass die Pakete in genau der Reihenfolge ankommen, in der sie auch gesendet wurden. Da nicht auf verlorene Pakete gewartet werden muss, kann man UDP als "schneller" sehen.

 

UDP klingt erstmal ziemlich mies, oder? Wieso sollte man das Risiko eingehen, dass Daten einfach verloren gehen oder in der falschen Reihenfolge ankommen, wenn man doch TCP hat? Wenn man sich anschaut, welche Anwendungen UDP verwenden, ist es aber eigentlich einleuchtend. Echtzeitanwendungen wie Video- oder Sprachtelefonie verwenden UDP, weil es akzeptabel ist, dass einzelne Pakete verloren gehen. Nehmen wir mal an, bei Teamspeak gehen ein paar Pakete hintereinander verloren. Das ist kein Problem - es geht vielleicht ein gesprochenes Wort verloren, danach läuft die Übertragung aber ohne Verzögerung weiter.

Was würde man jetzt tun, wenn Teamspeak TCP verwenden würde und ein paar Pakete verloren gehen? Erstmal wird gewartet, bis alle verlorenen Pakete erneut gesendet wurden. Solange hört man dann gar nichts. Wenn alle Pakete angekommen sind, hat man aber plötzlich veraltete Daten (Sprachnachrichten, die schon eine Sekunde alt sind). Was macht man mit den Daten jetzt? Sie trotzdem abspielen? Dann geht zwar nichts verloren, aber man hört veraltete Nachrichten. Oder sollen diese Daten einfach verworfen werden? Dann hat man lange gewartet und die gesamte Übertragung angehalten, obwohl man die Daten im Endeffekt einfach wegwirft. In diesem Fall macht UDP auf jeden Fall mehr Sinn.

 

Multiplayer-Spiele sind natürlich auch zeitkritisch, besonders z.B. Shooter: Es ist wichtig, mit aktuellen Positionsdaten der anderen Spieler zu arbeiten. Wenn mal ein Paket verloren geht, möchte man auch hier nicht eine halbe Sekunde auf veraltete Daten warten.

 

Prinzipiell gibt es aber auch bei Spielen Daten, die auf jeden Fall ankommen sollen, selbst wenn ein Paket verloren geht, z.B. Chatnachrichten. Mit UDP muss man also irgendwie manuell sicherstellen, dass diese Nachrichten auch wirklich ankommen. Das erfordert natürlich mehr Aufwand, allerdings gibt es zahlreiche Programmbibliotheken, die diese Arbeit abnehmen.

Link to post

Hm ... Das neue Design sieht irgendwie ein wenig zusammengestaucht aus. Aber naja.
 

vor 21 Stunden schrieb Olaxis:

Die Leute in der Arcade tragen auch wie es aussieht eine neue Kopfbedeckung

Ist das Kostüm nicht auch neu? Das sieht irgendwie aus wie 'n Sträflingsanzug mit Elektro-Halsband oder sowas.

Link to post

Am Anfang des GIFs ist ein Schiff zu sehen (Unten rechts), das dann rausspringt. Auch wenn wir das noch nie richtig bestätigt bekommen haben, ist das das was wir für random Encounter gehalten hatten. Aber ja, es scheint als würde man sich nicht mehr frei bewegen, sondern nur zu bestimmten Punkten hin fliegen.

Link to post

Ja... Und ich muss sagen, das gefällt mir durchaus! Und der blaue Balken ist anscheinend "Energie", die der Mech über Zeit verbraucht. Und da sowohl die maximale Energiemenge als auch der Verbrauch angegeben ist, gehe ich davon aus, dass beide auch durch Module beeinflussbar sind.

Link to post

Es ist zwar sehr interessant, jedoch frage ich mich persönlich halt ... Wofür? Damit man in einem Asteroidenfeld nichts bauen muss und sich jederzeit dahin teleportieren kann? ... Hm. Außerdem scheint es durch die Module ja nicht völlig frei designbar zu sein. Kommt für mich also eher rüber wie eine Schiffserweiterung.

Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now