Kermunist

A potentially easier to implement option, which would achieve the same end result, would be to set unbreakable joints and parts on for the first few seconds. Turn it off again just before the player takes control.

You can calculate the Schwarzchild radius for any object using r = 1.48x10^-27 x m Where m is the mass of the object in Kg, and 1.48x10^-27 is a short way of writing 0.00000000000000000000000000148. The mass of the cubic octagonal strut is given on the wiki as 1Kg, giving a Schwarzchild radius of substantially smaller than an atom. Much smaller even than the protons and neutrons which make up the nucleus of the atom. So small that if you put it next to an atom, it would look like an atom next to a small moon.

Here's some of the previous discussion. http://forum.kerbalspaceprogram.com/threads/64764-VASIMER-Engine http://forum.kerbalspaceprogram.com/threads/63269-VASAMR-thrusters http://forum.kerbalspaceprogram.com/threads/49214-New-technologies-you-think-should-be-added-to-the-game

Unfortunately you are correct with regards the tri-adapter. All parts are connected in a tree structure, which branches out from the first part you place (the 'root'), and no two branches can reconnect to make a loop. The one exception to this rule is struts, try placing very short struts linking the two parts which are not connecting the way you want. Assuming you are on PC, alt+L locks staging. Press it again to re-enable.

Well, to be totally honest I didn't look how long the thread had been running, and thought my suggestions might make it in before many mods adopted it. I would probably go for a blank version if it's not defined, as the assembly version is potentially misleading/confusing if it isn't the same as the version number the author uses when releasing the mod on the forum. Better blank than potentially wrong IMO. Hopefully it'll become a non-problem fairly quickly, as plugin authors who are early adopters of ComptatbilityChecker will probably also update it fairly quickly. I would probably avoid putting an 'expected KSP version' column or similar in. The reason being that the logic behind a plugin being incompatible is entirely up to the plugin and is unstructured. As it stands, a plugin author can flag up incompatibilities for any reason: KSP minor version; KSP build; another plugin version; operating system etc. The GUI should not structure something the code behind it does not, or it will get messy as people try to wedge unstructured information in. How about another field? Like this: One or more of your plugins have compatibility problems: +------------------------------------------------------------------------------+ | Plugin Version Problem Plugin Status | +------------------------------------------------------------------------------+ | Mod 0.1.6 Expects KSP 0.23 disabled [more] | | OtherMod 1.3.5 Expects KSP 0.23.1 disabled | | funMod 0.6 Needs Modulemanager some features disabled [more] | | cheatyMod 6.3.1 Only works on Linux trying to continue (bugs!) [more] | +------------------------------------------------------------------------------+ I also think that while it is good to make the code as versatile as possible, there is nothing wrong with writing clear guidelines on how it is to be used. For example (and this is an example of the type of guideline, not necessarily what they should be): Version Define a version number via the variable pluginVersion The version number should be the same as in the forums/spaceport, as it's primary purpose is making it easier for players to find upgrades. If no version number is available, this will be left blank Reasons If IsCompatible returns false, the variable failureReason should be set to explaining why. This should be a string of no more than 40 characters, for multiple or longer reasons, use the more button. Good examples of what to set this to are "Needs KSP 0.23" or "Needs ModuleManager".If not set, it will default to '???' Plugin Status If IsCompatible returns false, the variable pluginStatus should be set to explaining the actions taken as a result. This should be a string of no more than 40 characters, for multiple or longer explanations, use the more button. Good examples of what to set this to are "disabled" or "featureX disabled". It should not be left blank, if the mod isn't disabling any functionality, use "Attempting to continue" or similar. If not set, it will default to '???' More button If you #DEFINE USE_MORE_BUTTON then you must also define callbackMoreButton(). A button will appear next to your mod which will call callbackMoreButton() when clicked, this should open an additional dialog box. Clicking the button should not have any other side effects, to change the state of the plugin, use controls within the new dialog box. Good examples of how to use this are: Simple text boxes elaborating on failureReason or pluginStatus; A web update checker; A re-enable plugin button with disclaimers. If USE_MORE_BUTTON is not #DEFINED then no button will be shown. Finally, one other thing. I think text should refer to 'plugins' not 'mods'. Because: this method only works for mods with plugins; I think it is good to keep the distinction between parts packs and plugins in the minds of players; a disabled plugin will probably not remove parts, just make them inactive. Well. These are my ideas. I would define them as such, not feature requests as I don't do much mod writing. Feel free to use or ignore as you see fit. edit: On second thoughts, maybe using preprocessor directives isn't the best way to do the more button. I had though that it would be a neat way of avoiding compiler errors if callbackMoreButton is not defined, but that's more of a C++ tiny-microprocessor must-save-memory way of thinking, and some plugin authors might want to enable/disable the button at runtime in IsCompatible.

This all looks like a fairly good idea to me. Some suggestions: Require the mod using Compatability Checker to provide a version number for itself, and display that on the alert. This will make it clearer to the player what they currently have and hopefully make it a bit easier to find out if an update is available. It would also make it possible to check the version of other mods and disable the plugin if, for example, you need a newer version of modulemanager than is installed. Allow the mod to add a UI element (text or button) So the player has instant feedback as to what the mod did when it found incompatibilities. Most mods will either carry on regardless (and display some text saying "Possibly buggy") or disable themselves (and display "disabled"). Some may want to offer choice to the player, or provide more information than fits in the alert box, and a button opening a mod-specific dialogue box allow that. so the alert would look like: One or more of your mods are not compatible +----------------------------------------------+ | Mod 0.1.6 disabled | | OtherMod 1.3.5 disabled | | funMod 0.6 some features disabled | | cheatyMod 6.3.1 disabled [read more] | <--- read more is a button that pops up an extra dialog, handled by the mod | noisyMod 1.2.3b6 possibly buggy [disable] | <--- again, the button event is provided by the mod +----------------------------------------------+ IMO the first suggestion should be very easy to implement and would be quite useful to players. The second one would probably more work to do, so having suggested it I'll leave it to people who regularly write mods to comment on it's value.

It is a bit odd to watch. How about: 0) draw splash screen that obscures everything 1) set all joints unbreakable 2) Apply gravity/physics 3) wait ~1 sec for everything to settle 4) remove splash screen 5) set breakable joints That way, the dynamic shock of physics being applied won't break anything. If the rocket can't hold itself together under static gravity, it basically falls apart as soon as the player sees it.

I think this could be done fairly easily with a plugin. Roughly like this: On putting the craft on rails: 1) Check if there are any other satellites around the same parent body with a SMA of within 0.1% of this one 2) If so, set this one's SMA to be the same 3) Record the time at which it was put on rails Every so often (1 month?) or when taking a craft off rails: 1) Calculate the time since last flown 2) Subtract monoprop equal to time x mass x constant 3) If monoprop would be less than 0, set it to 0 give the craft a random small change to one of the orbital parameters. I don't really have time to code it up though.

Here's an example of the real-life track of an object that was captured by earth http://en.wikipedia.org/wiki/File:J002e3f_orbit.gif As you can see, the interactions with the moon result in a very non-KSP-like non-simple orbit, and after about 6 orbits it is ejected again. Any capture probably involves a reasonably close encounter with the moon or the upper atmosphere. Given the nature of orbits, if it has one such encounter, sooner or later it will have another, and at some point it will hit earth, or be ejected. It might hang around for a while, but it is very unlikely to ever enter a fully stable orbit.

If you bought KSP through the website before it was even available on steam, then you might be able to transfer it. When it first came out on steam, SQUAD made a way of doing it, and I don't think it was a limited time offer. You have to go into the KSP store and there's a button somewhere. Be aware that it transfers it, not shares it, and it's irreversible.

I imagine such a ting would look like this That is 8 re-entry vehicles from an american ICBM test, without warheads. (Though with fast moving objects, the camera catches them differently from the human eye. The naked eye would probably see downwards movement, not lines.)

Argh! You caught me. I realized it was wrong and edited it out within minutes, but I was too slow. I still maintain that the carpet is going to take more of a beating than the ceiling liner though (and the whole idea is patently ridiculous of course).

I wouldn't take my post too seriously. All the disadvantages I listed are in fact very understated (possibly that's a rather British sense of humor?), and the scheme is completely impossible for human sized objects: any attempt to implement it would be a deathtrap. That said, I don't think the ceiling is going to discharge into the crew that much. A strong insulating layer would prevent it, and the head charge is never going to be anywhere near as strong or as close to the roof as the feet charge is to the floor. It's going to have to be a very tough carpet. More problems: The electrostatic repulsion also applies to any other objects that are charged. Drop your pen? It's now shooting away at high speed. You can't have an uncharged pen, as it will get a charge when you touch it. The point you raise about keeping the charge distributed is a good one, and I was trying to hint at it in disadvantage 4. In the static case, the charge will redistribute towards the feet, so they will feel more 'gravity' than the rest of you. Probably most of your body will be in zero G, as most of the charge is in your feet. If you try and move, the charge redistributes. I haven't tried to work out if that would produce lethal currents, but vigorous waving of the left arm would probably be ill-advised. Corona discharge will slowly bleed off charge, it will collect on the floor (on the surface of the insulating carpet) and reduce the electric field. You will have to periodically move this back onto the crew/other objects you wish to have gravity. If you have an uncharged visitor, they will stick lightly to the floor or ceiling (van der waals force) until they touch someone, then the discharge will probably kill both of them. Also, diamagentic levitation is cool, but doesn't scale up very well either. I have never been able to levitate more than a few drops of water, and I am very glad I didn't have to pay the electricity bill for that.

Based on MilliKan's oil-drop experiment, I would like to suggest using electrostatics. Lets say we charge up our crew, and use an electric field between the floor and ceiling to keep them on the floor. With the potential difference between floor and ceiling at, say, 2MV,and they are 2m apart, we have 10^6V/m. We want the crew to experience 1g, which is about 10N/Kg, so using F=QE we only need 10uC of charge per kilo, or about 800uC per person. Advantages: The floor and ceiling are parallel plate capacitors, so the electric field (and thus 'gravity' strength) is the same everywhere, and at any height from the deck The charge spreads out across the person, so the 'gravity' acts on all parts of their body. Disadvantages: Moderate repulsive force between crew members*. Enough to keep your personal space anyway. Corona discharge from crew members will make them glow a bit. Especially pointy bits like fingers, toes, ears. Tears in the (insulating!) carpet, exposing the electrodes below, will instantly kill the unwary. Whilst this will work well for providing gravity to insulating objects, there may be some oddities as charge moves around conductive objects (such as crew members) *Force may in fact be of order 1g at 10 meters.

I work in a research lab, and this is very true. One of the workhorse bits of kit we have quite a few of is the Stanford Research Model 830 Lock-In Amplifier, most of them are not much younger than the ISS core modules. If one breaks, do you know what most of my colleagues would buy to replace it? Another 830. Similarly the General Radio 1616 bridge. General radio ceased to exist in about 2002, but that bridge has never been bettered. There's a lot of scientific equipment where the technology behind it is well understood, and can't be much improved upon. The newest kit is not necessarily better than the older one. Don't get me wrong, computers have revolutionized how we take, store and analyse big data sets, and digital storage oscilloscopes are very useful, but old kit is far from useless.

It can be a bit annoying. In the mean time, I suggest using x, shift-x and c to change the part placement mode without going back to he buttons.

A while ago someone had a go at building a computer (or at least a few gates) with mechanical motion and docking ports. http://forum.kerbalspaceprogram.com/threads/26868-KSP-computer-dev-team some exponential spatial growth with number of gates, so didn't get all that far. Cool though!

I think this might be related to the devs' intent to have just 'fuel tanks' into which you can place any type of fuel, though in that case the xenon tank is a bit of an outlier. That might not be too far away, as tweakables seem to be getting mentioned reasonably often these days.

Most of the manned capsules have a radar altimeter on the dashboard. You have to press C (or is it V? can't remember) to change to the cockpit view, then it looks like a dial with numbers around three quarters of the circumference. It starts reading at I think 3000m, with increasing accuracy as it gets lower.

Are you using any mods?

A good idea I think, but a better implementation might be to just apply a force in the upward direction to a single part the kerbal is closest to. Say 200N until the part reaches head height. That's a decent model of someone lifting something, and deals with the problem of turning over too-heavy rovers. It might need to be scaled down a bit for light rovers and low g worlds though. Even better would be a way of telling the kerbal to lift/push/pull an object in a selectable direction with a selectable force. Then they could right rovers, throw debris around, drag probes about etc. Not sure how to make a nice interface for that though.

Thanks for the update cybutek. I too am having the 'freezing' problem. To be more specific: In build engineer: When first placed, the display is correct. The buttons work. The display doesn't update when parts are added or removed. Removing and re-attaching the engineer part doesn't help. Leaving the VAB and coming back doesn't help. In Flight Engineer: The orbital and surface displays are correct. I didn't test rendezvous. The vessel display is correct on the pad, but doesn't update after that. The single-thread DLL fixes the problem for me.

The last time I looked the licence consisted of instructions not to redistribute and a slightly poor-taste joke about killing pirates, so I would hazard a guess on 'no'.

But for an elliptical orbit with periapsis close to the surface of the mun (which is probably what you want for landing) then your speed at periapsis is lower if your apoapsis is lower. I think that is what Kergereneku meant.

At the moment, KSP (like pretty much all programs) just asks the operating system for RAM as and when it needs it. The operating system is really good at looking after RAM, it is never going to decline a request when there is any way it can free up the RAM, and it's never going to offer RAM that's not needed. So there is nothing to gain by changing the total amount of ram allowed, best to just set the proposed drop-down menu to 'all the ram!' and leave it there. There is a limit though: KSP is a 32 bit program, that means it can only handle 3.5GB or so. It just can't keep track of more than that, so will never ask the operating system for it. That's why most of your RAM is going unused. The solution would be to change KSP to be a 64 bit program, but that's easier said than done. A quick search of the forum for "64 bit" will turn up tons of threads discussing it, but the short version is that KSP uses Unity, and Unity can't do 64 bit (on Windows anyway). So the Squad devs have to wait and hope the Unity devs fix the problem. I hear that a 64-bit KSP exists for Linux, if you want/are able to try that.