Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by HarvesteR

  1. Ah, I see you found the source. That post was the very first public announcement about KSP. Everything else sprouted from that (there was a post on Unity forums and on GameDev as well, but those didn't catch on). Heh, quite a blast from the past, certainly. And at a most auspicious time too, we're a few days away from the 2nd anniversary of that post. Cheers
  2. Hi again, So, here we go again. We are now starting work on the 0.21 update to KSP, so I'm writing this post to let everyone know what you can expect on the next big update to the game. Keep in mind that the following items are our proposed goals only, and as we all know, plans can and often do change. This means these are neither promises nor commitments, they're just the things we are going to be working on, as of this writing. As most of you already know, 0.21 is an important update for us, because it's the first proper update primarily focused on Career Mode, the least developed area of the game at the moment. Needless to say, we are all very excited about what's coming. So without further ado, here are our main goals for the next update: * Revised Flight-End scene flow. In preparation for Career gameplay, we are rethinking the way flights are ended. Gone is the 'End Flight' button in the Pause Menu, cause of many a tale of accidental space station deletion. Now, you'll either get to return to the Space Center (as before), or when applicable, Revert to an earlier state (to launch or to the editors). More information on this here. * Player Progress Tracking System Another step forward into Career Mode, this is an internal game system that will be used to track players as they progress towards advancing Kerbalkind to being a proper space-faring civilization. This is a core system, so don't expect much in terms of new content from this... It will pave the way towards some very cool new features down the road though. * Overhauled Space Center Scenery Time to go over the most underdeveloped part of the game. Gone will be the placeholder terrain, and in comes proper scenery for the space center. And because it's the same terrain as in flight, we don't need to reload it when going for a launch. This should cut down transition times from KSC to flight quite a lot. * The Astronaut Complex Facility Another huge feature in the making, the Astronaut Complex is a new building at the Space Center, that gives you an overview of all your available <s>victims</s> brave explorers, and lets you recruit new ones from a list of applicants. * Crew Management Along with the Astronaut Complex, this adds the ability to select the crew for a vessel before launch (from the launch sites or from the editors). Pick from the list of available crewmembers, and assign them to any (yes, any) part on the vessel. * Overhauled Space Center Facilities. We're also re-doing the VAB and SPH models, to bring them up to par with the facilites we already did on the previous updates. * More Upgrades to Parts and Part Modules. Continuing our work with moving all our parts to the new Modules system we implemented in 0.18, this update will feature yet more parts completely re-coded to the new system, allowing for many new possibilities from both stock and mod parts. These are our highlights for the update. Of course, there'll also be the usual batch of tweaks and bugfixes. Again, please do keep in mind none of these items imply a commitment from our part, and any or all could be delayed or modified at any time, as necessity demands. And as always, please refrain from asking about release dates. Stay tuned for more news and details about these and other topics on our dev blogs. Cheers
  3. Also, if you press space while holding shift, you'll jump off the ladder in the direction you're leaning towards, instead of just letting go. It's called a push-off, works best in very low gravity. Cheers
  4. Hello once more! Just to let everyone know, we've now released the 0.20.2 Patch for KSP. This patch is a quick hotfix, to deal with two critical issues that were left standing after the previous revision: Bug Fixes and Tweaks: Fixed the mouse wheel input issue on Linux. (should work like it did on 0.19) Fixed the excessive memory usage loading png and jpeg textures. Our thanks to Linux players Epinull and Mat Banks, who helped us figure out a way around the mousewheel bug. Mind that the mouse wheel problem is actually a bug in Unity, not in KSP. This means our solution for it is only a workaround, and isn't a 100% fix. There's still some weirdness around scrolling lists in dialogs, but that's minor in comparison to not being able to use it at all. For most critical cases, like zooming, scrolling the VAB view up and down, or scrolling the staging stack, the scroll wheel now works as intended. It should hold well enough until a fix from Unity comes along. As always, you can get the latest version from our KSPStore, or if you're on Steam, you should be updated automatically. Happy Launchings! Cheers
  5. Hi again! We don't believe every player should have to be a tester. On the other hand, if we had to keep the game at an ever perfectly stable state, we'd never make any progress. So, we're doing something here that'll hopefully allow us to move forward, without forcing everyone to endure the inevitable bug or thousand that comes with a game that's still under heavy continued development. Enter "Previous Releases". It is now possible to roll back your game to the previous version at any time you want. Here's how it works: * If you have the game on the KSPStore, you'll now find two sets of buttons to download the game. One for the latest release, and another for the previous version. Download and install whichever one you prefer. * If you have the game on Steam, you'll find a Beta branch on your Steam Game Settings for KSP, called 'previous'. Opting in to that branch will downgrade your install to the previous version. Changing back to the default branch will upgrade you back to the latest version. This way, if you find a new update has made something incompatible, or if it's too buggy for you and you want to wait for a more stable patch, you can opt to keep the old version a while longer. So, here's a few probable FAQs: Q: Are Previous Versions bug-free? A: Most likely not. Keep in mind KSP is still a work-in-progress, so even though these are more stable builds, it does not by any means guarantee a bug-free experience. Q: Can I load saves from the latest version on the previous one? A: Reverting back to a previous build will break forward-compatibility with saves from the later versions. (You can't load a save from 0.20 in 0.19, for instance). Supporting this would require time travel. If you've got a working implementation of time travel however, do let us know. Q: Will mods for the newer versions work on the previous one? A: Maybe. Most likely not. It depends on the type of mod (part packs are usually more resistant to change than plugin-based mods), but really, if a mod had to be updated to be compatible with the new version, it probably won't work anymore on the old one. BTW, If you didn't see it already, the 0.20.1 patch is out! Happy Launchings! Cheers
  6. Hi, I'm happy to announce that the 0.20.1 patch is now available! This patch fixes most of the issues encountered on the 0.20 release. Here's the changelog: Bug Fixes and Tweaks: Tweaked the logic for part-to-part collisions. Things should be much less likely to explode on contact. Reverted the Mun's height values, so landmarks and bases shouldn't spawn below ground anymore (mind 20.0 saves though). Tweaked part components on EVA so they start up with the right values. Tweaked the suspension on the new Medium Rover Wheels, to fix jittering. Fixed the too-low resolution on planetary diffuse and normal maps. Fixed the screen resolution not being properly applied on game start. Fixed some situations where the 'Control From Here' selection would be lost on resuming a game save. Fixed a serious issue with the Cupola Pod that could cause spontaneous unplanned vessel disassembly. Fixed an issue that caused internal spaces to spawn in duplicate sometimes. It was harmless but wasted resources. Fixed the scale of Gilly in the Tracking Station scene. Fixed a few issues with flags behaving weirdly after they were toppled down. Fixed the camera jitter when walking around on EVA. A note for Linux users: We're aware of the issue with the mouse wheel input. This seems to be a Unity bug however, introduced in the new 4.1 version (0.19 was built with an older version). We're in touch with Unity support on this matter, but unfortunately, there is nothing we can do on our end to fix this problem. We apologize for the inconvenience, and hope a fix will be released soon. More information here. You can find the new version as a full download on the KSPStore, or if you have the Steam version, you'll be updated automatically. Happy Launchings! Cheers
  7. In real life, the centrifugal force would probably throw everything out, and the planet would disintegrate... but that's a pretty boring answer. I tried this in KSP once, where such trivial matters aren't an issue, and sped up Kerbin's rotation to see the effects. Assuming the planet is able to hold in one piece (as Kerbin did), yes, the rotating frame forces would effectively work to cancel out gravity. Throwing a baseball eastwards would send it on a slightly higher orbit than your own (you'd be orbiting too), and throwing it westward would send it on an impact course. Of course, all that fun would only happen at the equator... As latitudes get higher, this effect becomes less pronounced, and at the pole you'd probably just get motion sickness from looking at the stars Cheers
  8. I saw the "two years" and wondered if it really had been that long.... The first pubic release of KSP was June 24th, 2011, so those screenshots can't be 2 years old yet. At most that's one and a half years. But regardless, it does show how far it's come. Back in those days, everything was a placeholder, there was no such thing as a proper space system simulation, and there were a LOT of unsolved potentially project-breaking problems. There's still a long way to go, certainly, but at least now we're fairly sure the sandbox works (most of the time). Cheers
  9. It's not just about moving files around, the big thing is how they're handled. Before, the primary entry point for assets were the .cfg files. That is, the game would go through all the part.cfgs (and others) it could find, read them and load files as needed. For instance, the part.cfg for the mk1 pod says it needs the mk1 pod mesh, its texture and some sounds, then each of those were loaded into memory in order to build the part. Now, it's a much more efficient system. Instead of doing the above, we go through the assets first, loading every model, texture and other asset we find on the GameData folder structure, and only afterwards we run through the cfgs, and we assemble the parts, internals and other cfg-defined stuff. This at first might not sound like it makes much difference, but it enables a few key things to happen. Most importantly, we now get to re-use assets across many parts. So if two part cfgs call for the same texture, it's already loaded, so we just use it again. Also, we can load assets regardless of how they'll be used later. Take flags for instance. The new database loader system made it very simple for us to just add a Flags folder, where we can find bitmaps to use as flags. The loader itself just puts it in the game. The flag logic later is what gives them a use. This works for just about anything. Imagine you're writing a tutorial, and you want to draw a texture on one of the tutorial pages. Before GameDatabase, you'd have to write the texture loading routine for that single asset, inside the tutorial logic itself. Now, you can just ask GameDatabase for the texture by giving it a url path, and not worry about file handling on bits of code that are doing other jobs. There's a lot more to it, of course. But those are a few of the advantages we gained by switching to this new system. Cheers
  10. That was a real bug. We've fixed it for the upcoming hotfix. It was just a suspension setting in the end... but jittery surface contact can lead to all sorts of trouble, so it's one of those issues that feels a lot more serious than it really is. Cheers
  11. Thanks to the OP for creating this thread! It's very interesting how on a thread about people not having issues, I was able to pick out pretty much all the same bugs we had gleaned off the more uh, negative threads, and in a much less depressing way. Hearing from those who AREN'T experiencing a bug is very often just as important as hearing from those that are. Cheers
  12. The lighting fix was on 0.19... That specular highlight on the ocean surface is a completely different issue though. The 0.19 lighting fix was related to the sunlight illuminating the ship from below at nighttime. Cheers
  13. Hehe, I also thought that was a big game-changing feature. It wasn't even planned at the start.. It was something I decided to do because the seats brought up the issue. You can read about it here. It's not a complete substitute for an assembly saver/loader, admittedly, but it's a very useful feature to have nonetheless. One other thing you can do with it is start your vessel by a structural part of your choosing, and build only an empty launch vehicle. Then, you can load that and construct a payload on top of it, and re-save as a new complete vessel. I find it makes for a much more natural and unrestricted build process. Cheers
  14. You don't have to be controllable to be better than debris. The seats set a minimum vessel type of 'Rover', even though they themselves don't provide a control source. That means vessels with seats are considered better than debris, but without someone on the seat, there's no way to control it (unless you attach a probe core or a pod). Cheers
  15. The seats aren't control sources. They just allow Kerbals to sit on them, thus becoming control sources for the vessel themselves. If you build something with no command pods nor probe cores, the editor will pop a warning to let you know, which you can ignore if you know what you're doing. Cheers
  16. Not a lot of them have it, admittedly. You can find out which ones by looking for a PhysicsSignificance = 1 on the part.cfg files. Of course, adding that line would make any part physicsless, which is definitely not recommended to do... Unless parts going off on their own each to their own corner of the solar system, or watching a stream of error messages go by the console is your idea of fun gameplay. Cheers
  17. Well, not quite, because if you eject something away from your ship, it'll go away from the staging list as well. This only works for activating stuff on the same stage, like the parachutes have always been able to do, but for anything now. Well, anything that has a function in staging. Cheers
  18. I've done all my testing here on saves I had from 0.19, and it's been working ok. We haven't raised the last compatible version cap, which means the game won't complain about incompatibility on saves from 0.19 and will let you load them. That's not saying they will work perfectly though, especially if you have too many mods. We never guarantee compatibility with plugin mods, because that would make our work impossible. I always recommend starting a new save with a new version, and also starting fresh with mods, to be on the safe side. Fully stock saves and crafts from 0.19 should load ok, at least as far as I can see. Cheers
  19. Well, I may be biased, but what I'm most excited about are the changes to the editor logic. We didn't talk about those much, but being able to start a vessel with something other than a command pod opens up a whole new world of possibilities. That, and the changes we did to controls to support it as well. Now, when vessels decouple, the decoupled new vessel 'inherits' the control state from the old vessel, so if you had it throttled up, the decoupled bits will still be throttled up. That already happened in some cases, but not through the same mechanism. Now, this also applies to switching to nearby vessels, which means you can go out on EVA, and re-board later, without resetting the input on the vessel you left. We also changed how parts respond to activating through staging. Before, if you had an engine and a decoupler on the same stage, if the engine was jettisoned it wouldn't get activated. Now, every part on a stage will respond to it being activated, regardless of whether that stage resulted in them not being on the same vessel anymore. Basically, it means anything can be made into a missile. That's what I'm most excited about. It really made a difference in the way I design my ships, and it feels a lot more unrestricted too. But I'm biased. Cheers
  20. If you press F5, you'll generate a quicksave. Quicksaves aren't overwritten like auto-saves are, unless you launch a new mission (then it generates one new quicksave state). You can reload a quicksave by pressing F9 (and holding it a bit). Cheers
  21. Those are called Physicsless Parts. It happens already. Cheers
  22. It is notoriously hard to write system specs for PC software, considering the amount of hardware variation there is. Add to that the fact that the game itself is ever changing, and you'll understand why ours is at best an approximated estimate. Anyhow, the performance you get from the game is also going to be significantly affected by how complex your ship designs are. Ships with less parts will obviously cause less lag than ones with many parts, and there's really no way around that. Well, there is one way, which is what Spore did: Add a 'complexity meter' to the game, which denies adding more parts after a set cap is reached. With a known upper bound, you can more easily find the requirements to run it decently. Of course, when this debate first came up, the response from everyone was a unanimous 'No', which I heartily agree with. I'd rather have 'estimated' specs forever than to have to impose some arbitrary limit on everyone, just for the sake of consistent performance. Cheers
  23. As of yet, none of the features for 0.20 require wiping saves. Can't guarantee it'll be like that throughout the whole update, but so far we've been able to keep it backward compatible. Cheers
  24. As for the dev streams, we've been thinking about changing the format for that a bit. I think an hour-long video full of us going 'uhh' and 'ehh' isn't the best way to present new things in any case, and even though we had a lot of viewers, the vast majority of community members didn't have the time to sit through such a long thing, to pick out the good information. We want to do a more condensed thing, still in video format, but where we're able to showcase the new things in a more clear and compact manner. The details for that aren't yet figured out though, and actually getting the first of these up is probably still going to be a while. In the meantime, everyone is very welcome to follow our dev blogs and articles, where we brag about the stuff we do just as much as on the streams. Cheers
  • Create New...