stabilize the physical shock during a mooring

[jojo5144]

if during a mooring. the two ships remained separated.

like two different ships, just stuck. able to exchange resources.

and put an option on the docking port to choose to merge the ships (in case of space station or other).

/edit: why not an engineer present (maybe even in eva) for the merger (Bill will come to connect all his)/

it may be possible to make moorings brief less violent (for the robotics part but also the rest).

I do not know if it's a good idea.

it will be so much cool for fuel exchange on the ground.

thank you for all your hard work @SQUAD and all the team

your game is more and more amazing

Edited June 3, 2019 by jojo5144

[Brownhair2]

I'm not sure what exactly merging ships would do that you can't already do. Docked ships can already drain resources from/provide resources for each other automatically, all controls (throttle, maneuvering, action groups, etc.) trigger for both ships, they're even labeled as a single craft.

The magnetism can be a little violent sometimes when you're docking, but it also makes things easier. Maybe docking ports could have a slider for magnet strength so that people can decide whether or not they need it.

[RealKerbal3x]

38 minutes ago, Brownhair2 said:

The magnetism can be a little violent sometimes when you're docking, but it also makes things easier. Maybe docking ports could have a slider for magnet strength so that people can decide whether or not they need it.

There's a mod for that! (I apologise )

But yes, a docking port magnetic strength slider would be grand in stock.

Edited June 3, 2019 by RealKerbal3x

[Loskene]

You do unintentionally raise a point here that for KSP there's no difference between docking (a loose connection for visiting spacecraft etc) and berthing (strongly connecting two docking ports together in a semi-permanent configuration, like ISS modules). Berthing is effectively what we already have in KSP as "docking", the two berthed vessels become one vessel and share everything until they are separated.

Why would this be at all important? Well it's not, but I'd still like it as a quality of life thing.

One major advantage I see of having both "dock" and "berth" options (maybe configurable on a per-port basis) is not having your action groups and staging all messed up and merged if you dock a ship to a station and each have overlapping functions. If a ship is only docked to a station then it should retain its own control point (switchable with the square brackets as if they were still separate craft) while allowing resource and crew transfer as if they were one craft the way it is now. Only berthed modules would actually become part of the station and respond to commands as the same vessel. This would mean if I'm controlling my space station with a ship docked to it, I no longer have to worry about manually shutting down the ship's engines in case I accidentally hit Z and send my whole station into a spin. It would also eliminate not knowing exactly what side you're controlling from when you click "undock" on a port. Small things, but it's the small things that cause big, if infrequent, headaches.

Is this worth its own suggestion thread?

[pandaman]

I like the idea a lot, but my guess is that it is not quite as easy to do well, from a coding perspective, as it may seem.

Hopefully I am wrong though.

[Loskene]

1 hour ago, pandaman said:

I like the idea a lot, but my guess is that it is not quite as easy to do well, from a coding perspective, as it may seem.

Hopefully I am wrong though.

This is said for every suggestion but I'm honestly struggling to think how it'd be the first thought this time, not claiming to be a developer but just based on what we know of existing KSP mechanics and using them in minimally-disruptive ways to achieve the desired effect.

Add a second button to docking ports (or a new part with 2 modes like an ISS universal adaptor: docking and berthing). "Berthing" mode behaves the same way all docking ports do now. Vessels are merged and all functions and resources are collapsed under a single command point. Advanced ports or universal adaptors can be switched between berth and dock mode, and if both sides of a connection are set to berthing configuration, they will join as modules of a larger construct like normal.

"Docking" mode (perhaps the only option on early-tech ports to mark and encourage a distinction between monolithic and modular spacecraft/stations) will be a new addition based on the same functions as existing docking ports, the only difference being while the magnetism stays on, the vessel merging never takes place. Docked vessels will be held in place with the same force as berthed modules for simplicity, but will remain as separate vessels as far as the display is concerned and can only be controlled by shifting to their perspective with the vessel switcher. Crossfeed can be enabled according to user preference and/or type of docking port and connection. You could simulate requiring fuel and power lines having to be run through open hatches, which is generally only done for berthed vessels or propellant-only docking ports, but I'll understand if that's not bothered with for gameplay's sake. For convenience sake an extra field could be added for the vessel mass (or other) display indicating the individual vessel and the total mass of all docked spacecraft, which would be handy even without these functions.

Pros:

-Eliminates the HUD clutter that's a hallmark of large space stations with many vessels docked, which makes the staging readout and action groups useless, eventually requiring every action to be done via hunting for part menus to click on constructs that can have many hundreds of tiny parts.

-Lets us quickly see and switch between every vessel docked to the same station, and be ready to launch using the ship's own action groups immediately.

-No more worries about accidentally activating a docked vessel's engines while trying to control your station, or getting into the paranoia-induced habit of disabling all visiting crafts' main engines after docking.

-Simplifies station and modular spacecraft construction with an easy way to delineate temporary or host vessels from the permanent construct, and stops resources being drained from payloads due to absent-mindedness.

Cons:

-Requires time from a programmer to modify the docking code appropriately, and possibly an artist/art technician to design and rig a new part for it.

-May cause conflicts with mods performing a similar function, necessitating they update or be replaced.

That's basically it far as I know. I'd file it under a QoL grab-bag feature they should get around to whenever it's one of those updates.

[pandaman]

6 hours ago, Loskene said:

^snip^

I'm not a programner either, but my thoughts about it being difficult were not so much about the gameplay/user interface aspect, which you addressed very well, but more about the under the hood coding to get it to work as intended.  It struck me as one of those 'It's easy, all they need to do is...' ideas that is actually much harder than it may seem.

Currently resources etc. transfer within a single vessel, two (or more) docked vessels become one vessel whilst docked, which enables easy transfers between them.  

The game does not currently allow transfers between different vessels, and I don' know whether it is a design decision or a coding limitation.  I suspect the latter, hence my concern that the 'difficulty' would be in the coding itself to reliably enable transfers between multiple different vessels. 

I could easily be wrong, but the fact that the vessels would need to be in contact (docked) I see more of a 'gameplay' design decision rather than a coding problem.  If the transfer between independent vessels issue could be solved then it opens the door to 'umbilical' transfers of fuel and electricity between nearby vessels too, so if it was that easy i suspect it would be done by now.

Hopefully I am proved wrong and it is in the next update 

[Gotmachine]

I like the idea, the forced merging of docked vessel is quite annoying.

But from a coding perspective it's really not easy to do because you can't have connected parts on different vessels, that's just impossible.
This basic fact takes away every stock behavior that is normally available for connected parts.

11 hours ago, Loskene said:

while the magnetism stays on, the vessel merging never takes place. Docked vessels will be held in place with the same force as berthed modules for simplicity

Keeping the vessels somehow attached together is much more complicated than it looks, and would require doing very hacky things.
When loaded, maybe this can be done using standard unity joints, but there are many potential kraken-level issues in doing that because KSP actively expect vessels to be independent entities.
And anyway those joint only exists when the vessel is loaded / not timewarping.
This mean a lot of position handling/correction when switching from/to loaded/packed/unloaded vessel because they will drift away from one another due to floating point precision issues and reference frame switching.
This would also make it incompatible with any mod that manipulate vessel coordinates/orientation
This will also mess up with the SAS, because the attached mass will be unaccounted for (I'm quite curious to see the outcome of 2 SAS fighting each other)

Resource transfer is less unknown territory (KAS and EVA transfer by Dmagic are doing it), but the UI side of it is quite a bit of work.
Crew transfer is probably the easiest feature to do.

Edit : actually, I think KAS is pretty much doing most the above but I don't think it is capable of rigid docking, and I'm not sure how well it behave for non-landed vessel.

Edited June 4, 2019 by Gotmachine

[Loskene]

I mean all I'm hearing there is "it would be really hard to do if you did it the hardest possible way"

Like just set up a condition to handle a second type of "docking" that catalogues and preserves the separation of resources and command orderings in a way that can be retrieved when updating UI, performing actions or undocking. You don't actually have to make them two separate vessels held by a new type of joint.

I understand the thinking guys, but it's usually people with no experience of development whatsoever that are the first to say "that's probably impossible"

Of course it's not impossible, few things are, it's only ever a question of whether the labour time outweighs the end value, and an assessment of that is something only one of the devs can give us. So thank you for trying but you really haven't added anything. Frankly calling something (especially something so trivial) "impossible" should come with a greater burden of proof than calling it possible or even easy, since it's by far the least likely outcome.

Edited June 4, 2019 by Loskene

[linuxgurugamer]

15 minutes ago, Loskene said:

docking" that catalogues and preserves the separation of resources and command orderings in a way that can be retrieved when updating UI, performing actions or undocking. You don't actually have to make them two separate vessels held by a new type of joint.

Speaking as a developer, modder, etc., I can tell you that it's not that simple.  You are talking about changing one of the fundamental characteristics  of the game.  At this point, it is probably not doable for a reasonable amount of effort.

[linuxgurugamer]

You do raise one point that I believe is fixable, and that is being able to preserve the action groups on vessels when they docked together. My thought is tht action groups can be associated with command pods, and when the command pod is the controlling pod, then the action groups associated with it would be active.

 Just some random thoughts while I'm out walking my dog, it may be easier it may be harder to do, but somebody might do it soon

[Loskene]

13 minutes ago, linuxgurugamer said:

You do raise one point that I believe is fixable, and that is being able to preserve the action groups on vessels when they docked together. My thought is tht action groups can be associated with command pods, and when the command pod is the controlling pod, then the action groups associated with it would be active.

 Just some random thoughts while I'm out walking my dog, it may be easier it may be harder to do, but somebody might do it soon

See? halfway there already. Look I'm not one of those people trying to say "it's just code, it's basically magic, do whatever", but I do have somewhat higher expectations when a game is this moddable and most of these functions have already been done or approached by mods in the past. Without knowing what the underlying source code that enables all these surface features looks like though, makes it genuinely impossible to say what we can do here. I mean they got docking ports to work with robotic parts, which were always the "Big No No, Here Be Dragons" of infernal robotics. I'd cut squad some slack here.

[jojo5144]

sorry for this idea. but I am enjoy that his launches the debate. I launched this idea because ksp is a game of "simulation" where physics is very important. and the big physical shock at a dock does not really exist. I am aware that if this shock is there, it probably means that it will stay at this stage of the game. Otherwise it will probably be repaired. this shake is responsible for 80% of my worries in ksp. I just give an idea. Can be stupid. I would like to make my fuel exchange to the ground less explosive especially since BG.

Edited June 4, 2019 by jojo5144

[GluttonyReaper]

 

On 6/3/2019 at 6:52 PM, Loskene said:

One major advantage I see of having both "dock" and "berth" options (maybe configurable on a per-port basis) is not having your action groups and staging all messed up and merged if you dock a ship to a station and each have overlapping functions.

My instinctive thought is that this falls into the "technically possible, but probably not worth it" category.

From what you've described, 'docking' would effectively be the same as 'berthing'... but with objectively less functionality. It doesn't seem worth the potentially large development time to what mind seems like realism for the sake of realism, without really adding anything.

As mentioned, there are other simpler ways to solve the issues with current system, which has already been shown to be feasible by vessel names being tied to command pods. In terms of progression, it seems simpler to model the limitations of docking vs. berthing than anything else - e.g. having fuel crossfeed disabled on early docking ports.

 

In regards to the OP, I suspect a lot of the reason the current system works like it does is to do with simplicity and flexibility. It's easy to forget once you've mastered it, but rendezvous/docking is *hard*. Hard enough without having to worry about whether you've got the right kind of connection or whatever - even now I occasionally flub up and use the wrong size port, and that's just three options.

[linuxgurugamer]

40 minutes ago, Loskene said:

See? halfway there already. Look I'm not one of those people trying to say "it's just code, it's basically magic, do whatever", but I do have somewhat higher expectations when a game is this moddable and most of these functions have already been done or approached by mods in the past. Without knowing what the underlying source code that enables all these surface features looks like though, makes it genuinely impossible to say what we can do here. I mean they got docking ports to work with robotic parts, which were always the "Big No No, Here Be Dragons" of infernal robotics. I'd cut squad some slack here.

No.  These are two entirely different problems.  The Action Groups are already being saved, it's just a matter of saving multiple.  This is totally different and several orders of magnitude from changing the way that physics works

[Loskene]

4 hours ago, linuxgurugamer said:

This is totally different and several orders of magnitude from changing the way that physics works

What?

[snip] At no point did I ask for any changes to how physics work, even stressing to keep things as unchanged as possible by suggesting the path of least disruption for adding a decently minor feature that would've saved some UI/operational headaches.

You know what, nevermind, this isn't remotely as important for how much time it's already wasted. Sorry to derail your thread op, didn't think there'd be this much nonsense about it.

Edited June 5, 2019 by Gargamel
Portions Redacted by Moderator

[jojo5144]

it's not just to create two modes including a mode with less functionality, but to be able to perform a fuel exchange bypassing the physical shock that the dock causes.

edit: because I thought it was just becoming one who caused the shock

Edited June 5, 2019 by jojo5144

[linuxgurugamer]

3 hours ago, Loskene said:

What?

[snip] At no point did I ask for any changes to how physics work, even stressing to keep things as unchanged as possible by suggesting the path of least disruption for adding a decently minor feature that would've saved some UI/operational headaches.

You know what, nevermind, this isn't remotely as important for how much time it's already wasted. Sorry to derail your thread op, didn't think there'd be this much nonsense about it.

Ummm, while I don't work for Squad, I think that I know a fair bit about how the game works.  If you don't know who I am, then I suggest you see why I have such a high rep.

Asking for two ships to be loosely linked but not a single vessel is a fundamental change in the way the base engine will work.  It doesn't change physics per se, but in order to have two ships loosely linked which will stay together during timewarp, rails, etc, will require significant changes in the way that the physics will need to be calculated for the two ships.

Edited June 5, 2019 by Gargamel
Portions of Quote Redacted by Moderator

[jojo5144]

someone saw me? what this ? a moderator can delete my topic ?

Edited June 5, 2019 by jojo5144

[Gargamel]

Some posts have been edited or removed.  Remember, the discussion is about the idea, not the people. 

Thread has been locked by OP request.