Micro docking ports?

[steedcrugeon]

Unfortunately there is some kind of GIF war- taking place on Imgur which means I cannot post the images for the test part. 

Instead please have a trial of this part (please note that this is an early beta part and is not intended for release). Just copy the folder into the GameData folder.

PicoPortBasic

Be warned docking this thing is very fiddly, funnily enough, due to size and the orientation sensitivity. Also I am having issues with colliders at present (in part due to it's size). This means in game terms that when building, you will need to put a seperator between the ports if they start connected. After launch and separation they behave normally.

@DStaal and @linuxgurugamer have a test and see what you think, i'd appreciate feedback. Over the weekend i'll hone the colliders and get the gendered versions done and finalise a texture.

[linuxgurugamer]

1 hour ago, steedcrugeon said:

Unfortunately there is some kind of GIF war- taking place on Imgur which means I cannot post the images for the test part. 

Instead please have a trial of this part (please note that this is an early beta part and is not intended for release). Just copy the folder into the GameData folder.

PicoPortBasic

Be warned docking this thing is very fiddly, funnily enough, due to size and the orientation sensitivity. Also I am having issues with colliders at present (in part due to it's size). This means in game terms that when building, you will need to put a seperator between the ports if they start connected. After launch and separation they behave normally.

@DStaal and @linuxgurugamer have a test and see what you think, i'd appreciate feedback. Over the weekend i'll hone the colliders and get the gendered versions done and finalise a texture.

Model name had a case error, it should be:      model = PicoPortBasic.mu

I don't particularily like that the orientation sensitivity is built-in.

I tried it by putting a small decoupler between two of them, when I got in space (using Hyperedit), I had control of the vessel, but the docking ports wouldn't undock (the otion wasn't there), I decoiupled using the mini decoupler I used for a spacer and the octosat core I was using became unresponsive.  What was really strange is that the RCS and SAS went dim, not out, but ther was nothing in the logs

Not this, I tested without and had the same problem

Duh!  I forgot to put on batteries

Ok, i docked the two, only one has the ability to undock ????

Edited January 12, 2017 by linuxgurugamer

[DStaal]

Ok, when I separated my probe into two, it immediately magneted back together - catching the separator in between.  I pushed off, but when I came back it didn't magnet.  (After thinking about it, maybe I didn't get far enough away - I only got about 80m.)  Wasn't able to re-dock; I may try again.

One comment: Those flanges (or whatever they're called), do they have any space between them?  Because I know from some other thread where they made docking ports with orientation and a modeled interlock, that they needed just a bit of space between parts for things to actually work smoothly.

[steedcrugeon]

6 hours ago, linuxgurugamer said:

Model name had a case error, it should be:      model = PicoPortBasic.mu

Good catch, thanks I'll correct that (it's actually and error on the model file as (trying to be in keeping with KSP convention) the first part was supposed to be lowercase.

6 hours ago, linuxgurugamer said:

I don't particularily like that the orientation sensitivity is built-in.

Really? I though that was part of the original pre-requisite, or was your thinking that only the gendered parts should be orientation sensitive?

6 hours ago, linuxgurugamer said:

Ok, i docked the two, only one has the ability to undock ????

Hmm, interesting. Assuming both sides had command capabilities (probe core, etc) which was the side the that did not have the option to undock? the side which initiated the dock or the side which was docked with.

4 hours ago, DStaal said:

Ok, when I separated my probe into two, it immediately magneted back together - catching the separator in between.  I pushed off, but when I came back it didn't magnet.  (After thinking about it, maybe I didn't get far enough away - I only got about 80m.)  Wasn't able to re-dock; I may try again.

What was the mass of your vessel (my testing used a little probe core about 0.35 in mass. if yours was by and order of magnitude lighter I may have to look into adjusting the config to accommodate the light weight. @linuxgurugamer did you have any issues with the initial magnetism of the docking port?

4 hours ago, DStaal said:

One comment: Those flanges (or whatever they're called), do they have any space between them?  Because I know from some other thread where they made docking ports with orientation and a modeled interlock, that they needed just a bit of space between parts for things to actually work smoothly.

Yes, the castellations are deliberately tapered (they may not appear so but I assure you they are and as are their subsequent colliders (each castellation requires its own collider in order for the interlocking to work properly). There is space between them to allow docking and undocking, its not particularly big space but as per the post to which you refer, thanks to @sumghai for all the info in this thread:

As I stated they are fiddly, not just because of this but also because the config dictates it's orientation sensitivity. you really do have to take care with the line up and approach and be travelling towards the target at very low speed. I'd like to think this reflects how you would deal with such a small docking port in real life as you would have little material to contact with or bolster the impact of the two vessels in the first place, that and there is the low mass of two colliding vessels to consider also.

In general @DStaal, is the scale of the part along the lines of what you were thinking?

 

[DrLicor]

You can make them easily by yourself.
Every part has a .mu file and a .cfg file to function. The .mu file are the models with texture etc. The .cfg the config files. It also has some textures etc.

In the configs are quite simple to understand, you just open them with notepad or CC+. 
If you make a new config, you basically make a new part. 
In the new config you link the model (.mu file) you want to use. 

But your case is even more simple, you can just copy the .cfg file and give it another another name. The only thing you need to do is to change the line with 'scale' or 'rescale' in it.

So what you do is:

1.  Go to the folder where the .cfg you want to use is located. In case of steam, it's C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\Squad\Parts\Utility. (if you run 32bit, it's Program Files instead of Program Files (x86)
2. In the Utility folder, you have 5 folders of decouplers:
   1. dockingPort
   2. dockingPortInline
   3. dockingPortJr
   4. dockingPortShielded
   5. dockingPortSr
3. Choose the design you want, I would recommend to go for the junior (dockingPortJr), and copy that one.
4. If you want to keep everything organized, I recommend to make a folder in the GameData folder, just like other mods, name of the folder doesn't matter much, just to recognize it for yourself.
5. In your folder, let's call it MyOwnParts for now, you paste the folder you copied in step 3.
6. Rename the folder to keep it clear for yourself, for now we go with dockingPortMini.
7. So for now, it should look like this: ...\Kerbal Space Program\GameData\MyOwnParts\dockingPortMini\.... with the following files in it:
   1. dockingPortJr.cfg (config file)
   2. model.mu (model)
   3. model000.dds (textures)
   4. model001.dds (textures)
8. Rename the .cfg file to dockingPortMini, again this doesn't effect nothing, only to keep things tidy and clean.
9. Open the .cfg file, you can just use NotePad if you doný have other programs for programming. 
10. You will get the following config:

    PART
    {
    	name = dockingPort3
    	module = Part
    	author = NovaSilisko
    	mesh = model.mu
    	rescaleFactor = 1
    	node_stack_top = 0.0, 0.1474114, 0.0, 0.0, 1.0, 0.0, 1
    	node_stack_bottom = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0, 1
    	node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0
    	TechRequired = miniaturization
    	entryCost = 7800
    	cost = 800
    	category = Coupling
    	subcategory = 0
    	title = Clamp-O-Tron Docking Port Jr.
    	description = Originally marketed as a child-size version of the normal Clamp-O-Tron, the Clamp-O-Tron Jr. soon found use among hobbyists and professional space agencies alike for its compact profile, lightweight structure, and all-round cuteness. As a result of its small size, kerbals need to hold their breath and wiggle to slip through.
    	attachRules = 1,1,1,1,0
    	mass = 0.02
    	dragModelType = default
    	maximum_drag = 0.25
    	minimum_drag = 0.25
    	angularDrag = 0.5
    	crashTolerance = 10
    	maxTemp = 2000 // = 3400
    	bulkheadProfiles = size0, srf
    	tags = berth capture connect couple dock fasten join moor socket
    	stagingIcon = DECOUPLER_VERT
    	MODULE
    	{
    		name = ModuleDockingNode
    		referenceAttachNode = top
    		nodeType = size0
    		stagingEnabled = False
    	}
    }

     

11. You need to change the following things:
    1. name = dockingPort4 (or docking5 etc.)
    2. node_stack_top and scale.
    3. title = Clamp-O-Tron Docking Port Mini             (or something like that, this will be the name of the part.)
    4. description: fill it in to your own liking, not very important. 
    5. mass = you can make it a bit lighter. depending on how small you make it.

 

Now comes a very critical part:

If you want it half the size, you set the rescale factor to 0.5, but you also need to set the node_stack_top to a different value. In this case it needs to be half of it's current, because you make the scale also half of it's current. etc.

Profit... 

Hope this helped you
 

[linuxgurugamer]

5 hours ago, steedcrugeon said:

12 hours ago, linuxgurugamer said:

I don't particularily like that the orientation sensitivity is built-in.

Really? I though that was part of the original pre-requisite, or was your thinking that only the gendered parts should be orientation sensitive?

Actually, @steedcrugeon  was somewhat ok with it.  I don't, I think it can be just a bit too fiddely if it is.  But, I do like the idea of gendered ports, which is why I suggested both gendered and non-gendered

 

5 hours ago, steedcrugeon said:

12 hours ago, linuxgurugamer said:

Ok, i docked the two, only one has the ability to undock ????

Hmm, interesting. Assuming both sides had command capabilities (probe core, etc) which was the side the that did not have the option to undock? the side which initiated the dock or the side which was docked with.

My bad, one side didn't have power

I did notice that even with a very small seperator (the OctoSat Plate), the magnetic force was still there after undocking, so I couldn't get apart.  When I used the TR-2c, it was ok. 

Once I was able to dock, the one which allowed the undock was on the probe core (the one I was NOT controlling).

Here is a link to my test craft.  You will need the Octosat mod installed, and don't forget to deploy the antennas and solar panels

One thing I noticed which was rather nice.  One docking attempt I made while 45 degrees rotated.  The ports pulled together, and I was then able to slowly rotate around until they mated.

So personally, I'd rather see a male/female set of ports rather than the orientation sensitivity.  Since you have these,how much more difficult would it be to make another pair?

I can definitely see the need and use for what you have.  But, my thinking is that any collisions will occur before docking, not while it's docked.  So, orientation specific is useless from that point of view.

Regarding the size, looks good.

I guess the GIF war is over, here is a picture of my test craft:

 

 

Edited January 12, 2017 by linuxgurugamer

[Sharpy]

Some alternatives you may consider:

- if your "mothership" is crewed, then KIS and KAS provide a decent option with a kerbal either just attaching the probe to the vessel, or linking a pipe/tether.

- the Hangar mod would allow you to store multiple probes inside one hangar, and vastly reduce "part count" as they are unloaded when stored, and "spawned" when deployed from the hangar.

[linuxgurugamer]

12 minutes ago, Sharpy said:

Some alternatives you may consider:

- if your "mothership" is crewed, then KIS and KAS provide a decent option with a kerbal either just attaching the probe to the vessel, or linking a pipe/tether.

- the Hangar mod would allow you to store multiple probes inside one hangar, and vastly reduce "part count" as they are unloaded when stored, and "spawned" when deployed from the hangar.

@Sharpy  This is for probes, not manned craft.  And, no one said anything about part count.  and, while the Hanger mod is nice, I don't thing it is relevant to this discussion.

Quote

 I need to do is to separate the probe into two once I get it into an approximate position, then re-join them once I'm done scanning so I can recover them.

But, of course, since this is an extended mission size and mass matter a lot.

 

Edited January 12, 2017 by linuxgurugamer

[steedcrugeon]

35 minutes ago, linuxgurugamer said:

So personally, I'd rather see a male/female set of ports rather than the orientation sensitivity.  Since you have these,how much more difficult would it be to make another pair?

I've already modelled the gendered pair, I just haven't thrown the texture on them yet. I wanted to see if this part was the correct size first.

There will now be 4 parts as a result of your feedback:

1. Pico Port Basic: un-gendered, un-castellated part Non orientation specific.
2. Pico Port Plus: un-gendered, castellated part. Orientation specific.
3. Pico Port M: gendered, un-castellated part. Non orientation specific.
4. Pico Port F: gendered, un-castellated part. Non orientation specific.

The model you have already played with will form the basis of the Pico Port Plus. This stems from @DStaal's original requirement to have a sub-miniature docking port which is orientation specific. The principal reason, as I understand it, is for the purpose of RCS balancing. For instance; adding two probes to a larger probe central core, all of which already have RCS thrusters. If the two docking with the core are a mated pair then, and attaching in the correct orientation will result in their additional RCS thrust behaving (relatively) uniformly.

 

[linuxgurugamer]

16 minutes ago, steedcrugeon said:

I've already modelled the gendered pair, I just haven't thrown the texture on them yet. I wanted to see if this part was the correct size first.

There will now be 4 parts as a result of your feedback:

1. Pico Port Basic: un-gendered, un-castellated part Non orientation specific.
2. Pico Port Plus: un-gendered, castellated part. Orientation specific.
3. Pico Port M: gendered, un-castellated part. Non orientation specific.
4. Pico Port F: gendered, un-castellated part. Non orientation specific.

The model you have already played with will form the basis of the Pico Port Plus. This stems from @DStaal's original requirement to have a sub-miniature docking port which is orientation specific. The principal reason, as I understand it, is for the purpose of RCS balancing. For instance; adding two probes to a larger probe central core, all of which already have RCS thrusters. If the two docking with the core are a mated pair then, and attaching in the correct orientation will result in their additional RCS thrust behaving (relatively) uniformly.

 

Cool!

Here is a thought:  Could you make the castellated stuff either configurable, or retractable?  I don't know how difficult that would be, but if it was retractable, then one part could serve two purposes.  Same comment re. the gendered ports.

 

[DStaal]

8 hours ago, steedcrugeon said:

What was the mass of your vessel (my testing used a little probe core about 0.35 in mass. if yours was by and order of magnitude lighter I may have to look into adjusting the config to accommodate the light weight. @linuxgurugamer did you have any issues with the initial magnetism of the docking port?

Yes, the castellations are deliberately tapered (they may not appear so but I assure you they are and as are their subsequent colliders (each castellation requires its own collider in order for the interlocking to work properly). There is space between them to allow docking and undocking, its not particularly big space but as per the post to which you refer, thanks to @sumghai for all the info in this thread:

As I stated they are fiddly, not just because of this but also because the config dictates it's orientation sensitivity. you really do have to take care with the line up and approach and be travelling towards the target at very low speed. I'd like to think this reflects how you would deal with such a small docking port in real life as you would have little material to contact with or bolster the impact of the two vessels in the first place, that and there is the low mass of two colliding vessels to consider also.

In general @DStaal, is the scale of the part along the lines of what you were thinking?

 

I was using my initial take on the scanner probe design - total mass of both bodies involved is about 2.9, with the lighter probe section (the one I've shown images of) about .7.

And I'm glad that you knew which thread I was referring to - I just wanted to make sure you'd seen it. 

But yes, the scale is good.  It fits my probe fairly well.

7 hours ago, DrLicor said:

You can make them easily by yourself.
Every part has a .mu file and a .cfg file to function. The .mu file are the models with texture etc. The .cfg the config files. It also has some textures etc.

In the configs are quite simple to understand, you just open them with notepad or CC+. 
If you make a new config, you basically make a new part. 
In the new config you link the model (.mu file) you want to use.

As I said in my initial post: Yes, I know I could do this with MM.  (Simpler, but equivalent to, your method - it can be about three lines of text.)  I was wondering if there was something designed to look like it actually fits.

3 hours ago, Sharpy said:

Some alternatives you may consider:

- if your "mothership" is crewed, then KIS and KAS provide a decent option with a kerbal either just attaching the probe to the vessel, or linking a pipe/tether.

- the Hangar mod would allow you to store multiple probes inside one hangar, and vastly reduce "part count" as they are unloaded when stored, and "spawned" when deployed from the hangar.

The intended deployment of my initial probe goes like this: My expedition ship pulls into orbit around a planet, say Jool.  From it's hangers, it disgorges one or more unmanned scanner probes - we'll follow the one to Laythe.  It transfers over into a polar orbit, then splits into two probes: A low-orbit scanner, and a high-orbit scanner.  They separate to their respective orbits, and preform the planetary scans.  They then re-dock to each other, and rendezvous with the expedition ship.  (Probably back in Jool orbit.)  Once there, they re-enter the hanger for refit and refurbishment, as the expedition heads off to the next planet on the list.   So yes, I've considered those options. 

3 hours ago, steedcrugeon said:

I've already modelled the gendered pair, I just haven't thrown the texture on them yet. I wanted to see if this part was the correct size first.

There will now be 4 parts as a result of your feedback:

1. Pico Port Basic: un-gendered, un-castellated part Non orientation specific.
2. Pico Port Plus: un-gendered, castellated part. Orientation specific.
3. Pico Port M: gendered, un-castellated part. Non orientation specific.
4. Pico Port F: gendered, un-castellated part. Non orientation specific.

The model you have already played with will form the basis of the Pico Port Plus. This stems from @DStaal's original requirement to have a sub-miniature docking port which is orientation specific. The principal reason, as I understand it, is for the purpose of RCS balancing. For instance; adding two probes to a larger probe central core, all of which already have RCS thrusters. If the two docking with the core are a mated pair then, and attaching in the correct orientation will result in their additional RCS thrust behaving (relatively) uniformly.

Yep, sounds good to me.    The one thing I'd comment on is your naming: I'd consider castellated the 'basic' part, and the uncastellated the 'plus'.  It's far easier to design (in real life) a gendered, orientation-specific docking port than an ungendered non-orientation specific part, especially at these sizes.  So, the 'plus' should be the 'advanced' part - the un-gendered, un-castellated.  (Though if you wanted to do a full-on cheap dock: gendered *and* orientation specific, I wouldn't stop you.    What you have at the moment looks like it should suit what I need, but I can see it being developed that way.)

[steedcrugeon]

6 hours ago, linuxgurugamer said:

Here is a thought:  Could you make the castellated stuff either configurable, or retractable?  I don't know how difficult that would be, but if it was retractable, then one part could serve two purposes.  Same comment re. the gendered ports.

 

Unfortunately I don't think that can be achieved with the stock ModuleDockingNode. You have to declare it's gender and if it's orientation specific in the config, fixing it at time of instantiation.

[linuxgurugamer]

1 minute ago, steedcrugeon said:

Unfortunately I don't think that can be achieved with the stock ModuleDockingNode. You have to declare it's gender and if it's orientation specific in the config, fixing it at time of instantiation.

Take a look at TweakableEverything, it does it in the VAB, and I could probably come up with a custom dll for this, depending on what's needed.

 

Edited January 12, 2017 by linuxgurugamer

[HalcyonSon]

12 hours ago, DrLicor said:

You can make them easily by yourself.
Every part has a .mu file and a .cfg file to function. The .mu file are the models with texture etc. The .cfg the config files. It also has some textures etc.

Is it really that easy?  I might have a use for a slimmer Modular Girder.  The normal size is the right length, but a bit wide and deep for mounting the Survey Scanner inside a 2.5m Fairing.  A smaller one could also be useful for rover construction.

[steedcrugeon]

8 minutes ago, linuxgurugamer said:

Take a look at TweakableEverything, it does it in the VAB

Oh I see, it actually interfaces directly with the Stock module. Gah it's one of the missing threads. Although having looked at the KSP API I'm not sure how I could implement mesh/collider switch on the part using stock.

New plan for the interim:

Step 1) Finish the current 4 part mod 'PicoPort', release as standalone 'Stock' part.

Phase B. produce a 'single' part bespoke for Octo-Sat derived from PicoPort parts but with the mesh switching capability that firesplitter related plugins allow. That way you could have a single part, multi-meshed to work with TweakableEverything? (EG decided on Gender based on Mesh etc).

part 3 - Profit?

[DStaal]

55 minutes ago, HalcyonSon said:

Is it really that easy?  I might have a use for a slimmer Modular Girder.  The normal size is the right length, but a bit wide and deep for mounting the Survey Scanner inside a 2.5m Fairing.  A smaller one could also be useful for rover construction.

The rescale factor trick he's trying to point out wouldn't help you, because it scales *all* dimensions equally.

For rovers, check out the Buffalo mod - it has some rover-optimized structural parts.

BTW: Docking works fine on the second attempt:

No issues with docking, I didn't try undocking again. 

The one thing that still worries me is that 'initial launch needs a separator in between' thing: I'm guessing each time I take it out of the Hanger that'll be an 'initial launch', and there's no good way to put a separator in between between deployments.

Oh, and because I'm amused by the fact that *none of the scanners were destroyed*:

 

 

[steedcrugeon]

@DStaal are you using the test part in game properly already? That's was not its intention!

I have figured out the separator issue (I was missing a line from the config which resolves this) so you should be able to launch with ports mated and not need a separator between them anymore.

I will be making the un-gendered part available for testing: This is probably going to be near as dammit the finished PicoPortPlus (i'm taking onboard your comments about the un-gendered one being the more advanced version).

PreBetaFolder

Delete the exisitng test part folder, place the SHED folder into the GameData directory. As always looking forward to feedback.

Edited January 13, 2017 by steedcrugeon
clarification

[DStaal]

I am using a the test part on the test version of my probe - which I recovered to Kerbin once deployment testing was complete.  My Kerbals wanted to learn the characteristics of the port, as well as to verify the working capabilities of the probe.

The test went successfully - though lessons learned included 'needs more RTGs', and 'needs more Xenon'.   

[DrLicor]

8 hours ago, HalcyonSon said:

Is it really that easy?  I might have a use for a slimmer Modular Girder.  The normal size is the right length, but a bit wide and deep for mounting the Survey Scanner inside a 2.5m Fairing.  A smaller one could also be useful for rover construction.

Can also be done, only now you have to add dimensions to the scale. 

It will look lije this: 

scale = 0.5, 1, 0.5.

The 3 factors here are the x-width, height and y-width ( what I now did was make it smaller, but the height will stay the same. 

You can mess a bit around with them to test it and figure out how they respond erc.

Also, I know it can be done with MM-files, but for beginners, this is much earier. 

Edited January 13, 2017 by DrLicor

[linuxgurugamer]

16 hours ago, steedcrugeon said:

@DStaal are you using the test part in game properly already? That's was not its intention!

I have figured out the separator issue (I was missing a line from the config which resolves this) so you should be able to launch with ports mated and not need a separator between them anymore.

I will be making the un-gendered part available for testing: This is probably going to be near as dammit the finished PicoPortPlus (i'm taking onboard your comments about the un-gendered one being the more advanced version).

PreBetaFolder

Delete the exisitng test part folder, place the SHED folder into the GameData directory. As always looking forward to feedback.

The ungendered parts works nicely

The Castellated part is still not working, too strong magnet and  only one can decouple

I added the following line to the PicoPortBasic and it worked:

referenceAttachNode = top

 

Edited January 13, 2017 by linuxgurugamer

[steedcrugeon]

9 minutes ago, linuxgurugamer said:

The ungendered parts works nicely

The Castellated part is still not working, too strong magnet and  only one can decoiuple

 

Glad the ungendered one is working for you. I'll do further investigation into the strength of the magnetism for the castellated part. I think I might need to increase it's capture range a smidge whilst lower the force.

I've noticed the decoupling issue, it doesn't seem to matter which vessel has control, only the port which did the docking seem to have the undock option after. I don't think its game breaking, just a bit inconvenient, but also peculiar given that this is the stock module. I may have to delve further into the API to see i'f there is a field which i have missed int he config which might explain it.

[linuxgurugamer]

4 minutes ago, steedcrugeon said:

Glad the ungendered one is working for you. I'll do further investigation into the strength of the magnetism for the castellated part. I think I might need to increase it's capture range a smidge whilst lower the force.

I've noticed the decoupling issue, it doesn't seem to matter which vessel has control, only the port which did the docking seem to have the undock option after. I don't think its game breaking, just a bit inconvenient, but also peculiar given that this is the stock module. I may have to delve further into the API to see i'f there is a field which i have missed int he config which might explain it.

Actually, once I added that line:

referenceAttachNode = top

 

the decoupling worked on both

[HalcyonSon]

10 hours ago, DrLicor said:

Can also be done, only now you have to add dimensions to the scale. 

It will look like this: 

scale = 0.5, 1, 0.5.

The 3 factors here are the x-width, height and y-width ( what I now did was make it smaller, but the height will stay the same. 

You can mess a bit around with them to test it and figure out how they respond etc.

Also, I know it can be done with MM-files, but for beginners, this is much easier. 

Very cool.  I already launched that ship with a bit of clipping, but this knowledge will come in handy.  I assume this trick could also be used to stretch a 2.5m Service Bay's height to fit a larger rover.

[linuxgurugamer]

1 minute ago, HalcyonSon said:

Very cool.  I already launched that ship with a bit of clipping, but this knowledge will come in handy.  I assume this trick could also be used to stretch a 2.5m Service Bay's height to fit a larger rover.

yes, but the textures will also be stretched

 

[DStaal]

On 1/12/2017 at 6:33 PM, steedcrugeon said:

I have figured out the separator issue (I was missing a line from the config which resolves this) so you should be able to launch with ports mated and not need a separator between them anymore.

Just launched a second test craft - unfortunately, your fix for this doesn't appear to have worked.  I launched, clicked 'undock', and... Nothing.  Well, the 'undock' button is gone, but other than that, nothing.  Using the castelated dock.