Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Monger

  1. I have a very special wish: shorter loading times. Please use the new foundation for proper streaming technologies. This sounds silly, but the long initial loading time and the time needed when switching scenes really nag on me in KSP. I would play the game four times as often, if jumping into the game and exiting it again would work more fluently.
  2. Thank you!! I really hoped that Take2 stepping in and buying Squad would mean they are planning a sequel. Really sounds promising.
  3. Yay! Thanks for all the work! But I second that: at least a link to the full changelog would have been nice, because I'd really like to know where all the subtle changes happened. But then again, I can find them myself by trying out, so... just updating Steam
  4. KerbNet is amazing! So excited when I can finally try it out (which will probably be when my child grows up, so... oh, well...). This makes a satellite network really, really useful. Will this work for airplanes, too? So, could I build a reconaissance drone which scans the ground for biomes, and marks them for future missions?
  5. SRBs are really cheap, so especially during early career mode they are a great choice. If tweaked correctly, they can also serve as second stage, and as very cheap platform for Mini-Satellites.
  6. Yes, we tend to forget how hard KSP is. Actually, how hard the reality of space flight is. Traveling into space is still extremely dangerous - despite the members of NASA and ESA being extremely well trained. There are physical limits to what a vehicle can withstand, and earths upper atmosphere is especially unforgiving. Space travel would be SO much easier if we lived on another planet, like Mars for example.
  7. Well, except that index errors are easily the no.1 source of bugs in any language that doesn't support enumerators natively... First of all, List<T> is heavily optimized for index searches, so accessing an index is cheap. Like all optimizations, this comes with a price. List<T> allocates quite a lot of memory, especially for big collections. Indexed search has a cost of O(1) for List<t>, so iterating over a full list has O(n). But List<T> doesn't handle well insertion or removal operations. There are collection types that can be iterated, but are not naturally indexed. For example, an ordered List is usually not indexed, but it is very fast when inserting elements. If you try to iterate such a list (e.g. via the Extension method ElementAt(int)), you end up with O(n²). Second, the enumerator may have knowledge of the data source that you don't have in client code, and optimize accesses. For example, if you have a remote data source like a data base, fetching single items one after another may be very expensive. But an enumerator can optimize depending on the data source. E.g. , table.where(x => x.Name == "Monger") may decide instead of fetching all data base items, iterating over them and returning a filtered view, to ask the database directly for a filtered result by creating a proper SQL query. LinqToSQL makes heavy use of that. If you work against interfaces (like you should), you are usually not aware of the collection implementation. In some cases, accessing via index is slightly more efficient than via enumerator. In some cases, accessing via index is really, really bad. tl;dr: Don't assume that all collections work like List<T>.
  8. This sounds unhealthy. Have you considered overriding the Enumerator (which seems to create this mess) with a bug-free implementation? I can understand why you may want to avoid LINQ expressions, late evaluation can easily blow up in your face. But for-each loops are usually much, much safer and sometimes even faster than regular for loops. Rewriting half your code base because of one bug sounds not very reasonable.
  9. I am a little shocked. Not because you are leaving KSP (after more than 5 years, this kind of expected), but because you didn't mention at all what you are doing next. Where are you going? What are you planning? Surely, you already know where you are going to. I really hope you are going in peace with the rest of the team and the project, because as I understood, things got a little tense in the last year. I still admire your vision for KSP, and the work you put into this dream. I really hope that you are able to dream again in a similar way for another project, but with the experience you have now. Please let us know what you will be working on, so we can follow the next project as closely as this one :-)
  10. I will not request another feature here, because my guess is, your backlog is already quite filled for the next few years. No, what I want is: for Squad to be successful, to still exist in a few years, to support KSP for a few years, and hopefully create another successful game. But as it is now, I fear it will not turn out that way. Quality issues are probably the No. 1 cause of death for software companies, including some famous gaming companies (e.g. Maxis). Of course it is extremely difficult to judge this from the outside, but I think I see several indicators that the development process slowly got out of hand: steadily increasing maintenance effort (growing QA, beta phases become longer and longer, most developers are primarily occupied with fixing bugs) steadily longer increment phases (apparently harder and harder to make changes to the game) Regular major breaks (i.e. long phases necessary to stabilize a product that was stable before) Regular big and time consuming refactorings (switching to Unity, multiple big overhauls of core game mechanics) semi-reliable builds (multiple developer complaints about slow and brittle builds) This all hints to rising technical debt, which makes developing and maintaining more and more frustrating, and at some point too expensive. So, what to do? Please find some help. Someone who really understands quality in agile development. Don't be one of these companies that keep telling themselves that everything is gonna be alright if you just keep working a little harder through the weekends. Because it won't.
  11. So what do we learn from that? Do NOT let branches drift apart for 6 months! This is insane. Thousands of file changes, hitting the code base at a single moment within a single commit. There is no way to track down single changes beyond this point, making the history of your source control basically useless. This will probably drag down the code quality for months. We'll see how it turns out, but if I guess right, this makes a christmas release of 1.1 basically impossible.
  12. Dann ist wahrscheinlich dein Schiff zu schwer und zu komplex. Ãœbe docken erstmal mit leichten und einfachen Schiffen.
  13. Well, trying new things is always good, but i have to agree: reading the devnotes is not just about information, it is partially personal. And I don't want to be told by proxy. If you have trouble to gain all the info from all developers all the time, then, well, only pick those that wish to say something. If you are unsure what kind of devnotes we would like, then ask us (e.g. by polling).
  14. "Perfection is not achieved if there is nothing left to add, but if there is nothing left to take away" (Antoine de St. Exupéry) Game development, like any software development, cannot be hurried just by throwing more money at it. Also, adding big features this late into the project is almost guaranteed to be a bad idea. SQUAD may take my money via crowd funding once they start their next game, especially if it should be KSP 2.
  15. 100km is not THAT high considering the size and sphere of influence of earth. Travel 10% of the distance to the moon, let yourself fall back to earth, and then we'll talk about heat shielding again.
  16. I hate the loading times. I would play KSP a lot more, if initial loading time were shorter, and jumping from one building or scene to another would not feel that non-fluent. What I really love about small games is that I can jump in and out of them in a hurry, so I can easily do that between coming home from work and having dinner. With KSP, this is not as easily possible.
  17. I think it still needs a lot of tweaks, but the game became increasingly complex with the last few patches. Getting to orbit is not easy, and getting back again neither. Designing a mission that can reliably return from other solar bodies became a lot more interesting. Grinding still feels terrible, but I think KSP is progressing nicely.
  18. The biggest beef I have with them is: why don't they turn up in the game? Maybe as small unlockable upgrading the buildings (or similar). This way, they are fully decoupled from the game, which is a pity. But altogether, I like them.
  19. I think there are many good reasons, but I'll give three: - I believe that Antoine de St. Exupéry was right: "Perfection is not achieved if there is nothing left to add, but if there is nothing left to take away". Just adding more doesn't make KSP a better game. - I trust Felipes vision. If he thinks that this is how KSP should be experienced, and this is the essence of the game, then I believe him. And so far I had no reason to doubt him. - I am interested in the game design. Every time I encounter something new, I wonder: "what did the designer have in mind? What does he expect me to do?". I am interested in the way SQUAD works, and I am not able to learn that if the game has been altered by someone else.
  20. To be fair: even though they list these points as minus, they have little impact to the final score. 87% is an excellent score. Usually, only a few games reach or surpass 90% each year in Gamestar. GTA 5 for example scores 92%. I don't think Gamestar has ever given a score in their history which was above 95% (unlike many other magazines).
  21. Gamestar is a german computer game magazine, and as it seems the biggest one in Europe (see here). So, Gamestar finally reviewed KSP here, and gave it 87%. Because I guess only a very small fraction of all forum members here can read this ^^, I'll translate the conclusion as best as I can:
  22. Pods can take quite a punch. For early non-orbital and low orbit missions you don't need it. Ironically, you don't need it either if you take a quite steep reentry, because more dangerous than the friction is the long exposure to it, i.e. the pod is unable to cool down efficiently. However, you will get other problems with a a fast descent (i.e. being unable to break fast enough)
  • Create New...