Jump to content

HarvesteR

Members
  • Posts

    3,542
  • Joined

  • Last visited

Everything posted by HarvesteR

  1. Hi, It’s time to talk about our goals for the next update. As you all know, we’re on a major push to develop Career Mode, but after a release as large as 0.22 was, we needed to have an update to catch up on all the stuff we’ve added, fix bugs and revisit some of the features in the last update. This is all so we can start off the next big thing on Career Mode with a game that’s as stable and polished as we can make it. So these are our main goals for 0.23: * All-Around Optimizations We’re going through each line of game code and making sure things are getting done as efficiently as possible. We’re also optimizing the asset loaders to reduce loading times, and upgrading to the latest version of Unity, to take advantage of all its new tweaks and fixes. * The Science Archives Collecting scientific data isn’t just about advancing the tech tree. The Science Archives will be a new section on the R&D Facility, which lets you review all the data you’ve accumulated to date. This is your library to view all the knowledge you’ve gathered for Kerbalkind. Also, this overview should help plan future missions. * Tweakables This long-awaited feature is finally coming with this update. Tweakables will allow you to open a context menu for each part during construction. This allows for unprecedented freedom in design and setup of a spacecraft. Want your wingtip control surfaces to act only as ailerons? Or your landing gear to start deployed or retracted, or to make some of them steerable? Tweakables will allow for all that, plus many other adjustments. * Science Revisited We too have been playing the newly-implemented Career Mode, and taking in all the feedback from the community. We are changing a few things to make Science much more interesting: * The Transmission logic is being redone, so no matter how many batteries you’ve got, you won’t be able to max out a subject by just using antennas. * We’re also changing the way experiments allow being reset, so don’t get too attached to those endlessly-repeatable experiments. * Science Lab Module If getting the data back to the labs is not an option, you’ll now be able to get the lab itself to the data instead. With antennas not able to max out a subject anymore, the Lab Module will allow you to increase the max amount of science you get from transmitting, by giving your crews a way to run tests and analyze the experiment results ‘in the field’, before beaming it back home. Don’t expect this to be a compact piece of equipment though. In fact, not many parts are larger than the Lab at the moment. * EVA Data Transport With new ways to process experiment data, we’re also going to need new ways to move it around. EVAs will now be able to collect and store not only their own experiments, but also collect data from other modules and data containers, including other Kerbals on EVA. * Quite a lot of other stuff Overhauled UIs, 3D Mouse Support, Monopropellant-powered EVAs, Steerable landing gear, Secondary propellants for engines, more Biomes, and of course, hunting down some of the most critical long-standing bugs… The list goes on. So these are our highlights. As always, these topics are our goals for the next release, and do not imply a commitment on our part to deliver them. If something doesn’t make it in time, we’ll push it back, and conversely, we could even end up adding stuff that’s not on this list, so the bottom line is, we aren’t writing this in stone. Stay tuned for more news as we develop them. Happy Launchings! Cheers
  2. We changed the app config today to launch the launcher exe instead of the game directly, but just now reverted it back, since there were a few issues we need to take care of before we can set it up as the default for everyone. The launcher is available on your game files, if you already want to use it (you can create a shortcut for it). But Steam will bypass it until we're sure all issues are taken care of. Cheers
  3. Keep in mind that at the time we did that interview, we had other values for the tech tree, and experiments awarded much more science than they do now. We then went through several revisions of the values, so while I can't say it's NOT possible (you never know what someone's going to be able to pull off), the set of values that generated that concern are now pretty different, so the whole discussion is probably moot now. In any case, my original point still stands. If you can manage to pick up that much science in one mission, then you're probably not the sort of player who would benefit from having to discover each tech node one at a time, since in all likelihood you're quite familiar with the game already. Cheers
  4. You don't need to compare that with the state of the node, just check it against the enum itself: bool techIsUnlocked = ResearchAndDevelopment.GetTechnologyState("someTech") == RDTech.State.Available; Cheers
  5. 140 Data. Data isn't the same as science. The aerodynamics nose cone analisys comes out as a pretty large amount of data... think of it as a very large file, the contents of which determine the science that you get out of it, not the filesize itself. Unless the 'scientific value' field on the review dialog actually does say 140 science, in which case that would be a bug. Cheers
  6. RDNode only exists inside the tech tree itself. If you just want to check the state of a technology, use the static methos ub the ResearchAndDevelopment class. All static methods on that class are safe to use regardless if whether you're in a career game or sandbox. Cheers
  7. 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
  8. The patcher is now properly set up on the server side, and updating to 0.22 with it should now be possible. Cheers
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. It starts with mid-sized engines actually (LV-T series). Going larger or smaller are both advancements. Cheers
  23. 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
  24. 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
  25. 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
×
×
  • Create New...