-
Posts
3,542 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by HarvesteR
-
What if Earth's day was only 85 minutes long?
HarvesteR replied to Mr Shifty's topic in Science & Spaceflight
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 -
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
-
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
-
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
-
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
-
Flags? Seats? Changing pods is the real .20 star
HarvesteR replied to Hakuryu's topic in KSP1 Discussion
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 -
What are you most excited about in 0.20 update?
HarvesteR replied to EvilotionCR2's topic in KSP1 Discussion
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 -
What are you most excited about in 0.20 update?
HarvesteR replied to EvilotionCR2's topic in KSP1 Discussion
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 -
I think kerbal space program should change its requirements
HarvesteR replied to Awesomeslayerg's topic in KSP1 Discussion
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 -
What are you most excited about in 0.20 update?
HarvesteR replied to EvilotionCR2's topic in KSP1 Discussion
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 -
KSP 0.20 vis a vis breaking 0.19 .craft files
HarvesteR replied to segaprophet's topic in KSP1 Discussion
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 -
What are you most excited about in 0.20 update?
HarvesteR replied to EvilotionCR2's topic in KSP1 Discussion
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 -
Really save a savegame
HarvesteR replied to Tokay Gris's topic in KSP1 Gameplay Questions and Tutorials
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 -
I think kerbal space program should change its requirements
HarvesteR replied to Awesomeslayerg's topic in KSP1 Discussion
Those are called Physicsless Parts. It happens already. Cheers -
I think kerbal space program should change its requirements
HarvesteR replied to Awesomeslayerg's topic in KSP1 Discussion
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 -
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
-
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
-
Hello again, It's been a while since we've had a proper one of these. Sorry about the delay with writing it (I said I would do it yesterday), but things have a way of heaping up on us, don't they? Anyhow, here are the highlights for the 0.20 release: * Flags! Not just planting flags on EVA, but a full implementation allowing you to select from a mod-friendly collection of flags, which also supports having flag decals on just about anything (more on that later). Assigned to: HarvesteR, Dan Status: Under Development. * Kerbal Seats External seat parts which allow Kerbals on EVA to approach and sit on them. From Munar buggies to seats on solid rocket boosters, and anything in between and beyond. Assigned to: HarvesteR, Dan Status: Design Phase * New GameDatabase Loader A complete overhaul of the game's asset loading system, allowing for much better handling and usage of loaded assets, and also creating a new folder structure where mods can have their separate folders, regardless of what they add. Assigned to: Chad, Mike Status: QA Testing * Loading Buffer Scene This is a trick we've picked up from the Unity guys at the GDC. To better clear off memory when switching scenes, we first switch to a blank 'buffer' scene, to ensure unused assets are properly unloaded before switching to the next one. This should improve crashes when switching back and forth, especially to and from flight. Assigned to: Chad Status: QA Testing * On-Demand Terrain Assets This might be the most significant optimization we've done so far. Instead of having all PQS maps for every planet and moon loaded when the flight scene start, we now only load the ones needed for the current celestial body. Those maps are pretty huge, and there are quite a lot of them. Memory usage should be significantly improved. Assigned to: Mike Status: QA Testing * The Kerbal Knowledge Base This is the first iteration of a new game system that'll be a big thing later on. The Knowledge Base will show all known information about anything you can focus on the map. Be it celestial bodies, ships, or Kerbals floating around. Assigned to: Jim (Romfarer) Status: Under Development. * Map Filtering Too many vessels and debris cluttering up the Tracking Station will be a thing of the past now, with the new Map Filtering tabs. Just click on them to view only a specific vessel type on the map and sidebar list on the Tracking Station view, or right-click to combine multiple tabs. Assigned to: HarvesteR Status: QA Testing * More Parts Always more parts. More on that later. Assigned to: Claira, Chad Status: Under Development. There's still more to come than what's on that list, but those are the highlights. The full changelog will get posted when the update is released. At this point you're probably also wondering, what happened to the resource gathering thing? Well, resources proved to be far too large a set of features to implement in one go. We've still got a long way to go with that, and right now, we decided there were more important things that needed implementing first. The Knowledge Base is the first step towards the full resources implementation, but we're pushing the rest of those features to a later update (yes, update, not expansion.). Anyhow, this is what our update is looking like so far. As ever, there is no public release date, so please don't ask if we're there yet. There's still some ways to go with this one. That's about it for now I guess. More news as they develop. Cheers
-
I'm going to close this thread because we've already had discussions like this before, and they didn't end well. Sorry OP, this is just to prevent another thread like what we had yesterday. There's going to be a new development update article shortly, in which I explain the state of things, in as much detail as I can. Stay tuned for it. In the meantime, please be patient, and . Cheers
-
Ok, I think it's time we close this thread down now. I know it started with the best of intentions, and thanks to the OP for starting it, but I reckon there's nowhere else for it to go now except down or off-topic. Cheers
-
EndlessWaves, you seem to be assuming that we are selling KSP through those other stores you mentioned, which isn't the case. The full version of KSP is only available through the KSPStore or through Steam. Any other store will at most have the demo, and even that as an unofficial mirror download at best. So maybe that's the point of confusion. Cheers
-
Both Steam and KSPStore get the updates at the exact same time. We've set up our build pipeline so that when we release, the builds get pushed simultaneously to both servers, so update-wise, there's really no difference. It's a matter of personal preference mostly. Cheers
-
The server had to be restarted to carry out an upgrade (we've gone from 8 to 16gb RAM on it now), and when it got back up, some services weren't running properly and had to be manually set right. Should be good now. Cheers