Jump to content

HarvesteR

Members
 View Profile  See their activity

  • Posts

    3,542

  • Joined

 Content Type 

Everything posted by HarvesteR

  1. HarvesteR
    I have tested multiple grapples against the vessel, or even to a single object. They should work, just as docking nodes do. If they come in contact with a part that is on the same vessel, they create a joint in a way similar to struts, they link the objects physically, without modifying the already existing hierarchy. As for grabbing the ground, that is the one thing the grabbers can't grab. It would require a completely different set of states and rules for that to happen... One thing at a time. Cheers
  2. HarvesteR
    Those took on average half a day to write, revise and grab screenshots for... so even though we'd love to do those, there simply aren't that many hours in the day. The weekly devblog works nicely for us because it lets us each just write a few lines in a couple of minutes, then Rowsdower takes care of putting it all together in a nicely formatted post. Cheers
  3. HarvesteR
    Ah yes, we forgot to mention that. The support features that we announced as part of 0.24 are now going to be in the ARM patch, so everything needed to properly play the asteroid mission and all the related usability improvements are all going to be contained in the ARM patch itself. Cheers
  4. HarvesteR
    That was, in fact, just a second celestial body I added to the test scene I used to test out the patched conics. That was well after Minmus had been added, IIRC. That screenshot comes from a totally separate project however. KSP is much too big and takes a good deal of time to compile and load, so when we're writing big features, we usually do it in a separate, cleaner environment first, then move all the new stuff in once it's ready to integrate. Think of it as taking a part off your car's engine to work on it on the bench, instead of having to do the same work lying under a greasy underside. Cheers
  5. HarvesteR
    Not entirely, but think of it like this: If two of us (myself included) were so busy yesterday we couldn't take five minutes to write down a few lines about our week, having the opportunity to take about an hour or so to do a complete write-up of something has become a very rare thing these days. That said, I am going to do my devblog still, stay tuned. Cheers
  6. HarvesteR
    The key thing you have to do to nail a landing with zero lateral movement is this: Chase the Retrograde Marker. As you begin your powered descent, you'll notice that by thrusting laterally to the surface (initially pointing retrograde but not changing attitude), your retrograde marker on the navball will start to go up into the blue half. This happens because as you lose lateral speed, your vertical speed component will become ever more dominant. It's tempting at this point to just flip perfectly vertical and try to hover into a landing, but the easiest way to make sure you're thrusting towards the direction that will most definitely slow you to a stop, is to always chase the retrograde marker. Now, keep in mind the speed reading on your navball can read relative to the surface (which takes into account the rotation of the planet), or relative to orbit (which doesn't). For the Mun, which only has about 9m/s surface speed at the equator, this may not seem important, but those 9m/s when touching down can very much tip you over, if not even smear you across a patch of surface. So, make sure your navball is reading 'surface' as you're about to touch down. This usually happens automatically, but you may inadvertently click the speed reading sometimes and disable the auto mode switch, which is why you have to keep an eye for that sort of thing. The speed reading also affects the velocity markers, so this is very important for final touchdown, otherwise you won't be slowing to a complete stop as you near the surface. With all that in mind, you have everything you need at your disposal to pull off perfect landings. Keep SAS on to make your life easier (mind the batteries if you don't have solar panels though, or engines large enough to have alternators), and chase that retrograde marker until it is dead center on the navball's zenith point (straight up). TL;DR: Keeping it short though, as long as you're in surface speed mode and always decelerating while pointing towards your retrograde vector, you're bound to pull off a dead-stop landing. Hope this helps Cheers
  7. HarvesteR
    That would be any part which is considered by itself a control source. Or more technically speaking, any part that contains a ModuleTripLogger component attached (by default those are added at load time to all parts for which isControlSource = true, but if you add it through the cfg the loader won't remove it). The Trip Log is built off the recovered vessel by compiling together the output of all ModuleTripLoggers on its parts. Then the trip log is read though to find the most impressive (highest subject value) place that vessel has been to, and that then is used to calculate the science value for recovering a vessel. So in a nutshell, you should almost always be able to get recovery science for a ship you bring back, since it's generally fair to assume that if you were indeed able to pilot a ship back home, that ship had to have some part that could provide input to it. It has a reasonable analogue too, because you can imagine that finding a piece of debris that landed back on Kerbin wouldn't tell you much about where it came from. We assume probe cores and command pods have some form of flight recorder device that actually stores where they've been, so the recovery team at Kerbin can tell where it came from. And in practice, that really is the case, since ModuleTripLogger is for all intents and purposes, a flight recorder. Cheers
  8. HarvesteR
    These test results are consistent with the PhysX documentation tips about joint stability. The problem with wonky joints comes from a single source. The rigidbody solver has issues converging (finding a stable solution within the allowed iteration steps) when you have very high mass objects constraining low mass objects. On the test here, this was happening with the base of the test craft, which was constrained between the ground and an ever increasing load from the top of the craft. Try this for confirmation. Have the base object of the rocket be heavier, say, a large tank. Then stack the same test rig on top, and check the stability of the system in the same way. My prediction is that it will either take a lot more mass to make it start to wobble, or that the wobble will be happening between other joints. Lastly, there is another situation which we can already say will be wholly cured with the new joints system. When you have long objects linked together, like a long truss or tank, up until now, that meant attached objects would end up creating a long joint between their attach point and the long object's center of mass. That means you'd see on many occasions, objects dancing around on top of each other. With the new joints system, we have solved that. Now the attachment points are linked node-to-node, or in case of surface attachments, node-to-wherever-the-node-is-relative-to-the-surface... That means the joint itself is kept as short as possible, so that 'dancing wobble' effect is gone now. There are a few cases still where we see flexing in the current state of the new system, some of those are intended, because we do want attachments that look flimsy to behave flimsy. We're still working to ensure those are the only cases where attachments are allowed to bend, but in any case, from what we can test here, there's already been a very noticeable improvement over the old system. Cheers
  9. HarvesteR
    Hi. Once more, here we are at the beginning of a new update, and I want to share with everyone our goals and ambitions for the upcoming 0.24 release of KSP. We continue pushing forward with Career Mode, but this update has a few other neat things that should be very welcome additions, be you a Career-driven achiever or a Sandbox tinkerer, something in between, or even extrapolating the ends of that spectrum! We’ve got a lot to accomplish but we feel like this will be a great way to kick off a big 2014 for KSP. Anyhow... These are our main goals for 0.24: Contracts The first iteration of the contracts mechanic is coming up. At the Mission Control Facility, you'll be able to take on contracts from a list of offers. Each contract will give you a set of objectives to fulfill, possibly with added requirements, and a deadline. These contracts are going to be dynamically generated off a number of different basic mission templates, and filled out with detail based on how far you've advanced in your Career. A feature this large is most likely not going to be complete in a single update, but we feel like we’re off to a very good start with our initial plan. New Mission Control Screen It's been there for a while, but so far no Kerbal has dared enter that mysterious building at the space center. Oh, plus the fact it didn't have an inside also made it extra difficult. We're adding a new Mission Control Screen, accessible through the already-there Mission Control Facility, which will present you with a UI where you'll be able to pick out contracts and decide whether to accept them or pass them by. Improved Part-to-Part Joints There is one unassuming line in the Unity 4.3 changelog that made a world of difference to us. I'll quote it here in fact: "Physics." Joints can now have separate anchor points configured for both connected rigidbodies. What this means is that the era of rockets 'dancing' on top of their engines is coming (finally) to an end. We are completely re-doing the joints, to have much more control over how they link together, and not least, how much we want them to be bendy and wobbly. We're not eliminating the wobble altogether, as that would actually be removing a lot of what makes failures fun. We're aiming to have better control over it, so we can have wobbly bits where we want them to wobble, and more rigid connections where things are supposed to be firmly attached. Multiplayer's First Steps This isn't so much a feature at this point, but it's worth mentioning in any case. We're starting work on the core components of multiplayer now, so by the time we're about done with Career Mode, we'll already have a solid platform to start building multiplayer features on top of it. Right now, the primary goal is to write the server backend that will run things. There won't be much to show of this for a while, but we'll keep everyone posted about the progress being made. Tutorials Revisited It’s been a long time since we did the in-game tutorials now. They harken back to ye olden times of version 0.17, and when you consider that 0.18 was when we added maneuver nodes and docking, you start to get a sense of just how much has changed in the game since the tutorials were written. Needless to say then, they’re in dire need of a revision, and that’s what we plan to do on this update, and if time allows, also add a couple of new ones. And as always, the usual batch of small tweaks and bug fixes that we do as we go along. And we can't say this enough, this list isn't a preview of the changelog for the next update. These are our ambitions, not promises. Some of this might not make it in, while at the same time other things not on this list might be included as well, so the bottom line is, don't take this as if it was written in stone. (It was, in fact, written on my sweet new G19s keyboard, which the kind folks at Logitech sent to us. And no, they didn't make me say this). Anyhow, that's all the news for now, stay tuned for more as it develops. Cheers!
  10. HarvesteR
    The estimated burn time does factor in the changing TWR, as it gets calculated based on the vessel's current acceleration (and expecting full throttle). What it doesn't do is antecipate how much that burn time is going to change as your TWR increases, so while it may start out saying 20 seconds for a burn, if you were to time the burn with a chronometer you'd notice the estimated seconds go by slightly faster than real-time, since it's recalculating as the craft mass decreases and your acceleration increases. It does work out to zero burn time at zero dV remaining though, which is the essential bit. Doing a single braking burn to stop at a very precise spot is a VERY tricky stunt to pull off though, hence the name of the maneuver. In fact, it's probably a good thing if you're coming up short... the alternative would be far less desirable. You can try not burning at 100% though, maybe leave it at 90-ish to compensate, and you'll end up closer to the ground. Do keep in mind you're essentially playing a game of chicken with the ground, and the ground doesn't care nearly as much about losing. Cheers
  11. HarvesteR
    The original idea (and implementation) was indeed that the Kerbals would use the monoprop from the pods to fuel themselves. During experimental testing however, we noticed everyone was getting frustrated with it because those tanks, being just normal mono containers, would get drained out using RCS, and when it was time to EVA there would be no more fuel left for them. It didn't work as well in practice as it did in theory, and without a total rewrite of the RCS flow logic, which we just didn't have the time for, we had to think of something else. In the end, this feature was causing more aggravation than enjoyment. There were other issues as well, for instance, the mono on EVA suits had to be 'hacked' to zero density, otherwise the added weight would make Kerbals unable to walk properly (just those 5 units of mono was several times heavier than they are themselves). The EVA propellant resource can have its own defined properties, so it works without having to resort to hacky fixes. The switch to EVA prop solved all those issues without having to do a full reversal back to the old system. Now they have all the advantages of having a proper resource-based pack propellant, without the problems that arose from that fuel being the same as the one used for RCS. I decided to leave the RCS containers on the pods however, because that did prove very useful for minimal craft designs, as you noticed as well. Cheers
  12. HarvesteR
    All Kerbals enjoy feeling weightless. That wait for the circ burn is all zero-g, so he was probably stoked about that. Usually other factors like velocity and spin contribute to terrify that grin off their faces, but Bob is slower to catch on than the others, so conditions were probably just right to put a smile on his face, for a while. Cheers
  13. HarvesteR
    I changed the default max delta-time per frame to 0.04, as you all noticed. It was already possible to tweak manually, of course, but the reason I changed it was because I noticed most players didn't know this tweak existed, and at it's old default of 0.1, you needed to be lagging pretty horribly already (10 fps is nigh on unplayable) before the game would start to slow down. That made the whole feature a lot less useful than it had the potential to be. Setting the new default at 0.04 means it'll start to kick in at around 25 fps, which means it'll always try to keep performance to a reasonable level. But more importantly, this will now happen to everyone regardless of whether they know of the setting's existence. Oh, and thank you for the thank you thread! It's always great to see that people appreciate the work we do. Cheers
  14. HarvesteR
    That was an idea I had considered at first, but it would circle back to a grind, where you run an experiment, then EVA out to reset it, then go back in to re-do it, and repeat over and over for infinite re-uses. In the end it just becomes a chore that you have to do. Having the labs be able to reset experiments worked out better, because the labs themselves are large and have high resource and crew requirements, so that tends to balance out better, and it's possible to do it internally, which makes it more convenient too. Cheers
  15. HarvesteR
    There's no limit to how many samples you can store, as long as they're not repeats of an already stored subject. And yes, that's one of the best ways to use the Labs, as a science 'base' to return to after sending out expeditions. Cheers
  16. HarvesteR
    Yeah, that's totally possible. You can store experiments in a lab just as you can on other pods and cabins. And yes, the best way to use the labs is to have them as part of a base or station. Carrying them around with you wherever you go isn't very practical. Their best uses come from being able to send out expeditions from them into other areas, to find new biomes and new ways to do science, then return with the new data to have it processed before transmission, and have one-shot experiments cleaned out to work again. Cheers
  17. HarvesteR
    My initial idea was in fact to have the experiments become inoperable immediately after use. I set it up that way, tried it for 15 minutes, and absolutely hated it. What happened there is that if the experiments went inop after any use, they would become spent before you even got to see if there was any good science to be done at that spot. It felt very frustrating to have to 'guess' at a good spot to deploy, and risk losing a good experiment if you missed. I realized then that it was because the game wasn't giving me a choice. When you run an experiment now, it will only become inoperable once the data is 'consumed' for transmission. So it's not so much like litmus paper anymore, but it still makes sense if you consider that the sample 'tray' or whatever the data gathering apparatus inside the module is will get destroyed in the process of being converted into something that can be transmitted. This then became a good way to separate the 'physical' experiments from the more 'digital' ones. The goo container and materials bay do have physical samples inside, so those have to be destroyed to be processed into transmittable data. The other experiments are either abstract, like reports, or are somewhat 'digital' in nature, like a temperature or gravity scan, so those can be freely reused since their data is already transmittable. From a gameplay standpoint, I like how this means you now have to manage your science 'cargo'. If you're doing a mission across several new subject types, you now have the choice to dump a less valuable experiment for a possibly more valuable one, and making informed choices is a key element of fun gameplay. This is why the initial idea also didn't work. You had to make a choice, but you didn't have any information to let you weigh the options, so that became frustrating. Being able to see what you got, how much it's worth, and weigh that against your limited uses of the experiment and the promise of more valuable data ahead, that makes it very interesting. Cheers
  18. HarvesteR
    Hi, Just in time for the holidays! I'm very pleased to announce the 23rd update to KSP is now available. This update, as you all probably already know, was mainly focused in smoothing out the features we've added all through this year, patching up long-standing bugs, doing optimizations, and adding a few new features that were long awaited. More Specifically: * The Science Archives: Browse through all the science you've done in your Career games in this new section of the R&D Facility. * Tweakables: Several parts can now be tweaked individually by right-clicking them during construction, allowing for entirely new possiblities in spacecraft construction. * Science Revisited: We've revised the way experiments are performed, stored and transmitted based on the feedback we got from the last release, to make Science much more engaging and interesting. Endlessly-repeatable transmissions that would let you max out a subject in a single mission are a thing of the past now. * The Lab Module: With experiments and transmissions no longer being freely repeatable, we've added the Lab Module to let you process your science data on the field, increasing the science gained by transmitting it. The Lab also allows you to reset single-use modules such as the Goo Canister and Materials Bay, since those will now become inoperable if their data is removed for transmission. * The R.A.P.I.E.R. Engine: The new 'Reactive Alternate-Propellant Intelligent Engine for Rockets' is a hybrid propulsion system that can run on external intake air while flying through the atmosphere, and will switch to internal oxidizer supply as you leave the atmosphere behind. * EVA Data Collection: Kerbals on EVA are now able to collect and store data from experiment modules and other science containers, including other EVAs. * Part Tooltips Overhaul: The old tooltips seen when hovering over part icons in the R&D or construction facilities have been completely overhauled. The new layout is a lot easier on the eyes and organizes information much more efficiently, making it easier to compare stats between parts and seeing what does what. * All-Around Optimizations: We've gone over a huge amount of code this time, to make sure the game is doing things as efficiently as possible. The optimizations were mainly focused around sources of lag with high part counts, so the game should be smoother around large ships. (Your mileage may vary, as no hardware setup is quite the same). * 6-DOF Device Support for Windows: Few games can benefit from a 6-degrees-of-freedom input device such as the Space Navigator like KSP. Seamless transition/rotation camera control on all scenes, plus pitch-roll-way and linear XYZ inputs in flight control mode, allowing for an unprecedented level of control. This feature is Windows-only for the time being, but we're ready to implement OSX and Linux support as soon as the drivers become available. Plus a heap of other additions and fixes. Here's the complete changelog: ==================================== v0.23.0 ========================================================= New: * The Science Archives: - Browse through all the science you've done in your Career games in this new section of the R&D Facility. * Tweakables: - Several parts can now be tweaked individually by right-clicking them during construction. - Landing Gear can be set to start out deployed or retracted, and can also be made steerable. - Engines can have a thrust limiter set on them, so you can balance out asymmetrical thruster configurations (or use differential thrust for taxiing). - Wheels can be tweaked to have their engines toggled, steering locked, all before launch (and after, of course). - Control Surfaces can be tweaked to toggle response to pitch, roll and yaw input individually. * Science Revisited: - Transmitting scientific data no longer allows you to max out the value of a subject just by repeating the transmission multiple time. - Removing the experiment data from some experiment modules (for transmission or by EVA) will render them inoperable. - Resetting an experiment can still be done freely as long as the data is not removed from the module. * Solar System: - Added a new Biome Map for Minmus. - Cleaned up the Biome Maps for Kerbin and the Mun, to remove areas where Biomes would be detected incorrectly. * The Lab Module: - Added a new part called a Laboratory Module, which allows experiment data and samples to be processed before transmission, increasing their science value. - The Lab Module requires 2 crews inside to operate and a whole lot of power as well. - Added a new button to the experiment review dialog to process collected data on the Lab if one is available (and operational) on your vessel. * EVA Data Transport: - Kerbals on EVA can now collect the data from experiment modules and store them on crew-carrying modules. - Kerbals can also collect data from other data container modules, including other Kerbals. - EVAs can also store samples collected from other experiments on the Lab. * Part Tooltips Overhaul: - The tooltips that pop up when mousing over a part on the editors have been completely redesigned. - The tooltips show essential info only at first, but can be expanded to show more info with RMB. - Once expanded, you can right-click again to collapse, or to pin other tooltips if you hover over other parts. - Re-organized the part information to group stats for each module and resource container on a part. - Added a larger icon for the part on the tooltip itself, featuring a scale to give an idea of size before picking. * All-around Optimizations: - We've gone over all our code to make sure it runs as efficiently as possible. - Upgraded to Unity version 4.2.2 to make full use of its own bugfixes and tweaks. - Texture loading has been sped up, loading times are noticeably reduced. * [Windows-Only] 6-DOF Device Support: - 6-DOF input devices such as the Space Navigator are now supported both as camera and flight controllers. - Scroll Lock will toggle the device mode in flight. - Due to driver limitations this is a Windows-only feature for now. We're ready to implement support in OSX and Linux as soon as those drivers become available. Bug Fixes and Tweaks: * Parts: - The logic for all-vessel resource flow (such as Electric Charge and MonoPropellant) has been re-done. - Fixed those resource containers not being able to drain fully or store an amount larger than their current available space. * Docking: - Fixed an issue that caused docking ports to resume their states incorrectly after docking, making it impossible to undock afterwards. - Fixed a big issue with docking operations through physicsless parts in the hierarchy between the port and the original vessel root. * EVAs: - EVAs now use actual resources for their jetpack propellant, instead of their own fuel system. - Fixed an issue with collision resolution that caused EVAs to sometimes fall over and become uncontrollable. - Kerbals other than you will now pick themselves up from ragdoll state if they are involved in any 'accidents' or are flat out being used as Kerbowling pins. - Parts that land onto splashed-down parts are now considered to be landed. This allows EVAs to walk on floating platforms. * Other Fixes: - The Return key will no longer reset the staging sequence in the Editors, or return you to the Main Menu at KSC. - The Main Menu now remembers the 'page' you were at when you left it, so if you return from a loaded game, you'll find it still at the "Start Game" screen. - Fixed several issues with joystick axis mapping and indexing. - Updated the Input settings screen to expose a few new control options that weren't accessible before. - Fixed an issue that could lead to loss of GUI responsiveness after leaving flight during reentry or supersonic flight. As always, you can get the new update as a full download (zip file or installer) through our KSPStore, or use the patcher tool to update your existing install. Or if you're on Steam, just sit tight as it auto-updates itself (Might be a few minutes. Restart Steam if it's taking too long). Compatibility with previous versions: We haven't had to bump the last-compatible versions on this update, so all previous saves and craft files should work just fine through the update. Do keep in mind mods may not work correctly, so it's always advisable to start out with a clean, unmodded install. Happy Launchings, and Happy Holidays! Cheers
  19. HarvesteR
    Happy Holidays! Technical difficulties with our Twitch.TV stream made things unclear with our announcements during KerbalKon. We wanted to clear the air and make sure there was a record of what we said and why we said it. We are working every day to improve our communication while also making sure the community knows what to expect from us. So let’s go over what we shared at the end of KerbalKon: 1. Completing the scope of KSP: This is our top priority for 2014 and we will be focused on completing Career Mode, which will link Science with new contracts and reputation systems. We don’t have a date on this for you, but we will be working on it starting on 0.24. 2. Resource Mining: The old resource-mining plan is being shelved, which by all means, is a good thing. It wasn’t fun once we got down to it, so we’re not losing anything worth keeping here. That doesn’t mean there isn’t a need for more “end-game” activities. We aren’t ready to disclose any new ideas now because we’re focused on Career Mode and anything we bring up now could end up getting scrapped later and we’ll have the same issue we have now. 3. Multiplayer: There’s been a LOT of misinformation about this specific feature, so let’s clear up a few things. This has always been a goal of the development team and has always been on the plans. Regardless of any public declarations in the past, fact or fiction, internally, multiplayer was always a possibility and we wanted to spread this info when the time was right. We decided to share this news now because multiplayer will be part of completing the scope of KSP. It won’t be prioritized ahead of Career Mode but as part of our scope, we will start working on it in 2014. One last thing we wanted to discuss was what it means to be an Early Access game. While we share a lot in common with MMO-style development processes, it is different in that the MMO is essentially complete from the start and receives new updates to extend content for players who have done everything. The Early Access game is still incomplete and must devote development time to adding features that might not seem important to experienced players, but make it easier to be picked up by new players, or make the overall game experience more complete, even if it doesn’t make it more lengthy. We hope this explains our plans a little more clearly and answers any questions from last week’s event. Happy Launching! Cheers
  20. HarvesteR
    I've thought about this feature too. It sounds like it would be a lot of fun to code, basically taking the g-force vector from vessels and transforming it into IVA coordinate space to be applied onto loose objects floating around. The main issue though, is that there are many many other features that out-prioritize a purely for-kicks one like this that need to get added first. Not to mention that such a purely aesthetical feature needs to be disableable through settings to not eat up CPU time for low-spec computers. Would be fun though, can't disagree there. Cheers
  21. HarvesteR
    I think you've explained it better than I did. Cheers
  22. HarvesteR
    I think there is a large amount of inaccurate overlap here between what the top-end of KSP gameplay needs and what the old resources system was supposed to add. I agree that once you master the challenge of spaceflight and are able to get anywhere and pretty much do anything, you start to feel there isn't much left to do. This is true of any game. However, most games at that point just end and you get to watch the credits roll by. With KSP, you are free to continue playing until you've exhausted all possibilities, and beyond. This "end-game lull" is a frequent issue with sandbox games. However, I disagree that resource mining-- especially the idea for resource mining that we proposed last year-- is the best solution to improve end-game activities. There are a lot of other cool things that we could add there, that would be a lot more interesting and fun, and that wouldn't require an overly complicated and honestly, very tedious system to give you new cool things to do. What those things are aren't something we want to discuss yet. For all we know at this point, whatever new idea we disclose now might end up turning into a new 'resources', that later needs to get scrapped, so let's not get into that discussion now. One thing that needs to be made clear though, is that a game in Early Access, while it shares a lot in common with the usual MMO-style development process (without any regard to payment model either, that's an entirely separate and off topic thing here), it is different in that while the MMO is essentially complete from the start, and receives new updates to extend the content for players who have done everything, the Early Access game is still incomplete, and must devote its development time to adding features that maybe might not seem important to experienced players, but that make it easier to be picked up by new players, or that make the overall game experience more complete even if that doesn't make it more lengthy. That's not saying we won't ever add more things to do on the end-game level... However, you may notice it's even been mentioned several times here that the key thing is that people feel that once you land on another planet, there isn't much else to do. That does not imply the solution to that is to get out the shovels and start mining. Especially if you were supposed to remember to pack the shovels in the first place and didn't realize it until after touchdown. My point is, that old plan we had for resources is most certainly not the right solution. It doesn't fit organically with the rest of the game, it requires you to remember to attach a bunch of single-purpose parts to a vessel (forgetting any of which would render a mission a complete failure), and really, that's just not how we want the game to play out. I think this is the crux of the issue then. The resources plan being shelved is, by all means, a good thing. It wasn't any fun once we got down to it, so we're not losing anything that was worth keeping here. However, that does not mean there isn't a need (and budding plans) for more end-game activities. I'm just saying that old plan for resource mining wasn't it. Cheers
  23. HarvesteR
    Wow, there are some seriously insightful posts on this thread.. I wholeheartedly agree on the notion that a game is something you should be enjoying as you play, not suffering through for the promise of some indeterminate reward further ahead. That said, there seems to be a balance to strike here (as with all things), because following this argument to its logical conclusion would lead to the idea that games should not be persistent at all, and we're back to how coin-operated arcade gaming worked. There is merit in working towards a higher goal in a near future, most definitely. But games, like many other things, are about the journey, not the destination. With KSP, that's actually quite literal an analogy. Musings aside though, there's nothing in 0.23 that has caused compatibility issues with previous saves. My test saves here are all from 0.22 or even earlier, and they are all working normally. A key thing to understand about compatibility in KSP is that when something makes a save incompatible, that doesn't mean the game will outright treat old files as unloadable. To make that happen, we here have to manually set a new "last-compatible" version number for the file formats that broke, so the game throws error messages and disables the incompatible ones. Unless we do that, the game will allow you to load the save and treat it as a fully compatible file. Note though, I can't say the same for modded installs. If a plugin breaks because of changes to the game code, then there's no telling what it could do... In that case, you'll have to wait until the plugin is updated to work on 0.23, but unless your game was corrupted as a result of the plugin failure, once the mod is updated you should be good to go again. Long story short, we haven't had to up the last-compatible version on any of the file formats here so far, so compatibility is preserved as far as we can tell. Cheers
  24. HarvesteR
    It doesn't mean that at first. What I'm working on is the code that draws the tooltips itself, and the GUI style that goes with it. So far the work has been on improving the general look and feel of the thing. That said, I have been going over the code from the parts that generates the text you see that's specific to each part, today in fact, I'm getting into reworking the content of the tooltips, specifically as it relates to the module code that outputs the info. Now, things like TWR and delta-V are beyond the scope of a part tooltip. That would require a new panel in the editor dedicated to displaying those values for the current craft you're building... Except for SRBs which are self contained, we have no way to determine the burn time of an engine (or it's delta-V) from the part alone, so that's a separate feature we're talking about there. It is definitely something I'd like to add in at some point in the near future though, probably not on this update, as things are quite busy enough as they are, but we'll get there at some point. In any case, there is new information that you can see on the new tooltips already, stay tuned for a dev post about it Soonâ„¢. Cheers
  25. HarvesteR
    That's the one indeed. In can see the little cube strut dangling there off the broken port. Turns out, while there wouldn't be any errors explicitly with this bug, the physicsless parts would get handled as if they were normal ones, and they'd get joints added to them. Joints that require rigidbody components, which got added with no initial setup to these objects. To get an idea of what this means, consider that by default, rigidbodies have 1 full unit of mass, respond to physx gravity (which we don't use) and that these parts were parented to another object. You can get a sense of the chaos that would come from it. It's one bug I'm very glad to see fixed. Definitely. Cheers
×
×
  • Create New...