Deadweasel

"Interpenetrate"??? No! Don't stab it into Jool! You'll destroy all kerbal life as they know it! "My god...."

*sigh* Might help if I were actually trying to run the latest release.... All is well, sorry to interrupt the well-deserved praise stream! "You are like a baby. Making noise, don't know what to do."

You might not have seen my update with image. The plugin isn't loading at all, even though the models themselves are. I can get the parts just fine, place them on a capsule (which has power to begin with) and send it out to "launch", but nothing works. Even though the capsule has power, I still get no context menu on the lights. I can't interact with them at all, even though the models appear to be working as they should.

I think there's a conflict somewhere. The lights no longer work, and I don't get context menus for them either. I've got a lot of parts mods, so it's going to take some time to narrow down the problem. UPDATE: Nope, not a conflict. With AviationLights and Squad's defaults being the only parts available, it's throwing an error while trying to load them.

I came back in to mention the part placement bug as well, (don't know why this didn't happen before), but I will confirm the confirmation that Romfarer's DockingCam was the culprit. "Dr. Weasel, do you concur?" Yes. Yes I do. :*(

Aha! Thought as much. Thanks for the confirmation C7, and let me echo Tw1's sentiments as well. They're gorgeous indeed!

It seems to be working for me, except the SAL icon is now placed directly over the new crew icon. Is there a fix to shift the SAL icon that I missed somewhere?

I kind of doubt it, given that the ones in Parts don't have configs at all. They're just the models and textures. Besides, I'm pretty sure, since SQUAD are already looking into that issue, they'd already have found it and called it out as the fix by now. I get the feeling that either the release version came from the wrong build, given these odd redundant parts, or that testing was done on an earlier build, and the bugs were missed on the later one actually intended for release.

Best thing to do for simplicity's sake is to edit the .cfg files and enclose everything in "Part { }". This will allow you to create a folder in GameData and keep the mod in there instead. That way you won't have to worry about odd interference from something else in the legacy Parts folder.

Interestingly, the one thing that would determine the requirement of their placement, the config file, is not included with the versions in Parts, but are there in the ones in GameData. I think this might have just been a simple oversight during the process of updating them.

Same here. I didn't buy it from Steam (joined in waaaay before that collaboration took place), and the Parts folder has them. Besides, Steam has nothing to do with individual file placement in a game.

When you're watching a YouTube video and you keep catching yourself trying to adjust the camera for a better angle.

Anybody notice those two engines showing up in the old Parts folder? I wonder why they're exempted from the GameData system like the rest of the default components?

Just about every part mod should work without problems. I've copied over all my parts and all my ships loaded and functioned properly right away. That said, I'd be wary of mods that change physics behaviors like FAR, or more complex plugins like MechJeb. I use neither so I can't comment on them, but I do use TT's Multi-wheels, and they seem to be a-ok.

In last major update, there was a bug with mouse scrolling, but it only affected Linux users which of course resulted in badly skewed numbers. It looked like only a very small percentage of players were experiencing it, so naturally the trend was to knock those players for doing something screwy with their installs (copying in incompatible mods, doing something odd with their configs etc). Funny, the mouse wheel problem turned out to be a valid bug, and was fixed in the first patch after the update. It just goes to prove that you can't really discount a complaint simply because the people experiencing it are in the minority, or worse, calling the players out for "doing it wrong" out-of-hand. There very well could be something problematic in the game that only shows up in certain cases that SQUAD didn't anticipate.

Ah, I see what you're getting at, and yeah I've seen the same problem. Annoying as heck! To add to the confusion factor, I can never seem to predict which vessel will get the focus when undocking them. I wonder at the logic that governs the decision. There are times when it's critical to know which will get the focus, because fast action will need to be taken on a vessel that's undocking in close quarters (like within a dock for example).

Here's a thought: Since threads like these will just keep popping, no matter what anybody tries to do to squash them, how about we as a community take it upon ourselves to spread information to those who may not have it yet? For example, regex calls out SQUAD's acknowledgement of the problem, but didn't include a link. No slight intended to regex because I think he's on the right path, but what if those among us who had such information made a concerted effort to spread it around, and in the process cut these threads short that get filled with so much non-information and useless responses? Somebody whines about ASAS: post a link to show that somebody is aware and working to fix it. That's all the folks who are complaining are really looking for anyway: some kind of response that proves it's not just them experiencing it, and that it's being addressed in some way. EDIT: Allow me to back what I suggested with a link: C7 calling out that they are aware of the ASAS trouble and are looking at it right now

A lot of people already do that. They post up pics of their creation in the "master" SSTO thread, then turn around and make their own individual post for it with more details and a download link. EDIT: It's the SSTO showcase thread (should be stickie'd, in my opinion)

One behavior I've seen is that you need to assign your action groups after assembly is completed. If you assign a group to a pair of components, then move the components and re-place them with symmetry, only the part you actually placed again will maintain its assignments. The other ones placed via symmetry will lose their assignments in the process. If you create an action group on parts that were placed via symmetry, then move the part, you will need to go back into the group, remove ALL references to all parts and re-assign them again from-scratch, because I have run into many cases where the assignments are still technically there in the group, but they're no longer associated with the symmetry-related parts anyway.

That has to be the most apt and image-inducing comparison I have ever read. *Replaces keyboard. Again.*

Which would be fine, IF the only time "decouple" showed up was in a case where only a single docking port was involved. As it stands, I think the original call-out (that docking ports show "decouple" if they were assembled in the VAB) is dead-on, and that's where the confusion sets in. Granted this is a pretty small thing and not really worth any level of griping or suggestions to correct in the grand scheme of things, but it's still an annoyance that elicits some curiosity into why it's like that. Why would the game really need to show something different based on how a port's connection was made? I agree that it makes sense to "decouple" if the port was assembled against a non-port component in the VAB, but as it stands, it looks like "decouple" is shown for any port assembled in the VAB, regardless of what is actually attached to it.

I agree that this has been a bit of a "??" point for me too. Would be nice if the game didn't bother with changing the label based simply on how the ports came to be connected. It would also be nice if both sides offered the undock option, because I've not really seen a pattern as to which side will actually offer it.

I lol'ed. Hard. You owe me a new keyboard.

The universe as we know it may very well be "infinite", but between what we (as humans) have seen of the light coming back to us, and M-theory's predictions, it's becoming more and more likely that the truth is that we're living in the aftermath of a massive explosion resulting from the transfer of energy and mass that originated from within another universe, and that the current extent of that explosion is around 14 billion light years across. There is this interesting image: Which is a map of the light coming from the most distant point in our known universe that we can see. It's very possible there's even more stuff further out that has already died out, but because we can't see it, it's likely we'll never know how big our universe truly is. The one thing that most astronomers can agree on so far though, is that our universe (in terms of space that contains, you know, stuff) is finite in size, not infinite (going on forever and ever). There's probably an edge, but what's beyond that, again, we'll probably never know for sure.

Hehehehe it's not like I'm fishing, but that aside, thanks a bunch!