Stoney3K

If you exit Kerbin's SOI ahead of Kerbin (prograde in Kerbol orbit), Kerbin will catch up and you will get back into the planet's gravity, you only need a tiny burn at periapis to make it back into an elliptical orbit. "Higher is slower", so if your Kerbol apoapsis is just slightly higher than Kerbin's, you will end up back in Kerbin's SOI only a few days later.

I think he's programming his own mod which needs to determine the right moment to launch.

The more difficult way around this, which is a lot more work to set up but in the long run is a lot more flexible, is to use sockets. Basically you let your add-on expose a socket (TCP or UDP, or any other domain if you want) on the local host so other plugins can connect to it. The .NET TCPSocket class is quite easy to use so I would recommend trying it out. The big plus of this is that you can set your own message format and set permissions about what plugins can and cannot do on the interaction with your add-on, and even replace functionality without having to link anything. You could expose your plugin to the local network if you want (with certain restrictions) so even apps on other machines can connect to it. Big downside is that you need to design your add-on to have interaction in the first place, so it won't work with existing addons which may not have any communication in mind.

It is possible to make the jump beacons "independent" of the resource used if you run the module off an imaginary "ExoticMatter", "QuantumFoam", "TachyonSoup" or whatever resource you want and have a set of parts which generate that resource according to balancing rules. Pretty much a variant on the stock ISRU which can take Karborundum (efficient), Ore (stupendously expensive) or XenonGas (same as Ore) along with a penalty of ElectricCharge consumption dependent on the resource you feed it, and turn that into your beacon-jump-fairy-dust resource. Once your beacon jump fuel is full, it will allow the beacon to jump. This allows you to set a resource system based on balancing and economics you want, and even nerf or buff it by slapping on additional parts, or enable users to re-balance the system or use different resources altogether using a ModuleManager patch. It does make the mod integrate with any resource set out there without it being dependent on a single one, or require players to re-configure resources if they have little knowledge of code. In other words, players that want to play "out of the box" with the rest of the game being totally stock, that would be possible (but horrendously inefficient), but once more mods are installed which open up resources, it allows for more versatile gameplay. It also enables you to use the heat system using the stock ModuleResourceConverter which puts out heat when it's running. As long as the beacon is charging, it puts out a lot of heat, requiring cooling. More efficient resources (Karborundum) would charge the beacons rapidly without requiring a lot of EC per resource consumed and without putting out a crapton of heat, but abundant resources (Ore) would eat up a massive amount of EC to charge per unit resource and dump out heat at an enormous rate, requiring more radiators (which in turn eat up more EC to run). So that means running a beacon off a stock resource like Ore is a possibility, but it would be a very big undertaking to build and keep running. You could even consider adding crew requirements to charge the beacons off anything else than Karborundum, requiring something like a dozen scientists to keep a close eye on the very unstable process of generating exotic matter which can tear a hole in space-time.

That seems to point to the launch clamps as a possible smoking gun to this issue. Does the console message happen every time you enter the VAB/SPH (presumably because it tries to render a launch clamp in a certain context)?

Would that make it a Dawnpier? Or a Rapion? I really can't tell. I doubt this would be any use in stock. It may have some limited uses in stock, but in that case I would guess it becomes more along the lines of a mixed mode airbreather and arcjet with some VASIMR-like properties. Great for near future Firefly-esque roleplaying, but not much good for other things.

Well yeah, that actually. As well as flags, which may be useful as camera positions, but in a lot of situations you don't want to switch to inert objects like flags or debris. They have no way of interacting with the outside world, so what's the point? I can see the point in switching to 'debris' when it's a payload that is deliberately left in orbit so you can monitor the approach, but that's about it. Flags are useful as targetable waypoint markers, and perhaps as camera locations but as nothing else. Having a separate set of keys that *does* allow switching to flags or debris would be great, with the default only being controllable vessels.

The reason these devs left may be a lot simpler, if their contracts aren't renewed because they are not fluent in Spanish and became too expensive for SQUAD because they work abroad and not in Mexico.

Those AV-R8 winglets have way too much control authority to begin with. You can turn the control surfaces of those winglets off and control the rocket with the gimbals of your Mainsail only. SAS sometimes has trouble determining which control surface acts in which direction, that's why it frequently goes off course on planes. Either turn the control surfaces off or dedicate them to one axis of control only.

This one *is* less challenging than the real world because of nuke engines. Building a booster that can hurl a 100-Kerbal ship into orbit and get back on the ground is probably more difficult than the rest that is bolted on top.

The problem here is more the "Kill rotation" mode that SAS has (displayed by the two rotating arrows on the indicator light) which has a very nasty tendency to overcorrect or move your craft the wrong way. I think this behavior is caused by the way SAS works in 'Stability Assist' mode, which pretty much holds the current craft attitude and tries to zero angular velocity at all costs. Which is exactly what you don't want when you add a control input from the user. What happens is that the user deliberately rotates the craft to change attitude, which has little effect until SAS is saturated. The user then lets go of the stick, SAS senses an angular momentum and applies a control input the other way to try and kill that angular momentum -- which in turn causes overshoot and oscillations. The way it should work is that user input should not be added to the SAS control output, but it should change the SAS attitude setpoint when the user applies a control input. When no input is applied, SAS should just keep attitude at the current craft attitude as it does now.

Current space stations are not intended as "permanent" installations. They are intended to be disassembled and de-orbited into a decaying orbit once their life cycle is completed. Constructing really big stuff in orbit isn't really something that is on our spaceflight radar, but that is more due to economic reasons than it is because of technical challenges. Decoupler-like parts that can weld stuff together chemically are very feasible (and similar tech is used in fx. railway engineering) but Earth-based space programs have no use for them. Why would you want to permanently attach an American module to a Soyuz? Nuke engines are just as much estabilished tech (NERVA was built in the 60s and 70s) but these as well are simply unused because they have a very limited usage window. In the defense of ISS though, the Russian, European and American docking ports are somewhat stronger than the ones simulated in KSP There are two very solid arguments to make for a "weld-a-dock" style part in KSP: Increasing joint strength of the connected parts, and decreasing part count for performance reasons.

+1 for semi-permanent "welding" docking ports used for orbital construction. I always imagine these as a set of docking ports which are lined with thermite-explosive bolts, so the parts weld themselves solid when triggered, forming a single part similar to a small Structural Fuselage. I don't think the parts removing themselves is a good idea, it would mean that other parts in the station would have to move into the gap, which would collapse part of your station. The "welded" part should occupy the same space as two docked ports. Otherwise, construction planning and the order of assembly becomes a very tedious task, and parts in the tree vanishing into thin air may be a very good feed for Krakens.

Well, I can see the "no hatches means better seat to mass ratio" argument, but that would mean removing the hatches on either end as well. And as you said, there is no way a hatch would physically fit on the Mk1 crew cabin, let alone have any physical room for a Kerbal to get out. Wel, er, yeah, kind of like, this. No reason to play musical chairs with Kerbals if you want one of them to get out.

Would it even be possible to modify the Mk1 docking port to work as a hatch? I really don't know if it is possible to have a hatch collider that can move, so the hatch would be obstructed if the door is closed, and it would be available when the clam shell doors are open. The other side could then feature a single window and a seat which would hold 1 Kerbal for crew transfer, which you could imagine as the seat for the cabin attendant. It would also fix Kerbals always exiting at the top of the aircraft or dangling a few meters above the ground because there is no way to reach ground level when the plane is standing on its main gears.

Well, if you look at the part description for the Mk1 crew cabin, it says that it was "taken from a business jet". Those business jets usually have a clamshell swing-out door which looks similar to the Mk1 inline docking port: I feel that not having a hatch on the Mk1 crew cabin itself would be fair if there was a separate part that could provide an airlock or a door with stairs.

Well the reason for "omitting" a hatch on the Mk1 cabins is to make it more difficult for players to use it as a space-borne crew compartment, but it only turned out to serve as an inconvenience. Adding a hatch to any ship is as easy as just adding any part that has a hatch and can hold at least 1 Kerbal. Since that includes *all* of the command pods, the only scenario that is defeated is a rescue taxi which is controlled by a probe core instead of a manned ship. Usually players will unlock the crew cabin way before probe cores anyway, so the gameplay advantage of such a tactic is minimal. Also, it does not prevent players from sending a probe core with an empty pod up (and attaching crew cabins as required) so Kerbals can get in or out. The "design decision" for the Mk1 cabin becomes even more stoopid when you consider that it does have hatches -- on each end, where it attaches to other stuff. So if you can build a ship which has a Mk1 cabin with an open end, it actually has a hatch. There is a lot of room for improvement in the EVA/crew transfer logic. In theory, if there is an unobstructed hatch anywhere on the ship, Kerbals can get in or out of the entire ship and transfer to/from an available seat automatically. No need to pick hatches and seats for every individual Kerbal one by one.

What you're saying is you want the 'stability assist' in surface mode to keep true to your flight path, instead of to your attitude in a straight line (not taking in account the surface curvature)? Right now, SAS in surface mode will fly a straight line when you set it to Stability Assist, however, the ground underneath you isn't straight but it's curved. So if you want to keep a constant vertical speed, you'd need to keep pitching down to correct for that surface curvature. The effect isn't really that pronounced at low speeds, but if you're going really fast (approaching orbital speeds or even beyond that) you'd need to correct for it. I never understood the current SAS modes in the 'surface' and 'target' navball modes anyway. Most of the time they serve no purpose -- the only modes that are useful are prograde (forward) and retrograde (reverse). Normal and radial (left, right, up, down) modes make no sense when flying across the surface because they will cause you to chase your own flight vector perpendicular to your flight path, which is a good way to start flying in circles. More sensible, context-sensitive SAS modes would be a good idea. Stab assist, Maneuver, Pro/Retro and Target modes would still make sense, but for example, in Surface mode, a 'Wings Level' mode would be useful to keep flying straight, just as much as a 'Zero vertical speed' (prograde vector on the horizon) would let you maintain altitude easily regardless of speed or heading changes. For 'Target' modes, a mode to align the ship's nose with the target's orientation would be very useful for docking. A 'Track' mode could project a vector which would send the ship straight for the target when thrust is applied, if the player is in the ideal position for a Hohmann transfer, this 'Track' vector would coincide with prograde.

And split them up into segments of 60 each, which in turn make up 60 sub-segments, and each of these 60 major segments are grouped into "bigger" segments of 6... I hope you get what I'm trying to say here. 'Time points' are meaningless if time itself holds no value in the game. Rocket construction and research is instant, while most missions take years to expire, and the only thing that makes time (remotely) relevant is transfer windows and transit times. You could make time more important by adding a KCT-style mechanic and let rocket construction and research take up time. For example, when a player hits the 'launch' button in the VAB they get the option of warping through the time that it takes to construct the rocket, or to leave the VAB to do other things and construct the rocket on the pad, leaving the pad occupied and unusable for launches. If the player has no other missions to attend to, warping may be a good choice, but if that takes too long and a mission expires or a transfer window is missed in the meantime, you have two options: Build the rocket and tend to your other missions, or build a smaller vehicle that can be completed in time. That could also encourage players to build small, compact rockets, and one can even put a bonus on re-using components that are stored in a stockpile, which would take less time to prepare for launch than building a rocket from scratch.

Well, if you want an elegant solution, you can carry a KAS ground pylon and a Jr. docking port down to the ground and secure it to Gilly. If there is any ship that wants to land and stay on the ground, it can just dock with the docking port which keeps it attached to the ground.

KIS does have ground anchors and harpoons (like Philae) which you can connect to a winch to tether yourself to the ground. I'm not sure if the KIS ground pylons or ground bases actually attach to the ground, or that they're just really heavy blocks of concrete which are held down by gravity. In the latter case they're less useful on low gravity bodies like Minmus or Gilly.

Sounds like it's worth the effort to hack KSPSerialIO to work with sending/receiving of UDP packets, so you can use Arduinos with Ethernet modules. Ever since those became really cheep, I moved away from serial I/O because it can be quite error-prone when not done right.

Again, same "problem": The infrastructure from the rocket engine (which is going to be detached) towards the crew capsule is going to be too complex and too expensive. Remember, adding a lot of meters of copper cable means adding a lot of mass that you're going to discard when the first stage is jettisoned. Basically just adding dead weight when you really don't want it. Crew capsules usually have batteries or fuel cells and solar arrays to power themselves. The Space Shuttle is the only spacecraft that has turbomachinery to power alternators -- it has three APUs that are basically turbines powered from RCS nozzles (aside from fuel cells). These are used to power the hydraulics and provide back-up power from launch.

Which is kind of ridiculous if you think of it, because such a tailcone would immediately be incinerated by the engine exhaust. In real life, the reduced drag is caused by the laminar flow of exhaust coming from the engine which pushes back the vortex behind the aicraft. It's this vortex (column of turbulent air) which creates drag, and when the engine is off, the vortex is directly behind the engine, but when the engine is running, the vortex is way further back which means it's not slowing down the aircraft anymore. Real aircraft only have tail cones in specific engine configurations which requires them for more laminar exhaust flow. In any case, it's something iffy involving the drag model used by stock KSP which makes the engine have less drag. I suspect the results would be different using FAR.

As far as jet engines go, I've had my most success with a Panther engine as a lifting engine coupled with a Wheesley on top set to reverse thrust. The trick here is that jet engines have a CoM which is actually in front (or above) their actual mount, so putting a jet engine vertically will move the CoM up and make the craft less stable. So sticking two jet engines on top of each other in line with the CoM will not move the CoM anywhere up or down. I usually map the 'Stage' action group to the Panther's dry/wet mode switch so you can get some additional upward thrust by tapping the space bar. Especially useful on takeoffs and landings and to sustain a certain altitude in hover.