surge

Infernal Robotics is still active and arguably, current (the 1.2.x version is unofficial, and requires small tweaks). I think the original thread creator went AWOL, so they don't have the rights to make the 1.2.x update buried in the thread official even though it was made by one of the creators. Or something like that. Reading through 70+ pages of the thread isn't easy. Here's one post that somewhat clarifies how to get the new version. So I'd like to see it here, if only because it makes it easier to find and check when they do make it official.

The word 'Inflammable' was officially removed from real dictionaries at about the same time Pluto was declassified as a planet. Both of them had been in use for, lets average it out to about 1000 years. Narcissistic rocket scientists keep making up new names for the same concept just because they can. Does that help? If it doesn't, I chose the least mathematically computative of them. I'm a computer scientist, not a rocket scientist, and I have very little idea or interest in what you're talking about. If you can improve it computationally, go ahead, this is copyright free software!

realism? duh.

1) parachutes have been deployable, but remain stowed until their settings determine since about 0.90 I believe. You can trigger them in space just fine. With the 1.0 physics the settings don't have the range to do this reliably though. 2) LKO is a stable orbit. Learn Newtons 1st law. Without kOS or RemoteTech, this is impossible. Even mechjeb cant do this. 3) The lowest tier you can get a kOS part is 4, not 3. The lowest tier you can get a non-commandable kerbal carrying container is 4, not 3. Unless youre counting from 0 for some reason, I suggest you fix this. 4) The guidlines for challenges suggest you propose your own effort as well. If you'd done this, you'd have seen all these problems. Just for fun, I did it anyway, with a launch weight of ~30t carrying 5 kerbals. Using a proper zero-lift turn and a tier 4 kOS unit and 2x tier 4 cabins, it wasn't difficult. I don't expect this to be included in the results.

As is standard for the switch from 32 bit to 64 bit that was done by everyone except intel several decades ago, there are 2 different versions of every library. You don't have the 32 bit version of libxcursor installed. As you're successfully running the 64 bit version of KSP ignore it. It looks like steam is trying to run the 32 bit version (because steam is a stupid pile of garbage, apparently), so just stick with what you're doing. ...unless you want to program X11 mouse games for old 32 bit 80486 machines for poor schools in India or something.

This prefs file in that directory could help to solve alot of problems linux users have, particularly with multiple monitor setups: To be precise, the file is: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/prefs Since unity is primarily a windows platform, they've thrown away the -geometry argument you normally get with any properly written X11 program. That means for most people with multi-monitor setups, they have to start KSP in a window, move it around to the correct position and then select fullscreen mode. This worked as a hack previously, but since 1.2, selecting fullscreen in game just maximises the window. If you run your 2d desktop as high as it can go (like I do), this causes 3d KSP to crawl to a snails pace as it tries to render over 6MB of data every frame on a display area that's constantly checking for occlusions. Unacceptable! The solution is in this file; you have to start the display area rendering the correct way, and don't let KSP try to change it. Unfortunately, none of this will work for those using xinerama, probably. Then again, if you are using xinerama, you clearly don't care about 3d framerate. For those with proprietry Screen setups (nvidia twinview, ATI equivalent, or multple graphics boards), this value determines on which monitor the game starts: <pref name="UnitySelectMonitor" type="int">1</pref> where: 0 = primary monitor 1 = secondary monitor I guess -1 would be a monitor "LeftOf" in xorg.conf? It could also be bus order related/random. i.e. 2. I don't have enough monitors to test this. Also in that file are geometries of the initial screen, and a fullscreen setting. If the initial window appears (always +0+0, unity ignores window manager hints completely) on a monitor that has a smaller display size than what is set here, it will be forced into windowed mode. If the monitor it starts on can't switch to the resolution in this file, it will be forced into windowed mode. Both are bad. Therefore, if you want proper fullscreen with a realistic resolution, you have to make sure the fullscreen setting is on here AND in KSP's settings.cfg, AND the unity prefs geometry is set to something the monitor it will appear on can handle. I'm not sure yet if what KSP's idea of what resolution you want has to be the same in settings.cfg. It may just accept what unity gave it. However, non-Ubuntu proficient users will be able to create start scripts to force these values to be acceptable as needed. As an example, I use something like this (by simply overwriting the unity prefs file):

It's fairly self-explanatory. According to textbooks, the 'apse line' is the line between periapsis and apoapsis. If you don't understand what's happening, I guess this maneuvre isn't for you!

Congrats. You made a thing that looks like a helicopter. How many billions of sas units does it need.

Are we there yet, dad? These will tell you how long it takes to get to another point in your orbit. It could be modified to determine time of flight between random points in the orbit. I'll leave that as an exercise, or maybe present it later if the personal need arises. Tip: The hard part about that, is that you can't get true anomaly from the other angles/"anomalys" easily, so you have to calculate the first point another way.

The hardest thing about helicopters is building a bearing. Ive never heard of 1/2 of the mods you mention, but Infernal Robotics is the only one I know of that has one. You can build stock bearings, but they are far too fragile to withstand the forces a real helicopter rotor hub needs. That is why all attempts so far have been essentially just 'things that whirl fixed blades around' like the early helicopters humans used to try to make. They used to be nicknamed whirlybirds, unsurprisingly, and all crashed spectacularly until Igor Sikorsky decided to incorporate a swashplate with a tail rotor. Unfortunately, no one can describe how a swashplate works. You just have to see it. Thus, the key to stable helicopters is the ability to change the angle of attack as the blade rotates, and longditudinal blade flex. Stock KSP doesnt have materials that are stiff in one direction but sloppy in another like a rotor blade. Nor the ability to make bearings small enough required for them. Even if you used something like Tweakscale and IR to make the tiny blade bearings, the game doesnt calculate physics fast enough - the swashplates, if not the actuators would almost immediately be destroyed. Makes you think, doesn't it - these little green b.astards have figured out explosives well enough to take them to other worlds, yet they cant even figure out how to make a simple mechanical device.

Slapping a kOS unit (weighing 0.03t) on the side and using my launch ascent guidance script gave 52.22LF, 68.83OX for a 80.556kmx79.591km orbit. (No pictures, since google screwed up their photo website, sorry). Orbital mass was 2.879t. Boosters were set to 50%. Transition turn ended at 10km @ 45°. monopropellant used only for minor steering. I should have turned off the reaction wheels, but I forgot. Oh, and includes a 10° safety turn at launch. It could probably do better if I could be bothered fiddling more, or better yet, figure out how to calculate things like optimal transition turn angles, launch TWR (the script used ~1.3 by throttling the sustainer engine), etc. Feel free to disqualify for not being stock, but I'm hoping you figure out that stuff for me with the results of this challenge; sounds a bit like you know your maths

Here's a simplified version that just circularises.

After a lot of research on various orbital manuevres, I've managed to create a fairly simple bit of code that allows one to set both perigee and apogee in one burn. Most of the research I did showed that some people think this is impossible without complicated loops, and it's barely mentioned, if at all, in the textbooks I have access to, so I thought I'd share it here. Obviously, there are some conditions: 1) The requested orbit and the current orbit must cross. It will crash if not - it would be mathematically and physically impossible to do in 1 burn. 2) If the burn is not done at an apse, it will cause the apse line to rotate. Obviously there are more fuel efficient ways to do this, however it can be useful for minor correction burns or when time is of the essence (perhaps you're about to crash into a planet!). Probably the most important advantage is that it can be done anywhere in the orbit (depending on how much fuel you can spare), so no more endlessly circularising and faffing about with those stupid "hohmann" burns. Yay! Anyway, on with the show:

I haven't tested it, but this probably also applies to contracts you've just accepted, but not completed, in which case the relevant section to remove is just "CONTRACT".

Mechjeb doesn't need any toolbar addon. I don't know where you read that. It can use one, but it's optional. Blizzy's toolbar mentioned by SpaceK531 hasn't properly been updated for the latest version of KSP. I recommend against using it, or any addon that requires it if you're just starting (although it does work). It was really only written because the old default KSP toolbar was so horrible, but Squad has fixed it now, so it's really only for people who have their game already set up that way.

It's a bit fiddly because it's badly "packaged", but GoSlash27 has made a "mod" that fixes some (most?) of the breakage RoverDude caused: (you just put the file in GameData/) It doesn't fix the sliding problem, but fixes most of the sloppy/useless traction behaviour. +1 for insensitive comments, this isn't beta software anymore. You have every right to complain.

For those who may have had the same problem, and are dissapointed and confused: I got a contract to test the TAC self-destruct part. "Hooray, more explosions!" I thought upon taking it, but after completing it, I noticed that the mod didn't work (it hasn't been updated for 1.1 yet), so I removed it. Upon reloading the game, I discovered I could not go to the tracking station, and most of the exit buttons stopped working. If this happens to you, fear not! You don't have to start your career again. Simply search the relevant persistant.sfs for the offending mod. You should find it in a section named "CONTRACT FINISHED". Remove that section, and you're good to go again. I don't know if this is specific to TAC self-destruct, but I doubt it - it looks like the game gets confused about a missing part in the contracts, and throws a hissy fit.

I did a quick google before I wrote that, but was blindsided by american propaganda. If you have the time, it's not hard to find. Basically, find any rocket launch that includes the whole thing, instead of cutting to commentators blathering like idiots when it's 1/2 way up Also, artistic license is used in the 'fairings' case; they help with aerodynamics obviously, but they are usually shed more quickly than most people imagine; basically, 5-20 seconds after booster ejection. I keep forgetting to arrange the stages so it does that, to my great annoyance.

The nasa shuttle, Soyuz and the chinese thing (HN1?) all do that on launch IRL. It basically means you're doing the launch most efficiently. Non-manned/kerballed rockets blatently abuse this and need heatshields... or as KSP calls them: fairings. Because they launch faster and at a lower flight path angle for even more efficiency, they don't have to care that some squishy, fragile human is onboard. You may have heard of maxq? that's mostly why they care about it (there are structural limits, but they are waaay more tolerant than the meatsacks sitting in them, usually).

Well here's the kOS autopilot to go with it:

For the googlers: since 'escaped' is mathematically just an elliptical orbit, to calculate KSP escape velocity is then: v = sqrt(BODY:MU *(2/r -1/(r +BODY:SOIRADIUS)/2)) +0.01. where r is BODY:RADIUS +SHIP:ALTITUDE (or whatever altitude you want to launch from) The 0.01 is not mathematically correct, but just to 'nudge' it over the line. Still working on figuring out the transit angle so I can figure out *when* to burn, but this is a start.

So I can't back up my creations here? Ok.

Sadly that is fiddly as hell, and there is no real answer. I have since changed the steerpid and am still fiddling with it: set steerpid to PIDLOOP(0.008, 0.0004, 0.02, -1, 1). // fast speed But the kOS docs are broken and wrong. The wiki page they used to point to is also useless in practice. The best way to tune them I've seen comes from super fancy R/C servo manuals: 1) set all values to 0. 2) slowly raise P until positive input is corrected by negative output and vice versa. 3) slowly raise D until you get a stable oscillation. Then halve it. 4) slowly raise I until it doesn't overcorrect. Then halve it too. The problem is firstly doing that takes phenominal amounts of time, and secondly PID controllers only really work for a specific range of inputs. If youre trying to steer a jet powered landspeed record Thrust-SSC replica, you'll need completely different values than for a cute little rover put-putting around at 10km/hr. I don't like it either, but thems the facts. I have in the past used variations of sin/cos() functions that essentially do the same thing, but don't account for long term errors. If you're desperate, learn some maths and try that. It's probably quicker and easier than CENSORED with pid controllers in the long run.

If you want ascent guidance try the following (xnode just does the maneuvre node). The key seems to be vectored thrust pitch-over angle/altitude at 0-lift start, not drag... you can make nearly any rocket get into space with this by adjusting that value. Some of my more 'pointy' rockets use poang as low as 50, but if you're trying to launch a draggy, horrible pile of junk, you may need as much as 85-80. And even then it probably wont get into orbit - it's just not possible.

So, this seems to be a place I can store my creations in case my disks die or something, right? If anyone else benefits from it, all the better! Questions are welcome... comments, complaints not so much. I'll start with a replica of a SU-27: Capable of "cobra maneuvre", has dinky missiles and bombs that dont work in recent versions because squad doesn't understand how pylons work, and have screwed up the fuel transfer. Requires tweakscale and kOS (the kOS part can be removed with no noticable effect) Made with 0.90, but updated in 1.1.3.