Crater

Working fine here, too.

Sorry to ask the obvious question, but did you definitely select "control from here" on the inline port?

Replying to this as it is at least the second person who has said something along these lines. If you read the first post, you will see that it is already released under GNU GPL 3. It has been for quite some time now, so there is no danger at all of the project being lost forever once KospY leaves (best of fortunes in the professional project that you're going to be focusing on, and thanks for the incredible work you've shared with us here).

Absolutely it is possible. If you look in GameData\Kethane\Resources\Kethane.cfg you will find the configuration for the generator, which specifies the max and min amounts per deposit, as well as the deposit count, with the ability to set defaults, and also to adjust them for each individual body in the system. You'll need to regenerate the Kethane deposits after you edit it, though (either start a new save, delete the node from your SFS file, or use the debug console to regenerate).

Well, if you upload the file to VirusTotal (www.virustotal.com) I'm afraid that 45 out of 45 antivirus apps would DISAGREE with you. You can find the results for the dll at https://www.virustotal.com/en/file/8ab6329a1db4c7de7535a0cd2835f2e4d2473d6aa160956c02b0e3dbefacb6d9/analysis/1377693486/ and the results for the entire zipfile at https://www.virustotal.com/en/file/c494a8af9665e0809c30329765cf92f9664621b8a6ccd78727482088d4a05136/analysis/1377693716/ , or you can upload it yourself if you like. So, if you do have a virus in your download, then either your ISP is operating a web cache that is infecting files that pass through it (which is unlikely, but technically possible), or you already have a virus on your PC, and it has spread itself into the kethane plugin. Even if you were correct that there was a virus in the file, your suggestion that Majiir had inserted it deliberately is based on nothing but your own..... I don't know, I just don't have the words.

So.... that 60 day transfer to Duna that you wanted to do........ oh, and your mid-course burn is going to be at 3:17am the Tuesday after next, make sure you set your alarm. If you don't allow timewarp at all, then even Minmus is too far away to seriously aim for, and the Mum would be more than most people would bother with. And if you set off for Eeloo right now, you'll be there for Christmas.... that's Christmas 2014. Timewarping at the lowest rate of any player is the only idea that holds up to any scrutiny. People who say you can use speed instead of time acceleration are displaying a fundamental failure to grasp orbital mechanics - if you set up an intercept with Jool, then tell your game that you are moving 10 times faster, you'll get there a LONG time before Jool does. But there are hosts of other issues - do you pause time if someone is in the VAB designing a craft? Or do you allow max time acceleration? If you allow time acceleration, what if they had maneuvers planned.... or what if they are putting together a rescue mission for either a craft that has life support, or is grazing the atmosphere, or tumbling slowly into the sun. And even then, what if you are trying to head to Jool, and the other player is setting up a Mun-base, or playing around on Laythe, and isn't warping more than a day or so at a time.... you could end up waiting real-time hours, days, weeks for your craft to get there. Don't get me wrong, I love that this is being developed, and the idea of multiplayer is a very interesting and popular one, but.... there is a reason that Squad isn't going anywhere near it, and nobody has ever seriously posited that the comms and interaction in realtime was unfeasible. But unless you have a solution to the timewarp issue, you have a problem.

As has been said above, the structure is fundamentally not stable. As for what would cause it to collapse... in ksp it would die of floating point maths precision errors, and in the real world it would suffer from n-body interactions that made it drift into its primary. We are not saying that it would suddenly collapse as you got to a certain length, just that you would be building a house of cards.

*grin* you time your launch so that you're in the right place at the right time, of course..... Seriously, though.... you should be in a pretty low orbit anyway to take advantage of the Oberth effect, so you shouldn't be looking at more than an hour plus or minus on the departure time, and that's only a fraction of a degree on the phase angle, which is easily correctable for with just a little delta-V. Mostly, you just have to go for whichever ejection point in your orbit seems closest to the correct phase angle. Don't forget that the calculator gives stats for a single point-in-time implusive burn at the exact moment. If you're using a nuke engine and pulling 1/4 of a g, you're looking at something close to 10 minutes of burn per 1000m/s of delta-V, which you will NEED to bracket across the ejection burn point, and some people choose to do starting an orbit or two early, and do the burn in stages at ejection point, then at PE each time on successive orbits, and the fact that you don't get to make an impulsive burn is going to add a lot more error than one orbit earlier or later on your ejection.

No, the correct UT will give you the correct phase angle (angle from Kerbin - Sun - Moho). The ejection angle is where in your orbit around Kerbin you are at the time of your burn. Getting that wrong can make hundreds or even thousands of m/s difference to your orbital velocity around the Sun, which means you will be way off course. It is the difference between accelerating prograde out of Kerbin's SOI and adding your Kerbin-relative orbital velocity to Kerbin's Sun-relative one, down to dropping out retrograde, and subtracting the same, along with all of the options in between that would include a radial component.

Uhhhh, in this case, I'm pretty sure that there is Intellectual Property in the mapsat code, as well as the base game, and that IP is still owned by Innsewerants. Otherwise, you could start to argue that Microsoft owned all the Excel addins out there, and given that some of the mathematical solver ones cost tens of thousands of dollars, I can't see them passing up a chance to take them over if the law supported it.

Did you just time it for exactly the UT specified, or did you adjust it to correct the ejection angle? (If the latter, I'd love to know how you worked it out, as I end up eyeballing them as often as not)

If you are out of power, RCS is offline, too - you always need power to the controlled craft in order to have any control whatsoever.

With stock ports, you definitely do NOT need power on the passive vessel in docking. In fact, you don't even need any sort of control pod or probe pod. You can dock to any piece of space-junk that has a docking port on it. (This very likely also applies to mod part docking ports as well)

As an open thread in Gameplay Questions and Tutorials at the moment shows, you can't re-enable a battery if your command pod has now power, since that is considered a control function, and you need power to have control.

You're describing a 1-man lander can with a docking port on it, or optionally two docking ports, top and bottom.

It looks like you disabled all the batteries (a million charge units in an OscarB battery? really?) that have any charge left in them. That means that you can't get any power to the control capsule (which has 0 charge left), and that means that you have no control of the ship - including the fact that you can't re-enable the disabled batteries. So yeah, you're screwed. Why did you disable all the (huge) batteries in the first place? Only non-cheat thing I can suggest is to take another craft up and dock it (or KAS connect in docking mode if you don't have a docking port), which will allow control over the merged craft, and allow you to reenable the batteries, undock, and carry on with your voyage. Other than that, quicksave, edit the quicksave file, add some charge back into the command pod, quickload, and use that to reenable the batteries.

To answer your original question about how many... if you used station-parts that were 100m long, which is huuuuuge in KSP terms, you would need in the region of fifty thousand launches. But, as has been said, the game engine has a maximum single-vessel size of about 2300m by default, so the physics engine would fail on the 24th. Also, ring-stations are gravitationally unstable. The maths isn't too hard, but essentially if you integrate around the surface of a ring (or sphere), the gravitational attraction from inside it sums to zero, which means that they cannot orbit anything that is inside them, and if there is any drift at all, it will continue. For more on this, read the Ringworld series by Larry Niven, they're great books.

Suggestions for people suffering a couple of problems.... MJ can't handle a launch without spinning out of control sideways within meters in spite of the control part being correctly aligned: Try deleting all of the craft-specific config files in KSP\GameData\MechJeb2\Plugins\PluginData\MechJeb2 - they're called mechjeb_settings_type_*.cfg and there is one for each craft you've flown. Sometimes they seem to have crap data in them, and the defaults work a lot better. MJ eats all your monoprop when docking / takes forever / fails / never aligns: The usual cause for this is that you are docking in a rotating frame of reference, which means that unless you align your target port along the normal +/- axis relative to its orbit, it will be rotating This is a function of the fact that it is following a curved path around the planet(oid), and that although you are following a parallel curved path, over the course of a single full orbit, you will have rotated through 360 degrees relative to one another. Aligning normal +/- means that the target port will only spin on it's axis, rather than crawling off around the side of the target vessel. If you try to dock with non-aligned port, with a larger vessel that can't flit around very rapidly on its RCS, then you will spend a disproportionate amount of time chasing the docking axis that is constantly moving away from you. Agile craft can still do it, but aligning the ports, or using higher orbits (which have longer periods and therefor lower rotation rates) will make life easier. The docking computer works fine, but if you give it a difficult job, it finds it difficult...

Only if you also go through making sure that all your parts use either spaces or tabs. Back on topic: To get around the stretched textures means no top/bottom caps.... would it be possible to use the fact that you can now have multiple MODEL {} nodes to have one for each end-cap and one for the center-tank, and only stretch the center one?

Guys, as Majiir pointed out, the data is not pre-existing, and is in fact CPU intensive to discover. The reason that mapsat scans and builds the map (and CSV) is to actually find the data and cache it for future use. It doesn't flag that you "know" this bit now, so you can use it, it really does scan the terrain and find its height for mapping purposes. This means that you can't just flag a hex as "known", unless you also perform the actual scans of that hex once you enter it. Someone suggested that a hex could be a full-screen map if you zoomed (which sounds good to me). That would mean something in the region of 1000px square, which is 1 million scan-point. Majiir quoted that in testing he has done, you can perform around 10,000 height queries in 200ms, which would mean that it would take a full 2 seconds to scan a single hex at that resolution. That would mean ZERO frames per second for a 2 second lag-spike, every time your sat entered a new hex. In principal, I love the idea, but that would be WAY too stuttery for me, and probably many others, which would mean that you're back to really scanning actual over-passed areas in each frame as your sat moves, rather than whole hexes, for smoothness of game. The same problem comes in if you enable non-focussed scanning. The issue isn't keeping all that data in memory, it is having 30 times more sats doing terrain queries in each frame than if you only have it for the focussed vessel. Either framerates would drop to nothing, or scan resolution would have to be terrible. You can't get anything for nothing.

The bad news is that when you install the mod, all your existing crews develop a sudden interest in breathing, eating, and drinking. The slightly better news is that, as it says in the OP Which means that once you install it, don't load any craft in flight until you're docking their first resupply vessel with them.... and resupply EVERYONE.

To sumarize the bug and the fix If more than one addon tries to use a "load once only" function from stock KSP, then only one of them will succeed. Majiir provided code that allows an addon to get equivalent functionality, if they use his code snipped instead of just the stock call. Basically, every addon needs to change their code to cope. You can only ever run one single addon that has not done so, attempting to use two or more will make only one of them work. You can, however mix and match as many addons as you like that have incorporated the fix, plus a single one that has not. So.... the fix inside Kethane stops conflicts with Kethane, but other mod authors are free to also use it.

Nope, KSPAddon is a way of running some of your code without having to have a part with a partmodule on the current active vessel. E.g. Seeing the kethane map from the tracking station. There was an issue where if you had several addons that did this (TAC Fuel balancer, modular fuels, Crew Maifest, MANY others) then there could be.... breakages depending on how they were coded to use the system. The fix was to help avoid the breakages. Nothing to do with other addons that use the Kethane Resource system. The API for that is clean and public and fine for other addons to use. The whole point is that others can use it without Majiir having to make changes in the Kethane addon. Edit : Ninja'ed by the OP

He means that making the fuel tank look taller or shorter is achieveable, but the glowing green blobs at the top and bottom of it (the attachment nodes) are in fixed locations, so a shortened tank will have a gap before the next part, and a stretched tank will end up overlapping the next part. Currently, I don't think any modder has found a way to adjust the locations of the attachment nodes within the game once it has loaded. i.e. unless Squad add some API calls to allow this, it may not be possible to do.

Yeah, which is why I sprinkled words like "about" throughout the post. I don't see that it would have helped to tell him that the payload could be up to 11.1111111% of the lifter mass, and I definitely mentioned that you could push it further. But if someone is asking what size a lifter needs to be in relation to the payload, then they are probably relatively new to the game, and are not likely to be building massively effective vehicles (no offence to the OP). 10:1 is a rule of thumb that helps to know that you are in about the right ball-park, and only depends on maths that almost anyone is capable of. It doesn't need a calculator, and doesn't give you multiple significant digits of precision for a perfect circularisation at exactly your target altitude just as the engines flame out from lack of fuel in your ascent stage.