Alshain

You are correct, the current demo version is still the version that this description was written for, so it is very much relevant. That said, despite being out of date, it still does what it needs to. @igor290506 An update probably wouldn't change very much. The key benefits from 1.0.2 and beyond are not going to be very noticeable to the average demo player. The aero is only slightly different which would make the biggest change, the parts won't be there, the part performance of Unity 5 doesn't matter with locked runway and launchpad. So realistically it's nearly what we have. Upgrading to 1.1.3 would probably make it worse than it is now, since landing gear is broken, and there is not really any point since in a few weeks 1.1.3 will likely be obsolete itself.

It may just be old. I vaguely remember something about the starting positions of the planets changing long ago, which of course would alter the days that launch windows appear. I haven't seen a calendar like that before, that is the first. If you want something more specific than the first tool you linked, AlexMoon's tool gives you a "porkchop plot" which allows you to hone in on specific departure dates as well as target trip Delta V. Once you have the departure date and ejection delta V, you can usually find an encounter. Just create a node, expand it out till the dV next to the navball reads the same as the ejection dV and then move the node around Kerbin till it looks like your trajectory makes a pass with your destination's orbit. After that set the planet as a target and fish around a little for an encounter. That works for everything except Moho and Eeloo (whose inclinations and/or low gravity make it much more complicated) ... maybe Dres but I've never had a problem finding a Dres encounter. Yes. The first link is valid.

It is pretty old news, but still funny none the less. There is a museum there now, so in the end it educates people about our space programs and that is always a good thing. http://www.space.com/21092-skylab-space-station-debris-photos.html

That is an incredibly bad calendar. I don't think half those launch windows exist. Out of the first 5, Eeloo was the only correct one.

If you are talking about the LDEF, the whole point of that was long term and it stored MANY experiments. That might actually be a way to fix it. Make it accumulate more science the longer it is in space (with a cap), but make it so Kerbals can not remove it at all and it can not be transmitted (i.e. you have to recover the module). Also make it so that it can only be continued in one situation, so once you start it in orbit of a planet, you can only continue to accumulate science in orbit of that planet unless you reset it and lose the science. That would be a very good way to fix it in fact, it makes it worthwhile to send it without making it too overpowered since you have to let it sit for a long time and you have to bring it back (which was actually a problem for LDEF after Challenger exploded). Of course science gain around Kerbin would be minimal compared to like Jool (typical of current science).

I don't think "following" is working anyway. Just recently (after July 25th) I "followed" the Daily Kerbal forum and I don't get any notifications at all when a new thread is posted there.

I don't think this forum software stores BBCode like the better ones do. It converts it to some native proprietary and saves it that way. As far as removing spoilers, you will have to copy and paste.

This is going to end well. /GrabsPopcorn

I think you missed the point of the people asking for mods to be stock. They don't expect it to be verbatim in most cases.

Well I expect changes of that nature, but the UI is so little of KER's code. Things in SPP and Fine Print were changed to make it fit. A lot of the code in KER is in fact better than stock. Take the burn time calculation for example.

I don't find it worth the science to even use it. It's not cost effective to send it anywhere outside of the atmosphere and I don't need its science since the solar system has way more than you need... so I don't really use it at all. The size/mass and the fact it can only be used once are a perfect storm for making the part undesirable.

I can't remember them all but SpacePlane Plus and Fine Print were two. SPP did get a slight shape redesign, but otherwise the same. On the other hand, their Enhanced NavBall implementation sucks. That stupid blue arrow is not very helpful, and it doesn't help find the other points at all. The ISRU and fairings are more examples of 'copied' features that don't quite live up to the mod. I would agree and disagree. It depends on the mod, some of those mods are better written than KSP.

Historically speaking that hasn't been the case. The mods they added outright have been excellent for the game, while the features they added similar to mods have been pretty bad.

Here is an actual schematic of the SpaceX Fairing. Note the adapter.

I think what @tater is saying is the fairing base should not be visible once the fairing is attached/built. It's distracting in appearance. Part of that is simply the texture though. Most of the decouplers aren't much better.

Neither of those are very good points. The fact that the mod is having a few buggy issues is not an issue because Squad would repair such defects, not that they don't have their own, the stock fairings have had issues too. The support requests from people who don't understand something happens every stock feature and mod. That's how it goes. Again, that's not a good reason to avoid it. There are people that do not understand how the stock fairing system works. They just have to be educated.

Well, that was just one example though. Radially attaching a Xenon tank and keeping it aerodynamic would require another tank or something that does support radial attachment to attach it to. So it's not all black and white. However, I will say I was very happy when they added radial attachment to the OscarB.

I don't have an opinion on whether it should or shouldn't be changed. I can deal either way, so I don't really care on that, but don't fool yourself into thinking this is a Quality of Life change. There are challenges presented with being restricted on where and how you place parts, even if it's just the added mass of adding a Radial attachment point, you still have to deal with that mass. That makes it a gameplay change. Whether that gameplay is desirable is another matter, but it's still a gameplay change.

That is why Squad requires the source be published. If any one mod developer did something... unethical... a potential dozens of programmers are there to find it. It's not a perfect guard, but there are other ways people find problems like that too. Add them all together and it's pretty hard to get something by everyone. I feel like this conversation/education of MM and mod security is very important, but also completely dragged the original topic off onto a rabbit trail. Since @Red Iron Crown is here, maybe this conversation could be split?

I believe it can be done with module manager if someone would take the time to do it. When it was originally created, the tech tree required a separate mod to do it and thus it isn't in the right format. I'm considering picking it up when I have more time. There are new parts that would need to be added as well.

It applies patches dynamically as it loads. So basically it loads the part into RAM as a copy, then Module Manager tells the game to alter that part according to the scripts people make for it. But it only alters the active copy in RAM, it doesn't alter the saved file on the hard drive. So if you were to remove a particular patch and restart the game, it would revert back to stock. This is what it is telling you at the bottom of the load screen, how many patches it is applying to the parts dynamically. Some scripts alter more than one part, so that is actually informative for those of us who make MM patches. If you want an example of what MM can do, just click the second link in my signature. There are many patches there that range from simply ease of use changes to outright gameplay changes. These are the same kind of patches that other mods use, they just bundle them with their own creations as well. Most importantly, it is all script (i.e. text files outside of MM itself) and there is nothing that a text file can do to harm your computer. One other thing, the author/maintainer of MM just got hired by Squad so that should alleviate concerns as well.

Well here is a thought provoking idea... do we need a general discussion forum at all? I mean you are either discussing gameplay or development or mods or something that goes in one of the other forums. Arguably all of the threads that haven't been locked or move there could easily fit somewhere else. "What did you do in KSP today" is 1034 pages of Mission Reports.

I think it's been renamed enough. Probably the most effective solution would be to reorder the list so it appears in the middle or at the bottom so people actually have to read through the forum names to find it.

Does anybody else keep seeing this thread and initially think of Minecraft? If you do you probably have written a Minecraft mod or two

ModuleManager is a library and API used by other mods so that they don't have to each maintain a set of code that essentially does the same thing. It kinda works like this. Squad releases a new KSP version, it breaks something. Sarbian releases a new ModuleManager version, all mods depending on it now work again (assuming no other issues in their unique code). Without the common library, each mod developer would have to fix the problem on their own. So dozens of programmers using their time to fix one bug instead of one programmer fixing the bug and everybody else reaping the benefit. You may not know it but you have hundreds of thousands of these code libraries on your computer. Unless you suspect it is malicious (which I can confirm MM is not) or badly programmed with inefficient code (which I can confirm MM is not) then there is no cause for alarm. You are actually more likely to end up with more efficient code with libraries than without, again back to multiple developers developing the same task in their own way, at least one of them is going to do a bad job of it.