HarvesteR

Just a note about that sky.... Yes, we are adding a new, higher-res (and IMO, much better looking) skysphere, but what you see in that video is still WIP, and very exaggerated for daytime on Kerbin. The new skysphere still doesn't have the dynamic dimming system implemented, so the stars are currently shining at full power even at the day side. The final version will have that improved. I gotta say though, that skysphere when viewed from orbit is quite a sight to behold. Chees

Quite the necrobump, indeed, but quite a blast from the past also. Look at that changelog! The issues we had were quite a lot more, uhh, primordial back then. (still locked) Cheers

Oh... if we're not, well... too late. I saw this yesterday, and it pretty much made my day/week/year/life. Cheers

That's probably correct. LandedAt will be blank unless you're landed at the launchpad, runway, or the area around KSC. Otherwise it is "". And you shouldn't be calling checkLanded on OnGUI really. That might cause trouble, since OnGUI doesn't run during physics update. Landing detection is done automatically, and the values should update themselves. Cheers

That's almost correct, but your velocity vector is in units/second, so what you did would give you your predicted altitude a second from "now", and a lot can happen in a second. If you want to get your altitude at the next frame, you can do GetAltitude(position + (velocity * Time.deltaTime)). Mind though, that this assumes no forces will act on your vessel, which is ok on low velocities, but will be pretty inaccurate in orbit, for instance. To get a more precise prediction of your position at any point in time, use the Orbit methods, like Orbit.getPositionAtUT(Planetarium.GetUniversalTime() + someTimeFromNow); Cheers

Ahh yeah, this is why we didn't bother much with packing and unpacking for the new PartModules. Joints are only active while their rigidbodies are non-kinematic. When vessels pack up, their joints get paused automatically (This is the beauty of the new part packing/unpacking system we created in 0.16. It's that much simpler now). Cheers

Currently, there aren't many of these messages, as they're part of the new PartModule interface, which we are slowly building up to replace Part subclasses. I've been adding them as needed here, but here's what we have now: OnPartPack - sent when a part is packed OnPartUnpack - sent when a part is unpacked OnVesselPack - sent to the vessel object (the root part on the ship), when it packs OnVesselUnpack - sent to the vessel object (the root part on the ship), when it unpacks OnVesselLoad - sent to the vessel object (the root part on the ship), when it loads its parts OnVesselUnload - sent to the vessel object (the root part on the ship), when it unloads its parts OnVesselDie - sent to the vessel object (the root part on the ship), when it dies OnPutToGround(PartHeightQuery) - sent to all parts on a ship when it's placed at the runway or launchpad. Used to override the default ground-finding algorithm, for instance, in case of a landing gear that is supposed to start deployed, or the launch clamps. Coming in 0.17: OnCenterOfThrustQuery(CenterOfThrustQuery) - used in the editor scenes to find the center of thrust for the whole vessel. Parts that produce thrust are required to fill in the values in the query object. OnCenterOfLiftQuery(CenterOfLiftQuery) - used in the editor scenes to find the center of lift for the vessel. Part that produce lift are required to return a lift force value based on the reference velocity vector on the query object. IIRC, that's all of them for now. Cheers

One of the best comparison analogies I've ever seen about KSP and Orbiter was this: "If Orbiter is like building a miniature model of a spaceship, with painstaking care and attention to detail, KSP is like playing with LEGOs." I'm a big Orbiter fan myself, and I don't want KSP to ever compete with Orbiter. Both might share a common theme, but they are very different projects, with very different goals. Orbiter, like any proper simulation, strives to be as realistic as possible, no compromises. KSP on the other hand, isn't meant to be fully realistic. It's meant to be an above-average realism space game. Anyhow, the way I see it, there will always be room for both games. Hail Probe! Cheers

PartModules don't have a virtual method that gets called when the vessel packs and unpacks, but parts send the OnPartPack and OnPartUnpack messages to all components attached to the same game object, so if you have public void methods with those names, they should get called when the parts pack and unpack. Cheers

What Skunky said ^^ It's stupid that we even have to say this, as it should be implicit, but let me make it as clear as I can: The forum rules are NOT to be questioned. The authority of the moderation team is also NOT to be questioned. We reserve the right to change the forum rules at any time. None of the modders are doing anything we here haven't ok'ed or even ordered them to do in the first place. So, acting out against the moderators is quite simply stupid and no one should do it. On almost every case, they're only enforcing decisions made by us, and giving them a hard time about it is not only useless, it's also a very quick way to get yourself in trouble. I hope I made this clear. Cheers

Hi, Just wanted to add something else here. The main reason we are banning these words from user names is that, for instance, "{Something} Kerman" and such are very sought-after names, and at the moment, we have over 40 member accounts called "{Something} Kerman", most of them being variations of "Jebediah Kerman". You can readily see the potential for confusion this creates. For that and the reasons Damion mentioned, we decided here that the only course of action that is fair for everyone is to ban these names altogether. So, if you're one of the members affected by this new rule, we apologize for the inconvenience, and hope you understand the necessity behind our decision. Cheers

It's not that we don't want to keep dev blogs anymore, the reason we haven't been posting regular updates is because we are still waiting on the forum overhaul to be completed (it's still half-way through). We are going to add proper in-forum dev blogs, and we've been waiting for that to start posting our updates again. What we don't want to do anymore is use normal threads to post info, because even with the locked-thread system we adopted on the 0.16 update, we still saw that people couldn't find information, and there was no organized place to hold discussions. With a blog + comments format, all that should be solved, which is why we are waiting for that to start the dev blogs again. Cheers

Yep, that was a slingshot maneuver. The Mun is moving at around 500m/s around Kerbin, so if you enter its SOI from the 'trailing' side, the Mun's gravity will pull you towards it, so when you leave by the other side of the SOI, you'll have gained some of that velocity. You can also do slingshot maneuvers to decelerate, in much the same way, only coming in from the other side of the SOI. I used this 'gravity braking' technique once when returning a spacecraft from Sun orbit back to Kerbin. I slung around both Minmus and the Mun (many trajectory corrections (and some "extra fuel") required) from the leading side, to slow myself into a parking orbit around Kerbin. About the jettisoned radials, they should change SOIs just the same as your own vessel. I'm guessing you jettisoned them early on, which meant they drifted away from you for a long time before you did the unplanned slingshot. Even though their initial relative velocity to you was low, over a full orbit, that can mean many kms of separation, and that can be just enough to miss an encounter.... It's hard to tell what happened to them, but if you have debris enabled, they should still be there, on an eccentric Kerbin orbit somewhere. Cheers

I just tweaked the color gradient for the over-the-surface part of the atmosphere. But, that made it possible to increase the intensity of the effect, so by the time the atmospheric 'aura' becomes invisible, there is a lot more visible atmosphere over the planet itself, so the transition looks quite a bit nicer. I also tweaked the atmospheric haze colour into a slightly bluish tint, so it looks better from the surface as well. Cheers

The easiest way to check in which scene you are in is to ask the HighLogic class. It holds all such information. for instance: HighLogic.LoadedScene - returns a GameScenes enum value for the scene you are in. HighLogic.LoadedSceneIsEditor : bool (true in the VAB and SPH scenes) HighLogic.LoadedSceneIsFlight : bool (true in the flight scene) HighLogic.LoadedSceneHasPlanetarium : bool (true in the flight scene and tracking station) Using those, you can set up a switch block or conditionals to do things based on the state of the game. It\'s much simpler than having to set up overrides for 30+ different callbacks. Cheers

Yeah, but we are going to gradually move all our part code into the new Module system, eventually deprecating the old part class extensions. The latest parts already use this new system. Namely, the telescopic ladders and the launch clamps, and more should follow soon. Cheers

That should be a string value actually (which, admittedly, is a char[]). It will be an empty string when you\'re landed on normal terrain, but it will have a few values on specific situations: If you\'re landed near KSC, it will read 'KSC'. If you\'re landed at the runway, it will read 'Runway'. and if you\'re landed at the launchpad, it will read 'Launchpad'. That value is used by persistence mostly, and gets saved in the SFS file as well. It\'s mostly used to detect the launchpad and runway being obstructed, and also to clear debris off the area around the space center. Cheers

Nice! Glad to hear it worked! Cheers

If you want to get coordinates relative to the 'universe', you can also use the Planetarium.up, Planetarium.right and Planetarium.forward unit vectors as a baseline. They define the coordinate system for the universal rotation. Cheers

I think I know what\'s happening with that Launch Clamp issue. It\'s not exactly a bug. I read somewhere the plugin extends the vessel pack/unpack range to somewhere around 9km... If that\'s the case, then what\'s happening is that you\'re getting a floating origin shift before the clamps can pack themselves. The clamps create a joint attaching them to worldspace, so they have to be packed before the floating origin shifts, otherwise they\'ll just spring back into position. You could try turning up the floating origin threshold from it\'s default (6km IIRC) to something higher than the packing threshold, to make sure the clamps go 'kinematic' before they\'re moved. (Mind that while the flight scene is running, the floating origin threshold is squared, so the threshold for 6km is 36,000,000) This is just off the top of my head, but it could work, without having to wait for a new release. Cheers

You know there are 10 kinds of people in the world... This is a tad late now, but I wanted to post a thread in celebration of reaching the 16th bit in the forum members count! The KSP Community is now over 32,768 strong! :w00t: So as always, a massive [glow=green,2,300]thank you[/glow] for everyone who downloaded and purchased the game, and here\'s to reaching that 17th bit soon! :thumbup: Cheers

We\'ve removed the old, bulky patcher from the releases now, since we\'re replacing it for the new one soonâ„¢. The Mac build is also larger because we\'re including the Mono Framework Runtime installer, which the new patcher needs (Unity only intalls version 2.0 of it, and we need at least version 2.8 ), so it\'s a bit larger, but hopefully in a convenient way. Cheers

I have to say, this is one of the best videos I\'ve seen yet. A most excellent choice of music indeed, and very nice camera work too. Great job there! :thumbup: Cheers

Hi, As promised, we\'ve now made the 0.16 release available as a full downloadable package at the KSP Store. You can download it after logging in with a paid account. This should solve all issues for those who were unable to patch their install from 15.2 to 16.0, and also fix several of the reported issues where some files appeared to be corrupted after a patch. (If you noticed any strange behaviour, please try a complete reinstall from the new releases) The Mac version also includes the Mono Framework Runtime 2.10 installer, which is required to run the soon-to-be-released update tool. You probably won\'t need it right now, as the new patcher isn\'t released yet, but it\'s good to have it in any case. Again, we apologize for the troubles from the first release, and hope everyone finds the new release worth the wait. Happy Launchings, The KSP Dev Team.