Jump to content


  • Posts

  • Joined

Everything posted by HarvesteR

  1. Concerning mods and the tech tree, this is how it works: All parts now have a "TechRequired" parameter in their cfg files, which is set to the ID of the technology node which unlocks it. IDs are unique, so there's no worry about branches or dependencies there. You just set, for instance, radial decouplers to the "generalConstruction" tech. Doesn't matter what other techs you need to get to general construction, the radial decoupler will be there when you get there. This means mod parts will have to be updated to appear in the parts list on a Career mode game, which is actually a very good thing. This requires mods to be updated to fit into the R&D tree, which means they can be added to the techs that best suit each part. Plugin-only mods should be unaffected. The R&D implementation just hides unresearched content, it doesn't keep it from loading. There is another new parameter on the part cfgs to define a part's 'entry cost'. The entry cost is an amount required to have the part available in the parts list. This means when you research a tech, the parts it makes available aren't made automatically available to you. You'll also have to put down some cash (game cash of course) to have the part. Without a working budget implementation however, it might not be possible to finish up this entry cost mechanic for this update, but it's easily disableable (word?) in case we need to go without it for now. That's about it for now. Cheers
  2. That is very cool. Thank you for sharing those with us! Cheers
  3. One thing I've found can cause losing control during a takeoff run is to have a misaligned wheelbase. That can happen if your landing gears aren't all parallel to each other (and aligned in the general direction you want to go towards). If it's a minor misalignment, it can cause some wobbling, but if it's significant, the wheels will get dragged slightly sideways and the skidding could tear your craft apart. Try to reattach your gear with angle snap turned on (or off), or move them somewhere else. If they're converging or diverging, they'll likely be unstable. You want to make sure they are parallel, as much as possible. Cheers
  4. The big thing with R&D isn't to impose a grind where parts are unlocked as a reward for something. What I want to get out of it is a mechanic through which the game presents itself gradually to players, to not welcome you with an overwhelming wall of content right from the start. As with the content, the tree itself is being designed to expand the further you get. At, first, you get a few general technologies to research, which in turn open up new nodes which are more specialized, and so on until you're getting to some really specialized stuff towards the higher levels. We're assigning parts to each of these nodes now with this idea in mind, and so far I think it's going rather well. Each part seems to find its place nicely in the tree we have here. As for how nodes will be researched, here are my thoughts: We can't impose any amount of time to unlock something. You could just sit on the pad and timewarp if that were the case, and that's not the sort of gameplay we'd like to see. I also don't like the idea of spending money directly to research something, as that would reduce R&D to be just a shop catalog. Instead, I think the most authentic mechanic would be for nodes to require a 'science' rating, which you earn through experimentation (flying) and gathering data (packing science gear aboard possibly). This system opens up a lot of very cool possibilies for later, which will give a lot of meaning to what you can do out there on your missions, even before we have an actual game economy or contracts. To paraphrase a friend developer, it's not about realism, it's about authenticity. Realism means putting you into a simulator cockpit and making you wait around for months to reach another planet. Authenticity means making sure what the game lets you do feels right, even if it's presented with some degree of abstraction, like using a numerical value to represent a more complicated process. Cheers
  5. No need to worry about that. R&D is probably only going to be available in Career Mode. For Sandbox saves, it wouldn't make much sense to have R&D anyway. The R&D Facility will be at the space center but it won't open the R&D screen. This is the best solution IMO. It leaves existing saves unmodified, and means everyone will get a clean start with R&D. Cheers
  6. We currently have over 160 stock parts in the game. It's definitely enough to have a tech tree. That said, yes, we are still missing a few parts to fill some particular niche here and there. The Tech Tree is actually helping out a lot in finding where those 'gaps' are, so we'll know a lot better over the coming weeks which parts we need to work on next. Also, don't expect whatever we release on the next update to be a final, unchangeable version of the tree. As with everything else we do, this is only a first implementation, so it's very likely it'll be revised again and again until we're completely happy with it. That's about as much as I feel ok with discussing at the moment, it's still very early to get into detail on it. Cheers
  7. I do have a theory on why some people were affected while others weren't. The drifting issue was related to how the SAS would release attitude lock when input was detected, and that could have been getting interference from joystick axes with zero deadzone. We corrected that by setting a minimum deadzone that's independent of the joystick deadzone, so if you have joysticks with no deadzone, it will still properly ignore the jitter from the analog inputs. I think those who didn't have this issue either didn't have any noise on their input axes (as detected by unity), or had deadzones set for their joystick assignments. Not sure... That's just my theory of how it could affect some and not everyone. Cheers
  8. Hi, I'm glad to announce we've just released the 0.21.1 Revision Patch for KSP. This patch addresses some of the most critical issues found on the 0.21 update. Most importantly, it fixes a big issue where you could end up stuck in the Editor scenes, due to the Launch and Exit button becoming unresponsive; and also fixes the new SAS, which wasn't holding attitude like it should have been. Here's the changelog: ==================================== v0.21.1 Bug Fixes and Tweaks: * Removed some unused assets from KSP/Parts. * Fixed an issue with some scenery meshes that could cause bits of the UI to become unresponsive in some cases (mainly in the VAB and SPH). * Tweaked some object scales slightly. * Tweaked the ocean color at sea level on Kerbin (was way too dark). * Fixed an issue that would cause lag while moving parts around the editor scenes if too many crews were hired at the same time. * Fixed an issue with the new SAS not properly maintaining attitude. Should be much better now. * Tweaked some parameters on the SAS to make it more responsive. We've also changed a few other details about the SAS: Now, all command pods, be them probes or capsules, enable SAS for the vessel. Not all of them are able to apply torque on their own though, much like it's always been with the old system. We've re-tuned the SAS to get a sharper response as well. The issue we found with it was a simple one but it had some very far-reaching implications. The new SAS releases the attitude hold when you apply input, so you can still control the ship with it on, but an issue on the logic for that was causing the attitude lock to not set very well, which resulted in it drifting off target. As always, you can get the latest update through the KSPStore, the Patcher, or get auto-updated if you're on Steam. (If Steam hasn't updated yet, try shutting it down and restarting. That usually causes it to refresh all apps) Important Note: * Do mind that as with any new release, you shouldn't expect mods to work with the new version. We strongly recommend doing a clean reinstall of your game on each new release. Happy Launchings! Cheers
  9. We did tweak the lighting on this patch. As a whole the lighting was too strong, and there were several places where you'd get complete white-out. Lighting for rendering is a complicated thing. There is no single solution that mirrors what you'd see with your own eyes (your eyes adapt), unless you use HDR (high dynamic range) techniques to simulate this adaptation, which alas, isn't something Unity does very easily at the moment. That said, we're always trying to find ways to improve the looks of the game, and we found that by lowering the main sunlight intensity, we got a much nicer tone distribution throughout the lighting range, which means you get to see more tone variation, which is good. This shot shows it pretty well. Where now you see pretty splash lighting, before you'd only see a white blob. As for the Mun itself, my opinion on it varies from shot to shot... Sometimes I think it's too dark, other times I think it's ok... I guess it's one of those things that will keep getting tweaked over time. Cheers
  10. I think a slightly critical piece of info slipped past untold... Whether or not crews can respawn is a toggleable difficulty setting now, which admittedly lacks a UI toggle switch, but is already definable on the save file. Have a look at the Parameters section and you'll find it. The default setting (for now) does allow crews to respawn, so even if you do end up with a favorite Kerbal on the "lost" list, if the game parameters allow it, they'll come back to life eventually. Cheers
  11. Thanks! It's very nice to see someone noticing our backend work, outside of a bug report. It really was an insane amount of code reshuffling that we needed to do to make it happen... Verging on stupid almost, but I'm very glad we managed to pull it off, because now we have a much neater solution for elements that are shared between multiple scenes. As for other similar systems. One game I know does something along these lines is ArmA. Once you load a map on it, that map will stay loaded until you exit the game or load a new map, even if you quit to the main menu (there are background cutscenes for each map). That cuts down on loading times while you're doing missions on the same map. The same happens for KSP now with PSystem. We don't have discrete maps, but you'll notice that if you're just playing around Kerbin, especially near KSC, the transition time between the space center, VAB and launch is drastically reduced, because the terrain can just remain unmodified while we switch scenes now. We only have to rebuild now if you're returning from somewhere far away. Cheers
  12. Now this is much more like it! I'm also suspecting from all the reports that something, could be a mod, could be a bad settings file, could be old parts lingering about the KSP/Parts folder, might be interfering with normal SAS operation. The new SAS might be a lot of things, but it most definitely isn't a thing that requires constant input to maintain attitude. It's been pretty consistently doing that on all the test cases we did here, and there were a lot of them. If the SAS isn't holding attitude properly for you, then it very well may be in a buggy state, because that is certainly not the intended behaviour. First things first though, we need a proper baseline to compare different cases here. So how about we use the Aeris 3A spaceplane as a benchmark? It's easy to fly and it's got a few particular flight characteristics that are easy to spot. So, the test is as follows. * Launch a new Aeris 3A from the runway, set it at full throttle and try to maintain level flight. * Do not adjust trim. On neutral trim, the 3A has a slight tendency to pitch down when the tanks are full. * Climb out to 1000m altitude and verify that it's doing that. Let go of the controls and make sure this tendency to drop the nose is there. * Ok, that's our control. If you've observed anything else at this point, something is already wrong with your game and you should be doing a complete reinstall. * Now, let's test the SAS. From level flight, engage it with T and don't apply any input. Verify that it's maintaining attitude. * If that didn't happen, then something is wrong with your game. Reinstall. * Now, a few more tests. Apply some slight pitch up input without disengaging SAS. Pitch up to about 30° and watch the aircraft maintain the new attitude. * If that didn't happen, then something is wrong with your game. Reinstall. If you spotted something wrong by doing this test, please list all your mods if any, and check the KSP/Parts folder to see if there's anything in there (on a stock install it should be empty). Also, try deleting your settings.cfg file and running the game again. It's unlikely, but not impossible that a bad config would mess things up. That should be enough to spot most cases where things are very obviously wrong. We can start with that for now. Cheers
  13. Hi again, I'm very happy to announce that we've just released the 0.21 update for KSP! As you all probably know, this update was our first to focus mainly in Career Mode. We've still got a long way to go with that, but I can't tell you how satisfying it is to finally see progress in this part of the game, after over two years of working on the sandbox. Here are the main features for this update: * Revised Flight-End scene flow. In preparation for Career gameplay, we've redesigned 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). * New Space Center Scene. The most underdeveloped part of the game finally gets its much deserved overhaul, featuring new models for nearly all the facilities, plus a couple of new ones as well. Keep on reading for more details on them. * 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 victims 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. * New VAB and SPH Interiors. The insides of the construction facilities are also completely re-done, the models are not only vastly better-looking than before, they're far more efficient as well, so there's no performance tradeoff here. * PSystem. This was one of the biggest code overhauls we've ever pulled off. Now, instead of having everything duplicated in each of the game's scenes, all common elements like the scenery, game logic, ambience and the planetarium are created once and get reused. This means the world you see at the space center is now exactly the same as the one you see in flight, and in the tracking station. It also means much slicker transitions between scenes, as we don't have to respawn everything again. * Overhauled SAS Flight Control Sytem. Veteran players (and new ones alike) will be happy to know we’ve done away with the old Stability Augmentation System (or Sickness Avoidance Solution or whatever you want to call it) we had, which caused more flight stability problems than solutions sometimes, and re-built it completely from scratch. We can’t overstate how much of an improvement over the previous system this is. * Much Improved terrain on Kerbin, the Mun, and other places. New procedurally generated craters on the Mun, low hills around Kerbin, and a lot of other tweaks and optimization make for a much more interesting landscape to fly around and <s>crash into</s> land at. * A Completely Redesigned Website. Alex's secret project is finally revealed! Check it out. And of course, the usual battery of bug fixes and tweaks. Here's the changelog (there are actually more changes than this, these are only the most noteworthy): ==================================== v0.21.0 New: * Space Center Scene: - The Space Center scene now uses the same terrain as in flight. - Time now passes in the Space Center scene, and day/night is consistent with in-flight. - The game terrain persists across scene transitions, making loading scenes much faster. * Construction: - Completely overhauled the interior models for the VAB and SPH buildings, complete with animated trucks and cargo lifts. - All-new exterior models for the VAB, SPH and Tracking Station. - New Astronaut Complex building. - Added a description field where you can write up a few lines to describe your space-faring contraptions. * Crew Management: - It is now possible to assign crew manually to missions before launch, both from the Construction Facilities and from Launch Sites. - Added completely new Launch Dialogs on the Runway and Launchpad at the Space center. - The new Astronaut Complex dialog allows you to hire crews from a list of Applicants, and view the status of all your crewmembers. - Revised the crew handling game logic, for a much more reliable and robust system. * SAS Modules: - Rewrote the SAS control logic from the ground up. - SAS is now enabled for the entire vessel, and requires actuators like winglets, RCS or others to actually have an effect. - Repurposed the old SAS modules are now Reaction Wheel Modules, that apply torque while consuming electricity. - The new SAS logic allows applying manual input while SAS is on, letting you set the ship's attitude without having to constantly toggle it. * Procedural Terrain: - Added a new module to generate craters procedurally on the Mun. - Largely revised Kerbin's terrain to produce much more interesting mountains, hills, valleys and coastlines. * Flight Re-Flow: - Removed the physically-impossible "End Flight" button. - Added new options to "Revert" a mission back to launch or to construction. - Added new 'Recover' button on the Tracking Station, to allow recovering a vessel (as opposed to Terminating it) when possible. - Recovering vessels makes its crew available again, while Terminating kills them. - The 'Space Center' button now allows you to leave flight at any time, warning when necessary about saving restrictions. * Progress Tracking: - The game now tracks your progress as you play, providing essential data for the upcoming Career Mode features. - Progress data is (optionally) uploaded to our servers, * Misc: - Improved the in-game shadowing to enable shadows at much larger distances. - Added several new parts from the KSPX pack as stock content. Bug Fixes and Tweaks: - Scenario Modules now properly save and load when the rest of the game saves and loads. - Scenario Modules can now have multiple target scenes set. - Improved the internal logic for switching to nearby vessels, it shouldn't refuse to switch with valid vessels nearby anymore. - Added a system to attempt upgrading incompatible save files if/when possible. - Tweaked PQS on other planets and moons to not initialize until approached. Improved performance a bit. - Added a new system on PQS to clamp terrain subdivision while moving very fast. Orbiting low near the surface is a lot smoother now. - Many more small tweaks and improvements. Important Upgrade Notes: * Do mind that as on all new updates, you shouldn't expect mods to work properly. * This new version is incompatible with SFS (savegame) files from previous versions. However, we now have a system that will allow you to upgrade these incompatible files if possible. So, as usual, you can get the new version at the KSPStore, or be automatically updated if you have the game on Steam. You can also use the patcher to sync your install without having to do a full download. Happy Launchings! Cheers
  14. Planets being small was one of the most important design decisions we made. The Kerbal system is scaled (roughly) to 1:11 of real-life. This allows for a number of "improvements" over the real thing: You can orbit Kerbin in around 30 mins, instead of the 90+ it takes to orbit the Earth; Launching into orbit takes around 4-5 minutes, as opposed to 10-15; Orbital velocity at 100km altitude on Kerbin is around 2300 m/s, around the Earth it's over 7000; With everything scaled down, things happen faster, and you also get a better understanding of what exactly happens as you orbit. It's a much more dynamic experience this way, and consequently more fun. Others have said it already, and it's very true: KSP is a game first, a simulation second. If some aspect of the real thing is boring or too complex, we will do all we can to minimize time spent doing it or making it simpler. Examples of that are how Mun is at 0° inclination to Kerbin (you can get there thinking in 2D), or how the galactic plane is aligned to the ecliptic and equatorial plane, creating a unified space "horizon". We take such liberties wherever we find that there's no fun to be gained in making it more realistic. Because really, if complete realism were the most fun you could have, we'd all be outside playing. Cheers
  15. Very true. In fact, the Vomit Comet needs to be piloted just right to maintain that parabolic trajectory, which isn't that easy on a craft specifically built to not free-fall. But you don't have to be perfectly parabolic to start to feel weightless. Close enough will do, and this is what happens if you fly close to orbital speeds while maintaining altitude. You're not perfectly in free-fall, so you experience something in between zero and 1G. Cheers
  16. A "chip in your brain" is a very vague proposition... What are the specifics of it? Would it be connected to anything in the brain? Would it have a power source of its own or be powered by induction from an external source? would it have any sort of network interface, and if so, would you be able to configure it? Or is it just a random piece of electronics I found in my head after waking up in a bathtub full of ice one day? IMO, I understand a "chip in the brain" by the notion that it is a complete computer, only with a very very 'user-friendly' human interface system. No keyboards, touchscreens or anything, just a straight connection by what you will it to do (somehow). The outputs could be visual, or audio, or just a mental image. The issue then becomes a much more familiar one. What sort of Operating System are you willing to install or have installed? Will it let you tweak it to your liking ala Linux (with the possiblity you might zap your own brain by botching up a tweak), or will it be an in-brain version of iOS? Computers do what we tell them to do, nothing more and nothing less, and most certainly not necessarily what we want them to do. Whether or not you want one in your head is actually besides the point... Cheers
  17. Ok, so, I'm going by the assumption that the OP question was this: If you take an aircraft that can go fast enough in the atmosphere, does it experience less G force as it approaches orbital velocity? Yes. I've had this happen here myself. This has nothing to do with centrifugal force and whether or not it exists (it does in a rotating reference frame), it's simply the fact that the mechanics of orbiting don't switch off just because you're in the atmosphere. I built a space plane one day that had enough engine power to fly at an appreciable fraction of orbital velocity. IIRC, it could do over 1000m/s at around 20km altitude, which is nearly 50% of orbital speed at Kerbin. Flying level above the surface (0 vertical speed), I noted the G meter indicated around 0.5 G. I was perplexed by that for a while, until I realized that we really were flying at almost half the speed it takes to orbit the planet, and it makes sense then that if you're moving that fast and maintaining altitude, the G force will tend to zero as you approach vCirc. Note though, that this is G force I'm talking about, not the gravitational pull of the planet. The force of gravity acting on the ship is still the same (or roughly the same as at the surface, because 20km is peanuts to space). Zero-G is achieved once your acceleration matches that of gravity. We experience 1G at the surface because we are opposing gravity already just by the fact that we're not falling through the ground. Orbiting however, isn't opposing gravity, it's falling along with it. As you fly forward very fast then (assuming level flight in relation to the surface), you experience less G force on you because you're approaching a state where your acceleration matches that of gravity. You don't experience zero G immediately however, because you're still opposing it by maintaining level flight. The closer you are to orbital speed then, the closer to zero G you get, and the less wing load is required to stay level. If you go faster than vCirc then, you actually have to pitch down to maintain level flight, because that trajectory would send you away from the surface. You then experience G force again as you have to oppose the acceleration of gravity. I hope this explanation made sense... I tried to explain it by as many angles as possible, but there's only so much you can do without having to start drawing up charts (I'm not going to start drawing up charts). Cheers
  18. It's nothing to get excited about I'm afraid... The server simply seems to be down. We're scrambling to fix it and will resume normality as soon as possible. Cheers
  19. That map is an example provided in one of the Libnoise tutorials, which is an opensource numerical noise library we still use to generate terrain in KSP. The very earliest versions of Kerbin were using the map as a placeholder, and after the game went public people started founding countries and creating all sorts of stories around it. We didn't have the heart to replace it by a unique one, even though it was a few tweaked seed values away. These days, the original map isn't used at all anymore, but we've generated our height maps from it (and from that generate the planetary surface maps), so the continental layout remains very similar. Cheers
  20. Craft files are still compatible. The only thing that needed to break was save compatibility. Your creations should be safe... Assuming of course it's not using mods that might themselves break, or something else... compatiblity is never simple. In any case I've been using the same stock ships here as always for testing, and they didn't give us any trouble so far. Cheers
  21. While we've been able to maintain compatibility over the last couple of updates, unfortunately this one isn't such a case. The new crew management system changed the format for saving crews (to something much better), and the new format isn't compatible with the old version. Instead of risking breaking things even more by writing some sort of upgrade logic, we decided it was better to just break compatiblity and start fresh. This also gives us a nice opportunity to do other tweaks that we can't usually do, exactly because they tend to break saves. Because we're going to break it anyway, we can push in a lot of other little tweaks that wouldn't have gone in otherwise, so hopefully they will make it worthwhile. You can always manually edit your save so it matches the new format, but that can cause other issues, so we really don't recommend it. Stay tuned for a dev blog soon about new things that we got to add because we decided to break compatiblity. Cheers
  22. Threads like this are the reason we started the Science Labs board. It's just awesome to see such an aggregation of brain power come together to tackle a difficult and interesting problem. So, what I would consider to be the ideal solution to SAS is this: When enabled, it would hold the vessel's attitude to what it was when it was engaged (as it tries to do now), but if any input is applied by the player, it would allow you to command the attitude setpoint. I think any solution to the SAS system will involve some sort of adaptive scheme. It could start off with default values, and by noting the input it's applying versus the reponse it's getting, it could adapt its parameters to something more suitable. The problem is that this response might be buried in noise, or it might only become measurable after a delay, so grabbing good data isn't easy. Factor in the vibration from the vessel's own geometry, and it gets even worse. I do have a few ideas about how to exclude the vibration from the input... We know where the CoM is in relation to the vessel transform, so we can take a cross vector of that against a 'pristine' CoM, calculated using the stored pristine coords for each part, instead of the actual part positions. That difference is your 'flex' vector, and we can exclude that from the vessel's actual rotation to get a 'rotation at CoM' value, and derive the angular velocity at CoM from that. Excluding flex, we can hopefully have the true angular velocity for the vessel, with makes for a much more reliable input to any PID scheme. EDIT: Better yet, instead of a cross vector, we can take a from-to quaternion, and use it to directly exclude the wobble from the vessel's rotation. The resulting rotation can then be used to find the flex-free angular velocity. Cheers
  23. Hi again, I've realized there's something that could be a possible source of confusion. Who exactly is currently part of the KSP dev tem? The Credits shows a good number of people who aren't part of the team anymore, so I decided to write up a short post about the dev team and who's actually part of it these days: The KSP Dev Team, as of today: Working on the game itself: Myself (HarvesteR): A brief search shows that I am in fact, still here (as Full-time lead developer). Chad (C7): Full time technical artist. Mike (Mu): Full time tools & game developer. Jim (Romfarer): Part-time UI Developer. Artyom (Bac9): Part-time Content Designer, working during weekends and in his spare time. Working on other KSP-related things: Alex (aLeXmOrA): Full time web developer. Daniel (DanRosas): Full time animator, going back and forth between doing game content and promotional videos. Rob (N3X15): Intern web developer. Marco: Full time technical support. Miguel (Maxmaps): Full time PR Manager. James (Skunky): Full time Community Manager. Managing a dozen projects at the same time (of which KSP is but one): Adrian: Executive Producer. Ezequiel: Executive Producer. New to the team (say hello): Jesus: Full time production manager. Freelance: Victor: Soundtrack composer. Edu: Sound Effects composer. On Leave: Claira (ClairaLyrae): Part-time Content Designer, currently on leave for classes. Jeff (NovaSilisko): Intern Content Designer, currently on leave. No longer part of the team: Anthony (Damion Rayne): Community manager until April. Jacobo: Content Designer until early this year. Ivan: Did some content for KSP once, still works at Squad on other projects. Juan Carlos: Did some content for KSP once. No longer at Squad for a while now. As you can see, the credits can make it seem like we're a much larger team than we really are. Regardless though, I just wanted to reassure everyone with this post that despite us being only a few, we are all working as hard as we possibly can, to make sure KSP becomes the game we want it to be. Cheers
  24. You know how we say we're amazed every day by what you guys manage to pull off? This is a whole new level of that. Hats off to you sir! I'm properly amazed. Cheers
  25. These extreme loading times appear to be caused by a new unity bug (introduced on the latest version and exposed by a tweak on 20.2). There is a known workaround, which is to disable any unconnected network adapters you may have. I can't guarantee it'll work for everyone, but it appears to have been effective for many. Cheers
  • Create New...