Jamin

Your trick solved my immediate problem. (My philosophical "why were these parts designed this way in the first place" question stands, but hmm seems less crucial now.)

I saw a month or few ago a beautiful space station, roughly of the Space Odyssey wheel kind. The outer ring was made of Mk3 Passenger Modules joined at bulkheads with perhaps a 15-degree bend at each attachment, plus overlap as needed to close the narrow cleft caused by the bend at the attachment. Very pretty! Kudos, Kerbal architect. And so I wanted to build my own, a design with my own quirks and choices. One thing I wanted was to have the bottom of the Passenger Module face "down" - that is away from the hub. So, building from the hub outward, I find myself wanting to (e.g.) place a BZ-52 Radial Attachment on the end of a spoke, ragged end outward, and then attach the center of the roof of a Mk3 Passenger Module to that ragged end. But what I want, the passenger module very much does NOT want. It only wants to attach at either of its two bulkheads. (And before you say "just kludge it with parts internal to the passenger module etc", I should mention that instead of the BZ-52 I might also want a pair of mated Clamp-o-tron Docking Ports so that the station could be assembled in orbit.) So... I edit the CREW.cfg file that I found under GameData/Squad/Parts/FuelTank/mk3Fuselage (oh, hello, do you think the kerbals on the station realize they are living in a fuel tank???), changing attachRules: 18c18 < attachRules = 1,0,1,1,0 --- > attachRules = 1,1,1,1,0 (actually, I made a JAMIN.cfg alongside CREW.cfg, renamed a few things inside it and apparently did not break too many things). This change _helps_ but is not perfect. Now the Jamin Passenger Module will attach on its roof side, but the attachment doesn't occur AT the roof, but more like at the center of the module. The clamp-o-trons and an entire structural fuselage segment attach plunged into the interior of the passenger module. (I wonder what the passengers make of this???) So, there is apparently at least one more thing for me to fix to have the attachment occur AT the roof rather than through the roof, and I would like to know what that is exactly, but I also have a larger philosophical question: Why were these Mk3 Passenger Modules set up to be so finicky about attachments in the first place? For that matter, this same question applies to basically the complete line of Mk3 parts - fuel tanks, cargo holds - because they seem to all behave this way. Is there some other benefit obtained by restricting attachment?

I've been trying to do some fairly simple 'modding'. Okay, EXTREMELY simple modding. I wanted to join a bunch of trusses together to reduce part count. (Yes, I'm aware of the 'UbioWeldingLtd' mod, and it sounds excellent, but for some reason it is broken for me in 24.2 with MechJeb, InfernalRobotics, and TweakScale.) Turns out even a stack of four trusses was too complicated for starters. So I tried what I thought would be The Very Simplest Thing : Make a 'new' truss that is basically a re-badged clone of a stock truss. That's right, an 'assembly' of one part, changing none of its parameters. I had imagined that what would go in my config file would be something like this: PART { name = trussClone module = Part author = NovaSilisko, Jamin MODEL { model = Squad/Parts/Structural/trussPiece1x/model } title = Clone of the 1x1 Truss manufacturer = Jamin Corporation description = Nothing at all like a plain 1x1 truss, except for everything. [INDENT]}[/INDENT] In my fantasy-land, everything else would be inherited in some smart fashion when it was noticed that PART{} contained one or more MODEL{}. So maybe the default cost and mass could be the sum of all the costs of the MODELs within, the strength and temperature of the assembly could be that of the least strong and most melty components within, and maybe there's some wise way to combine attachRules of all the pieces into default attachRules for the new part. I was very astonished to learn that the minimum needed to accomplish my goal of make a clone of the 1x1 truss was more like this (and it still might not be quite right): PART { name = trussClone module = Part author = NovaSilisko, Jamin MODEL { model = Squad/Parts/Structural/trussPiece1x/model } rescaleFactor=1.0 // default is something like 2, why??? node_stack_bottom = 0.0, -0.5592728, 0.0, 0.0, 1.0, 0.0, 1 node_stack_top = 0.0, 0.5592728, 0.0, 0.0, 1.0, 0.0, 1 node_attach = 0.0, -0.5592728, 0.0, 0.0, -1.0, 0.0 cost = 25 category = Structural subcategory = 0 title = Clone of the 1x1 Truss manufacturer = Jamin Corporation description = Nothing at all like a plain 1x1 truss, except for everything. attachRules = 1,1,1,1,0 mass = 0.1 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 1 crashTolerance = 80 breakingForce = 200 breakingTorque = 200 maxTemp = 5000 } I think the greatest offender might have to be 'rescaleFactor'; lacking inheritance, I would have expected the default to be 1.

(Followup to my prev reply) I just now tried settings from 0.03 up to 1.2. I see oscillations across the range. The oscillations at 0.3 look nicer, not so spasmodic... :-) Also, by "MacBook Air", I meant a 3-year-old one. Might not have the most snappy graphics.

I had hit this bug long ago, soon after 0.23.5 came out, and it was sort of a brick wall versus something I wanted to build. I've been hoping somebody else would notice&complain and that it would get fixed. The recording was deliberate to show this bug. One detail I forgot to mention was that I use a MacBook Air running OSX 10.9.4. Another reply suggested that this might be chalked up to part-clipping. I don't think so. I can build it with I-beams instead of girders - I think their skinnier size avoids clipping, assuming I understand when part clipping does/doesn't occur - and can still obtain these spontaneous oscillations immediately after the physics "turns on". My "Max Physics Delta-Time per Frame" is 0.04 secs. I have no clue if that value is stock/high/low. I'll try twiddling it. Thanks!

At 2:20 in this vid, a simple craft I built with latest KSP (0.24.2) and Infernal Robotics (0-18-4) exhibits unbounded oscillations when placed on the pad. (Everything earlier in the vid is me building it.) This bug seems to occur when high symmetry (8-fold or 6-fold) is employed with hinges, rotators, etc. The final girders I added seem to make it happen more reliably. I first tried IR with KSP 0.23.5 (asteroids...) and it was present then.