Jump to content

HarvesteR

Members
 View Profile  See their activity

  • Posts

    3,542

  • Joined

 Content Type 

Everything posted by HarvesteR

  1. HarvesteR
    If you're the sort of player who can max out the tech tree in 5 missions, then in all likelihood you already have a pretty good notion of what all the parts are and what they're meant to do. The tech tree is balanced to introduce, not to restrict. If we made it challenging to veteran players, we'd be making it downright impossible for new ones. That said, tweaking the definitions is not only something we expected already, but I'm actually looking forward to see what you guys come up with. Happy tweaking. Cheers
  2. HarvesteR
    The patcher is now properly set up on the server side, and updating to 0.22 with it should now be possible. Cheers
  3. HarvesteR
    Yes and no, OnVesselRecovered is fired once you get back to KSC and the vessel is actually recovered. When you press the button, there's another event that gets fired to notify the recovery component that it is supposed to register the vessel and start the scene transition. But as far as the OnVesselRecovered event goes, it should all work as expected. Cheers
  4. HarvesteR
    Hi, I'm very happy to announce that the 0.22 Update to KSP is now officially released! As you're all probably aware, this update introduces the long-awaited Career Mode which, while still under development, is now open. This update was one of, if not the largest update we've ever done in terms of amount of content and features. Here's the changelog: * Career Mode: - Career Mode is now open! Although still very much under development, you can now start new Career saves. - Sandbox mode, of course, is also available from the start. * Research and Development: - Added the Research & Development Facility to the Space Center. - R&D allows players to unlock parts (and later other stuff) by researching nodes on the Tech Tree (In Career Mode). * Science: - Researching requires Science, which must be earned by performing experiments during your missions. - You can now collect surface samples while on EVA, and process them to do Science. - Science experiments return results, which are different for each situation in which the experiment is performed. - Experiments can (as all proper experiments must) be repeated over many different situations across the whole Solar System. - Added a new dialog to show the results of experiments when reviewing the collected data. - Added a new dialog to show a breakdown of all scientific progress made after recovering a mission. * Parts: - Added new scientific parts, like the Materials Bay and the Mystery Gooâ„¢ Canister. Also added experiments to many existing parts. - The old science sensors now have a purpose. They all have their own experiments which enable them to log scientific data. - The antennas are now functional, and can be used to transmit science data back to Kerbin, if recovering the physical experiments is not an option. - Antennas consume massive amounts of power when transmitting. Make sure you have fresh batteries in. - Added a new deployable antenna, which is an intermediate model compared to the two original ones. - Completely remodelled the Communotron 88-88 Comms Dish. The new mesh uses the same placement rules so it won't break ships that have it. - Nose Cones now actually help with improving stability during atmospheric flight. - Revised a lot of part values and descriptions, in preparation for them actually meaning something in the near future. - Overhauled the landing legs and gears, they now have proper shock-absorbing suspensions. * Editor: - Added a system to allow saving and loading of Sub-Assemblies. - Subassemblies are subsets of spacecraft, which can later be attached to other designs and re-used. * Space Center: - The KSC Facilities have all been revised, and feature new ground meshes and many other graphical improvements. - Greatly improved the Island Airfield. - Added lighting FX to several facilities. The Runway (among many other things) is now properly lit at night. - Added a new backdrop and soundtrack for the Astronaut Complex Facility. - Added a new music track for the R&D Facility. * Flight: - It is now possible to recover a flight after landing/splashdown on Kerbin without going through the Tracking Station. Look above the Altimeter. - The SAS system was again largely overhauled, based on all the feedback we've gotten from everyone. It's now stabler than ever. * Solar System: - Celestial Bodies now support Biome Maps, which are used to create different conditions for experiments. - Biomes are currently implemented on Kerbin and on the Mun, more will be added on later updates. * Launcher: - We've got a new launcher application for KSP, featuring a news bulletin, patcher management, and also allows you to tweak settings from outside the game. * Windows and OSX Installers: - The KSPStore version of the game can now also be downloaded as an installer wizard on Windows, and as a .dmg image on OSX. Bug Fixes and Tweaks: * Fixed an issue that caused a stream of errors to be thrown after planting a flag and opening the map. * Fixed several minor and not-so-minor issues with scene transitions. * Greatly improved the scene transition times. Loading delays between scenes should be significantly reduced. * The SAS indicator on the UI now changes colors to indicate when your input is overriding it. As always, you can get the new version on our KSPStore. But this time, not only can you download a zip file or use the Patcher tool, we've also got an Installer package for Windows and OSX, to make the installation process simpler. If you have the game on Steam, you should be automatically updated soon (It could take a few minutes for it to detect the new version, try restarting your Steam client if it takes too long). Happy Launchings! Cheers
  5. HarvesteR
    It really is a better solution than End Flight, because this one doesn't do any save-state hackery to remove a live vessel off of flight. Instead, what it does is register that vessel up on a component that persists across scene transitions, and then call a scene change back to KSC. Once at KSC, the recovery components finds the listed vessel, which is now unloaded and safe to remove, and recovers it in the same way as recovering through the TS or through the launch sites. It's a much cleaner solution. I'm very happy with how it turned out. I'm also very happy that the button isn't set on the pause menu, becuase having to hit Esc means you're forced to stop playing for a second, and immersion breaks. The new on-screen button lets you recover a mission without breaking the flow. You'll be able to tell when recovery is possible when the little triangle LED between the altimeter and vertical speed gauges turns green. Cheers
  6. HarvesteR
    That was before we had build numbers. Now, we usually just set the x1 to show it's in experimentals, and keep track of versions using the build IDs, which are far more reliable. As for the videos requiring clearance, we don't base our approvals on editorial content, we're just looking for content that could lead to misinformation, since those builds are pre-release. For instance, if a video shows a game-breaking bug that we fix by the time of release, or it shows a feature that we later end up changing, then the preview is inaccurate by the time the release is out, and whoever watches the video will get the wrong impression. That's usually the sort of thing we're after. As for the original questions, the media group was given access to the experimentals deployment channel, which is why you see different version numbers on each video. Based on that range of numbers, they're all pretty close, as in not more than a few days apart, but then again, we did do some major tweaking during these days, so it's entirely likely you could see a few differences in bits here and there from video to video.... hence it being called a 'pre-view'. Cheers
  7. HarvesteR
    That google graph is somewhat misleading. I had seen it before, and the spike you see on July is actually reflecting the boom we saw during the Steam Summer Sale. We are just returning to normal levels again, and also keep in mind the September data is incomplete. Please be patient guys, it seems each update brings up this same discussion again. We have our own internal deadlines for 0.22, and things are moving well according to plan. That's all I can say. Cheers
  8. HarvesteR
    No engine that I know of does that. The sorts of issues we had to work through with KSP would have been there regardless of Engine choice, unless we had decided to build our own, in which case we'd still be doing that and KSP wouldn't exist. Cheers
  9. HarvesteR
    Thanks for posting this. It's very much dev-focused I know, but there are some good bits of information in there that should hopefully be interesting to everyone. Cheers
  10. HarvesteR
    So far, nothing we've added has required us to break compatiblity with previous saves. That said, there's never any guarantee that it won't happen. We do try to avoid it as much as possible though. Keep in mind though, that even if saves do remain compatible in 0.22, the R&D features won't be available in sandbox games. You'll have to start a new Career game to have a tech tree and actually do science. In sandbox mode, the experiment modules don't do much. Cheers
  11. HarvesteR
    This is a little known fact, but it is actually possible to disable the Revert options completely in your game if you want. The option exists, it just hasn't been added to the game UI yet. Open your persistent.sfs file in your save folder in a text editor. Look for a section called Parameters, and a section called Flight inside that. You'll find two options, one called 'CanRestart', which regulates the use of the 'revert to launch' option, and another called 'CanLeaveToEditor', which regulates the 'revert to VAB/SPH' option. Set those to False and the revert options will be gone. As for my personal take on this: It's a single-player game, play it however you think it's most fun. Cheers
  12. HarvesteR
    We did try, of course. If that had been possible, it would have been a lot easier for us too. When you speed up a physics simulation, you can do two things, one, increase the time that elapses during a single frame of the game. This is known as the 'time step'. You increase the time step so that on each frame, more time in the simulation goes by. This has an issue though. Increasing the time step means you're also decreasing the amount of 'detail' on your simulation. Take the case of an object thrown upward ito the air. Where at 1x you'd get a nice and detailed arc with the object in freefall, if you warp time too fast, you get to a point where on one frame you're at the upward leg of that arc, and on the next, you're already coming down, and all that happened in between is simply non-existant. So what this means is that increasing the time step causes inaccuracy on the simulation. You can see it happening in game, even at 4x warp, how the joints flex and bend far beyond their normal limits. 4x is about the most we can reasonably allow that won't cause complete mayhem in the sim. The second option then is to correct for this loss of accuracy by adding more "frames" in between each game frame. These are called physics steps in unity. Essentially, you increase time, but you run more physics steps for each frame so that the time in between each frame was indeed simulated. In the case of the falling object, that would mean that even if you only did see two frames, one with it going up and another with it going down, the game internally did all the calculations, step by step, to figure out the position and velocity of the object at each point on its trajectory. As you can imagine then, this second approach has a very severe impact on performance. The more you accelerate time, the more physics calculations the game needs to do to ensure it's accurate. If then at 4x you have to do four times as many calculations, imagine what warping at 100,000x would do to your computer. So the best solution for us was to do what we did, which is to allow as much physics warping as we can, but for higher warp rates, turn physics off altogether and put all objects "on rails". That restricts us to 2-body systems (even outside of warp, since otherwise we'd have a discrepancy), but it allows for warp rates as high as what we have, without compromising accuracy. Cheers
  13. HarvesteR
    If you mean a time component referring to requiring some time to elapse to research a new tech node, then no, that's something you can work around by simply having a ship at the pad to wait it out. These time constraints usually only work for real-time games, where time management is big. Now, as for the experiments themselves, some experiments could require a running time. Like you said, some gravity measurement in Kerbin orbit could be picking up data over the course of several orbits. But then we get into the "you can jsut time warp" issue, so I think such mechanics have to be worked in carefully. The cool thing about this is that it doesn't really matter much as far as the science is concerned. This becomes a front-end feature, something that the experiment module itself worries about. It's up to how each experiment works then. As for the money, you are correct. A budget implementation is something we're only planning for later, so it's not going to be on this update. But in keeping with our ways of always keeping the game at a playable state, the R&D system is able to function without it, as a standalone mechanic. Hence the whole science thing. Money does come into R&D eventually, but it's much too soon to be talking about that right now. Cheers
  14. HarvesteR
    So, I've been thinking long and hard here about how we're going to do the 'earning science' bit. It's a good idea, but putting it in practice poses a few challenges. How do we rate the science value of your missions? What even defines a mission in the first place? These things are actually pretty hazy in terms of how the game deals with them, so coming up with a nice, solid way of doing science is a deceptively tough task. I do believe I've worked out a good solution now: The game won't award you any science automatically. That would be artificial and generally meaningless, but worse still, it would require us to make arbitrary decisions about the science value of this or that action. That's a bad road to go down. Instead, we can let you 'do science' as part of your missions, and get your science points for yourself. Here's how: We already have a few science sensor parts, which apart from a context menu readout, are largely decorative. We can put those to some use now, along with a couple other scientific parts we're going to add. The idea is that science parts work as one-shot experiments. That is, they're activated by action group or as part of the staging sequence, and once deployed, they to their thing. This is essentially deploying the experiment to gather data. This data isn't science yet though, because you need to get it to your resident experts over at R&D to crunch the numbers and make some sense out of it. To do that, you can recover the experiments (or whatever is left of them). That will convert the data you gathered into scientific knowledge, provided you don't already have it. This is done by us storing where each experiment was run and what it was, and using that 'source' as a key to a multiplier value, which starts at 100% and gets progressively lower the more data on the same subject you gather. The more you spam the same type of experiment in the same place, the less science you'll get for the data it generates. Now, if we've learned anything this far, it's that recovery is by no means guaranteed. So here's where the antennas and comm dishes finally get a purpose. Once available, you can use comms equipment to transmit science data back down and gain science immediately. Of course, you can't expect to get as much knowledge for the same experiment data if you beam it back as if you had recovered it hands-on. How efficient the data-for-science rate is depends largely on the quality of the antenna being used, as does its power requirements. The possibilities for what the science-gathering parts can be then are pretty huge. They could be anything from experiment canisters filled with some mystery goo, a camera array, a mass spectrometer, anything really. Functionally it all works the same way, and better yet, it works with the game rather than over it. That's about it in a very tightly packed nutshell. I'm pretty happy with this idea now, it should fit any style of playing. You could focus on running as many different experiments as possible in Kerbin's lower atmosphere, or rush into discovering the different properties of Mystery Gooâ„¢ across the farthest reaches of the solar system, and hopefully any point in between as well. Disclaimer: Mystery Gooâ„¢ is not really a planned feature (yet). Cheers
  15. HarvesteR
    This is something mods have to do, we can only provide the tools do it here. Anyhow, it should be possible to add a few 'ifs' to a part module or any piece of game logic really, to check if a certain technology is available. That lets you (the mod-maker) restrict functionality until a certain tech is researched. This is also safe to use in sandbox saves. In sandbox mode, the R&D module isn't spawned, so the code interface falls back to an 'everything is available' mode. Cheers
  16. HarvesteR
    It starts with mid-sized engines actually (LV-T series). Going larger or smaller are both advancements. Cheers
  17. HarvesteR
    MechJeb's parts will have to be added to a tech node before they can appear in a Career game, so until MJ (and other mods) are updated for Career-friendliness, they won't appear in the parts list. That should give all mod-makers a chance to revise their cfg values for things that were of no consequence until now (costs mainly), and assign their parts to the tech node that fits them best. Cheers
  18. HarvesteR
    The development "progression" actually was an important inspiration for the design of the tech tree. It makes sense because the parts we added over the course of the project were the ones we felt were most necessary at each step along the way, so it stands to reason that as you progress in your own game, you'll feel the need for those parts in a roughly similar order. The early stages of the tech tree were designed with that in mind, of presenting core essentials first, letting you find the problems, then giving you the tools to solve those problems (roughly, there are other considerations too). Theoretically, yes. There is no technical restriction that would prevent you from loading a ship that contains parts you don't already have researched, so craft file sharing and such should work. This sort of restriction shouldn't be a technical one in any case. It's a gameplay rule, so it should be (if at all) implemented at a higher level. There is something interesting about loading a craft file which has parts you haven't researched though, it's something similar to reverse-engineering a construct you don't fully understand. You have the parts, but you don't really know what they are (no tooltips), and you can't really make more of them without the original to copy from. In the end, this might be a self-cancelling side effect. The practical limitations of loading above-your-tech vessels would probably outweigh the 'cheat factor'. If not, we can always write in a check to prevent it from happening, or as a half-way solution, just prevent alt+copying of parts you don't have. Cheers
  19. HarvesteR
    That is up to the mod itself to do. It is possible to 'ask' research and development if a tech is available through the ResearchAndDevelopment.GetTechnologyState(string techId) method though. Cheers
  20. HarvesteR
    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
  21. HarvesteR
    That is very cool. Thank you for sharing those with us! Cheers
  22. HarvesteR
    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
  23. HarvesteR
    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
  24. HarvesteR
    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
  25. HarvesteR
    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
×
×
  • Create New...