[0.23.5] Hollow Structures & Hulls (Updated: 2014-04-09)

[Alskari]

Nope. Nothke is the one who posted that. Don't know that he's ever released it.

[WinkAllKerb'']

Some of the connector sections will not attach for certain nodes. This is due to the fact that KSP only allows for two root nodes. Try attaching them at a different geometry. For now there is not a good way to work around this, other than to make multiple parts with re-ordered nodes. Which would be horribly messy. (This mod might provide a possible work around.)

Hi, not sure i well understand what you refer too (one of the first mod i downloaded and not tried cause memory lack and so many thing to try when your new to ksp etc.) but if i well understand the matter was thinking of:

2 MODEL{ model = some random docking port}node (scaled visible/invisible edit: scale= n,n,0 will kill texture in this axis tried it once almost 99% sure)

+ param resist

+1 MODULE { name = ModuleDockingNode }

as the dock will react simultnaeously this way dunno if it could help and if it will fit what you want to do (and if of course if i well understand wich part your talking about as i have not yet been able to try your mod but will soon for sure ).

hope it help cya

Edited September 4, 2013 by WinkAllKerb''
scale details + fast food typo ;)

[Alskari]

Hi' date=' not sure i well understand what you refer too (one of the first mod i downloaded and not tried cause memory lack and so many thing to try when your new to ksp etc.) but if i well understand the matter was thinking of:

2 MODEL{ model = some random docking port}node (scaled visible/invisible edit: scale= n,n,0 will kill texture in this axis tried it once almost 99% sure)

+ param resist

+1 MODULE { name = ModuleDockingNode }

as the dock will react simultnaeously this way dunno if it could help and if it will fit what you want to do (and if of course if i well understand wich part your talking about as i have not yet been able to try your mod but will soon for sure ).

hope it help cya [/quote']

I'm not sure I'm following. Are you saying that docking nodes do not obey the root node limitations?

[WinkAllKerb'']

it s kinda tricky and won't replace the ability to attach from two attach node at the same time, but as a temporary solution actually with the model structure + module call you can:

have two docking port that use the same module so you will attach by simultaneous/shared magnetism instead of classic node (talking about your solar panel ring if i well understand wich part cause this matter)

edit: when you build you attach from one side (whatever the side you choose and at launch magnetism take the relay automatically) i use that for my craft with multiple docking @ the same time

1 attach @ vab , n dock and at launch the n dock become active

Edited September 4, 2013 by WinkAllKerb''
typo

[Alskari]

No that's in reference to the connector frame pieces. The root node limitation is in reference to being able to connect a part perpendicular to it's last node's orientation. If you take a look at the mod I think you'll see what I'm talking about. The docking trick is handy for doing multiples of things, but my concern is the orientation of the part to begin with. Attaching a part along an axis other than the root node will result in it turning red and it will not allow other parts to be attached to it.

Unless I'm totally off base on what you're getting at. I'm not a .cfg file trickster.

[WinkAllKerb'']

huhu i m fighting with 7 attach nodes and there orientation too xD for something like 4to5 hours now, got five node that work but still two missing coming to the forum through *.cfg iteration xD

If you take a look at the mod I think you'll see what I'm talking about

i will for sure as soon as i beaten the two last node cause i will definetly need a break xD earlier in iteration i was able to attach with weird orientation but pos was wrong now pos is good but i don't remember exactly how i was able to enable the weird orient attach XD

(edit: it has something to do with attach_'type'_'name''increment' and the way you group them by "type" and "name" & "increment" in a revert order of *.cfg writing + something else i m fighting with right now as i not established the law behind that exactly yet

(edit2: just checked i ll give a try with *.cfg edit and feedback in a day or two need some rest for now, wish my english to be better

Edited September 4, 2013 by WinkAllKerb''

[Alskari]

Well I appreciate you looking into it. I believe that the other mod I linked simply reorders nodes w/in the .cfg, saves it, and then forces an update of the part. Which can lead to different problems. Take your time, and I like what you're doing w/ the .cfg edits. I was looking at the .cfg files on Kerbal ModeLite and thinking how efficient it was. I'll probably need to learn these tricks myself, as I expect it can really cut down on the time involved with modeling and the size of a mod.

Keep up the good work!

[WinkAllKerb'']

basically "select root" & "subassembly manager" act like (via some ksp fonction) a 3d coordinate system transform math algorythm to change a craft origin + reordering the MODULE{module(s)=...} of each parts, definetly should be an in game feature

And not sure but may be there is an alternative/complement with MODEL{model(s)=...} via very light *.cfg edit + yes mesh & texture call (it s may be even possible to have only one img for a whole set of piece and call this img with a different mesh allocation and texture assign/re-assign for each part) or similar concept wich could help all existing mod reducing there size sharing/merging texture & 3d model (require pre conceptual organisation and/or reorganisation). {model} is really a true powerfull new light & simplistic tools same as new attach node parameter (scale/rescale/node vector orient/position reconfig etc.) (and i can't imagine if they add a few more param in some incoming update .

So i m Investigating/testing and i tell ya ( was totally brainwashed yesterday xD)

Edited September 5, 2013 by WinkAllKerb''
typo + complement after quick check of some source code here & there

[Gus]

[ EDIT: Apparently this is a known feature of the VAB. Move along, nothing to see here.]

I discovered something interesting about attaching to your squarish parts today.

Take say, a structural frame hall. If you leave it in it's default vertical orientation, and try to attach an antenna to it's side, the antenna will be mounted radially and look silly if not centered.

If however, you first rotate the structural frame hall to lie horizontally, and then attach the antenna to the top flat surface, the antenna will mount vertically (ie. normal to the plane of the horizontal surface) at ANY location on this surface.

This even works when I rotate the piece though 30 or 60 degrees to make the bevelled surface horizontal. The antenna will mount normal to the beveled side at any location.

The only stock piece I know of where you can test this (very few rectangular stock parts) is the RoveMate. It behaves the same way.

I believe this is very useful to know when building craft with parts with flat sides.

Sorry if this is "old news" (or in a manual).

Edited September 5, 2013 by Gus

[WinkAllKerb'']

oki, so here the first kind of thing that could be done: (wich allow to remove 3 folders)

(edit: + not checked all the existing texture but this could be probably reproduce for many part especially if you plane around the "mesh" pattern for the whole set and remove almost all the *.png/mbm but 10 to 20 or so, wich is a totally speculative approximation but that's the idea)

weri_Frame2xHub2m.cfg

PART
{
name = weri_Frame2xHub2m
module = Part
author = Alskari, WinkAllKerb'

MODEL
{
   model = HSH/Parts/Frame_2xHub/model
   position = 0, 0 ,0 
   scale = 0.5, 0.5, 0.5
   rotation = 0, 0 , 0 
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
texture = model000 , HSH/Parts/Frame_2xHub/model000
texture = model001 , HSH/Parts/Frame_2xHub/model001
texture = model002 , HSH/Parts/Frame_2xHub/model002
texture = model003 , HSH/Parts/Frame_2xHub/model003
texture = model004 , HSH/Parts/Frame_2xHub/model004
}

rescaleFactor = 1

node_attach = 0.8125, 0, 0, 1, 0, 0 , 0
node_attach = -0.8125, 0, 0, -1, 0, 0 , 0
node_stack_right = 0.8125, 0, 0, 1, 0, 0 , 0
node_stack_left = -0.8125, 0, 0, -1, 0, 0 , 0

node_attach = 0, 1.375, 0, 0, 1, 0, 0
node_attach = 0, -1.375, 0, 0, -1, 0 , 0
node_stack_top = 0, 1.375, 0, 0, 1, 0 , 0
node_stack_bottom = 0, -1.375, 0, 0, -1, 0, 0

cost = 5000
category = Structural
subcategory = 0
title = 2m Structural Frame 2x
manufacturer = W.E.R.I.
description = Structural bit
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 2
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 100
breakingForce = 25000
breakingTorque = 25000
maxTemp = 5000
fuelCrossFeed=True

vesselType = Ship

}

weri_Frame2xHub2m-Perp.cfg

PART
{
name = weri_Frame2xHub2m-Perp
module = Part
author = Alskari, WinkAllKerb'

MODEL
{
   model = HSH/Parts/Frame_2xHub/model
   position = 0, 0 ,0 
   scale = 0.5, 0.5, 0.5
   rotation = 0, 90 , 90 
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
texture = model000 , HSH/Parts/Frame_2xHub/model000
texture = model001 , HSH/Parts/Frame_2xHub/model001
texture = model002 , HSH/Parts/Frame_2xHub/model002
texture = model003 , HSH/Parts/Frame_2xHub/model003
texture = model004 , HSH/Parts/Frame_2xHub/model004
}

rescaleFactor = 1

node_attach = 0, 0, 1.375, 0, 0, 1 , 0
node_attach = 0, 0, -1.375, 0, 0, -1 , 0
node_stack_back = 0, 0, 1.375, 0, 0, 1 , 0
node_stack_front = 0, 0, -1.375, 0, 0, -1 , 0

node_attach = 0, 0.8125, 0, 0, 1, 0, 0
node_attach = 0, -0.8125, 0, 0, -1, 0, 0
node_stack_top = 0, 0.8125, 0, 0, 1, 0, 0
node_stack_bottom = 0, -0.8125, 0, 0, -1, 0, 0

cost = 5000
category = Structural
subcategory = 0
title = 2m Structural Frame 2x - Perp
manufacturer = W.E.R.I.
description = Structural bit attachable perpendicular to normal.
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 2
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 100
breakingForce = 25000
breakingTorque = 25000
maxTemp = 5000
fuelCrossFeed=True

vesselType = Ship

}

weri_Frame2xHub-Perp.cfg

PART
{
name = weri_Frame2xHub-Perp
module = Part
author = Alskari, WinkAllKerb'

MODEL
{
   model = HSH/Parts/Frame_2xHub/model
   position = 0, 0 ,0 
   scale = 1, 1, 1
   rotation = 0, 90 , 90
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
texture = model000 , HSH/Parts/Frame_2xHub/model000
texture = model001 , HSH/Parts/Frame_2xHub/model001
texture = model002 , HSH/Parts/Frame_2xHub/model002
texture = model003 , HSH/Parts/Frame_2xHub/model003
texture = model004 , HSH/Parts/Frame_2xHub/model004
}

rescaleFactor = 1

node_attach = 0, 0, 2.75, 0, 0, 1 , 0
node_attach = 0, 0, -2.75, 0, 0, -1 , 0
node_stack_back = 0, 0, 2.75, 0, 0, 1 , 0
node_stack_front = 0, 0, -2.75, 0, 0, -1 , 0

node_attach = 0, -1.625, 0, 0, -1, 0, 0
node_attach = 0, 1.625, 0, 0, 1, 0, 0
node_stack_top = 0, 1.625, 0, 0, 1, 0, 0
node_stack_bottom = 0, -1.625, 0, 0, -1, 0, 0

cost = 7500 // temp adjustement
category = Structural
subcategory = 0
title = 4m Structural Frame 2x - Perp
manufacturer = W.E.R.I.
description = Structural bit attachable perpendicular to normal.
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 4
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 100
breakingForce = 25000
breakingTorque = 25000
maxTemp = 5000
fuelCrossFeed=True

vesselType = Ship

}

I m now trying to trick the orientation matter, got a few idea to workaround we'll see

Edited September 5, 2013 by WinkAllKerb''
typo

[Alskari]

oki' date=' so here the first kind of thing that could be done: (wich allow to remove 3 folders)

(edit: + not checked all the existing texture but this could be probably reproduce for many part especially if you plane around the "mesh" pattern for the whole set and remove almost all the *.png/mbm but 10 to 20 or so, wich is a totally speculative approximation but that's the idea)

[img']http://i.imgur.com/qgyaN6A.jpg

I knew this was possible, but I despise keeping track of nodes within .cfg files. Is there a new trick for that as well? Could I just make different Unity objects w/ node arrangements?

At any rate I appreciate you looking into it.

[WinkAllKerb'']

I knew this was possible, but I despise keeping track of nodes within .cfg files. Is there a new trick for that as well? Could I just make different Unity objects w/ node arrangements?

At any rate I appreciate you looking into it.

regarding the node tracking inside the cfg i see that as a false/fake matter as all *.craft files wich are txt editable too in one click keep track of the nodes anyway so it's for everyone the same and i think irrelevant to despise even if i can understand what you dislike in that, fact is the actual state of the game overpass this, so as it s for everyone the same i think you should keep cool with that (that just require very basic math +&- so anyone can do this as Johnsonwax explained in his tutos following Mu release posts) + nodes in a {model} type cfg files are in no way linked to the unity node object they are totally independant nodes.

So it s not a really a trick but some new cfg syntax/command released by squad in the interest of everyone. (texture & 3d model loading, physics engine, multiple add on install whines related, and of course and most important some new possibilities to explore etc.)

it's possible to add/remove as much node as you want, it's all about node type/ 3d transform/ surface projection/ vectoring orient/x,y,z scaling transfo for the node to be usable.

(wich start become fun with collider + sphere, ovoïde, etc. the other day i was playing with stock sphereprobecore in a complex assemblage and adding some node to the sphere surface wich is decal from the part origin for example you can have to deal with formula like that if you want to do a polished work with complex scaling and orient: some complex 3dtransformexample and don't want to be limited by the syntax/tools provided by squad wich are just wisiwyg of thoose kind of formula in some way all 3d tools, catia,euclid,autocad,blender,3dsmax etc. use thoose kind of things, preformated complex math algorythms and you can link this with what you despise in this way: it depend if you look at this from the artistitic creative point of view or brut math algorythm point of view or provided by squad syntax point of view, that s why i say you shouldn't pay too much attention to this nodes coordinate, i can just be neutral regarding what's everyone try to protect behind this)

note sure i well understood the second part: unity 3d model and integrated objects are untouched and remain as this, after you can transform/combine any single or multiple 3dmodel to create a new ossature, and reproduce by calcul prexisting node(s) but also create totally new one that are not in the *.mu for this new original part and assign some fonction/module via *cfg. But it's totally independant from Unity environnement.

(most powerfull tools i can imagine is: recombine exsiting models (vab/sph environnement without collider & node restriction ), map the extern 3d ossature and texture (isamapsat like), autogenerate a new model & texture pattern (any parsing + transfo like algorythm) xD )

I pursue getting ride of the axis matter.

Edited September 5, 2013 by WinkAllKerb''
typo + pidgin meaning adjustements

[WinkAllKerb'']

try this part: (i found a few other way too to workaround this but this path/way sound good to improve and look deeper in regarding phy engine & center of mass)

weri_Frame2xHub2m_MonoPart.cfg

PART
{
name = weri_Frame2xHub2m_MonoPart
module = Part
author = Alskari, (WinkAllKerb' *.cfg edit)

MODEL
{
   model = HSH/Parts/Frame_2xHub/model
   position = 0, 0 ,0 
   scale = 0.5, 0.5, 0.5
   rotation = 0, 0 , 0 
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
texture = model000 , HSH/Parts/Frame_2xHub/model000
texture = model001 , HSH/Parts/Frame_2xHub/model001
texture = model002 , HSH/Parts/Frame_2xHub/model002
texture = model003 , HSH/Parts/Frame_2xHub/model003
texture = model004 , HSH/Parts/Frame_2xHub/model004
}

rescaleFactor = 1

//adjust the space within fictives nodes the way you want regarding physic engine calculation more spaced or almost merged (don't seem to work if merged with double/quadruple node @ the same place but if i made a vectoring orient error while trying) or intermediate keep an high attention to the vectoring node orient - i spaced them as tuto purpose
node_attach = 0, -0.875, 0, 0, 0, -1 , 0 //adjust here too
node_stack_nonroot7 = 0, -0.875, 0, 0, 0, -1 , 0 //adjust here too
node_attach = 0, 0.875, 0, 0, 0, -1 , 0 //adjust here too
node_stack_nonroot6 = 0, 0.875, 0, 0, 0, -1 , 0 //adjust here too
node_attach = -0.3125, 0, 0, 0, -1, 0 , 0 //adjust here too
node_stack_nonroot5 = -0.3125, 0, 0, 0, -1, 0 , 0 //adjust here too
node_attach = 0.3125, 0, 0, 0, -1, 0 , 0 //adjust here too
node_stack_nonroot4 = 0.3125, 0, 0, 0, -1, 0 , 0 //adjust here too
node_attach = 0, 1.375, 0, 0, 1, 0, 0
node_stack_nonroot2 = 0, 1.375, 0, 0, 1, 0 , 0
node_attach = 0.8125, 0, 0, 1, 0, 0 , 0
node_stack_nonroot1 = 0.8125, 0, 0, 1, 0, 0 , 0
node_attach = -0.8125, 0, 0, -1, 0, 0 , 0
node_stack_nonroot0 = -0.8125, 0, 0, -1, 0, 0 , 0

node_attach = -1.3125, 0, 0, 0, -1, 0 , 0 //adjust here too
node_attach = 0, -1.375, 0, 0, -1, 0, 0 
node_stack_root2 = -1.3125, 0, 0, 0, -1, 0 , 0 //adjust here too
node_stack_root1 = 0, -1.375, 0, 0, -1, 0, 0

cost = 5000
category = Structural
subcategory = 0
title = 2m Structural Frame 2x MonoPart
manufacturer = W.E.R.I.
description = Structural bit
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 2
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 100
breakingForce = 25000
breakingTorque = 25000
maxTemp = 5000
fuelCrossFeed=True

vesselType = Ship

} 

edit2: suggestion, add a assymetric 'colour code'/icon/whatever to your texture & also assymetric texture pattern projection for easier identification in game of the roots nodes

Edited September 6, 2013 by WinkAllKerb''
typo

[Alskari]

Mod has been updated. Folder organization has been improved. A few minor model changes, but more importantly Gus has been kind enough to rework the weights for everything according to logic, as opposed to my previous arbitrary guessing method.

I've been working on a new series of parts which should improve the look and versatility of this mod. Expect to see some examples soon.

WinkAllKerb - I haven't had a chance to look at the .cfg in the game you provided, but I will do so this weekend. Thanks again for your interest.

[WinkAllKerb'']

np, also verify how this "fith element" vectoring node orient impact with "breakingtorque" & "breakingforce" "dragModelType" "maximum_drag" "minimum_drag" "angularDrag" (and strut connector equivalent also) as i myself not verified that atm. There a possibilities of axis transfo (like unity & internal)

(edit: as long as you keep them '=' no matter but verify that if you intend to have thoose paremeters pairs different/unbalanced in the future but shouldn't be a matter at all regarding the SF orientation of your work merge them @ a originalNode_value+- '1 e n' so ficitive node will be unseeable )

Edited September 6, 2013 by WinkAllKerb''

[Alskari]

Working on a new look and style.

[jackal40]

Looking good - can't wait to see more!

[ahappydude]

Dome style looks great!

[Alskari]

Thanks guys!

Taking some of the reworked parts out for a crash landing on Minimus.

[Alskari]

This is an example of the .cfg files I'm moving to. Hopefully this will save a ton of memory. Also it's easier for me. Below is a single .cfg file I'm using on a new part (Ultralight Frame) which is shown as above.

It has two orientation options. Attachment from one of 4 hallway nodes (TF1, TF2, TF3, TF4) or on one of two empty wall nodes (TF5, TF6). The parts rooted to the hallway connectors do not have a special designation, the ones rooted to the wall connection are designated '-P' for perpendicular.

The parts at a scale of 1 (4m) do not have a special designation, the ones scaled .5 (2m) have a '-2m' designation.

Suggestions or questions are welcome.

PART  
{  
name = UL_Frame
module = Part
author = Alskari

MODEL
{
   model = HSH/Parts/UL_Frame
   position = 0, 0 ,0 
   scale = 1, 1, 1
   rotation = 0, 0, 0
}

rescaleFactor = 1

NODE
{
   name = srfAttach1
   transform = TF3
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach2
   transform = TF4
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach3
   transform = TF5
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach4
   transform = TF6
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = top
   transform = TF1
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach
   transform = TF2
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

cost = 5000
category = Structural
subcategory = 0
title = Ultralight Frame (Square)
manufacturer = W.E.R.I.
description = Frame with space for two wall options and 4 hallway connections.
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 6
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 100
breakingForce = 25000
breakingTorque = 25000
maxTemp = 5000
fuelCrossFeed=True

}  

/////////////////////////////////////////////

PART  
{  
name = UL_Frame-P
module = Part
author = Alskari

MODEL
{
   model = HSH/Parts/UL_Frame
   position = 0, 0 ,0 
   scale = 1, 1, 1
   rotation = 0, 0, 0
}

rescaleFactor = 1

NODE
{
   name = srfAttach1
   transform = TF3
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach2
   transform = TF4
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach3
   transform = TF1
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach4
   transform = TF2
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = top
   transform = TF5
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach
   transform = TF6
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

cost = 5000
category = Structural
subcategory = 0
title = Ultralight Frame (Square)-P
manufacturer = W.E.R.I.
description = Frame with space for two wall options and 4 hallway connections.
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 6
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 100
breakingForce = 25000
breakingTorque = 25000
maxTemp = 5000
fuelCrossFeed=True

}  


PART  
{  
name = UL_Frame-2m
module = Part
author = Alskari

MODEL
{
   model = HSH/Parts/UL_Frame
   position = 0, 0 ,0 
   scale = .5, .5, .5
   rotation = 0, 0, 0
}

rescaleFactor = 1

NODE
{
   name = srfAttach1
   transform = TF3
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach2
   transform = TF4
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach3
   transform = TF5
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach4
   transform = TF6
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = top
   transform = TF1
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach
   transform = TF2
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

cost = 5000
category = Structural
subcategory = 0
title = Ultralight Frame (Square)-2m
manufacturer = W.E.R.I.
description = Frame with space for two wall options and 4 hallway connections.
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 1.5
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 100
breakingForce = 25000
breakingTorque = 25000
maxTemp = 5000
fuelCrossFeed=True

}  

/////////////////////////////////////////////

PART  
{  
name = UL_Frame-P-2m
module = Part
author = Alskari

MODEL
{
   model = HSH/Parts/UL_Frame
   position = 0, 0 ,0 
   scale = .5, .5, .5
   rotation = 0, 0, 0
}

rescaleFactor = 1

NODE
{
   name = srfAttach1
   transform = TF3
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach2
   transform = TF4
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach3
   transform = TF1
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach4
   transform = TF2
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = top
   transform = TF5
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

NODE
{
   name = srfAttach
   transform = TF6
   size = 1.0
   method = FIXED_JOINT //FIXED_JOINT, HINGE_JOINT, LOCKED_JOINT, MERGED_PHYSICS or NO_PHYSICS
}

cost = 5000
category = Structural
subcategory = 0
title = Ultralight Frame (Square)-P-2m
manufacturer = W.E.R.I.
description = Frame with space for two wall options and 4 hallway connections.
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 1.5
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 100
breakingForce = 25000
breakingTorque = 25000
maxTemp = 5000
fuelCrossFeed=True

}  

Edited September 12, 2013 by Alskari
Clarity regarding nodes.

[ahappydude]

Its really nice to see that you are still making parts for ksp ! I got a few orbiting stations made entirly by hs&h ^^ And it still works sweet with seasickness cure before hitting space and after re entrying

[coolmodi]

Without this mod KSP uses around 2GB, with it it's nearly at 4GB all the time, with very frequent crashes because of enough Memory

Is it normal that this mod takes that much RAM?

[Alskari]

Without this mod KSP uses around 2GB, with it it's nearly at 4GB all the time, with very frequent crashes because of enough Memory

Is it normal that this mod takes that much RAM?

While I haven't had issues with crashes, obviously some people have. The current release is also much larger than it needs to be. I didn't realize how much more condensed I could have made the mod. As for the RAM usage I haven't done a thorough investigation, so I can't say what is normal.

I expect to have an updated release before Friday. Even with bigger textures and higher face counts, the new release is looking to be much smaller than the current one. I'd recommend checking back then.

[coolmodi]

I expect to have an updated release before Friday. Even with bigger textures and higher face counts, the new release is looking to be much smaller than the current one. I'd recommend checking back then.

Sounds good

I hope this will get better, because i really like this mod, but crashes every 10min make it impossible to use for me.

Maybe this http://bugs.kerbalspaceprogram.com/issues/765 is still a problem, i don't know, but this mod also uses .png textures.

Edit: Seeing that there are 227 PNGs in the mod, and all are 1024x1024, that "bug" would explain those 1gb+ RAM usage.

Edit2:Converted all the the PNGs to 128x128, bringing RAM usage from 3,6GB to 2,9GB. Maybe it's stable now like this.

Edited September 18, 2013 by coolmodi

[Alskari]

I had seen some discussion on png not working as well as tga format so I switched all of my new textures to the tga format. Glad I did. I was planning on moving all current parts to a mediafire 'Legacy' optional download, maybe I'll convert the textures first.

Thanks for your investigation.