Planetery Lander will mich wohl veräppeln :(

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

    • Planetery Lander will mich wohl veräppeln :(

      Hallo!

      Da ich momentan auf meine alte Base keine Lust habe, wollte ich ein neues Spiel starten. Auf dem selben Planeten. Ich bin dann halt im Lander gespawnt und direkt nach dem Einstieg hörte ich schon "Shipfuel low". Ich schaffe es nicht in dieser einen Minute das Teil zu landen. weil ich sehr schnell kein Treibstoff mehr habe.

      Ich weiß als ich bei meinem alten Save angefangen habe ich mit dem Lander noch min 10 Minuten herum geflogen bin, bis ich die Stelle zum bauen gefunden habe. Haben die das etwa geändert?


      Hüte dich vor der Gattung NPC.
      Er wird seinen Bruder morden,
      nur um in deinem Questlog stehen zu dürfen.
    • das ist leider nur einer von vielen fehlern die es momentan gibt aber es ist nicht immer so wir haben vor kurzen auch eine neu welt angefangen und bei mir war auch zu wenig treibstoff drin habe damit ne bruchlandung hinbekommen aber meine beiden mitspieler haben es ohne probleme und mit reichlich treibstoff geschafft zu mir zu kommen mit ihren planetery llandern
    • Eine Lösung ist es, die erste(n) Minute(n) C zu drücken, dann werden die beiden Hauptstromfresser deaktiviert, oder den Trägheitsdämpfer mit dem selben Resultat erst mal auszustellen, bis man jeweils recht nahe am Boden ist. Dann hat man noch genügend Treibstoff um sich ein klein wenig nach einem geeigneten Landeplatz um zu sehen und eine sichere Landung hin zu bekommen.

      Ich glaube, das Problem hängt mit generellen Schwierigkeiten mit den Batterien zusammen, wo von 3 Stück gut gefüllt an Board sind, die aber anscheinend nicht genutzt werden.
    • @kane87hl Sowas geht doch nicht, oder!? Manchmal glaube ich, das Keen seine Updates nicht vor der Stable Veröffentlichung nicht überprüft ob die Inhalte, die funktionieren, durch nen Patch nicht mehr funktionieren. Ich mein es ging ja vorher.

      @SarahAndrea Royce Danke für den Tipp! Aber wenn man eine kontrollierte Landung wählt, dann sollte man auch genügen Zeit haben, um den perfekten Landeort finden zu können. Trotzdem werde ich es mal so versuchen.


      Hüte dich vor der Gattung NPC.
      Er wird seinen Bruder morden,
      nur um in deinem Questlog stehen zu dürfen.
    • Valdis schrieb:

      @kane87hl Sowas geht doch nicht, oder!? Manchmal glaube ich, das Keen seine Updates nicht vor der Stable Veröffentlichung nicht überprüft ob die Inhalte, die funktionieren, durch nen Patch nicht mehr funktionieren. Ich mein es ging ja vorher.

      @SarahAndrea Royce Danke für den Tipp! Aber wenn man eine kontrollierte Landung wählt, dann sollte man auch genügen Zeit haben, um den perfekten Landeort finden zu können. Trotzdem werde ich es mal so versuchen.
      ich glaube kaum das die leute so viel zeit haben jeden teil des spiels zu testen ob alles so läuft wie es soll wenn es so wäre gäbe es viel weniger fehler im spiel.
      ich bin mir auch nicht sicher wie ernsthaft die entwickler noch am spiel arbeiten habe von mehreren leuten gehört das die entwicklung so gut wie aufgegeben wurde und die entwickler ihre meiste kraft in andere projekte stecken
    • kane87hl schrieb:

      ich bin mir auch nicht sicher wie ernsthaft die entwickler noch am spiel arbeiten habe von mehreren leuten gehört das die entwicklung so gut wie aufgegeben wurde und die entwickler ihre meiste kraft in andere projekte stecken
      Meines Wissens nach suchen die immer noch Mitarbeiter - und wenn man ein bisschen die angekündigten Arbeiten verfolgt, dürfte in ein bis zwei Monaten nochmal ein großes Update kommen, dass eine weitere Überarbeitung des Netcodes und der Physik-Engine enthält.

      Nur weil vordergründig nichts zu sehen ist, heißt das noch lange nicht, dass nichts gearbeitet wird.


      PS: Von wem hast du gehört, dass Keen "aufgegeben" hat?
      "Tanker anvisiert, Lastwagen versenkt."
      Aus dem Logbuch der USS Seetiger,
      dem rosaroten U-Boot

      Quelle: "Unternehmen Petticoat", Film
    • Ach ja, seit drei Jahren immer die selbe Leier. "Die entwickeln nicht mehr!", "Die sind zu faul zum Testen!", "Die machen alles andere als das Spiel!" ... Da habe ich schon einiges gehört, das meiste völliger Blödsinn, denn entgegen aller Theorien kommt immer noch wöchentlich ein Update und daran hat sich seit Jahren nichts geändert. Aber klar, wenn mehrere Leute etwas ohne jegliche Fakten behaupten, muss es ja wahr sein. Dass seit Jahren wöchentliche Updates veröffentlicht werden, ist ja nebensächlich. Macht man ja so, wenn man keine Lust mehr hat.

      Ich möchte an dieser Stelle nochmal darauf hinweisen, dass das Spiel nicht fertig ist. Die Stable Version ist auch nicht fertig und voller Bugs. Es sollen bloß keine Bugs enthalten sein, die das Spiel wirklich unspielbar machen. Das Spiel soll laut Steam in einem "very playable state" sein. Ein "ziemlich spielbarer Zustand" ist das schon, wenn man den Lander nicht bequem auf die Erde bekommt, aber irgendwie eben schon. Es ist ein kleiner Teil eines Spiels mit unglaublich komplexen Möglichkeiten. Die alle zu testen ist mitunter unmöglich. Jede denkbare Kombination von Blöcken? Alle möglichen Eintrittswinkel über jeder möglichen Erhebung eines Planeten testen? Ich will keines Weges sagen, dass man nicht testen sollte, aber jeder, der mal programmiert hat, weiß, dass man nicht alles überblicken kann, wenn man mal eine Änderung macht. Etwaige Konsequenzen sind nicht immer glasklar gegeben und werden einem auch nicht magischerweise aufgeführt, also kann sowas schon mal passieren. Als QA Mitarbeiter schaut man sich ja auch nicht unbedingt die ganzen Änderungen im Sourcecode an und spekuliert dann wo sich was geändert haben könnte, was jetzt fehlerhaft klingt. Nein, man bekommt eher eine Liste von Änderungen und testet dann das und ähnliche Dinge oder schreibt sich entsprechende Tests (was in SE vermutlich schwierig ist). Du kannst einfach nicht jedes einzelne Feature, das jemals implementiert worden ist jede Woche aufs neue testen. Das ist weder möglich noch wirtschaftlich.

      Nur damit das klar ist: Ich habe auch Kritik an Keen und bin kein Fanboy, der ständig sagt "alles was die machen ist voll geil, yo", aber die meiste Kritik, die Keen entgegen gebracht wird, basiert auf Halb- oder Unwissen und ist nicht gerechtfertigt. Die meisten Leute regen sich nämlich einfach nur auf, wie @Valdis (was ich an der Stelle auch nicht unbedingt für unberechtigt halte), stellen dann eine Kritik in den Raum, die vermutlich auch gar nicht böse gemeint ist und nach Durchstöbern der Fakten bestimmt verworfen werden würde, aber andere nehmen das dann für bare Münze und verbreiten es. Das schadet der Community und dem Spiel, was ich wiederum schade finde, denn ich denke, dass das Spiel selbst mit Bugs viel Spaß macht und noch großes Potential birgt.
    • Wenn man mal richtig gefrustet ist empfehle ich das Spiel einfach für eine geraume Zeit links liegen zu lassen.
      Hatte vor etwa 'nen Jahr auch meinen Frust auf "Keen" und erst mit der Beta wieder reingeschaut.

      Nach so einem Zeitraum fällt erst auf, wie weit sich Space Engineers inzwischen doch entwickelt hat.

      Man kann ja allerlei behaupten - dass sich die Entwickler gar zuücklehnen und nur 'ne ruhige Kugel schieben aber nich' ...

      blub9529 schrieb:

      Monaten nochmal ein großes Update kommen, dass eine weitere Überarbeitung des Netcodes und der Physik-Engine enthält.
      Ich harre der Dinge, die da noch kommen mögen... :D
    • @Spcemarine

      1. Hab ich nicht gesagt, dass die zu faul zum testen sind.

      2. Ich weiß auch, dass es noch nicht fertig ist.

      3. Kann jeder Entwickler sich viel Zeit und Geld sparen, indem sie Bugs von vorne rein "bekämpfen". Und wenn ein neuer Inhalt in einem funktionierenden System einen Bug erzeugt, was vorher gut funktionierte, dann sollte man doch erst den neuen Inhalt veröffentlichen, wenn er mit dem Spiel funktioniert.

      Ein Autohersteller kann ja auch kein "fast fertiges" Auto auf den Markt bringen. Wenn der Motor nicht funktioniert, nur weil sie Holzdübel anstatt Schrauben verbaut haben, dann muss man das vorher testen, ob die Holzdübel auch eine gute Idee war. Ist zwar ein lustiger Vergleich, aber im Endeffekt ist es doch das gleiche.


      Hüte dich vor der Gattung NPC.
      Er wird seinen Bruder morden,
      nur um in deinem Questlog stehen zu dürfen.
    • Valdis schrieb:

      1. Hab ich nicht gesagt, dass die zu faul zum testen sind.
      Missverständnis! Ich wollte dir das keineswegs unterstellen, aber ich hab es eben schon gehört und es passte gut zur Thematik. ^^

      Und nun zum Rest: Darf ich fragen welche Erfahrung du bereits in der Softwareentwicklung gesammelt hast, worauf hin du behaupten kannst, dass man Zeit und Geld sparen kann, indem man Bugs frühzeitig ausmerzt? Meines Wissens nach verfahren die meisten Entwickler eher nach einem System, in welchem erst möglichst viel implementiert wird und nur auf grobe Bugs geachtet wird, um dann danach in einer QA-Phase die Fehler zu beseitigen. Der Punkt bei SE ist allerdings, dass der Entwickler versucht möglichst offen für Vorschläge aus der Community zu sein. Damit muss u.U. die gesamte Software "umkonzipiert" werden.

      Ein Beispiel dafür ist der MP. Das Spiel war nie als MP-Titel geplant, aber die Community wollte ihn unbedingt und so wurde ein eher schlecht als rechter Multiplayer implementiert. Mit dem Fortschreiten der Entwicklung und dem immer komplexer werdenden Spiel reichte der ursprüngliche MP bald nicht mal mehr als Übergang aus, wodurch im vergangenen Jahr intensiv daran gearbeitet wurde. Nun ist die ursprüngliche MP-Version vermutlich zum größten Teil komplett durch neuen Code ersetzt. Also hier die Frage: Hätte man sich damals in 2015 nun Zeit und Geld gespart, wenn man den MP gleich "richtig" implementiert hätte? Ja, wahrscheinlich schon. Aber waren die Anforderungen daran damals klar? Nein, vermutlich nicht.

      Und genau das ist der Punkt. ( . <-- dieser Punkt! :D Nicht witzig? Okay v.v) Selbst wenn man seine Features, die man implementieren will, schon zu 100% kennt, ist es nicht einfach ein Modell zu erstellen, das am Ende einwandfrei funktioniert und das während der Implementierung zugunsten von Performance oder ähnlichem nicht mehr angepasst werden muss. Somit sehe ich es als ganz und gar nicht offensichtlich an, wenn du behauptest, dass jeder Entwickler sich viel Zeit und Geld sparen kann, wenn er Bugs in frühen Phasen der Entwicklung behebt. Ich lasse mich von erfahrenen Softwareentwicklern, die schon an Projekten einer solchen Größenordnung mitgearbeitet haben, jedoch gerne vom Gegenteil überzeugen.

      Der Vergleich hinkt an der Stelle, die du bei 2. selbst zugegeben hast. Das ist mehr als hättest du ein Auto vorbestellt, welches geliefert wird, sobald es ganz fertig ist und du jederzeit beim Hersteller mit einem Prototyp probefahren kannst. Wenn du das machst, fliegt dir dann halt mal der Motor um die Ohren, weil die Dübel zu Asche verbrannt sind. :D
    • Naja, der Vergleich hinkt schon deshalb, weil ein Auto ein physisches Objekt ist, während eine Software ein virtuelles Objekt ist. Ein Auto fährt, oder es fährt nicht. Bei einer Software gibt es da einige tausend Zwischenstufen.
      Ich bin zwar kein Programmierer, aber in meiner Ausbildung zum IT-Systemkaufmann hatten wir auch Programmierung, und selbst bei den doch eher einfach gestrickten Sachen, die wir gemacht haben, war es teilweise schon echt schwierig, im Nachhinein auftretende Fehler aufzuspüren und zu korrigieren. Und oft ist es so, das eine kleine Änderung an Stelle A einen ganzen Rattenschwanz an anderen nötigen Änderungen nach sich zieht. Und da rede ich nicht von Syntax-Fehlern, die haut Dir die Programmierumgebung schon um die Ohren.
      Hier geht es eher um Fehler im Gedankenkonzept. Auch wenn man sich vorher ein Ablaufdiagramm erstellt, schützt dieses nicht vor logischen Fehlern oder einfachen Irrtümern. Und dann geht das ganze wieder von Vorne los... ^^
    • AAAABEEER! :D

      @Spcemarine
      Angenommen du hast 10 Leute, die das Spiel testen, Bugs aufspüren und diese vernichten. Vielleicht dieselben Leute, die zuvor an den neuen Inhalten gearbeitet haben. Vielleicht machen die dann deswegen noch Überstunden und die Kosten sind bestimmt für den Oberguru nicht grade billig. Dann ist doch die direkte Arbeit zum frühen erkennen von Fehlern zuvor am neuen Inhalt im Endeffekt billiger und spart Zeit. Oder etwa nicht?

      @Taurec
      Wäre es denn nicht besser den Code dann direkt richtig zu tippen oder Fehler schon früh zu erkennen? Sicher, das kann man bestimmt nur durch ausprobieren des, was weiß ich, Programms.

      @ All
      All das wird doch bestimmt schon in der Unstable getestet. Oder? Wenn es da schon nicht funktioniert und/oder Bugs auftauchen, dann kann es in der Stable auch nicht funktionieren.


      Hüte dich vor der Gattung NPC.
      Er wird seinen Bruder morden,
      nur um in deinem Questlog stehen zu dürfen.
    • Zum Thema Bugs finden und beheben: Es gibt Bugs, die treten nur unter bestimmten Umständen auf. Bestes Beispiel: Die Magische Himmelfahrt auf Planeten im MP. Tritt nur im MP auf, und selbst da ist der Bug nicht mal gezielt reproduzierbar. Ähnlich war es mit dem Landing Gear, man hatte zwar einen explosiven Fehler, aber wenig Ahnung zu Beginn, wo zum Henker der herkommt.
      Außerdem: Jemand, der an einem Programm arbeitet, wird es anders handhaben, als der Endnutzer. Während der Entwickler Fehler abfängt, die ein Nutzer vermutlich nie produzieren wird, übersieht er eine Möglichkeit, die durchaus entstehen wird. Manchmal wir zwar dann aus einem Bug ein Feature (z.B. Grav-Antrieb, Gleitschlitten, etc.), aber häufiger passiert dann Mist.

      Die Entwicklung von Software ist bei weitem komplexer, als man denkt! Ich mag mir gar nicht vorstellen, wieviel bei einer Änderung, z.B im Verhalten eines Blockes, tatsächlich geändert werden muss (Möglichkeiten: Datenübermittlungen zwischen Funktionen; Datenformate; Funktionen zum Auslesen der Datenformate; Referenzen; Funktionen, die die Kontinuität eines Spielstandes gewährleisten; etc. etc. pp.), damit das Spiel nicht den Status "Corrupted" einnimmt.


      Valdis schrieb:

      Wäre es denn nicht besser den Code dann direkt richtig zu tippen oder Fehler schon früh zu erkennen? Sicher, das kann man bestimmt nur durch ausprobieren des, was weiß ich, Programms.
      In der Theorie ganz gut... Aber nur weil es beim Entwickler sauber läuft, muss es nicht beim Kunden laufen :D . Keen nutzt aktiv die Community, um sein Produkt zu verbessern - das ist mehr wert, als man denkt!


      Valdis schrieb:

      All das wird doch bestimmt schon in der Unstable getestet. Oder? Wenn es da schon nicht funktioniert und/oder Bugs auftauchen, dann kann es in der Stable auch nicht funktionieren.
      In der Testversion wird häufig Fünfe grad gelassen, weil man nicht jeden kleinen Bug ausmerzen will - man dokumentiert, wo kommt der her, wie ensteht der, wie können wir den fixen. Das wird gesammelt, und dann in der nächsten Stable mit reingenommen. Dann stellt man fest, okay, bei ein, zwei Sachen haben wir Mist gebaut, dann kommt eben 2 Stunden später der Hotfix. Aber es wird definitiv NICHT jeder Bug sofort im Testbranch gefixt.


      Sorry für das viele Gekritzel da oben :P Da gehts um die Berufsehre (mache gerade Ausbildung zum Fachinformatiker Anwendungsentwicklung)
      "Tanker anvisiert, Lastwagen versenkt."
      Aus dem Logbuch der USS Seetiger,
      dem rosaroten U-Boot

      Quelle: "Unternehmen Petticoat", Film
    • Valdis schrieb:

      Ein Autohersteller kann ja auch kein "fast fertiges" Auto auf den Markt bringen.
      Richtig.

      Es gibt eben kein "Early Acess Auto" - bei dem der Motor halb fertig, das Getriebe und die Radaufhängung zig mal umgestrickt wird.
      (witziger Gedanke übrigens... ;) )

      In einem Software-Produkt aber schon, deswegen ist es im Endeffekt eben nicht das gleiche.

      Valdis schrieb:

      Wäre es denn nicht besser den Code dann direkt richtig zu tippen oder Fehler schon früh zu erkennen? Sicher, das kann man bestimmt nur durch ausprobieren des, was weiß ich, Programms.
      Da hast du schon recht. Wenn es nur so einfach wäre.

      Nimm mal an, man hat das ganze getestet, durchaus gewissenhaft.
      Dummerweise wurde aber irgendein dreckskleiner Bug übersehen.

      Der Code wird angepasst um dies zu beheben.
      Nun stellt sich beim testen raus, dass die Anpassung an zwei, drei anderen Stellen zu einem unerwünschten Verhalten führt.
      (Das müssen nicht unbedingt Bugs sein)
      Jetzt wird an besagten Stellen nochmals nachgebessert und getestet.

      Fehlverhalten weg - aber dafür ein sporadisch auftretender Fehler an anderer Stelle.
      Und der Rattenschwanz geht so weiter...

      Das ist von mir jetzt zwar etwas... fantasievoll dargestellt, aber wenn du meinst das wäre aus der Luft gegriffen,
      dann brauchst du nur mal selbst ein einfaches kleines Programm - meinetwegen sogar in BASIC - zu schreiben
      und dieses Programm nach eins, zwei Wünschen von jemand anderem anzupassen.

      Du wirst erstaunt sein, auf was man da alles so kommt.
      Da gibts Dinge, die gibts einfach net... :P

      Wie schon erwähnt war in SE der Multiplayer ursprünglich nie vorgesehen - ebenso wie die Planeten, etc.
      Diese Features wurden nachträglich eingebaut, um der Comunity einen Gefallen zu tun.
      Die Folge war (und ist) so ein Rattenschwanz an Bugs und Fehlverhalten,
      welche eben verdammt schwer zu handhaben sind.

      Andere Spiele wie zum Beispiel Empyrion haben den Vorteil,
      dass sie so wie sie sind von Anfang an in die Richtung geplant und konzipiert waren.
      Würde man dort nun auch damit beginnen ursprünglich ungeplante Features einzubauen,
      gehe ich jede Wette, dass ebenso mit Problemen gekämpft werden würde.

      Was die Komplexität angeht...
      Die Entwickler von Space Engineers sind wirklich dringend auf das Feedback der Comunity angewiesen.

      Sie können einfach nicht alle denkbaren Kombinationen ausprobieren.
      Stell dir nur mal vor, welche Konstrukte man alles so in SE bauen kann, da sind der Fantasie keine Grenzen gesetzt.
      Wie soll man das alles jemals austesten?

      Valdis, ich kann deinen Frust gut verstehen. (Verdammt gut sogar :D )
      Lass dich aber aus Frust nicht zu einem unfairen Urteil verleiten...

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von JumpinJack ()

    • Okay, zuerst war es nur eine Vermutung, jetzt bin ich mir ziemlich sicher: @Valdis du hast keinen blassen Schimmer vom Programmieren, oder? Du musst dringend von der Auffassung wegkommen, dass du Software annähernd bugfrei schreiben kannst oder es offensichtlich ist wo Bugs auftreten könnten. Wenn das so offensichtlich wäre, dass sich Bugs gleich zeigen würden, würdest du ja nicht den Fehler machen ihn zu implementieren. Klar gibt es einige offensichtliche Fehler, die jeder erfahrene Programmierer zu vermeiden versucht, aber das Programmieren stellt dich täglich vor andere Herausforderungen. Da lässt sich kein Schema F anwenden, um Bugs zu minimieren. Wieso wäre Software allgemein sonst so fehleranfällig?

      Da das also unmöglich ist, lass uns Alternativen suchen. Die Alternative dazu ist, jede einzelne kleine Änderung testen. Das ist zum einen ziemlich arbeitsintensiv und zum anderen könnte das Testen beim Verändern von sehr tiefliegenden Sachen, auf die viel aufbaut ein Haufen Tests anfallen. Darunter auch Randfälle, an die man nicht denkt. Und nochmal: Space Engineers ist extrem komplex. Du sollst im Grunde alles machen können. Das ist extrem viel. Geht also auch nicht, bzw. ist sehr teuer und langwierig. Dann veröffentlicht man als Entwickler vielleicht doch lieber ein Spiel mit ein paar Bugs, die zwar manchmal echt nervig sind. Allgemein ist das Spiel ja trotzdem spielbar.

      Und wegen der Sache mit der Arbeitsteilung: Du willst dem Programmierer eigentlich nicht die Zeit für gründliches Testen bezahlen. Das macht besser jemand, dem du weniger Geld zahlen kannst. Der Dokumentiert dann wie und warum ein Bug entsteht, gibt das wieder an den Programmierer und der behebt es dann. So Funktionier Quality Assurance in der Regel.

      (An dieser Stelle sei vermerkt, dass ich nicht ganz durchgestiegen bin, was du mir sagen wolltest @Valdis ... Ich hoffe, ich hab den Kern trotzdem getroffen.)
    • Ich weiß schon, was ihr mir alle zu sagen versucht. Aber ihr müsst schon zugeben, das ein Fehler im Programm schon bei der Programmierung bemerkt und behoben werden kann. Und wenn er früh behoben wurde, dann spart man sich doch später die Zeit, die man bräuchte um den Fehler in einer langen Kette von Zeichen zu finden.

      Beispiel: :D
      Damals zu meinen C64-Zeiten (ich glaub da war ich 15) habe ich und ein Kumpel ein Programm aus einem Heft abgetippt. Das waren Unmengen an Hex-Zeichen. Als ich damals mittendrin steckte, bei Zeile hundertschlagmichtot, sagte mein Kumpel: "Da hast du einen Fehler drin!". Hätte er den Fehler nicht gesehen, dann hätte ich hunderte von Zeilen nachschauen müssen, um die Ursache zu finden weswegen das Programm nicht geht. ich habe zwar dann kein Geld gespart ;) , aber Zeit. :D Zeit, die ich für andere Dinge einplanen konnte.

      Wäre ich damals volljährig gewesen, hätte damit Geld verdient und würde dann so einen Patzer verursachen, dann hätte der Chef Geld verloren. Weil dann das Programm zu einem späteren Zeitpunkt raus gekommen wäre. Also ist es doch im Endeffekt besser einen Fehler früh zu erkennen.

      Dann hat man ...

      ... mehr Zeit, um sich um andere Programme und/oder Inhalte zu kümmern.
      ... mehr Geld, um vielleicht noch ein paar Leute zusätzlich einzustellen.

      SO! Ein Spiel mit Bugs verursacht bei Spielern oft großen Unmut und Ärger. Diese werden dann an den Entwickler weitergegeben, welche dann beim "Chef" Zorn verursacht, den er an die Programmierer weitergibt und diese eventuell davon Bauchschmerzen bekommen.

      Ist ein Fehler früh erkannt worden, dann haben Spieler Spaß, der Chef ist froh und die Programmierer arbeiten, wegen der Fröhlichkeit von ihrem Chef, mit mehr Freude an dem Programm. Der Endeffekt ist die Ursache und die anschließende Wirkung.


      Hüte dich vor der Gattung NPC.
      Er wird seinen Bruder morden,
      nur um in deinem Questlog stehen zu dürfen.
    • Valdis schrieb:

      ein Fehler im Programm schon bei der Programmierung bemerkt und behoben werden kann
      Dann würde es ja aber keinen Fehler im Programm geben, wenn man Fehler bei der Programmierung bemerkt.
      Du kannst einfach nicht erwarten, dass ein Programm, wenn es hinreichend komplex ist, direkt bugfrei geschrieben wird. Das ist komplett unrealistisch. Und bei Bugs in Software von erfahrenen Entwicklern handelt es sich i.d.R auch nicht um Patzer wie Tippfehler o.ä. (sicher, wenn man 10 Stunden daran sitzt ein komplexes Problem zu lösen, ist jeder einmal unkonzentriert und vergisst eine Negation, einen Nullcheck oder ein Vorzeichen, aber sonst steht so etwas nicht an der Tagesordnung) sondern um kleine Fehler in extrem langen logischen Ketten von Anweisungen. Diese kleinen Fehler haben u.U. dann große Auswirkungen, weil viel darauf aufbaut. Es kann auch quasi keine Auswirkungen haben, weil es nur ein Randfall ist. Diese Fehler werden passieren. Daran lässt sich nichts ändern. Daran kann auch der Chef nichts ändern. Er kann auch niemanden einstellen, der auf Anhieb perfekten Code schreibt, denn solche Leute gibt es nicht. Jedenfalls ist mir niemand bekannt, der das kann. Wenn du ihn findest, sag es mir. :P
    • Valdis schrieb:

      @Taurec

      Wäre es denn nicht besser den Code dann direkt richtig zu tippen oder Fehler schon früh zu erkennen? Sicher, das kann man bestimmt nur durch ausprobieren des, was weiß ich, Programms.
      Von dem Gedanken kannst Du Dich gleich mal verabschieden. Bei erfahrenen Programmierern, die schon jahrelang Berufspraxis haben, kannst Du davon ausgehen, dass der CODE fehlerfrei ist. Denn, wie gesagt, einen Syntaxfehler haut Dir Deine Programmierumgebung sofort um die Ohren.
      Die Fehler liegen eher im gedanklichen Bereich, und da gibts keine Perfektion. Da sitzen ganz normale Menschen, und alle Menschen machen Fehler. Es gibt eine ganze Reihe von Fehlern, vor der Dich deine Programmierumgebung nicht schützen kann. Z.B.

      • Logische Fehler: Du hast einen Ablaufplan erstellt, nach dem das Modul, an dem Du gerade arbeitest, etwas tun soll. Hast aber einen Gedankenfehler drin. Da die Programmierumgebung nicht weiß, was Du erreichen willst, kann sie Dich davor auch nicht warnen. Zack ist der Fehler drin. Und jetzt stell Dir mal eine Software vor, wie ein Betriebssystem. Windows z.B.. Das besteht aus tausenden von Programmmodulen, die alle von anderen Personen geschrieben wurden. Da sitzt ja nicht nur einer, und programmiert, da sitzen hundert Leute. Der Eine programmiert Treiber, der nächste programmiert die GUI und wieder einer programmiert Interpreter usw. usf..
        Und Du hast jetzt einen logischen Fehler in dem Programm drin, der aber nur bei bestimmten Konstellationen auftritt. Weil der fehlerhafte Teil Deines Codes nur in Situation A von Modul 1.295 aufgerufen wird. Alle User, die das Modul 1.295 nicht installiert haben (Könnte ja ein Feature sein, dass nicht zwingend ist), ODER bei denen Situation A niemals auftritt, werden diesen Bug niemals bemerken. Und dann kommt der DAU, und provoziert Situation A mit Modul 1.295... Das passiert dann vielleicht nach 3 Jahren mal. Der Programmierer, der das mal geschrieben hat, ist vielleicht gar nicht mehr da. Aber selbst wenn, viel Spaß bei der Fehlersuche. ;)
      • Zigtausend unterschiedliche Hardwarekonfigurationen , Betriebssystemen und Treiberversionen. Es ist einfach unmöglich, eine Software zu programmieren, die mit ALLEN denkbaren Konfigurationen gleich gut klar kommt. Selbst wenn ein Hersteller sich auf z.B. Windows beschränkt, auch da gibts schon zig Versionen, die bedacht werden müssen. Ganz zu schweigen von etwaigen "Tuning"-Veränderungen, die ein User vielleicht an seinem Betriebssystem vorgenommen hat und vom Entwickler des OS gar nicht vorgesehen waren.
        Bestes Beispiel sind diverse Ratgeber, wie man z.B. Cortana deinstallieren kann oder den Windows Shop. So, und jetzt kommt Space Engineers mit einem neuen Feature: Sprachbefehle innerhalb des Spiels (Nur als beispiel). Die Programmierer von SE waren schlau: Warum ein eigenes Modul zur Spracherkennung programmieren, wenn doch Windows schon Cortana hat. Statt also ein eigenes Modul zu programmieren, setzen sie nur ein Verweis auf das entsprechende Modul von Cortana.
        Und jetzt kommt User XY, der sich so schlau vorkam, Cortana zu deinstallieren, der sich dann beschwert, dass SE beim Start abschmiert weil das Modul von Cortana nicht gefunden wird... Aber klar, die Programmierer sind schuld... *g*
      • Und dann eben die Schnittstellen zu anderen Modulen selbst. Person A programmiert Modul A und Person B programmiert Modul B. Und im fertigen Programm müssen diese Module miteinander arbeiten. Auch hier kann man zahlreiche Fehler machen, obwohl der Code an sich "fehlerfrei" ist. Und was passiert denn, wenn Modul A mal upgedated wird, und Modul B nicht? Und was sagen überhaupt Module C-Z dazu... Alles nicht so einfach.
      • Auch beliebt: Variablen vertauschen. Da suchst Du Dich dumm und dämlich...

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Taurec ()

    • Valdis schrieb:

      Aber ihr müsst schon zugeben, das ein Fehler im Programm schon bei der Programmierung bemerkt und behoben werden kann.

      Ein Fehler kann natürlich schon bei der Programmierung bemerkt und behoben werden.
      Jeder denkbare Fehler natürlich nicht.

      Valdis schrieb:

      Damals zu meinen C64-Zeiten (ich glaub da war ich 15) habe ich und ein Kumpel ein Programm aus einem Heft abgetippt. Das waren Unmengen an Hex-Zeichen.

      Sehr gut.

      Jetzt stell dir vor, du hättest diesen Code nicht abgetippt, sondern selbst ersonnen.
      Und dann müsstest du mittendrin ein paar Änderungen reinflicken und der Code soll
      dann immer noch einwandfrei (natürlich Bugfrei ^^) funktionieren.
      Dann das Ganze auch im entsprechenden Umfang, nicht nur diese paar KB an Codezeichen.

      Bin selbst kein Programmierer. Nur hobbymäßig hin und wieder...
      Als Jugendleiter im Verein (ist inzwischen auch schon an die zwanzig? Jahre her)
      habe ich ein Programm zur Auslosung von Wettkampf-Paarungen geschrieben,
      im Schweitzer System mit Buchholzwertung und allen drum und dran.

      Benutzte damals noch die QBASIC Compiler Version ^^

      Funktionierte nach dem Austesten sämtlicher Eingabemöglichkeiten auch soweit fehlerfrei.
      Tja, und dann kamen die Änderungswünsche.
      Oh welch Graus, ich entsinne mich nur ungern daran... :/
      Wenn ich den darauf folgenden Aufwand geahnt hätte,
      hätte ich mir das Austesten gespart und für später aufgehoben,
      nachdem alle Anpassungen reingeflickt worden sind. :whistling:

      Das dumme bei Programmen wie SE ist aber, dass es nie ein "nachdem" gibt.
      Es wird ständig angepasst und geändert.

      Deine Anforderung, den Code mit jeder Anpassung generell bugfrei zu halten
      ist somit nicht umsetzbar, es sei denn, die Entwickler hätten auf die Unmsetzung
      diverser Inhalte generell verzichtet und sich nur an das ursprüngliche Konzept gehalten.

      Dann wäre Space Engineers heute aber bereits Geschichte.


      P.S. Übrigens...

      Der Spruch, dass nur derjenige keine Fehler macht der nichts arbeitet
      gilt nicht nur in der Softwareentwicklung und dürfte vielleicht auch dir geläufig sein...

      Oje, ich sehe gerade, es hagelt nur so an Komentaren.
      Ich hoffe, du nimmst das nicht persönlich Valdis,
      und kannst dies als reinen Meinungsaustausch sehen... ;)
    • Ich würde mal vermuten Valdis, du verkennst komplett die schlichten Dimensionen und die Art und Weise wie objektorientiert programmiert wird. Das hat mit dem abtippen von Quelltext zu C64 Zeiten in keinster Weise zu vergleichen. Wir reden hier nicht von einem Script mit ein paar Hundert Zeilen. Auch nicht von ein Paar Scripten mit je ein Paar hundert Zeilen.

      Ändere ich in nur einer der 100 verschiedenen Basis Klassen eine Zeile, kann das direkt Auswirkungen auf die restlichen 99 haben, je nachdem welche Klassen noch darauf zugreifen.

      Jetzt nehmen wir mehrere Programmierer die zeitgleich an verschiedenen Klassen arbeiten, das ganze über Jahre, dazu Grafiker und Designer die mit ständig wechselnden Treibern, Netzwerkstrukturen und Betriebssystemen arbeiten, wechselnde Standards, neue Ideen und Implementierungen, Änderungen in funktionierenden Klassen aufgrund von Forderungen der Community und was weiß ich nicht alles.

      Ich arbeite in SE mit Scripts unterhalb von 2000 Zeilen bei einer maximalen Zeichenzahl von 100.000, ich arbeite seit bald 2 Jahren an dem Trading Script und
      muss immernoch Bugs beheben, auf veränderte API im Programmblock reagieren, Änderungen an den Blöcken durch Patch verursachen direkt Fehler in meinem, bisher funktionierenden, Script, etc.

      Ok, ich mach das nicht beruflich, aber auch in einer Dimension die mit einem vollständigen Spiel niemals auch nur im Ansatz vergleichbar ist. Schreibfehler sind da keine drin. Sonst würde der Code überhaupt nicht Compileren.