Spricigo

Arguable. But if you decided to crank up the difficulty then you should be prepared to deal with the consequences of your choice. In any case, the idea is the same: make sure you can afford the mission and go for it.

Do you want to explore the Mun? Then explore the Mun. Just make sure the mission will not bankrupt the space program* and go. *not that easy to run out of funds, mind you.

For this particular use I prefer to use Dmagic's EVA transfer. The advantages are: A nice UI, so you don't need to open the Kraken knows how many fuel tanks Only need the additional part on one ship, not both. Ships remains separated. No surprising phantom force.

Not sure how trajectories would help, seems more a work for Waypoint Manager.

este mod embute o modulo do mechjeb em todos os modulos de comando.

são mods diferente, somente o autor não quis manter post separados para cada um dos mods dele.(no caso do burn together, um mod 'adotado')

aposto que diz isso pra todos.

dependendo do que voce quer: permite você gravar a trajetoria de uma nava e depois "tocar'; se você quiser apenas que as naves pareçam estar juntas (por exemplo pra gravar um video) funciona perfeitamente. Mais no fim do post você encontra "BDAc Mod Familly" e no spoiler o mod Burn Toghether. Basicamente faz todas as naves no alcance seguirem os mesmos comandos. se você quiser realmente controlar todas aos mesmo tempo. E esse permite você gravar lançamentos e depois repeti-los 'fora de cena'.

welcome aboard. 1st thing to consider is that the game keep track of the contracts that you accept/decline/ignore/complete/fail and use it to sort what kind of contract is offered. You are more likely to get an offer for contract similar to what you accepted/completed and less likely to what you declined/failed. If you feel some kind of contract not worth the trouble just avoid it. Now to the actual issue: Practice, practice and practice.Precision landing is a skill to develop (like many other in KSP), with enough practice may become second nature. Instrumentation is fundamental, if you can grab some mods to provide more of that essential info about your craft your target (Kerbal Engineer , Waypoint Manager,...) and don't get distracted by the camera when you should be paying attention to your instrument. as in this exemple. The Navball shows you the craft correct orientation regardless of how the camera is set, looking for the camera is not only unnecessary but counterproductive. (well, except for the lack of radar altimeter which is only present in IVA in stock KSP).

My take is different, Stock could allow both methods. Choose when creating a new server.

unfortunately not only by squad. I hear it disturbingly often in my job as an Inspector (which often requires upsetting someone).

I'd like to remember what you said when people opposed DMP in another thread: conclusion: since you have no experience with competitive KSP multiplayer your arguments about it, accordingly your own words, are pointless. Personally, i consider that people can have good reasoning about something if good info is provided, even without direct experience. In any case, the last line of your post is correct, we are looking to it from different angles. From your perspective DMP allows for engaging gameplay, from me it don't offer a fraction of what is expected from a multiplayer game.

No, i will post before him. @Vanamonde

Yes, it's trim. Unfortunately control sheet I found is not clear about trim:

Orbiting is just falling and misisng the ground. We accomplish it by going sideway so fast that our fall don't keep up with the curvature of Earth Kerbin. We just don't do it at the surface level to avoid drag (collision with the ground is just a severe kind of drag) That define the first requirement for a good launch to orbit: using most of the energy to build up horizontal momentum (mass*velocity). The second requirement is to minimise what can reduce our momentum. IOW reduce gravity, drag and cosine loses.

If you are doing something because there is someone else in your save you are already interacting. But, yes there is a lot of space* to where you can flee from another player trying to catch you. But then you may have other vessels (stations, relays,..) that he can target. In any case, those discussion usually get stuck in how timewarp will work, so all those other issues are forever waiting for consideration. *pun attempted

IMHO a more important issue than how to control timewarp. Cross-posting from a different thread:

The intrinsic problem with the eternal discussion about "the timewarp issue" is that everyone get it wrong. Timewarp is not an issue, is a solution. The issue is that the gameworld is, literally, astronomical huge. As result a 'short trip' take hours while a 'long trip' take decades, and the game is all about travelling to different places. But than we add the option to accelerate time and the problem is solved. When we start to talk about multiplayer someone raise "the timewarp issue". Well, the multiplayer will have timewarp, problem solved. No one need to wait for years to do something. And them we need to face the warpcontrol issue. That is an issue without a totally satisfactory solution. Everyone agree to warp gives the power for a player to deny when others will warp. Warp cause desynchronisation gives the power for a player to deny the opportunity of others to interact with him. I feel that people that defend any of this solution miss an important point: players may have conflicting goals, their intent may be to compete instead of cooperate. In that case we need to ensure that the warpcontrol rule don't give anyone an unfair edge. Now, at that point most people either insist that their preferred rule is better or that neither can be applied. I think we need to get over it and realise that is better to have both system to chose between.

Avoiding a collision, or making it happen. If two kids are together in the sandbox, we should need to consider the possibility of they throwing sand at each other faces.

To meet is to be in the same position in the same time, nothing more. Matching trajectories is unnecessary. BTW: You didn't answer my question. (again)

The impasse remains: What immersion is lost by sharing SoI locations? Notice, that make evident the primordial divergence there. Your system is focused on gameplay (e.g. no one need to wait for others and if two people want to interact they just need to put themselves under the circumstance where it is allowed) however what I'm questioning is about the realism (e.g. two player can 'meet' and yet not be able to interact). Gameplay reasons will not address my (or anyone's else) concerns with realism. I may accept that your idea don't consider breaking the immersion a problem, however I can't accept your claim that no one is concerned about it. In either case is not the solution for everyone. Same when someone proposes "everyone warp at the same rate". I accept if he/she don't consider waiting for other player a problem, however I'll not accept someone claiming that no one will be annoyed for waiting.

And mine is that there is no real reason at all for player to not share the locations of SoIs. How do we solve that impasse? Seems that we need to agree to disagree.

Don't blame me for not understanding what you failed to explain. You dismissed any all all my concerns as "not important". You first stated that player interaction will only happen under a limited set of condition. Then claimed that it allow for virtually unlimited player interaction. If that is not contradictory enough: My impression is that you assume that all we want is a glorified shared save.

I still don't understand that halfpregnant concept. You want us to discuss your idea but don't want to take in consideration opposition to the idea. You say that those situations only happen 1% of time. That is enough for me not liking it. And should be enough to you recognize that your idea have an issue.

I read the whole post. Pointed contradictory statements. Please clarify.