Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by StarManta

  1. This is one I'd also love to see discussed! If it's been in development as long as I suspect it has, though, I doubt it - ECS only came out less than a year ago. That said, as long as they're not needing to be concerned with backwards compatibility, it might not be too big a job to change parts of it (e.g. all the ship parts) to use ECS and take advantage of that performance bump. That would be exciting!
  2. No, they're making a clean break. If they supported backwards compatibility they wouldn't be able to do half the new stuff they're planning.
  3. The announcement post mentions a pair of binary planets, so there's SOME level of upgrades from the current system. I'd be surprised if it was true N-body, but I'm not gonna rule out being surprised.
  4. I have a feature to add to this: Undo. If you have dragged it too far in one direction, or dragged it until you realized it was the wrong direction to drag it, you can undo.
  5. I disagree. If this function is available on every part, it doesn't even need a "label and button" like standard actions - it could be just a tiny button with a little eyeball icon in the corner of the context menu. (Since it's a non-destructive action it doesn't need to be labeled - it's safe for users to discover it by trial and error) In fact, I would say that limiting it to certain parts would dramatically reduce clarity, in addition to utility. The probe cores and cockpits already have a lot of options, and another "text and button" option would simply get lost in the list.
  6. The problem is that forces can still translate and feed-back through the docking ports, and that's what prevent them from being on different cores. For example, imagine you have a big space station, and a tiny capsule, connected to the station by a docking port. Now, take another ship, and ram the tiny capsule. The physics engine must not only calculate how hard the capsule pushes back against your ramming ship, it has to calculate how hard the entire station pushes back. The mass of the station, not to mention how it's configured, all factor into the "pushing back" factor - if said docki
  7. Maybe you get upgrades to the Tracking Station not by just spending money on them, but by getting X number of GPS satellites in orbit?
  8. I'd like to see the bug report on that one. Expected behavior: house remains intact. Observed behavior: house is on fire. Priority: Medium
  9. Well, it would be if you could see the number without having to keep your mouse over the thing. (This seems to be one of the interface quirks that's getting retooled for 1.1, FWIW) MAYBE if you have an extremely high-ranked Pilot (like 4-5 stars), AND have docked before a certain number of times. But having an auto-docker that newbies can use instead of learning how to dock would remove one of the most satisfying challenges from the game. (Go check out the KSP subreddit sometime, and see how many of the posts are "This isn't much, but I just docked two things and I'm SO PROUD". A widel
  10. I would probably put up BitTorrent links.
  11. Rockets? I got nothing. But KSP is far more than just rockets: Solar panels. The foil on the LEM. The skin of the Command Module, as posted earlier in the thread. Spacesuit helmets. Windows on every module and capsule.
  12. Right now, KSP is still using the older shaders/materials, and probably will for a while. Unity 5 introduces new Physically Based Rendering materials, which have "shininess" builtin - you could literally write a slider to make a part more matte-finished and less shiny, and vice versa. With reflection probes*, these would properly reflect the world around them, at least in terms of planets and the cosmos. (self-reflection is still a pipe dream for realtime graphics) Even better, even matte-finish parts would benefit - they would reflect Jool's green or Duna's red without the need for a PlanetSh
  13. #3 and #4: Wheels have been overhauled for the upcoming 1.1 - wait for that, then revisit. That said, jwbrase is correct, and "broken wheel" can cause some serious trouble if it happens while moving. There's a reason that IRL autonomous rovers on other worlds max out at around 0.1 mph. Exploration in KSP is largely about the challenge of getting there and back, and aside from the little ones, every planet is wildly different on that front.
  14. I am assuming most of the people in this thread have never seen the Delta IV Heavy.
  15. I think a visual marker in the main camera view makes a lot more sense than anything you could possibly put on the navball.
  16. I think the thought process was: 1) "Mission control" is a cool word associated with realistic space travel, and we should have a building called that. 2) We need a place so someone can accept contracts 3) Missions and contracts are kind of the same thing
  17. A few features you would do in Mission Control if I were the one designing it: 1) Plan your mission - (whether a new launch or a new mission for an existing craft) Most of this would be setting up a bunch of maneuver nodes; the main difference between this and doing it in the flight is that this would not require the craft to already be built and launched (so you can build one with the right amount of ΔV). This would require some improvements to the maneuver node system, most notably the ability to make a maneuver node from being landed. Using this, you would be able to approximate the am
  18. While this is wise and true - doesn't Besieged do pretty much exactly what KSP does in terms of its heavy processing? Large groups of rigidbodies and colliders (mostly primitives), attached by joints? Pretty much all KSP adds to the formula is patched conics and the rails physics, but that's hardly a performance hog. Personally, I'd been fairly reserved about the performance improvements to be expected until now, for all the reasons you enumerate - but if Besieged can improve by a factor of 10x in optimal situations and 4x in normal ones (based on their 'advertised' performance increase),
  19. This just gave me an interesting thought. If the "single-ship = single-thread" principle is true, then I could have a game crawling at 5fps when I have a giant space station... and then jump to 40fps when I smash into that space station and break it into a dozen pieces. Players might start to get concerned if there is a sudden framerate increase.
  20. Reading the dev notes, they have mentioned fixing a LOT of the long-standing bugs that we've just learned to live with. For example, yesterday's devnotes mentioned the one where moving symmetrical objects in the VAB would break their shortcut key configurations, and some bugs with craft that are splashed down - and there have been similar updates in the devnotes for months on end now, indicating that they are putting serious effort into killing these long-standing issues. The update to Unity 5 and 64-bit should singlehandedly resolve memory crashes on modern machines, which are far and away th
  21. The old GUI functions had the font sizes all but hard-coded into them. In order to have text at a larger size, every UI element would have to be written with that size in mind. It's virtually impossible to support multiple pixel densities well with that system. (side note: The Unity IDE itself is built on that older GUI system, and the IDE still doesn't have proper retina display support. Unity has copped to that being one of their bigger regrets in designing that system - they're had to spend a LOT of developer time working around it.) The UnityUI system that KSP 1.1 is using has a
  22. Start thinking of (and suggesting) the prerequisites that would be needed for such a thing to be viable. Most significantly: IVA Improvements out the wazoo. KSP's IVA is nowhere near ready to be an exclusive gameplay mode. Yes, some Youtubers have done it, and we're so in awe of them precisely because KSP makes it so hard. (and every single one of those videos was done on a tried and true spacecraft and very simple, straightforward flight plan - never one they're trying for the first time in that view, and never anything harder than landing on the Mun) - Most or all of the IVA views simpl
  23. The color of a vessel's orbit could be changed in the same menu where its name and icon get changed, and as mentioned, this menu ought to be available from more places.
  24. I've mentioned a concept like this on several other threads - this is a really good concept. As mattinoz said, logarithmic time scale would be better than linear (or both an a toggle switch). It should also show things like predicted time to hit surface, time to enter atmosphere, etc - all important events like that for all vessels (so we don't have a ship that gets pulled from orbit by Tylo while we're paying attention to Duna). I've been curious about getting into KSP mod development, but I'm reluctant to start a solo effort - if anyone's keen on making this a mod and wants some help on
  • Create New...