WinkAllKerb''

wak-mk3-fus01.cfg PART { name = wak-mk3-fus01 module = Part author = C. Jenkins, WinkAllKerb' MODEL { model = Squad/Parts/FuelTank/mk3Fuselage/model position = 0, 0 ,0 scale = 1.25, .625, 1.25 rotation = 0, 0, 0 // parent = anotherModelTransform <---------Not necessary unless Second or subsequent part. // texture = model000 , Squad/Parts/Utility/dockingPortLarge/model000 // texture = model001 , Squad/Parts/Utility/dockingPortLarge/model001 } rescaleFactor = 1 // --- node definitions --- node_stack_top = 0.0, 0.965625, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -0.965625, 0.0, 0.0, 1.0, 0.0 //Original scaled value: 0.0, -0.968125, 0.0, 0.0, 1.0, 0.0 node_attach = 0.0, 0.0, -0.4, 0.0, 0.0, 1.0, 1 cost = 275 category = Structural subcategory = 0 title = Mk3 Fuselage Half-L manufacturer = C7 Aerospace description = This airframe fuselage features the latest in re-entry survivability. Apparently air gets very hot at high speeds (Who knew?!). To combat this, we attached only the finest in slightly used thermal tiles to the under belly. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 mass = 0.15 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 1 crashTolerance = 50 breakingForce = 50 breakingTorque = 50 maxTemp = 3000 fuelCrossFeed = True } Lenght/2 mk3 fuselage notice a few things: - the price is a bit weird as i not removed the fuel cost and it's half less expansive as the mk1 fuselage - the 3D model ossature/frame top bottom not totally symetric wich create some not really aesthetic visual "overflow" when stacking parts (if you 180° 1 out of 2 while assembling to solve this frame overflow, then matter is texture junction/link) (- Drag not adjusted) And definetly as said actually i ll leave MK3 on the side as there's not so much basic material to weld around with. ( + bac9 and TT [& some others i sadly not been able to try yet mainly due to the memory matter loading lot of mod together :/ ] mk3 like parts are real nice until more stock mk3 parts will be added )

Thanks a lot for this Tuto TT it's great help to understand a few things regarding coordinate/ system transfo/multiple collider overlap/etc. & helped me to solve some welded iva matter even i don't use the 3d tools directly

Kerbal Kart i m in xD need some funny driver avatar now huhu.

Nope 85% chances it will come as you said with a fuselage on top of it, the photo only show the animated chassis of the irl part, wich have been designed this way mainly for two things: lot of designs/tech choices regarding safety factors + high speed trains. So in KSP, inter module and probably not under mainly regarding the fact of what i plan to do with the incoming skycrane welded part, i prefer to keep a standardized delta-space between module to combo docking port and inner landing strut (once again rocket company thread => Munlowe Skycrane), the use of inner landing strut to enhance module stabilty while landing phase require an high attention with parts collider, randomly placed too large under wheels probably won't fit as easily with this but if i found a nice way to play with landing strut/wheels animations + anoying shaking with approximative scaleVsRescale (wich you can see on the tiny tanksteer prototype wheel in the set). Balancing a smaller overall parts count with welded parts while keeping a high assemble modularity & staying close to [stock] spirit real puzzle me sometime (lot of the actuals welded parts available real need some improvement regarding this and should be considered as first shot that will be improved after the set offer a nice basis to play with) (& yup born in .fr one of the small meaningless neutrino in Universe ;x couldn't resist sry ) @Darth Paul: Thanks Including welded MK3 parts in the set actually more on my crazy to do board, still a lot of thing i want to test/do before playing with MK3. I ll give a quick look welding MK3 in the nexts days and PM ya and/or post here a L/2 Mk3 fus. *.cfg file. Regarding welded fuels tanks i have delayed the investigations regarding fuel consumption, mass transfer etc. should come later question is when xD. (same with lift and wings, you can check PolecatEZ welded parts thread he tried some things arounds rescaled wings ) (my actual main focus is providing a basis set of structurals, dock, welded animated object & iva for bigger modulable station, base, ship use with low part count and then improve/opti this basic set) Until that you can check Ubiozur welded parts thread, he actually work around the welded Fuel Tank with a better knowledge of the matters (some explains can be found near page 2 or 3 can't remember exactly with this.

consider this as a planned incoming part in some of the next update

+1 By mutli-material you mean multiple {model} parts ? (anyway i will test this ) Great work

Yesterday Update spaceport Hotfix (see main post for details) + an "around the SX3 concept" with news welded part ImgurGallery. Main gallery also updated with the new parts.

Was thinking about something like that a few week ago you made it, tip top

Love it very nice 3dmodels and textures themes need more

Thoose PodHab look real promising great work as usual Yogui

The strut connector thing is related to structural reinforcement to reduce the use of strut connector between parts wich quickly kill the part count of all craft, so i implemented this in almost every part: (150 breakingtorque & 150 breakingforce)x4 + 200 (basis for each part) for a total of around 800 per part. I m still actually testing this value to keep the ship breakable while reducing the use of strut connector between part. The 150x4 is an equivalence with the strut connector linear and angular strenght resist to breakingforce and breaking torque wich is totally a test feeling equivalence. This is also included in the part price this way (4 (strut connector weight + cost) / 2 [could change to /3 in some future update])+welded cost & weight not to pay twice the cost of strut and there weight so + 500cost & +0.1 t per part for this structural reinforcement This is some early test and probably require more adjustement. All parts "cost" and "weight" are now calculated from subparts parameter addition + some ratio and/or constant (subpart scaling related ratio, integrated module + or -, module scaling ratio , additionnal reinforcement, extra design ratio, extra design constant, etc.) Some parts may look expansive but most of the time there cost and weight is real near what you should get by building the welded part the normal way in VAB or SPH (a few thing still need to be adjusted with more precision but not that much) Not sure i well understand the second part so i ll try a quick Rukia® metaphoric draw ( ) just to ensure i understand what you meant: You mean a concept like the french TGV with wheel between wagon insteed of under them ? (wish i could made this kind of intermodule rotate too like the tgv would be real great with some kind of dynamical rotating connection xD, plugin anyone ? hop hop hop xD ) In addition most of the parts in this update will be improved in the future, with a few more integrated welded things (ressource and/or module and/or aesthetic details like top/bottom hatch etc.) some also may be rewelded together to reduce more the parts count for bigger station and spaceship, probably a few more structural scaling variation to enhance modularity between parts (thoose parts are really an early first shot around the SX3 concept.) Actually the new SX3 parts allow to build some station or spaceship with M.M.B. inner/inter system push/pull/standByDocking capacity this was the main idea behind this (i ll try to put some pict today after building an inner system cargo) Thanks a lot for your feedback Cy-one i myself didn't get lot of time to play with thoose new parts yet :/

Update: 26 new Parts and a few other things (details in the update history) Enjoy

Definetly one of the most important thing when creating new parts (either {MODEL}'s ones or else) is to be sure there no conflictual 'name' PART { name = ...... ... } call wich is really annoying in most case, especially when an existing part have been modified without name change, that s the main reason i no longer use some mods that use the same name as squad ones due to this kind of conflict.

nice will test this one

I quickly made this. some other stuff should come later. randomname.bat save this in squad/parts/ double click and youpi result all [stock] *.cfg compiled in 2 single *.txt that you can use with all "office" like tools (one include // ---comment---, the other one without ) @ECHO off ECHO Erasing previous concatenate ERASE parseFull.txt ECHO Processing subfolder *.cfg concatenate ... FOR /R %%i IN (*.cfg) do type "%%i" >> parseFull.txt ECHO Processed PAUSE ECHO Deleting previous Parsing Files ... ERASE parseSlim.txt ECHO Processing Parsing ... FOR /F "eol=/ tokens=1,2,3* delims= " %%a IN (parseFull.txt) do @echo %%a %%b %%c %%d >> parseSlim.txt ECHO Processed PAUSE @ECHO on Use this in respect with everyone licence i'm not responsible if you do not !

for sure it is all feedback welcome, i guess new parts updates will be very delayed until i m done with the textual part automation aspect of the process. I ll probably just do a little spaceport update with latest fix on existing parts and a few new station/spaceship/structural parts with the same design/colour scheme of the M.M.B. chassis & Command modules

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 )

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

try this: // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_? = ? node_? = ? node_? = ? stackSymmetry = n // 0= x1, 1= x2, 2= x3 , 3= x4 etc.

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.

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

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)

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 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

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

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