diomedea

New unknown bodies (asteroids not yet tracked) spawn periodically, up to 7 to be visible in the tracking station; after tracking them, new ones will be spawned. Unfortunately the only way to recover your game would be to use a previous save. No idea why you had the initial issue, could be something may be found if you still have a save from where that issue shows.

I had the same exact line since first trying Cacteye with KSP 0.25, and was myself thinking of a bug. However, it turned out that is an intended feature. That is better documented in this post here.

What are your graphics (screen resolution) settings? Seems like the part where the button shows is cut off in your screen, and sure it has much lower resolution than mine (pic below, blue button is the one you are looking for):

Quite possible you exceeded memory limit, or anyway had a crash. Startup comments still change, even if the loader stopped. Best thing would be to upload and link your output_log.txt here (instructions here).

I see you spent a lot of time writing about this, but really seems like you need no advice nor help, as you're proceeding to isolate the issue yourself effectively. Some add-ons are pretty permissive about letting NREs being logged instead of filtering cases, but generally because the author knows those NREs have no effect. Sure I don't like that, as it makes bug chasing all the more difficult. I use NREs (in particular repetitive ones that seem connected to other abnormal manifestations) as a guide in the bughunting. Interesting to see if your savegame has anything making RealRoster (or other add-ons) screw up. In case, correctly you should let the author know, he may consider the issue worth his time. Even if what is creating the issue was put in the save by KSP or any other add-on.

Well, at least I got a thanks, I was beginning to doubt I would ever succeed in that . So, in the latest posts we kept discussing more on ways to make possible the case you presented, and some of the mechanics involved in vessel building (behind-the scenes). Believe we can scratch that as accomplished. Now, back to what seems to be involved in your consideration: from a player standpoint, stacked or surface-attached should not make a difference. Certainly that consideration did not bother me much, and I did not get it as your goal before. So, thanks for showing what it was in the end. I did a bit of experiments to see if tweaking the attachment rules for those tanks and DPs used in the showcases above could provide the ability to surface-attach a tank to the back of an existing DP, but to no avail. Perhaps it could be achieved by modding stack nodes with the DP, but I feel the end result would not be as desired. So it really seems like to obtain what you suggest, a different rule/attachment mechanic is required. But with that, I'll let developers (or modders) to consider how best to implement it, and avoid to get myself into further technicalities.

Ok, got that. So you first build a vessel section attached to the probe core, then you detach it and try to reattach by the DP. And however, that section's first part is the tank, so is the only part to have nodes active, is effectively the root part for the section you are moving. One of Squad developers or a modder would probably tell the correct name for that, I get the editor defines as "protovessel" each section it manages. But the rules for protovessels are quite the same as for crafts or subassemblies. Each craft has a root part, and other parts are attached to it (never the reverse) or to one part already attached; so a craft definition is actually similar (topologically) to a tree, new parts branch out from existing ones. But the system has a few limitations: one, as discussed, a tree can only be "planted" by its root (I can reiterate, but am sure you agree, it would be absolutely terrible for performance to allow nodes on other parts be active while joining a section). Another limitation exists IMHO: only one node effectively joins a part to an existing tree, is not possible to have a part joining multiple times (generally, with a number of different other parts), in what would be considered topologically a "loop". There are advantages in certain situations using closed loops (most notable with joints, only one is effectively keeping a vessel together with any single part; if you are familiar with ConnectedLivingSpace you probably found you can't make a looped living space), so I would like to see them implemented, however I guess most of KSP internal routines would require a deep revision (e.g., the one that checks for fuel available to engines). However, back to your case, I can only recommend to use SelectRoot. Sure you need to plan in advance, define the subassemblies and change their root parts, then you can build the vessel from the main section and join each subassembly in turn. I never had an issue with that add-on, and when an add-on is such good, IMO Squad could directly use that. And however, let me tell there is no need to suggest to have that feature (back to the OP, now that the case is pretty well defined): Squad already has plans for it. About how Squad implements things: everybody here has an opinion, you tell the ENB is better, but you rank among the seasoned players. Squad looks at how to make features intuitive for new players too, and certainly the navball arrow is more so and less confusing to them than the ghost markers used by ENB. But besides opinions, KSP is good for being so moddable: if any feature can be improved over the stock ones, some modders will do. SelectRoot (possibly with some updates) may remain a valid add-on, if the same feature was worse implemented in stock.

The case you are presenting can be obtained if the root part in either subassembly is the tank, not the DP. Unless, you have an add-on that changes how the editor work. There is no way otherwise that you can make those subassemblies beginning with a DP. Now, we all know that a subassembly can be connected only by its root part. So, very clear the DP can't show connecting nodes. So, you want subassemblies to connect with whatever other part is presented to an existing assembly in the editor? That would mean to keep a number of nodes open (at least every stack node still unconnected) and would make the editor perform much worse than now, quite probably would crash because of the amount of transformations required about all those nodes while moving the subassembly. Or, the alternative would be to build that subassembly with the DP as root. And then we are back to the fact already explained in my previous posts, no rule currently exist to allow attachment of new parts by their surface. That would require to implement a new attachment rule, that I think may be feasible. But, must be worded this way to make it understandable. BTW, it seems you may also appreciate to find where these attachment rules I keep talking about are: about half way of this wiki page. UPDATE: don't know why I did not think of that before. Have a look at the sequence below. Doesn't it make what you want? Curious about how I made it? Just by using SelectRoot. And if that is enough to solve your problem up to KSP 0.25, I believe the editor improvements in 0.26/0.90 are already set to include what you need.

Wow, 80MB of output_log.txt! Some reading indeed. More than 4.7 million lines logged, however what should be telling is in the first 27K lines here (initialization and all involving the editor scene; editor= VAB and SPH). Rest of the log is about other activities. However, I can't find much of interest even in those 27K lines (no exception at all, and however tons of "GUIContent is null. Use GUIContent.none" statements that to me tell nothing, probably show there is a problem but don't help to find where). KSP.log is however telling something. It reports: - a number of textures not found, in particular from ART; - errors while loading "...\GameData\LLL\Parts\Utility\Grill\modelx.mu"; "...\GameData\UmbraSpaceIndustries\AES\Spaces\AES_Internal.mu"; - an Exception tied to PartLoader method (possibly tied to missing textures); - two Exceptions tied to ActiveTexture Management. I may be wrong, but: - missing textures may show an install problem with those add-ons, something I would check; - the Exceptions with ATM may mean that add-on can't work as intended and, while it inhibits the loading of normal textures, if it can't work can't create the reduced textures to be loaded instead. So, what I would suggest now is: 1. Check ART, if is installed correctly. Test if the issue is still there. 2. Exclude all the newly updated add-ons, one by one; test if the issue persists each time. 3. In case none above worked, something may have gone corrupt with ATM. You can exclude that but most probably you also need to exclude other add-ons (as memory use will skyrocket). Reinstalling ATM clean should allow to rebuild the textures cache, and I would expect to find no further error then. But if still the issue showed (either without ATM or with a cleaned ATM), please upload a new KSP.log

Only one accident to report, while launching a heavyweight in RSS (>2600 tons at launch), clamps were simply not enough to avoid the pad to be burned down, while instead the craft slowly took off without a scratch.

MOARdv, thanks for your commitment with this add-on. Really glad to see it updated and improved, too .

Sal, I bow even more in recognition of your prolific activity . Now, please confess the truth, Squad is paying you for every post you make!

No ideas currently. Would help if you could follow the guidelines on how to get support, information as suggested there would be decisive to diagnose the fault.

Much better now. Vanishing parts is not an unknown issue, but there is no single cause to it. So, has to be properly investigated. Most useful to this would be to examine the output_log.txt file (found in /KSP_x64_Data subfolder). If I had to start checking mod by mod what could cause the issue, I would start with [x]Science, that one caused gripes to me as well (but, your case may be very different).

No, really, what's the deal? You had KSP working even though it was 64bit and with all those mods installed (against all warnings given by Squad and modders about the instability that would result), but then after you updated those add-ons (not KSP) it is KSP the evil that garbled your parts? Not that something may not be working due to: 1) one of those add-on updates introduced a bug 2) one of those updates has created an incompatibility 3) you are simply going beyond what your system could support (hint: parts not being loaded/textures not being loaded may be very telling) And anyway, ever cared to check what is stickied in front of this section, with that not-so-easy-to-miss (READ FIRST) warning in the title? If you want to receive support, first consider to make a report consistent with those guidelines. Any attempt to help without that info from you would too easily result in a loss of time from both us and you.

Maybe you should express better what the "opposite" case is? I already wrote there is no attachment rule allowing a new part to be attached to an existing one by its surface (instead of the rule allowing to attach a new part to the surface of an existing one), so the "opposite" case you mention is either what I already wrote about being impossible (and asking you to rephrase, it still is hard to get what you mean) or is a mirrored situation of what I showed, but to me those mirrored situations work as well. About the exclusion feature, I know the case of the two stack nodes (top and bottom) of a low part being too close and so easily snapping the other way round (yes, most evident for batteries). That is why I wrote the exclusion feature being helping in almost, instead of in every case. But with a minimal amount of care I always could set those parts as intended, and I reckon some users like to have the possibility to connect parts by the "wrong" stack node.

Well, something seems to be working differently, can you see the stack node with both the DPs in the image below? (both the one surface-attached, and the one going to be attached to it): Rest assured I have no add-ons to change how nodes work in that KSP install. About attaching anything radially to a DP, no you can't do that, but you can't do that with anything, not just with docking ports. There are parts that are defined in the nodes attachment rules so to allow other parts to be surface attached to them, but the contrary rule so to allow parts to be attached by their surface to a node does not. If that was what you intended to suggest, you should rephrase it. About the snapping being too easily done on the wrong node, do you know that with KSP 0.25 they made possible to exclude radial nodes from attaching just by holding the Mod key down (Alt key on Win systems) ? That should help for almost every need with attaching parts.

Please note what follows is about KSP for Windows. I just add that suffix to the destination line in the .lnk file for KSP. You open the .lnk file right-clicking on it, and show "properties", then the link tab, to find the destination line, it has to have the full path to KSP.exe in it (KSP_x64.exe if on a Win 64bit KSP), and all you need is to add the -force-opengl bit to have KSP using openGL instead of DirectX. DirectX requires almost double the amount of memory to hold textures currently, for most of the texture formats used by add-ons, so generally that suffix allows to use memory better.

Yes, definitely, the shielded port does not connect. However I understand the surface-attached ports case to be about any other port (shielded don't count as they don't connect in any position, their issue has to be different). As written before, I tried with two sizes of the Clamp-O-Tron, and they did connect for me. So, this case may show not a general bug, but a specific problem with the OP install.

I like the idea of providing suggestions on how to improve the editor. However, am I missing something? Surface-attached ports (Clamp-O-Tron both normal and Jr.) do connect in my KSP with any similar port, if properly aligned.

Your output_log.txt shows a large number of Exceptions raised by Trajectories, and in the end a crash due to system being out of memory. Try to exclude Trajectories and see if game starts. If not, you are still beyond the amount of memory available (not a surprise, new versions of KSP and add-ons require more memory due to new features/parts), so you may have to exclude a heavy mod from the mix, or to use ways to otherwise reduce memory use (try Active Texture Management, and/or use the -force-opengl suffix).

Can you check to have the NASAsission folder within GameData, where also the Squad folder is? All 3.75 mt parts are in there, seems like somehow that folder is missing in your install. Also, and in any case, please follow the bug reporting guide, info mentioned there is crucial to provide support.

Not one, but three popular add-ons that I know can display the vessel mass in VAB/SPH: - Kerbal Engineer Redux; - MechJeb; - VOID.

Excellent, I'm very pleased when seeing add-ons integration working .

No release yet? Then, this belongs to add-ons development, not releases. Moved. When you have an actual release, you can start a thread with the releases section.