Spricigo

That is exactly what the paradoxes is. Since player1 did something in the future (in this case the simple fact of be at that time) player2 is affected.

"save/craft sharing is multiplayer" </sarcam> The problem with "future development endeavor" is that future has no end.

Of course it can be done without paradoxes when everyone warp at the same rate. This is a sacrifice of gameplay for realism reason. We may instead have a system with paradoxes, a sacrifice of realism for gameplay reasons.

Moot point, disturbing the bug smashers is necessary to get the info since the bug smashers are the ones that know about how the bug smashing is going. Also notice: I didn't said the info shouldn't or couldn't be relayed from devs to players. Just that may not be the best use of devs time.

As you point out in that system everyone always stay in the same time, that includes 'at the editor'. So, that's not really an issue. The issue in that system may be players not agreeing on when and/or how fast to warp.

Mind you, using a cluster of five mainsails to launch a 3 crew mission to the Mun is like using a sledgehammer to smash a fly. Only go that way if looks is more important than performance.

Just copy the entire [Kerbal Space Program] folder to a different location.

The problem is that Squad is not supporting pre-historic versions anymore. As a result they have no motive to have it available for players. There's a good chance that what is on steam* (actual and "most recent stable" versions) is all you can get now. *or whatever shop you got the game.

Didn't matter if you agree with me. The issue is that the game don't agree with you. And, unlike me, the game will not give up if you refuse to acknowledge how aerodynamics works.

You have all that is necessary for an Apollo style Mun landing. For more specific help, more specific info is required. Try to elaborate more on your idea, tell us what details are important to be Apollo alike and what can be kerbalized.

No, we don't agree with this. And not even is important if we agree with this or not because we need to accept the fact regardless of if it meet or expectations. The drag is concentrated further ahead of where the mass is concentrated. This cause your craft to flip. In other word, the mass of your ship is not concentrated in the blunt end.

If the poll is to chose what version we suggest to start at then my vote is for 1.3.1 .

I see a misconception here. The fact that "part in front" is heavier than "part in rear" is not enough to ensure the craft will not flip. Fist because "portion of the craft in front of CoM" have exactly the same weight than "portion of the craft behind of CoM". The CoM is the pivot point. Second because how much drag a parr is causing have nothing to do with its mass.

What? Why are you saying that? NO. MY UNDERTANDING OF THE PROPOASAL DIDN'T CHANGED AT ALL!!! If you are not willing to accept we have different opinions about this subject them this conversation is a waste of our time. Bye.

Too much drag in the bottom part of the craft, specially the flat heatshield and the transition between the Hitchhiker and the Cabin. (open nodes cause huge amounts of drag in stock aerodynamics). I 'd ditch the Hitchhiker, use a bunch of Cabins in radial symmetry around the central core and protect the whole thing with a non-staged 2.5m fairing. (leaving a hatch out if that is necessary) BTW, CoL indicator don't tell you the whole story, you need to also consider the not-lift aerodynamic forces and (in the case of stock indicator) lift from non-wing parts.

nice spaceplane, @Brikoleur Any chance of a craft file?

No. Who will post next is @notmeagain

If your objective is to reduce mission cost, just keep in mind; parachutes (but regular and drogue) are a very effective way to reduces your speed in atmospheric flight. Packing the same amount of "breaking power" on engines or wings can be a lot more expensive. That said, you can either try to land your rocket like uncle Elon do, or make it a glider. Different ways, with different things to consider.

Why not? The planets SoI are objects within the Sun's SoI. Maybe a more important point: The Sun's SoI end where the planet SoI start. If the SoI limits are not the same for all the player, they are not all in the same SoI. Your proposal just change from don't agree about when is now' to don't agree about where is here. And we still have paradoxes. Bill and Alice dock their vessels...then they reach a SoI transition that is only there for Bill. ...? Why not. They are all in the same SoI. ...or not?

That don't avoid paradoxes. Breaking the simultaneity produces paradoxes. Ok, so how about we start by getting that well explained before we move to the exception? Bill is in kerbin SoI and want to go to Duna, while Alice is in Duna SoI and want to go to Kerbin. So for each one one does the usual procedures, and they leave each planet SoI at the same moment (gamer time). Problem is: their window don't happen at the same time, Alices want year 1, day 155, Bill wants year 1, day 255, They cannot share the Sun's timeline because they want to enter the Sun's SoI at different times. Nothing is so bad that can't be made worse... Charlie is in solar orbit the whole time, for he is year 1 day 55. Screw whatever plan Alice or Bill have, warp-to-window as much as you want and as soon as you enter Sun's Soi the planets will be out of alignment, since that is what is happening in that SoI timeline. Btw, Charlie is stubbornly refusing to warp time so the planets can reach the favourable alignment Alice and Bill want.

If there is an exception than is not exact the same thing. Specially when that exception is what is being questioned. How about Ike? And my bud's craft at same orbital heigh around duna? Will the accelerated ike smash my bud's craft or will my craft miss the planned encounter with Ike upon arrival? That is the issue. It breaks the simultaneity between movement of celestial bodies and movement of craft. That is not good. In that case, seems you forgot to present the general rule.

may interest you: In any case a good baseline to compare your proposal

Thank you for the explanation, Dark Lion. Got it now. Personally, never stumbled upon that one, probably a combination of building mostly small, with few part and with EditorExtensions.

Quoting what I think is the main point of your post. Notice, I'm just a player, Yes, that is a reasonable request. A few other lines are IMHO a bit too harsh, but that is understandable, with the frustration. In any case, i'd like to point that is a tricky situation for Squad*. The time explaining what they are doing to solve the issues, is time not solving the issues. And all those long explanation may backfire quickly in an eventual change of plans (not unlikely to be necessary). So, yes. A word or two about their progress is welcome, but maybe even better is squad* staying 'quiet' and solving the issues faster. *change it for BlitWorks or TakeTwo if you prefer. I'm talking about the people I expect are working hard to give us the graet game KSP deserve to be. BTW: again IMHO: Squad Vision for KSP on console is to offer the same experience computer gamer enjoy. Unfortunately there is still a good amount of work to make that vision in a reality, but Squad is committed to it.

Of course there is consequences: ore get mined, data get processed, contract deadlines approaches, transfer windows come and go, the position of your craft changes. Time need to pass for events to happens. Time warp exist because some events requires quite a long time to happen. The result is that the player don't need to wait for such events, but no event happens at a different time . If you take away the possibility to accelerate time the player is forced to wait for weeks, mouth or years. Bluntly put: if the player is forced to not play, he will not even bother to log in the game. A feature that cause that effect is a failure. if The conclusions for this argument are only applicable for that limited conditions. In any case the difference remains, it takes time to happens. In the same time other events will happen. If the crafts will meet instantaneous and nothing else changes that is a paradox. Even worse if the rendezvous would not happen under normal time flow (e.g. because the object you want to intercept is in a scape trajectory) yes,, that is what I said. A fortuitous consequence, like 100% recovery ratting is a fortuitous consequence of landing in the runaway. i suppose that is the idea. To pick the time that is better for you instead of waiting for years until it happen. But does change where you will land. Not, it don't change. Make the same maneuver with at the same position and the orbit will be the same. The difference is if you will land in the intended SoI or not. In that case is not a solution for the issue at hand. We need something that handles multiple bodies dynamics. Oh yes...is preserved...I just need to log back in a few mouths to do it. Ok, that is My plan. I have my ship in LKO ready to depart to Duna, my issue is that The transfer window is three months away( notice that is a timing problem). What I need to do? As you say, teleport don't help me at all. Why bother in implementing a game-breaking mechanics, that don't helps when needed? We already have other alternatives, while those have their own issue at least they work for all situations. Moot point. Waiting for the transfer window already takes months. Without time acceleration KSP become essentially doing nothing. No we don't need a different solution for this. We just teleport to the edge of the SoI, wait a moment for the transition to occur and teleport again to the next SoI edge or destination. What we need is a solution for the changes that are not happening because is not within our current SoI. I said it in my first answer to your idea: Those are not different warp situation. In all the cases something will happen in the future and the player want to go to the time when it will happen. 1st. Your idea, as you described, is not timewarp, is teleport. Under normal single player game is not possible to teleport. 2nd. Paradoxes. The idea make event that would happen simultaneous under the normal flow off time happen at different moment (and vice-versa). 3rd. The idea simple don't work in several situation. (In any case I want something happening outside my current SoI) 4th Is up to you to back up the proposal with convincing arguments that it is actually a good idea. So far you only tried to dismiss my arguments without addressing anything. From what you explained both sync to interact and agree to warp are IMHO more effective and less troublesome.