xtremeqg

Do'h... totally forgot about that one! Normally I never use it because it means more clicking in the tracking station to delete all the floaty bits. However, with the TR-1A being broken I guess there's no alternative. I really wish there were clean radial decouplers so I wouldn't have to fiddle with the rotation and offset gizmo but c'est la vie.

So... I'm quite stumped as in how to attach a different vessel radially to for example a carrier rocket. Merging the two vessels together in the VAB is easy enough, but finding a clean way to attach them...? Initially I figured to just use the Mk2 Clamp-O-Tron that the vessel below has. Unfortunately there are no attachment points on the docking port, even when deployed. Now, the most obvious alternatives are the TT-38K, TT-70, or the hydraulic manifold. As these are meant for radially attaching things they are functional, however they also leave ugly residual parts and are therefore not "clean" (I don't like spiky bits sticking out of permanently active vessels). So instead, I tried an inverted TR-1A on top of the BZ-52. This worked... until I tried to stage it. Somehow the two vessels are fused... Looking at the save file, I can see the the following: Part #12 (stackPoint1) has parent = 1, srfN = srfAttach, 1, attN = top, 13. Part #13 (stackDecoupler) has parent = 12, attN = bottom, 12, attN = top, -1. Part #14 (mk2FuselageShortLiquid) has parent = 13, srfN = srfAttach, 13. If I interpret this correctly, this means that the BZ-52 is radially attached to the root node, the TR-1A is attached to the BZ-52 and the chain ends there. Yet somehow the detached vessel remains surface-attached to the TR-1A. So I guess I should file a bug report for the TR-1A not decoupling surface-attached parts? In any case, how to cleanly separate radially attached vessels other than save file hacking (ie. using a stock radial decoupler and deleting the ugly bits later)? I looked at a bunch of mods and mod packs but I can't find the decoupler I'm looking for.... Any ideas?

Nop, what happened was the following: * Sent Jeb on a Mun mission * Launched some other unmanned sattelites in the mean time (timewarp et al) * Mun landing etc etc etc started getting low on supplies so burned all my dV in the direction of Kerbin for a near 90-degree reentry (woot no deadly reentry mod). * Landed, recovered vessel * Launched some more unmanned sattelites (timewarp et al) * Wanted to rename some of them but got stuck in the tracking station with the "cannot exit" bug. * Checked debug log, saw nullpointer violation and went looking in my save file for the kerbal I fired (scientist with max stupidity lol?) way back that I got from a rescue mission. * While looking noticed message saying something along the lines of "something something TAC something : Deleting Jeb" * No more Jeb in roster, no fired kerbal either. * Edited both back to life, fixed some weird roster indexes while I was at it (most were set to zero, some to -1, others were incremental 1... 9) and made the unfireable kerbal less stupid (har!) * Merrily launched 20 more things I went and looked but unfortunately my log file's contents appears to be only showing today (I guess KSP truncates it every time?) but I will send you everything (including save file, mod list) when it happens again. Ps I did look on page 1 altho in hindsight probably not well enough for any particular place to report bugs / issues and any guidelines.

Found an interesting bug where TAC decided to delete one of my kerbals that was currently drinking coffee in the staff building. TAC was still tracking the state of a vessel that had already been recovered: ..... ReturnFromSurface { completed = 252829.21337237 vessel { name = Lander flag = Squad/Flags/default } crew { crews = Jebediah Kerman } } ..... SCENARIO { name = TacLifeSupport scene = 5, 7, 6 SavedGameSettings { IsNewSave = False Enabled = True HibernateInsteadOfKill = False RespawnDelay = 9203545 CrewMemberInfo { name = Jebediah Kerman lastUpdate = 252859.173372354 lastFood = 252859.173372354 lastWater = 252859.173372354 vesselName = Lander vesselId = 1c3aff43-5952-4b8e-b551-0b45aa4be45d hibernating = False } .... VesselInfo { vesselName = Lander vesselType = Ship numCrew = 1 numOccupiedParts = 1 lastUpdate = 252859.173372354 lastFood = 252859.173372354 lastWater = 252859.173372354 lastOxygen = 252859.173372354 lastElectricity = 252859.173372354 remainingFood = 0.283031490436213 remainingWater = 0.187001600134518 remainingOxygen = 28.9797527702011 remainingElectricity = 250 remainingCO2 = 70.8807240487511 remainingWaste = 0.074022435408242 remainingWasteWater = 0.685124947200803 maxFood = 1.097 maxWater = 0.725 maxOxygen = 111.038 maxElectricity = 250 estimatedElectricityConsumptionRate = 0.035416666666667 hibernating = False Guid = 1c3aff43-5952-4b8e-b551-0b45aa4be45d } } } ....... As you can see, the completed time is earlier than the last updates. The vessel itself does not exist in my save file as it was recovered.

That's complete nonsense, please don't spew false information about things you don't know. The size difference between 32-bits and 64-bits comes from the availability of 64-bit words, which translates directly to larger registers. Now, for data nothing really changes. 32-bit datatypes remain to be 32-bits in size. Hell, even on an 8-bit or 128-bit platform they would still be the same size. I would expect unity's internal data structures to use a bit more memory (64-bit pointers, double the space usage). Textures, sounds, meshes and other assets will use the same amount of memory. A 32-bit PNG (24-bit color, 8-bit alpha) will never use more memory, the only thing that uses more memory is the pointer which holds the virtual memory location for the slab of memory it resides on which in this case is a 4-byte increase. tl;dr version: You are wrong, more addressing bits does not directly increase memory usage. Just storing addressing bits takes more memory.

Hmmm... I see a couple people that should run SuperPI to make sure their CPU isn't unstable. I've launched probably 2000 missions or more and I've yet to encounter the Kraken. I can't trigger it no matter how much I mess with Jool, Kerbol or the Mystery Boulder... I only managed to make some +500 part space stations dance by using too many flimsy docking ports and non-physical structure parts. But that's really asking for it.

Glad I could be of help Fandrel64. Interesting bug tho I haven't taken a peek at the DLL code. For sure seems like some filename parsing bug, be it in KSP or in this addon. Well... you can weld docking ports, just make sure you only have one docking port per part that includes the ModuleDockingNode module. From what I can tell this part module is probably looking for some animation or anchor on the model to use as a docking target so with a single docking port you'd be fine (quite similar to how engines can be welded). Of course there's nothing stopping you from welding multiple non-functional docking ports to the same part by removing ModuleDockingNode...

See any peculiar messages in the debug log when you load the game? (ALT+F12) Maybe it's just Unity's sub-meshes that don't work properly on Mac.

It's pretty much what the game decides to be "top" (I think it's the first node that is considered the top).

That's pretty much a KSP bug amplified by this mod. The VAB handles building "sideways" really poorly and appears to consider the distance between the CoM of your part and the connecting attachment node and eventually decides it's "too far". The workaround is to build "vertically" by reorienting the attachment nodes which you discovered yourself by rebuilding the welded part in various ways.

Haven't seen any news from UbioZur so took another stab at getting part welding to work. Rather than building part.cfg files and reloading the part database I intent to have a single dynamic part with properties that define all the sub-parts. This should speed up loading since KSP doesn't need to load each individual welded part, they are only defined in the vessel itself. So far I've been successful in cloning one part onto another part. Cloning multiple parts into the same part shouldn't be terribly difficult since Unity has built-in facilities for merging multiple meshes into a single mesh using sub-meshes (each with their own material). Below you can see two cloned parts, I cloned the appearance of one of the fuel tanks (note: I did not clone the colliders or attachment nodes so it is still using the originals). I'm not really a designer though so Interface-wise it is a bit problematic as you won't see any welded parts in your parts list. I was hoping to be able to add another tab/panel to the VAB similar to the one used for sub assemblies. Does anyone know how to do that? From what I can tell the editor's part panels seem hardcoded:(

Interesting, I'll try. To be honest I didn't see any sliders, just a button in the VAB that told me there's an update for toolbar something or other.

You may want to increase the mass, breakingForce and breakingTorque. KSP does not play well with really big parts.

It has probably been mentioned before in this thread but besides ignoring disabled engines it doesn't take gimbals into account either. I had a single stack rocket with 4 engines on a quad coupler for testing and noticed that during steering it was completely shutting down engines on a certain side (treating engines like RCS I suppose). Problem however is that gimbal could have done the same thing and would not cause the vessel to lose thrust. Other than that though this mod is a must-have for anyone wanting to build a shuttle-like rocket without spending 3 days balancing fuel and thrust to make it fly straight.

THIS I hate it when I need to increase my part count just to enable something.

This is a KSP problem which has nothing to do with this mod. You can build really well vertically but outwards has always been a problem. You can try some tricks such as rotating the root object and trying to attach things differently.

Provided it was built using stock parts, yes

Adjust the breakingforce and breakingtorque parameters in the part.cfg file. I've noticed that in many cases it is too small for the total part mass which causes structural failures even with the slightest movement.

The following seems a bit low: breakingForce = 457.9819 breakingTorque = 457.9819 Try increasing that to 3000-5000.

From my understanding this is a problem with MM, not with this plugin. The way welding works is by creating new parts and reloading the database. MM only performs it's work on startup thus any reloads will cause parts that require MM to misbehave.

As long as your thrust vector lines up with your center of mass, it will fly straight regardless of how things look visually. In this case I would probably mess with the thrust vector as messing with CoM usually makes things do backflips when doing physical simulations. Lots of SAS does wonders too~

In my case I just took the positions of some attachment nodes at the ends and calculated the CoM manually, then added some fudge to make it more "natural" (lean towards heavier parts). Hopefully UbioZur can implement it in such a way that it takes the final positions of all parts, grabs the CoM + mass + CoMOffset (multiplied by rotation vector of course) and then work out the average which would be the correct CoMOffset. For awesome points all part positions should then be offset by this value so that the camera also sticks to the CoM.

Never use em, just slap a radial separator (I usually pick the largest one) on the very top of the second stack with some struts holding the bottom. The force of the separation will push away the stack from the rest of your craft and unless you are flying really wonky you should have no problem clearing the debris. Kinda wished that radial separators wouldn't leave mounting points on my main rocket but guess we can't have everything.

Try building your part vertically rather than horizontally or vice-versa. Worked for me. Wasn't there some blender file floating around with a fully-featured high-res model of the Normandy? When you weld the part you are asked which category to put the part in (it seems to picks the root node's category). The new part in my case was listed last (after all the stock parts) in that category. I usually have to exit and re-enter the VAB cause all the parts become unselectable (and sometimes blank). Also, if you are playing career mode you'll need to unlock the new part first.

Yea... it's more convenient to prototype big things like below in the SPH but as I said, the attachment nodes were correct (and floating mid-air) so it's probably just some typo. Actually no... 360 ≠0 and 1.017778E-13 ≠0. The former is benign and simply modulus 360 should fix that but mathematically it's the same. The latter however can be a problem as fractions will add up. I grabbed the ones from git and hacked the parts somewhere into the tech tree, hence the weird ENG texture. I do, but it seems like they are using MM to add the TechRequired property which is causing the parts to disappear in career mode when you weld something. Ahhhh... *restarts game*. That's why the parts were lacking things like dish ranges and power requirements. Maybe MM has some interface to call which causes it to do whatever it needs to do?