Ruedii

I think it is useful to correct things so they don't explode or break their connection with the ground and fly into the air. However, that might just be me. As of Unity's actual control of colliders, you can detect a collision or mask it so it doesn't affect physics. When dealing with the ground, want to do the former on objects being dropped, and the later on object being mounted. Probably the proper behavior with an object being dropped is to mark it red, disallow dropping and say "CANNOT DROP: OBJECT COLLIDES WITH SURFACE; TRY SOMEWHERE ELSE OR USE OFFSET CONTROLS TO ADJUST HEIGHT." (All caps because that's how the error should read.) As of issues with things exploding or breaking the moment they connect to a craft, the craft the object is being mounted to shouldn't have any physics interaction from the mounted object. If this isn't the case, it is because the mounted part is having it's physics activated before it is connected from the KSP core's to the craft instead of after. This could be as little as a single frame, and the result of doing the two occurring simultaneously. To quote the Hyperion QA CL4PTRP unit in Borderlands The Pre-Sequil: "Just add a one frame delay that always fixes everything." For the time being, the dev documentation needs a note about mods intending to have surface mounted objects providing proper margin for error on the bottom colider. (This is probably very important note to add to the dev docs for the KIS libraries.)

Cool all the various flags from legos! BTW, I love Lego's simplified de-trademarked version of the NASA flags. They clearly designed any of the ones without the NASA trademarks before they secured NASA partnership deal (not a hard task, but loads of red-tape unless they approach you like they did Squad) in order to be close enough while still being under fair use when used for commercial gain. As a result the flags are beautiful simplified models.

Three Cheers! Thanks for finally getting this out!

Yes, this has been a problem off and on for a LONG time. The issue presented itself different ways in different KSP versions, with the latest version causing explosions. It's a needed feature, not a bug. I probably should have been clear on that. Unfortunately I only know an outline of what needs to be done. When dropping a collision check done, and then it should simply refuse to drop until you correct the height, or it should lift the height until it is clear (Lifting the height might actually be a better, more automatic option.) When attaching to the ground one of the collision checks in the main game needs to be turned off. This is probably a separate bug. Finally, when attaching to a craft, the part's physics should not be turned on until it is connected. This will fix issues with parts exploding when the node is misplaced and the colider overlaps the ship's colider. I'll try to get this put on as a feature request soon, with a more detailed outline of proper behavior.

Exactly my point. And a simple check could prevent this. It's probably not a bug so much as a missing feature, so sorry about the phrasing there. As of exploding when attaching, that is a bug if the part is part of the same vessel to that of which it's colliding. It means that the colliders are initializing before the part becomes attached to the craft. As of exploding and (flying into the air) when attaching to the ground this can be fixed with some simple removal of collision checks. An object attached to the ground should not be checked for collision with the ground. The base game has no need for such a feature because it doesn't let you attach objects to the ground. I don't mean to sound argumentative about this. It's just a real problem, even with stock parts, and it should be addressed. Whether it is a bug or a lack of a feature is a trivial matter. It's really besides the point it doesn't matter. Just don't feel like it's something wrong with the mod. It isn't, it's just something that would help make it work better.

I said DROPPING not attaching. Nodes aren't used when dropping.

It's exploding due to collision with the ground or the part/vessel it's being attached to. Both of those are bugs. If a object collides with the ground it should either move it's offset clear of the ground or refuse to let you drop it. It explodes or flies into the air if it collides with the ground when dropped. If attached it should theoretically be fine, but it currently isn't.

OK, I found a possible workaround, but I'm going to need help implementing it if someone else doesn't want to beat me to it. The attachment nodes need to be offset a small ammount from the ground and/or the colliders need to be a touch back from the attachment point to the ground. This very short distance SHOULD fix the issue. Also, the cardboard box needs unused default connection node moved so that KIS knows where to place it on the ground. If this node is shared with the backpack attachment, then a second node needs to be added and set to be default. Preferably one of such unused node point should be placed on each cube face so you can turn the box and face it the way you want on the ground using KIS' switch node function. (Always fun to have a feature like this.) I like the idea of the default one having the open side facing up. It's been hotter than a hot day on Moho at Noon where I am (Ohio) so I haven't exact at my most productive lately. I've actually been on the edge of heat exhaustion for the past three days. However I'm hanging in there. Attempting to remember to put my computer in deep sleep mode when I'm not using it as to reduce it's unintended function as a high-power heater.

OK, I'd like to report an issue with explosions when something is attached or dropped in a manner where the Colliders intersect the ground. (or possibly another object but I haven't verified this.) This should be fixed with a series of bug fixes to make sure the collision exclusion layers are properly being mapped. Additionally, there is a lack of a function that prevents "dropping" an object intersecting the ground or another object. If I recall this used to exist before the KAS functions were integrated into KIS. However, there were also changes in the KSP version (and the underlying version of the Unity3D and PhysX engines) thus it may also have to do with that. Should I post this bug on Github along with typical formal bug reporting detail, or should I rely on someone closer to the project to do it?

OK, I've done a little more fiddling. It seems there are some physics issues with colliders overlapping the ground in KIS creating spontanious explosions. You can verify this by placing a cardboard box of sufficient weight half-way underground. The way to workaround this would be to modify the collider to have a little extra ground clearance (not too much because you don't want to be able to pass under it) and have the node and the visible polygons extend down to the ground or slightly below. This issue does, however, need to be fixed in the KIS library through some form of collider culling routine and/or collision behavior modification but that's another matter.

Not truly paradoxal so to speak. Depends on how you see the poll. Voting for the position you want to win will cause it to lose. However, voting for the position you THINK will win is an unusual position of guessing based on human nature, knowing your vote will result in your guess being less likely. BTW, I voted no, because I guessed people generally expect other people to be pessimistic and thus would vote yes, wanting to be right. Not sure if that was why I was right when I voted that way. Might be more fun if other people say why they voted the way they did. Would be interesting to hear other people's analysis of this.

Yeah, I've been having some random crashes when returning to tracking station. I am suspecting the KIS/KAS module but I can't be sure. It may be Kerbal Engineer or MechJeb. (I use them both because Kerbal Engineer has a nicer lightweight HUD).

It turns out the wrong elements are durable from what I can tell. Your getting phantom forces from binding between the collider and the ground mount node, and the node can't stretch enough because it's strength is too high. There may also be issues with the shape of colliders. I'm not sure if fixing this will help. Two suggestions are 1. simplify the colliders on any of the parts with legged bottoms to combine the tripod or quadripod into a single geometric volume. 2. Decrease the ground mount force to a medium level. 100 should be good. The bottom face of the collider should always be a simple single flat polygon. Polygons stretching up from it for a reasonable distance should also be simple single polygons. I also noticed you can't control power transfers and such. Adding a probe core module to the SEC Main Control Unit config file fixes it This fixes a lot of other minor resource annoyance bugs.

155. Arguing that instead of being pronounced phonetically GIF should be pronounced Gee Eye Eff, further derailing the thread. 156. Diverge onto a thread about the patent abuse and the LZ compression used in the GIF format. 157. Point out AGAIN that GIFs should be replaced with PNGs. 158. Make a remark about Animated GIFs being annoying. 159. Continue talking about GIFs for 5 whole posts!

Yeah the ground strength setting is too high from what I can tell. I've been fiddling with the settings the past few days. I'll post a fix to github once I know for sure that it's fixed. (I need to test it on uneven terrain, the test on flat terrain passes now.)

Sure, my reply was very serious . . . 133: Forgetting to put smiley faces after being sarcastic.

Yeah, I like this idea too. ----- On the note of the spontaneous explosions, I took a look at the config files. It looks like the parts are connected too firmly to the ground. Their connection should be around 200-600, and currently it's at 2000. That high of a joint force will cause extreme spring forces with KSP's rubbery joint behavior, thus causing collision, tinsel or compression forces capable of destroying the device. Should be able to be fixed by bringing the connection strength down, to a reasonable force. The experiments should only need around 200-400, the base station around 400-600.

OK, some of the experiments are also exploding on me. I'll take a look at the config files on those as well. I don't think there should be too much abuse of making these nice and durable, so long as they are the same strength or weaker than much lighter KIS alternatives for use as anchors. I still want to file my suggestion for having a "outlet plug" specifically designed to link in a typical electrical crossfeed capable part assembly as a power source. (e.g. a fuel tank and a fuel cell or a couple of batteries and a solar array.)

It seems that as of KSP 1.1.3 the experiments aren't staying put when fastened to the ground again. Do you think it's the mod's fault, or KIS/KAS's fault? Also, should I look at the mod's cfg files to see if there is a way to easily fix it? Same problem here. Seems it's a bug.

I do not see what is wrong with posting extraordinary long replies. Sometimes a lot of stuff needs to be said, and you can't say it in a few words. In those cases making extraordinarily long posts should be fine. It's not like you are going off on a tangent and talking about things completely off topic like tomatoes are a berry not a vegetable and by the standard that deemed them a vegetable asparagus would be a fruit or bringing inflammatory topics, like how Linux is better than Windows, and EMACs is for old fashioned nerds into the mix, or [snipped political joke]. We all know better than to do things like that. After all we all play a game that relates to orbital mechanics and rocket science. There is no real reason we shouldn't be able to post long essays as replies.

You probably should learn the features of GIT-Hub by developing some patches for other projects on it first. That way you can gradually step into the water instead of diving in the deep end of managing a project on it. That's how I'm doing it. I'm right at the point I'm ready to dive in and make my first project on it, but I have to decide what it is.

You can design all the parts with curved or sloped edges and just let them clip into each other. I recommend using sloped edges instead of curves, though.

If there is a way to force all 4 spotlights on the 4 way spot to be the same color that should allow the lens color to work.

You don't need to use GIT for github. A GIT GUI (built into most modern Development Environments) is preferable for handling the repository. However, you can simply use the web interface to manage it.

Yeah, but the buzzard is heavier and more damage tolerant. (In other words the buzzard cockpit isn't a lightweight death trap.)