Jump to content

[0.22] UbioZur Welding Ltd. 2.0 Dev STOPPED

UbioZur

By UbioZur
in KSP1 Mod Releases

 Share

Recommended Posts

benc85

benc85

Posted
Posted

Oooooh, the work I could give you...

To save you spending the rest of your life welding together my crap, would you consider giving me some tips on how you go about welding them so I can give it a go myself?

I'm attempting to get THIS, into something more manageable... and welding some of the larger static sections together would be a massive help :D

Link to comment
Share on other sites
NoMrBond

NoMrBond

Posted
Posted

There was a dev thread for the 0.20 release detailing the MODEL{path} functionality for the part.cfg's

Essentially just have a look at that, poke around in the .cfg's for UbioZur parts, and maybe even the B9 parts to get a feel for how the layout works and just have a go yourself

Worst case scenario is just some floaty and/or meshed frankenparts which you can iterate on to fix

Link to comment
Share on other sites
johnsonwax

johnsonwax

Posted
Posted (edited)
To save you spending the rest of your life welding together my crap, would you consider giving me some tips on how you go about welding them so I can give it a go myself?

Well, I just learned how to do a fairly simple one with some revealing details, so I'll walk you through it.

I'm building a station using THSS - the triangular trusses, and I need to both keep part count in check, and maintain reasonable rigidity. I have several areas where there's a length of 4 trusses to get the right length, a 2x, a 1x, and two 1/3 length. So, I'll create a new part that loads 4 models, welds them, and sets the nodes at the end.

We start with the first part which looks like this in the original .cfg file:

// --- asset parameters ---
mesh = model.mu
rescaleFactor = 2.57
scale = 1

// --- node definitions ---
node_stack_top01 = 0.0, 1.491, 0.0, 0.0, 1.0, 0.0, -1
node_stack_bottom = 0.0, -1.491, 0.0, 0.0, 1.0, 0.0, -1
node_attach = 0.0, 0.0, -0.25, 0.0, 0.0, 0.1, 1

Unlike the stock parts, we have a rescale factor to deal with, which matters. We can also get the length of the part from the distance between the top and bottom nodes (1.491 + 1.491).

The first thing I had to sort out was the scaling. 2.57 was too large, 1 was too small. Turns out the proper scaling is sqrt(2.57). I'm not entirely sure why we do it this way - the model itself would then seem to only be scaled by sqrt(2.57) but the positioning scaled by that much again (which gets us the 2.57 for position, but only sqrt of that for size).

We're going to build the model in this way:

6 = 2x part

3 = 1x part

1 = 1/3 part

3611

So, the longest piece will be more or less in the center, with the others balancing it out best they can. We could actually balance it with a bit more math, but I don't think it matters.

MODEL {
    model=JARFR_THSS/Parts/Structural/JARFR_TriStrutDouble/model
  // 2.982 long
    position = 0.0, 0.0, 0.0
    scale = 1.0, 1.0, 1.0
    rotation = 0, 0, 0
}
MODEL {
    model=JARFR_THSS/Parts/Structural/JARFR_TriStrut/model
  // 1.5 long
    // Half the height of the first model + half the height of this one
    // (1.491 + .75) * sqrt(2.57) => 3.5926
    position = 0.0, 3.5926, 0.0
    scale = 1.0, 1.0, 1.0
    rotation = 0, 0, 0
}
MODEL {
    model=JARFR_THSS/Parts/Structural/JARFR_TriStrutShort/model
  // .516 long
  // Half the hight of the first model plus half the height of this one
    // (-1.491 + -.258) * sqrt(2.57) => -2.8039
    position = 0.0, -2.8039, 0.0
    scale = 1.0, 1.0, 1.0
    rotation = 0, 0, 0
}
MODEL {
    model=JARFR_THSS/Parts/Structural/JARFR_TriStrutShort/model
  // .516 long
  // Half the hight of the first model plus the full height of the third plus half the
  // height of this one
    // (-1.491 + -.258 * 3) * sqrt(2.57) => -3.6311
    position = 0.0, -3.6311, 0.0
    scale = 1.0, 1.0, 1.0
    rotation = 0, 0, 0
}

// --- asset parameters ---
rescaleFactor = 1.6031

// --- node definitions ---
// Half the height of the first, plus the whole height of the second
// (1.491 + .75 * 2) * sqrt(2.57) => 4.7949
node_stack_top01 = 0.0, 4.7949 , 0.0, 0.0, 1.0, 0.0, -1
// Half the height of the first, plus the whole height of the third and fourth
// (-1.491 + -.258 * 4) * sqrt(2.57) => -4.0447
node_stack_bottom = 0.0, -4.0447, 0.0, 0.0, 1.0, 0.0, -1
node_attach = 0.0, 0.0, -0.25, 0.0, 0.0, 0.1, 1

The comments above show the math (I use calca for this kind of stuff - makes it really easy to keep track of everything)

In the first model, we load the largest segment, and position it at 0,0,0. That represents the dead center of the part.

In the second model, we load the next largest segment, and set it's position. Since the first part is centered, we need to shift half of its length, which would put the center of the 2nd part right at the end of the first, so we need to shift half the length of the second part to put it at the end. Then we multiply by the rescale factor.

In the third model, we do the same as above, but in the opposite direction.

In the fourth model, we extend it further, half the first, all of the third, and then half the fourth, and then multiply by the scaling. Sketch it out once and it'll be clear.

Finally we need to locate the nodes. These are positioned at the end of the part, so the top node is half the first, plus all of the second, then scaled. The bottom is half the first, all of the third and all of the fourth, scaled.

I haven't dealt with any more complex nodes and parts, but I think it's all just variations on the above. What will take some investigation is how to merge parts with different scaling.

But for fairly straightforward linear welding jobs, the above should get you pretty far.

{EDIT}

Ok, you can scale any part along any dimension through the scale parameters, so if you want a part 50% longer, you can go with:

scale = 1.0, 1.5, 1.0.

By moving the scaling factor inside the model, things get both simpler and it handles the case of models with different scaling factors. The code below produces the same result as that above:

MODEL {
	model=JARFR_THSS/Parts/Structural/JARFR_TriStrutDouble/model
  // 2.982 long
	position = 0.0, 0.0, 0.0
	scale = 2.57, 2.57, 2.57
	rotation = 0, 0, 0
}
MODEL {
	model=JARFR_THSS/Parts/Structural/JARFR_TriStrut/model
  // 1.5 long
	// Half the height of the first model + half the height of this one
	// (1.491 + .75) * 2.57 => 5.7594
	position = 0.0, 5.794, 0.0
	scale = 2.57, 2.57, 2.57
	rotation = 0, 0, 0
}
MODEL {
	model=JARFR_THSS/Parts/Structural/JARFR_TriStrutShort/model
  // .516 long
  // Half the hight of the first model plus half the height of this one
	// (-1.491 + -.258) * 2.57 => -4.4949
	position = 0.0, -4.4949, 0.0
	scale = 2.57, 2.57, 2.57
	rotation = 0, 0, 0
}
MODEL {
	model=JARFR_THSS/Parts/Structural/JARFR_TriStrutShort/model
  // .516 long
  // Half the hight of the first model plus the full height of the second plus half the
  // height of this one
	// (-1.491 + -.258 * 3) * 2.57 => -5.8211
	position = 0.0, -5.8211, 0.0
	scale = 2.57, 2.57, 2.57
	rotation = 0, 0, 0
}

// --- asset parameters ---
rescaleFactor = 1

// --- node definitions ---
// Half the height of the first, plus the whole height of the second
// (1.491 + .75 * 2) * 2.57 => 7.6869
node_stack_top01 = 0.0, 7.6869 , 0.0, 0.0, 1.0, 0.0, -1
// (-1.491 + -.258 * 4) * 2.57 => -6.4841
node_stack_bottom = 0.0, -6.4841, 0.0, 0.0, 1.0, 0.0, -1
node_attach = 0.0, 0.0, -0.25, 0.0, 0.0, 0.1, 1

No sqrt. The outer rescale factor is 1 (which you can change to magnify the overall model). Much simpler arrangement.

Edited by johnsonwax
Added information
Link to comment
Share on other sites
TheCardinal

TheCardinal

Posted
Posted (edited)
Well, I just learned how to do a fairly simple one with some revealing details, so I'll walk you through it. ................................

Two questions:

1) Where does the rescalefactor 2.57 come from? (first code part)

2) Could you give another example for my better understanding, f.i. combining three rcs of the same size?

Edited by TheCardinal
Link to comment
Share on other sites
Mihara

Mihara

Posted
Posted

Hmm... Hmmm.....

Please enlighten me, either UbioZur himself or whoever's in the know.

Let's assume I have a craft file, which contains an arrangement of parts the way I need them, and I want them welded into a single file. So I parse that craft file, and locate the part.cfg files for each part in that file. Assume for simplicity that they themselves are simple part files, i.e. are not assembled in turn from multiple models, and contain no bizarre objects like procedural wings, so are limited to mesh/texture/nodes/scales configuration.

Do I have sufficient information to construct a welded part.cfg from that alone, containing MODEL {} nodes arranging these individual models in the desired shape, or do I need some extra magic numbers?

Link to comment
Share on other sites
johnsonwax

johnsonwax

Posted
Posted
Two questions:

1) Where does the rescalefactor 2.57 come from? (first code part)

2) Could you give another example for my better understanding, f.i. combining three rcs of the same size?

It comes from the original part that I'm trying to weld. The first excepted code is from someone else's part. They used the 2.57 rescale factor. I'll post some more complete examples using parts with multiple rescalefactors, etc.

One trouble:

My parts aren't highlighting in-game when you hover over them. Parts from others with multiple models do - not sure what I'm doing wrong. I think I have everything there, but not knowing what's the trigger for that functionality makes it hard to narrow down the problem.

Link to comment
Share on other sites
johnsonwax

johnsonwax

Posted
Posted

Do I have sufficient information to construct a welded part.cfg from that alone, containing MODEL {} nodes arranging these individual models in the desired shape, or do I need some extra magic numbers?

You do have all you need in some/most cases. The size of the parts is gleaned from the node locations in the original. If you want to connect from other locations - like surface attaching a piece, then you'll need to do some trial/error to get the position right, but anything that you want to weld along node/node joins is pretty straightforward. I've got 3 welded parts now - one is 7 models including one animated solar array, and another is 9 models with parts assembled along two different axes, many flipped/rotated, and two stretched along only one dimension. I'll post a tutorial of that one later today.

Link to comment
Share on other sites
  • 2 weeks later...
WinkAllKerb''

WinkAllKerb''

Posted
Posted (edited)

Great job, also investigating/trying some thing around [model] now, as said (here.) having trouble with multiple internal/hatch/animated object/(some of thoose kind of modules).

"Parsing" the *.craft files to make them*. cfg seem to work in the main lines (atm i m using a very basic open office/excel like sheet with some very basic macro to minimize some of the calcul "pos" & "rot" conversion but still have to adjust a few things manually).

In // recently read that the use of some direct call to "generic animation module" + "manual add of action groups" could help with multiple call of a single named unity object in a [model] like *.cfg file but i m stills stuck with that for now.

I noticed that in a *craft files this kind of object got an {part=name_increment} + their own modules in the {part} structure but appear that [model] structure don't allow this kind of increment/rename for mutliple {module ...} call of the same [model] object or some kind of direct attach of a {module} to a [model] (wich would be perfect ;) )

so i wondered if there is a way to rename/increment 'multiple/same' [model] in some way for later 'multiple/same' {module} call

(Scuse the poor english froggy too here + totally new to ksp i don't even talk about modding ;) ). Et une fois plus bon boulot Ubio !!! j'adore vraiment la simplicité de l'idée comme beaucoup.

Edited by WinkAllKerb''
broken link typo
Link to comment
Share on other sites
UbioZur

UbioZur

Posted
  • Author
Posted

Sorry guys Got IRL killing me at the moment, moved to spain, and no internet.

Wink, not sure what ou are asking, but you can have two call (MODEL{}) for the same model in the .cfg without problem.

I do not go through any .craft with the tool and don't plan to so I can keep the node detail.

I will try to get a playtest version of the ingame tool asap, but I can't promise anything. Internet is quite limited at the moment (need to go to a café for it)

Link to comment
Share on other sites
UbioZur

UbioZur

Posted
  • Author
Posted

Oh and for the flat solar panel (double post I know):

2x1


PART
{
// --- general parameters ---
name = ubio2x1solarPanels5
module = Part
author = UbioZur

// --- asset parameters ---
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = -0.2, 0.0, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.2, 0.0, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z
node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, 1.0

// --- editor parameters ---
cost = 200
category = Utility
subcategory = 0
title = 2x1 OX-STAT Photovoltaic Panels
manufacturer = UbioZur Welding ltd.
description = Two Solar panel arrange on a 2x1 grid. Re-entry heat can melt the weld. 
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 0,1,0,0,1

// --- standard part parameters ---
mass = 0.010
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 8
maxTemp = 3200

MODULE
{
	name = ModuleDeployableSolarPanel

	sunTracking = false

	raycastTransformName = suncatcher
	pivotName = suncatcher

	isBreakable = false

	resourceName = ElectricCharge

	chargeRate = 1.5

	powerCurve
 	{
		key = 206000000000 0 0 0
		key = 13599840256 1 0 0
		key = 68773560320 0.5 0 0
		key = 0 10 0 0
 	}
}
}

2x2


PART
{
// --- general parameters ---
name = ubio2x2solarPanels5
module = Part
author = UbioZur

// --- asset parameters ---
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = -0.2, 0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.2, 0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = -0.2, -0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.2, -0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z
node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, 1.0

// --- editor parameters ---
cost = 400
category = Utility
subcategory = 0
title = 2x2 OX-STAT Photovoltaic Panels
manufacturer = UbioZur Welding ltd.
description = Four Solar panel arrange on a 2x2 grid. Re-entry heat can melt the weld. 
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 0,1,0,0,1

// --- standard part parameters ---
mass = 0.020
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 8
maxTemp = 3200

MODULE
{
	name = ModuleDeployableSolarPanel

	sunTracking = false

	raycastTransformName = suncatcher
	pivotName = suncatcher

	isBreakable = false

	resourceName = ElectricCharge

	chargeRate = 3.0

	powerCurve
 	{
		key = 206000000000 0 0 0
		key = 13599840256 1 0 0
		key = 68773560320 0.5 0 0
		key = 0 10 0 0
 	}
}
}

3x1


PART
{
// --- general parameters ---
name = ubio3x1solarPanels5
module = Part
author = UbioZur

// --- asset parameters ---
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = -0.4, 0.0, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.0, 0.0, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.4, 0.0, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z
node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, 1.0

// --- editor parameters ---
cost = 300
category = Utility
subcategory = 0
title = 3x1 OX-STAT Photovoltaic Panels
manufacturer = UbioZur Welding ltd.
description = three Solar panel arrange on a 3x1 grid. Re-entry heat can melt the weld. 
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 0,1,0,0,1

// --- standard part parameters ---
mass = 0.015
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 8
maxTemp = 3200

MODULE
{
	name = ModuleDeployableSolarPanel

	sunTracking = false

	raycastTransformName = suncatcher
	pivotName = suncatcher

	isBreakable = false

	resourceName = ElectricCharge

	chargeRate = 2.25

	powerCurve
 	{
		key = 206000000000 0 0 0
		key = 13599840256 1 0 0
		key = 68773560320 0.5 0 0
		key = 0 10 0 0
 	}
}
}

3x3


PART
{
// --- general parameters ---
name = ubio3x3solarPanels5
module = Part
author = UbioZur

// --- asset parameters ---
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = -0.4, 0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.0, 0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.4, 0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = -0.4, -0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.0, -0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Electrical/solarPanels5/model
	position = 0.4, -0.25, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z
node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, 1.0

// --- editor parameters ---
cost = 600
category = Utility
subcategory = 0
title = 3x3 OX-STAT Photovoltaic Panels
manufacturer = UbioZur Welding ltd.
description = Nine Solar panel arrange on a 3x1 grid. Re-entry heat can melt the weld. 
// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 0,1,0,0,1

// --- standard part parameters ---
mass = 0.03
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 8
maxTemp = 3200

MODULE
{
	name = ModuleDeployableSolarPanel

	sunTracking = false

	raycastTransformName = suncatcher
	pivotName = suncatcher

	isBreakable = false

	resourceName = ElectricCharge

	chargeRate = 4.5

	powerCurve
 	{
		key = 206000000000 0 0 0
		key = 13599840256 1 0 0
		key = 68773560320 0.5 0 0
		key = 0 10 0 0
 	}
}
}

Link to comment
Share on other sites
WinkAllKerb''

WinkAllKerb''

Posted
Posted (edited)

Thks for the answer Ubio as for all the very usefull infos you shared in this thread, and scuse my real pidgin english when i try to explain some technical/code things. Spain is a nice place i love the Dali museum there if you have some time don't miss it, wish i could go there once again someday but IRL is real complicated atm too.

Best regards finalizing the plugin ;)

EDIT: for now i try to improve my KSP physical param cfg knowledge so my part combo to be close to squad design/spirit, and i have to say: "a little painfull it is, from scratch when your're starting"® :) may the Forke be with us or something like that.

Edited by WinkAllKerb''
Link to comment
Share on other sites
UbioZur

UbioZur

Posted
  • Author
Posted

Thanks little square and Cy-one.

So far I have the basic structural parts done, few problems when the nodes are "sideways" and not top or bottom. And of course I need to play with the scale / rescale factor because the fuel tanks have issue with them.

Link to comment
Share on other sites
cy-one

cy-one

Posted
Posted

Mhm... Just a question. Do you think your plugin will be limited to squad-parts (because you can make your plugin to handle them with ease, as all nodes/scales are known), or will it be able to handle other stuff, too?

I honestly don't really care, as most of my "aww damn, I would love to weld those x parts together" usually involve only stock-parts :D Nevertheless, I'm curious.

Link to comment
Share on other sites
M4ck

M4ck

Posted
Posted

I'd like to add a bit of my work here, a multi-size docking port. The facing on each dock is at the same height, you won't bump into anything strange when using them. It works like it is supposed to, I've already tested it in orbit with different test probes attached to it, detached and replaced by probes with other dock sizes. The only issue is that when selecting "Set as target" or "Control from here" on the Omni dock, you have three buttons instead of one - but it does not matter which one you click, they all work fine.

Javascript is disabled. View full album

PART
{
name = OmniDockingPort
module = Part
author = NovaSilisko

MODEL
{
	model=Squad/Parts/Utility/dockingPortLarge/model
	position = 0.0, 0.0, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Utility/dockingPort2/model
	position = 0.0, 0.0, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Utility/dockingPort3/model
	position = 0.0, 0.145, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}

rescaleFactor = 1


node_stack_top0 = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
node_stack_top1 = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
node_stack_top2 = 0.0, 0.2828832, 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


cost = 2200
category = Utility
subcategory = 0
title = Clamp-O-Tron Omni Docking Port

description = Invented after a less-than-peaceful protest against the lack of spacecraft attachment systems that could make buiding multi-purpose symmetrical bases possible, the Clamp-O-Tron Omni Docking Port allows for the firm attachment of two separate vessels regardless of the other dock's type. After docking, vessels can be just as easily undocked.

attachRules = 1,0,1,0,0

mass = 0.25
dragModelType = default
maximum_drag = 0.25
minimum_drag = 0.25
angularDrag = 0.5
crashTolerance = 15
maxTemp = 3400

MODULE
{
	name = ModuleDockingNode
	referenceAttachNode = top0
	nodeType = size0	
}
MODULE
{
	name = ModuleDockingNode
	referenceAttachNode = top1
	nodeType = size1
}
MODULE
{
	name = ModuleDockingNode
	referenceAttachNode = top2
	nodeType = size2
}

}

Link to comment
Share on other sites
M4ck

M4ck

Posted
Posted (edited)

I haven't tested it yet, but it should work well, I'll test it soon and update if needed.

Edit: Yes, it works as well, although if you build something pre-attached to it by a jr port, the Omni can suck it in again after the first decoupling. After that, after regular undocking, everything seems fine.


PART
{
name = OmniDockingPortSmaller
module = Part
author = NovaSilisko

MODEL
{
	model=Squad/Parts/Utility/dockingPort2/model
	position = 0.0, 0.0, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}
MODEL
{
	model=Squad/Parts/Utility/dockingPort3/model
	position = 0.0, 0.145, 0.0
	scale = 1.0, 1.0, 1.0
	rotation = 0, 0, 0
}

rescaleFactor = 1


node_stack_top0 = 0.0, 0.2828832, 0.0, 0.0, 1.0, 0.0, 1
node_stack_top1 = 0.0, 0.2828832, 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


cost = 900
category = Utility
subcategory = 0
title = Clamp-O-Tron Omni Docking Port S

description = Invented after a less-than-peaceful protest against the lack of spacecraft attachment systems that could make buiding multi-purpose symmetrical bases possible, the Clamp-O-Tron Omni Docking Port S allows for the firm attachment of two separate vessels regardless of the other dock's type. After docking, vessels can be just as easily undocked. Supports regular and jr. ports.

attachRules = 1,0,1,0,0

mass = 0.1
dragModelType = default
maximum_drag = 0.25
minimum_drag = 0.25
angularDrag = 0.5
crashTolerance = 15
maxTemp = 3400

MODULE
{
	name = ModuleDockingNode
	referenceAttachNode = top0
	nodeType = size0	
}
MODULE
{
	name = ModuleDockingNode
	referenceAttachNode = top1
	nodeType = size1
}

}

Edited by M4ck
Link to comment
Share on other sites
UbioZur

UbioZur

Posted
  • Author
Posted
Mhm... Just a question. Do you think your plugin will be limited to squad-parts (because you can make your plugin to handle them with ease, as all nodes/scales are known), or will it be able to handle other stuff, too?

I honestly don't really care, as most of my "aww damn, I would love to weld those x parts together" usually involve only stock-parts :D Nevertheless, I'm curious.

I will for sure just "support" the stock parts as a first priorities. The way I develop it, it should allow for mods parts to work, but since there is lot of mods, I am not planing on making them a priority support, but if a small fix can allow some more mods to work, I will see to add it.

M4ck, Nice idea, concept and design.

Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...