Rangliste

Als ein Backer sich im Spectrum über 30K und seine finanziellen Verluste ärgerte und bei CIG nachfragte, bekam er eine sehr detaillierte Antwort die einige Fragen beantwortet und Einblicke in die Entwicklung ermöglicht. Clive Johnson CIG@cjohnson Zitat: "In Ihrer Frage gibt es eine ganze Menge zu beantworten. Ich werde versuchen, auf die wichtigsten Punkte einzugehen, aber bitte entschuldigen Sie, wenn Sie das Gefühl haben, dass ich etwas Wichtiges ausgelassen habe. Wann werden die Server stabil sein? Am Ende der Beta-Phase. Warum nicht schon vorher? Weil wir erst den Rest des Spiels fertig machen müssen. Wenn an einem Spiel als geschlossener Alpha gearbeitet wird, liegt der Schwerpunkt auf der Entwicklung von Features und Inhalten. Stabilität und Fehlerbehebung treten in den Hintergrund, und es werden nur Fragen behandelt, die die weitere Entwicklung behindern würden. Das mag unprofessionell klingen, aber die Idee dahinter ist, Ideen so schnell und kostengünstig wie möglich auszuprobieren. So können die Entwickler herausfinden, welche Teile des Spieldesigns funktionieren und welche überarbeitet werden müssen. Es hat keinen Sinn, Zeit mit der Fehlerbehebung für eine Funktion zu verbringen, die sich jederzeit ändern oder sogar ganz aus dem Spiel entfernt werden kann. Die Entwicklung wird mit dem Spiel in diesem halbgeschädigten Zustand zumindest solange fortgesetzt, bis alle Funktionen und Inhalte gesperrt sind. Das Spiel geht dann in die Beta-Phase der Entwicklung, in der Fehlerbehebung, Optimierung, Balance und Feinschliff im Vordergrund stehen. Im Idealfall wird während der Beta-Phase nicht an den Features gearbeitet, aber es werden fast immer in letzter Minute noch einige Änderungen eingefügt. Bei SC handelt es sich natürlich um eine offene Entwicklung, d.h. während der Schwerpunkt in der Alpha-Phase noch darauf liegt, verschiedene Ideen auszuprobieren, muss das Spiel stabil und funktionsfähig genug sein, damit die Geldgeber es testen und ihr Feedback geben können. Das Schlüsselwort dort ist "genug", was natürlich nicht perfekt bedeutet. Es ist wichtig, dass wir die richtige Balance zwischen Fehlerbehebung und Weiterentwicklung finden: zu viel Fehlerbehebung und Entwicklung verlangsamt sich, zu wenig und wir bekommen nicht genug Feedback oder die Fehler behindern die Weiterentwicklung. Hat CIG die richtige Balance zwischen Fehlerbehebung und Weiterentwicklung? Das Problem bei der Feststellung, ob ein Build "stabil genug" ist, besteht darin, dass wir nur betrachten können, wie sich die Stabilität auf die gesamte Spielerbasis, d.h. den Durchschnitt, auswirkt. Es wird daher einige glückliche Geldgeber geben, die weit weniger Abstürze oder andere Probleme als der Durchschnitt erleben, während es einige arme Seelen geben wird, für die der Build ein fehlerbehaftetes Crash-Fest zu sein scheint. Fragen Sie die glücklichen Spieler, ob wir die richtige Balance haben, und sie könnten sagen, nein, das Spiel ist stabil genug, und wir müssen uns mehr auf die Erweiterung des Spiels konzentrieren. Fragen Sie die Unglücklichen, vielleicht sagen sie dann immer noch nein, aber sie wollen, dass wir die Arbeit an neuen Funktionen einstellen, bis alle aktuellen Fehler behoben sind. Nur sehr wenige Leute werden ja sagen. Als Faustregel gilt: Bevor wir einen Patch für Live veröffentlichen, versuchen wir sicherzustellen, dass er mindestens so stabil ist wie die vorherige Live-Veröffentlichung. Einige Patches können für bestimmte Spielweisen mehr oder weniger stabil sein als frühere, aber insgesamt sollte die Stabilität von Patch zu Patch besser werden. Natürlich klappt es manchmal nicht so, wie wir uns das wünschen, und die durchschnittliche Stabilität wird am Ende nicht so gut sein wie bei der vorherigen Version. Warum beheben wir nicht die Server-Abstürze, die 30000 Unterbrechungsfehler verursacht haben? Das tun wir. Es sieht nur so aus, als ob wir es nicht tun, denn unabhängig von der Ursache führen alle Serverabstürze dazu, dass Clients die gleichen 30000 Unterbrechungen der Verbindung erhalten. Diese Verbindungsunterbrechung geschieht, weil die Clients nach dem Absturz des Servers plötzlich keinen Netzwerkverkehr mehr von ihm empfangen. Sie warten dann 30 Sekunden lang, um zu sehen, ob der Datenverkehr wieder aufgenommen wird (falls der Server vorübergehend blockiert war oder es einen kurzen Netzwerkausfall gab), bevor sie aufgeben, zu den Front-End-Menüs zurückkehren und den Trennungsfehler anzeigen. Während dieser 30 Sekunden sehen die Clients, dass sich die Türen nicht öffnen und dass KI, Terminals und andere Einheiten nicht mehr reagieren. Befürworter verwechseln diese Symptome manchmal mit einem Anzeichen dafür, dass der Server kurz vor dem Absturz steht, und man sieht im Spiel-Chat vielleicht, dass ein Serverabsturz bevorsteht, aber in Wahrheit ist der Server bereits tot. Es handelt sich um einen Ex-Server. Er hat aufgehört, ein Ex-Server zu sein. Wenn wir ihn nicht auf seine Stange genagelt hätten, würde er die Gänseblümchen in die Höhe schieben. (Der Chat im Spiel funktioniert nur deshalb weiter, weil er von einem anderen Server verwaltet wird). Wenn ein neuer Patch für PTU vorbereitet wird, stehen fast täglich neue Builds zum Herunterladen zur Verfügung. Sobald DevOps im ATX den neuen Build auf die Server gepusht und zum Download zur Verfügung gestellt hat, überwachen sie den Build während der ersten Stunden und arbeiten dafür oft bis spät und suchen nach allem, was auf ein Problem hinweist, das sofort behoben werden muss. In den nächsten Stunden spielen die Leute das Spiel, laden ihre Absturzberichte hoch, reichen sie beim Issue Council ein, antworten auf Feedback-Foren usw. Server-Abstürze werden alle automatisch in einer Datenbank aufgezeichnet. Wenn die EU-Studios aufwachen, sieht die technische Qualitätssicherung die hochgeladenen Client-Abstürze und die aufgezeichneten Server-Abstürze durch und nimmt eine erste Einschätzung vor, wer die schlimmsten Übeltäter sind, je nachdem, wie oft sie auftreten und wie schnell nach dem Beitritt zu einem Spiel. Serverabstürze landen fast immer an der Spitze des Stapels, allein schon deshalb, weil sie mehr Menschen betreffen als einzelne Clientabstürze. Jiras werden erstellt und an die Produktion weitergeleitet. Die Produktion erledigt hier drei Dinge: erstens schickt sie den Absturz Jiras zur Triage an die Leads, zweitens bestätigt sie die Prioritäten und welche Abstürze die QA versuchen sollte, zu reproduzieren oder anderweitig zu unterstützen, drittens meldet sie besonders schlimme Abstürze bei den Direktoren für Prioritätsanrufe, falls zusätzliche Personen umbesetzt werden müssen, um eine rasche Lösung zu gewährleisten. In der Zwischenzeit triagieren die Leiter die Abstürze und stellen sicher, dass sie an die richtigen Programmierer in den richtigen Teams gehen. Dann untersuchen die Programmierer die Fehler, wobei sie oft mit der QA zusammenarbeiten, um so viele Informationen wie möglich über den Fehler zu finden. Meistens können die Programmierer einen Fix noch am selben Tag committen, aber manchmal kann es ein oder zwei Tage länger dauern. In seltenen Fällen kann es ein paar Wochen dauern, um das Problem aufzuspüren und einen Fix zu finden. In sehr seltenen Fällen ist der Fehler ein Symptom eines tieferen Fehlers, der eine Umstrukturierung eines Systems erfordert, damit es auf eine andere Art und Weise funktioniert, nicht rechtzeitig oder ohne erhebliches Risiko für den aktuellen Patch durchgeführt werden kann und zu einem Rückstand hinzugefügt werden muss, der für eine zukünftige Version eingeplant werden muss. Sobald ATX online geht, veröffentlichen Community und DevOps ihre Berichte über den vorherigen Build aus den Informationen, die sie im Laufe des letzten Tages gesammelt haben. Die Produktion gibt einen Build mit allen neuesten Fixes frei und trifft sich mit QA, Community und DevOps, um zu beurteilen, ob der neue Build wahrscheinlich besser sein wird als der letzte oder ob zunächst zusätzliche Fixes erforderlich sind. Die Produktion gibt ihre Empfehlung an die Führungskräfte weiter, die an diesem Tag eine Go/No-Go-Entscheidung über den Versuch treffen, den neuen Build an PTU zu übergeben. Falls ja, beginnen ATX QA und DevOps damit, sich durch eine Vorab-Checkliste zu arbeiten, deren Bearbeitung mehrere Stunden in Anspruch nimmt. Wenn L.A. online geht, können die EU-Programmierer alle Probleme übergeben, die speziell für die L.A.-Teams bestimmt waren oder an denen die EU-Teams gearbeitet haben, die aber ungelöst sind und von einer weiteren Untersuchung profitieren würden, nachdem die EU für den Tag fertig ist. Wenn ATX die Vorab-Checkliste ausgefüllt hat, und wenn der Bau abgeschlossen ist, beginnt der Zyklus von vorn. Wenn wir die Abstürze beheben, warum kommt es dann immer wieder zu 30000 Verbindungsabbrüchen? Zwischen jeder vierteljährlichen Veröffentlichung ändern wir eine Menge Code. Einiges davon ist komplett neu und einiges davon sind lediglich Änderungen an bestehendem Code. Jede Änderung, die wir vornehmen, birgt die Chance, dass sie Fehler enthalten könnte. Wir sind auch nur Menschen und alle machen von Zeit zu Zeit Fehler, so dass jedes Quartal das Potential hat, eine Menge neuer Fehler hinzuzufügen. Es gibt Prozesse, die die Wahrscheinlichkeit, dass das passiert, verringern, aber einige schlüpfen immer wieder durch. Sobald ein Fehler entdeckt wird, muss er behoben werden. Manchmal funktioniert eine Korrektur nicht. Manchmal wird der Absturz nur in einigen Fällen behoben, aber nicht in allen. Manchmal ist in der Korrektur selbst ein Fehler enthalten, der andere Probleme verursachen kann. Eines der Dinge, die wir recht häufig sehen, ist, dass, sobald ein häufiger Absturz behoben ist, ein oder mehrere andere Abstürze häufiger auftreten werden. Das passiert, weil der Absturz, der gerade behoben wurde, die anderen Abstürze so stark blockiert hat, wie es sonst der Fall gewesen wäre. Wie oben erwähnt, gibt es auch Abstürze, die nicht sofort behoben werden können und warten müssen, bis mehr Zeit zur Verfügung steht, um sie richtig zu beheben, oder bis andere geplante Arbeiten abgeschlossen sind. Letztendlich werden jedoch die meisten der häufigsten Abstürze behoben. Was dann übrig bleibt, sind die wirklich seltenen Abstürze, die Abstürze, die nur einmal im Monat auftreten und über die wir noch nicht genügend Informationen haben, um sie zu beheben oder zu reproduzieren. Einer dieser seltenen Fehler allein wird keinen großen Unterschied machen, aber hundert solcher Fehler würden für mindestens drei Serverabstürze pro Tag ausreichen. Wenn wir die Server nicht stabil machen können, warum bieten wir dann nicht irgendeine Art von Wiederherstellung an? Es wurde vorgeschlagen, dass die Bereitstellung einer Art Frachtversicherung verhindern könnte, dass Spieler große Summen an aUEC verlieren, wenn ihr Server mitten im Frachtlauf abstürzt. Ich glaube, dass dies in Erwägung gezogen wurde, aber es ist klar, dass dies als Exploit missbraucht werden könnte. Solange dieses Problem nicht gelöst ist, ist es unwahrscheinlich, dass eine Frachtversicherung im Spiel auftaucht. Ein weiterer Vorschlag ist, eine Art Wiederherstellung nach einem Serverabsturz hinzuzufügen. Die Idee dabei ist, dass bei einem Serverabsturz alle Clients mit einem 30000 wie jetzt in die Menüs zurückgeworfen würden, dann aber die Möglichkeit hätten, sich einem neu aufgebauten Server anzuschließen, der den Zustand des Originals aus der Persistenz wiederhergestellt hat. Das ist eigentlich etwas, was wir uns erhoffen, aber es erfordert mehr Arbeit am SOCS und volle Persistenz, bevor es geschehen kann, so dass wir noch weit davon entfernt sind. Es gab auch andere Vorschläge, wie z.B. Clients oder Server, die den Zustand des Spiels in lokalen Dateien speichern, aber diese sind nicht sicher, oder es wäre eine vorübergehende Lösung und eine Verschwendung von Arbeit für die Implementierung und Wartung, die stattdessen auf die Arbeit an der richtigen Lösung verwendet werden könnte. Im Moment ist es am besten, wenn wir weiterhin Abstürze beheben, sobald wir sie finden, und hoffen, dass die Server stabil genug sind, dass die meisten Spieler das Spiel testen können." Übersetzt mit www.DeepL.com/Translator (kostenlose Version) Quelle:https://robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/server-issues-30k/3034939

Nicht von mir aufgenommen

@RockOutdiese Probleme haben leider alle im Moment, dass liegt sicher am PTU . Das wird besser wenn 3.9.1 live ist *hust*. @Alter.Zocker und @Butcherbirdvielleicht geht es nur mir so, aber bitte solche Neuigkeiten aus dem Evocati-Build als Spoiler markieren, ich möchte mich am Freitag überraschen lassen und uninformiert die Show genießen.

@Alter.Zocker Die "Fleet", bestehend aus einer Javelin, 2 Idris-M und diversen Kleinschiffen , fliegt abwechselt die Orbital-Stationen von Microtech, Hurston und Arccorp an. Sie verweilt dann ca. eine Viertelstunde umd fliegt dann wieder weiter.

Ja @Sirch,is schon klar, hab aber auch nur geschrieben, dass offenbar die Mole mit bei den Umfärbbaren Schiffen dabei ist...es kam weiter oben nämlich die Frage auf, bei welchen Schiffen das Umfärben denn nun funktionieren soll. Aber danke nochmals für Deinen Hinweis, so sollte es für alle Mitleser nun auch klar sein

Hallo zusammen, spannende Neuigkeiten zum Thema Skins: Schnelle Übersetzung (DeepL, ohne Korrektur): Mit der Veröffentlichung von Alpha 3.9.1 und der Einführung der Invictus Launch Week (Star Citizen's Fleet Week) freuen wir uns, eine Reihe von Änderungen einzuführen, wie Sie Ihr Schiff zu Ihrem eigenen machen können. Viele von Ihnen werden sich wahrscheinlich noch an unsere Fragen und Antworten zur Schiffsanpassung erinnern, und wir möchten zu Beginn bestätigen, dass unsere langfristigen Ziele die gleichen bleiben. Während Sie schließlich in der Lage sein werden, sowohl Hersteller- als auch Aftermarket-Geschäfte im Spiel zu besuchen, um sich über eine Vielzahl von Anpassungsoptionen zu informieren, haben wir ein temporäres System eingerichtet, um den Wunsch zu stillen, das äußere Erscheinungsbild Ihres Schiffes zu verändern. Was bedeutet das also genau? Alle Schiffe werden mit ihrer Basis-Skin und der Möglichkeit zur Ausstattung mit zusätzlichen Skins über mobiGlas ausgeliefert. Wir werden dies in Alpha 3.9.1 für eine Vielzahl von Schiffen einführen, weitere werden folgen. Die Skins sind in der Tat austauschbar, d.h. wenn sie einmal angebracht sind, werden sie nicht dauerhaft auf dem Schiff befestigt, und Sie werden immer noch die Möglichkeit haben, Skins zu entfernen oder auszutauschen. Für die Flottenwoche finden Sie eine Vielzahl von Skins im Pfandlager, und wir freuen uns, Ihnen mitteilen zu können, dass Sie diese Skins in einem kommenden Patch auch im Spiel für aUEC kaufen können. Mit der Zeit werden wir weiterhin neue Skins auf den Markt bringen, und es ist erwähnenswert, dass wir für die Zukunft eine Reihe exklusiver Skins planen, die nur im Spiel für aUEC erhältlich sind. Das ist wichtig für uns, weil es den Piloten da draußen, die ihren Lebensunterhalt unter den Stars verdienen, die Möglichkeit gibt, ihre hart verdiente Arbeit zu zeigen. Was die Preisgestaltung anbelangt, so werden die Häute, die außerhalb des Spiels mit echtem Geld verpfändet werden können, auf einem Prozentsatz der Schiffsrumpfkosten basieren, aber einem Plateau unterliegen, um zu verhindern, dass große Schiffe überteuerte Häute haben. Mit Blick auf die Zukunft werden wir mit dem schrittweisen Prozess der Migration älterer Farben auf dieses neue System beginnen, so dass zum Beispiel bereits veröffentlichte Häute wie die verschiedenen Aurora-Häute bald austauschbar und für Aurora-Besitzer nutzbar sein werden. Es ist auch erwähnenswert, dass einige Skins, wie z.B. der Valkyrie Liberator von CitizenCon 2948, nicht zur Verfügung gestellt werden, da diese als begrenzte und exklusive Skins gedacht waren. Wenn Sie diese derzeit besitzen, vertreten Sie sie mit Stolz! Wir freuen uns darauf, bald mehr Informationen zu teilen! Bis dahin sehen wir uns in der 'Verse! Übersetzt mit www.DeepL.com/Translator (kostenlose Version) Quelle: https://robertsspaceindustries.com/comm-link/transmission/17610-Paints-And-You

Vielleicht sollte man auch einfach nicht immer versuchen jeden Pixel von CIG zu deuten. Gerade immer im Hinblick auf einen "geheimen" Sale.

Diary of Zero Sense. Log #75 - Quantanium Mining. Im Stanton System brach ein Quantanium Goldrausch aus. Ich machte mich auch auf die Suche. https://star-citizen-diary.blogspot.com/2020/05/log-75-quantanium-mining.html

Also ich denke ja, wer die F8 für seine hohen Spenden geschenkt bekommen hat, hat genug Grund zur Freude. Warum muss man sich da noch ein Exklusivrecht wünschen? Ein solches Schiff wird sicher nicht nur für diese Backer entwickelt. Auch ich meine, gelesen zu haben, dass Normalsterbliche erst in den Genuss des Schiffes kommen sollen, wenn sie in SQ42 einen bestimmten Punkt erreicht haben. Bei einem Sale wäre es sinnvoll, die Abgrenzung zu diesen Aussagen erläutert zu bekommen, um auch alle Neider mitzunehmen. Ich persönlich mag die F7C-M Super Hornet sehr, die Saber fand ich aber immer etwas schnittiger. Die F8 Lightning wäre ein schöner Kompromiss. Aber bevor ich noch keine offizielle Aussage dazu gelesene habe, schnappe ich mir einen Spekulatius und mein Popcorn und lausche, was hier im Thread noch so passiert

Hallo zusammen, ich wünsche Euch ein entspannten Start in die Woche... und bleibt gesund. Ich habe ein neues YouTube Video hochgeladen, zum Thema Land erwerben... Es ist im neuen Schnitt Format erstellt worden, und von 3 Stunden Live Sendung auf unter 10 Minuten zurecht geschnitten um die Informationen kompakt zu halten. Heute Abend bin ich ab 19 Uhr Live auf Twitch und Beantworte gerne Eure Fragen, ich freu mich sehr wenn Ihr auf ein Kaffee in meiner Live Sendung vorbei schaut. würde mich über ein kurzes Feedback sehr freuen, zu den neuen YouTube Format... was zusammen geschnitten wurde aus der Live Sendung, im freestyle Format... Liebe Grüße Fhexy Star Citizen | Land erwerben | Außenposten errichten | auf Monden Planten Asteroide