Dunbaratu

That's what's so weird. I mean this is like one of the very first things anyone tries to do in a career game once they get their first ability to make an orbit.

They appear to have mass in the VAB. When adding them to a vessel they do make the engineer readout increase the mass. Not sure why they behave so screwy in practice though.

Even when that very large very light thing is a heat shield? That defeats the entire point of having a heat shield when adding just a heat shield alone (even without the science jr module) causes you to flip over nose first. Read the thread.

What picture?

I guess until this gets fixed, we end up having to say that science Jr's are not recoverable from space. They have to become transmit-only science parts.

The problem occurs even with the mildest possible de-orbit - going from a 72km circular kerbin orbit, to dipping the periapsis down to 38km. I'm guessing they changed the mass of things so that the science Jr is no longer moving the center of mass far enough down, and so the described arrangement ends up being topheavy when it wasn't before.

Really? Wouldn't a chute deployment just instantly rip apart in the heat? - - - Updated - - - I'm surprised this didn't show up during all that experimentals testing. I mean - it's obvious the very FIRST time you try to de-orbit.

KSP 0.9 DRE mod's heat shielding: As long as you don't make your return capsule too tall, the areodynamics will naturally keep your heat shield pointed forward, in both stock and FAR areo models. KSP 1.0's heat shielding: Your return capsule wants to flip nose-first and requires powerful torque to keep the heat sheild in front. I just lost Valentina to this effect - the torque of a single capsule wasn't strong enough to keep a vessel composed of capsule, science jr module, and heat shield, pointed butt-first on re-entry.

It's not a 'bug' I saw mentioned in the list of KSP 1.0 things, but I'm happy it's been fixed. If you go to the Administration building you see the strategies you can select no longer operate on the ridiculous ratio of about 10 funds per science point or 10 funds per reputation point. That ratio made the admin building an underpowered waste if you wanted to convert something INTO funds, and overpowered if you wanted to convert something FROM funds. Now they seem to understand that Funds operate on a different scale than the other two. A single Fund point is really only worth about 1/1000th of a science point, and they seem to have changed the scales of the strategies accordingly.

Thanks for the help. I just realized that if KSP 1.0 is as close as they claim, I may just abandon this career anyway and start a new one when it comes out, making the whole thing moot.

I accidentally began the "Remote satellite network around Kerbin" mission long before I had the tech to deal with it. (wimpy one-square solar panel, and wimpy batteries that can't keep the the satellites awake all through the dark side of the planet, so the shake-out tests never stay up long enough.) So I figured that's my fault and I'll take the hit for cancelling the mission, and I'll come back to it later in the tech tree. But it never shows up in the mission list again. Once cancelled it never comes back. What do I have to edit in the files to force it to respawn the mission?

// initialize a list: set foo to list(10,15,20,"hello",BODY:kerbin). // just to prove the lists can be heterogeneous. // access with subscripts: set idx to 2. print foo[idx]. The markup syntax looks like it got a bit borked, but the examples showing it are here: http://ksp-kos.github.io/KOS_DOC/structures/misc/list.html#constructing-a-list

No. That's a massively complex calculation. It's just telling you what KSP's orbit prediction line shows on-screen.

I generally despise the common meme that everything should be coded to the least skilled programmer that might come across it. That attitude is a race to the bottom, and its the reason modern languages don't let us have nice things anymore. (like proper switch statements with correct case fall-throughs). However, there is a second reason that the example code snippet is poor practice. It's got nothing to do with the skill involved in understanding it. It's because it's dependent on presuming to know the exact underlying hardware implementation of the double float. Sure, that solution will work *IF* you are guaranteed to know exactly which IEEE floating-point standard is in use for that implementation, and thus exactly which bits are stored where, how many bits are mantissa, how many are exponent, etc. That sort of hardware-locked thinking only belongs in very tight narrow applications where you really *are* guaranteed to know the hardware involved forever and ever for the future life of the software - certain integrated burned-in software for example.

I just messaged erendrake about it - he says it's probably because they moved the repository to a new shared location, and in so doing forgot to alter the CKAN data file to reflect the change. EDIT: It seems to be fixed now. It's now finding version 0.20.

For some reason CKAN is still claiming the most recent version of Infernal Robotics is still 0.19.3. To download this I have to do so manually from the site.

To install..... or wait for 1.0 first..... such hard choices.

I hadn't realized I left the title unchanged. - - - Updated - - - @ drtedastro : Okay just to be certain I made sure to push the version I'd been using privately to github, and made a release zip of the version compiled against KSP 0.9. It should be usable for you.

uhm... it does work in 0.90 - at least as well as it never did in the past. Meaning - you can shoot the laser at terrain and it works fine, but to shoot it at parts of vessels it randomly shoots right through them half the time. I fought and fought and fought and could not get it to fix that problem. It has something to do with the timings of when the game engine moves the pieces "in its head" before showing the move - sometimes it has moved some but not all the parts of the ship to the XYZ coords they'll have next time, at the moment the laser does its raycast calculation. Most of the advice on how to fix it from Unity programmers didn't understand that as a mod writer, I'm not in a position to get to decide when the ship parts get moved. That's in SQUAD's control and I can't do anything about it. (Most of the advice was about how to sync up when my laser part moves versus when the rest of the objects move - which I have zero control over.) Some advice said raycast belongs in physics update, other advice says no it belongs in normal update (where animation frames happen). I've tried both. No help. It slightly changes WHEN the problem occurs, but not WHETHER it occurs. What I really need to fix it, I think, is a callback that I can be guaranteed Unity will only call *in between* all the objects trying to move themselves to their new positions, not something that gets called intermingled *during* all the callbacks when all the other objects in the game are choosing to move themselves. If some objects are moving themselves during fixedupdate, and others are moving themselves during update (which seems to be the case as far as I can tell), then neither putting the check in update NOR in fixedupdate will actually work. I need it called *between* updates, while every object in the universe is now frozen at whatever state it was in the last time all the positioning settled down and got synced up - at least that's what I *think* is wrong. I don't know of a callback that does that. There seems to be one that gets called just after all the other updates, called lateupdate, but I think what I need is a similar one called latefixedupdate, but that doesn't seem to exist. At any rate trying again and again to just randomly guess what the heck unity and KSP were doing, without the ability to find out or run a debugger and therefore only getting info from debug dump printouts (which, since it's a timing issue I can't tell if they're changing the behaviour merely by existing in the first place), I sort of gave up for a while. The code is currently in a bit of a messy state because of all my abortive attempts to try different things to get evidence on what was going on. It doesn't currently look much like my original design, or how I'd prefer it to look. I started doing some really wonky things with it that probably are utterly irrelevant to the problem - like trying to remember a previous result from the last update and buffer it to spit out if asked the value, and catch when the value suddenly gets a lot bigger , and demanding that it must stay bigger for several updates before the code will "believe" it. (I was trying to "fix" it by saying as long as at least ONE raycast got a hit recently, it will use that instead of the intermittent misses. That reduced the likelyhood of the problem but it still cropped up - it wasn't a real solution and it just left the code all cluttered with nonsense.) I think the real solution is to figure out when the heck I can trigger the callback where it reliably won't be happening in the midst of the parts moving. If you want to take a stab at fixing it, go right ahead. I may come back to it after KSP 1.0 is out, just to see if it got any easier to deal with. The primary reason I left it was that I also work on kOS, and LaserDist was sucking all my time away from things in kOS that I actually knew how implement properly without having to guess randomly with trial and error. I figured working on kOS was a better use of my time than sinking hours into a project with nothing to show for it.

Try it again after erendrake makes a patch release. I suspect it might be the out-of-dateness of the ZIP mentioned earlier. We'll see. I'm not on my kerbal computer at the moment so I can't test anything.

Hmm. here's a possible workaround - make it take a single argument which is a list of 2 things. THe list's contents get effectively passed by reference, sort of, that way. so you make it called like so: swap( list( ap, pe ) ). EDIT: I just discovered from a new github issue that apparently the version of the DLL that was released doesn't have the LIST() that takes arguments in it. It is working in the develop source code repository's version so the one that was published must be a day out of date or so from the development one. (The LIST() with arguments was the very last thing changed in the code before we froze.) We'll have to see if we can get erendrake to update the ZIP file that's on the various sites.

Outside of KSP, use any text editor like notepad, to write files that end in *.ks into the folder Ships/Scripts that's under your Kerbal Space Program folder. (The folder is outside of GameData because it's your content you created, not the mod's content the devs created). When you do that, those files can be seen in the game as your "archive" folder, as in SWITCH TO ARCHIVE. or SWITCH TO 0. ('0' and 'archive' mean the same thing).

The vessel:heading suffix is telling your your heading to travel at to get TO the vessel in question. It's meant for helping you aim toward a target vessel. Watch this space. When 0.17.0 is released, there will be a fledgling user functions library link that has a function to get your compass heading using entirely user-land code. - - - Updated - - - I don't know realfuels. Is it like stock in that there's two types of fuel you have to burn in unison (i.e. like liquidfuel and oxidizer). If so it could be the very same problem, and it's really a "bug" in main KSP rather than in kOS (although not really a bug, just the way you'd naturally expect it to work). When people get the remaining drop of liquidfuel that won't go all the way to zero, it's usually because the oxidizer HAS gone all the way to zero and the engine cannot burn that last bit of liquidfuel without the associated oxidizer to go with it. Think of it as a slight measurement error where the engineering cannot possibly be precise enough to get the amount of the two types of fuel to match each other *exactly* and burn down *exactly* at the same time. In actuality it's accumulated floating point error from subtracting tiny amounts of fuel repeatedly in very tiny time slices 25 times per second. That can become just off enough that the two fuels don't hit zero together. While you could call that a computer error, I figure it actually makes perfect real-world sense. You're never going to have a system engineered so precisely that it gets the two fuel types to run to zero at the same time, to within a factor of a fraction of a gram of fuel. In general, if you're trying to test for running out of fuel, and you're using a bi-fuel system like liquidfuel plus oxidizer, then always build your check so it checks if *either one or the other* has become zero, not just one of them.

This line of the requirements of use, in the first post of the thread: > Ensure you're in the list of users below (#4) before releasing your mod Links to a post that was last edited on September 1st, 2014. Technically if that rule was being followed to the letter, nobody who has added KAE to their mod after 1 September would be allowed to release, because their mod's name wouldn't be in a list that was last updated then. Can the first post be edited to refer to a newer list? I'm sure the newer list must exist and the first post is just linking to stale information.

https://github.com/KSP-KOS/KOS/issues/713 It was an accidental omission, corrected in the developer's branch a few days ago, but waiting to get released when the rest of 0.17.0 gets released.