swjr-swis

Yep, it's that hot again. We can fry eggs and steak on the pavement, and planes (literally!) end up looking like wet noodles. This is what makes me love KSP. Btw, if you tweak the placement of that back landing gear, especially the angle of it, it should be a lot easier ans safer to land it...

Exactly.

Edit: @bewing, @Streetwind, and @Red Iron Crown point out a few important things I missed in this post, make sure to read/use those too: credit bewing - the Wheasly engine loses a lot of thrust before getting even close to the target altitude of 18 km. Consider alternative or additional engines. credit Streetwind - the rear gear is so far back that it will make pitching up to lift off very difficult. Far from CoM - long leverage arm - takes a lot of force. Place them close behind the CoM. credit Red Iron Crown - RIC explained more clearly the interaction between control surfaces and the CoM. 1) The control surfaces are in front of the CoM. The editor won't tell you this, but that will make them reverse how they work once the plane is launched: when you try to pitch up, they will actually be pitching you down. You can correct this by pulling the 'Authority' slider to the left and make it negative. Edit: I didn't word the above very well. A more accurate way of explaining the CoM/control surface reversing problem added by @Red Iron Crown: 2) They are also very close to the CoM, which means they will be almost useless for pitching because they have no arm for leverage. Two of the smallest control surfaces somewhere on the tail fin will be much more effective in pitching the plane than these. 3) Once you correct those things, you likely won't need the double wings for the plane to lift and fly, or the extra fins on the wing tips. Will save you parts, money, drag, fuel, and give you a higher top speed. (*) 2) The control surfaces, especially those on the back of the wing, are still too close to the CoM to be of much help with pitching. A few smaller ones on the tail will be more effective. 3) Here too, once you correct the pitching, you have way more wing surface than this plane needs to fly. A pair of the slanted wings (the ones on the end of the wing) should really be all that's needed. (*) Let us know how you're faring. (*: unless of course you are after a specific look for the plane, then there really are no rules . But right now it seems you are more interested in the practical matter of just making it lift off and fly rather than making it look a specific way.)

Sometimes, really good bug hunters/reporters are made part of the KSP team. To be able to let the rest of us know about their work in the weekly dev notes, they need a first name to go with the nick. The last name is used in the farewell message when people leave the team. So nothing nefarious, you can breathe easy. Just be glad they don't ask for middle names. I always knew I was in actual trouble whenever I was called by my middle name (or worse, all of them, very precisely pronunciated... often the first sign that I done messed up real bad ).

Why would it have to be plates specifically? If it's a flexible material, it could be folded out and in multiple times, and probably only need a very minimal frame or even just air pressure to maintain the shell - with a bit of slack - around the craft. Like the material used for the inflatable habitation module they just started testing on the ISS.

When you 'merge' a whole independent ship, that was not created specifically as a subassembly, the game will use the root part of that ship as the attachment point. That root part may not be the part with the 'free' node you want to use. And if that root part has no free nodes of its own and is not surface-attachable, you won't be able to attach it rightaway. So just click in the air to 'park' that ship a moment. 1.1 introduced the ability to re-root unattached assemblies. Use this to your advantage. Use the Root gizmo on the unconnected ship, to select the part you want to connect with. This can be one with an actual free node (eg a docking port or the open end of a tank, etc), or a part that can be surface attached. Basically you force the game to redo the part structure so it becomes a proper subassembly with the part you want to connect with as root. Now try and place it and you'll see it'll work. Word of warning though: the game will have very odd ideas sometimes about the orientation, so don't be too surprised if it looks like it's attaching all wrong. Sometimes it's pretty darn impossible to convince it to attach 'right', but if you ignore it and place it anyway when it turns green, you should be able to move it in the right position with the rotate/offset gizmos. If the part you want to be root is somehow already the root of that ship, just make a random other part root first, then back to the one you actually want. Sometimes the game needs to be forced to 'redo' the root for it to work. Barring all that, pics and/or craft/save files if it's still not working and you want more help, otherwise it's just blind guesswork.

Jeb considers it immoral to launch with anything less than 6 Mammoth-sized boosters or anything under 2.0 TWR. Bill gets highly offended if the craft is not redundant and over-engineered to the point where it could lose a bare minimum of 50% of the launch parts on the pad and still make it to LKO. Bob will throw a hissy fit if we leave even 0.001 science points ungathered from any biome visited. And Valentina thinks it's immoral to keep sending her up with three guys on years-long interplanetary... actually, no, she's totally ok with that, as long as they all do as they're told. But she does regularly get miffed about the guys always getting picked by default before her, and keeps threatening to take over the space program with 'her girls'. She gets this scary totally serious look when she's on about it too...

I voted no, because I like and want to keep the added options to tweak friction and suspension spring and damper (in fact, I wish those last two options were 'live' and not just in the editor - would be so helpful to level different parts of a landed base for docking/coupling). They just need to fix them to work right. And so the whole 'blocking' thing isn't necessary anymore.

And risk it activating? At best, it just sends off a signal... at worst, it decides the experiment is over. Best to just let it be.

When you "Cannot activate when stowed" When your plane decides mid-takeoff that the grass looks greener at the left side of the runway. When you stage for launch and immediately hear the sound of deploying parachutes. When physics 'kick in' and your massive interplanetary rocket decides to spontaneously shed parts. (plot twist: you over-engineered it so much that it still made orbit). When you realize this launch is the premiere of Holiwheel on Ice. Perfect launch, stage to release boosters... and the inflating heat shield starts to make your rocket look like a flying mushroom. When the navball prograde indicator decides to tell you at 15km up that it likes orange better than blue.

It's because of the incredibly high density of matter in the Kerbal universe, and because none of the parts are intentionally designed to explode. Due to the density, the slightest bit of thermal or kinetic energy added will initiate a nuclear reaction, but since none of the parts are explictly shaped to redirect that energy into their own mass, the rest of the part is immediately shredded by the initial shockwave and blown apart before it can be 'used' in the reaction. Hence, the energy and size of the explosion is always auto-limited to that first tiny initial bit, and the rest of the matter is dispersed, regardless of the size/amount of the part.

The cubic octagonal strut is a horrible battery... it doesn't maintain any charge at all.

Adding the link to the new issue you posted: http://bugs.kerbalspaceprogram.com/issues/10088 A few suggestions about that report: Can you upload the craft files of the craft that show the issues with the solar panels and the landing gear? That way I can confirm the report. Also, as much as this thing has plagued us, 'critical' is not the right level, game can still run as long as we don't use any fairings/bays at all. Not saying that makes it any better, but you should know it'll be downgraded. Asking for it to be removed completely is likely pointless, and pretty much guaranteed to get protested by others. A setting that lets us globally disable it in our individual games would be more realistic to request, and keep those that like the mechanic happy as well. The ideal, in my view, would be to allow to disable/enable it per-part, as a toggle, but as that's more of a coding effort, I'm afraid to ask. I'd settle for a global setting. I'll see if I can add some examples to show the absurdity of making parts inoperable inside a hollow container, when those same parts work as normal inside solids, just to ensure that that side of this whole issue is properly reported as well.

Can you elaborate on what you feel would be a 'proper' report? As in, what needs to be added/changed to the following to make them 'proper' enough to get the visibility we're being teased with: http://bugs.kerbalspaceprogram.com/issues/4928 http://bugs.kerbalspaceprogram.com/issues/4955 http://bugs.kerbalspaceprogram.com/issues/5955 http://bugs.kerbalspaceprogram.com/issues/6022 http://bugs.kerbalspaceprogram.com/issues/6758 Also the result of a relatively quick search, by using the single words stowed/activate/bay/fairing/'occlu'. All of these include examples of a bay or fairing making other parts inoperable at unexpected or unwanted moments.

1) expend a lot of effort throwing yourself into it's path 2) spend no effort at all while intentionally missing it for a while 3) give up trying to miss it, and with a sigh and a puff, hit it Isn't that everyone's standard?

I dunno, people keep seeing all kinds of things on Mars pictures. Cactii, lizards, bears, facehuggers, women. Surely there's gotta be tree-like vegetation too, to support all that fauna...

The Mk1/Mk2 Illuminator spots have become significantly less bright since 1.1.0pre, presumably due to the Unity engine change; they used to be significantly brighter before which allowed for a lot of customization with the scalers. Although for some reason, it seems to only have affected the spots this badly, because the helmet lights and the landing gear lights which are arguably much smaller, greatly outshine the spots. I was going to link a report from the bug tracker about this, in which I included before and after screenshots to show the very noticeable difference (the screenshots are still on my imgur), but after trying all word combinations I can think of, it doesn't find that report anymore. So all I can say is: it was reported back then, I don't remember seeing it actioned, and now apparently isn't even in the tracker anymore. If you feel lucky, try reporting it again. <shrug>

To make a truss frame solid (or as solid as the stock game allows), as in the given picture, one end of the horizontal trusses between the longer vertical ones has to be 'fixed' with duct tape struts, because to actually close a square/loop the game would need to allow two (or more) nodes on any single part to be connected at once, where at this point, it only allows one node to connect. Having to use struts (or docking ports) to overcome this adds more parts, more mass, more drag, is very hard to do without introducing small torque forces or imbalance... and is never quite as solid as it could be if the direct method of attaching were possible. The game makes a special case out of struts and docked ports, checking on their connected state (and presumably, calculating the forces) through a separate module. Other than missing code to do so, no. Like you said, it's already done in the game for 'special' cases like struts, docked ports, and with invisible struts inside fairings (and bays?). Personally I wouldn't want it done automatically, or only automatically: game defaults seem to frequently be at odds with my design goals/needs, so I would prefer it to be something I can do or override manually. For example, holding a certain key in the editor makes attachment nodes visible even without holding a part... at which point the nodes become right-clickable, with the option menu showing an 'attach' button. Clicking that button then surface-attaches that node to any suitably nearby part (or to keep the tree structure as it is now, ray-cast a pseudo-strut, but then with the same attachment strength as a regular surface/node attachment). Alternatively, at clicking the button, let me highlight exactly which part I want to attach that node to (like how the stock root gizmo works) - this would probably work better for those cases where more than one part is nearby enough to be a candidate. If it requires a separate module, call it ModuleCloseStructure or somesuch. All it needs to store is what other part it is attached to and at what location. A problem remains with what to do with fuel/EC routing, but this is solved for docking ports already as well, so code-wise that too can serve as an example.

For ALL parts/modules that get deactivated on being 'stowed', not just engines? Where is this magical global setting I've been unable to find so far? And why is it not stock (an MM patch doth not stock make)? I did check both the Physics.cfg and the settings.cfg, but I don't see it. Although I really want to be able to set this individually by part, at this point it has messed up so many times that I'd already be happy with just a general switch in the settings that allows me to turn it off entirely, for all parts and all conditions. I can then set it as soon as the update hits and then just blissfully forget about it forever and never look back. For the very few edge cases where I actually DO want a part to be inoperable when stowed, I can do it manually or use an action group, like we used to before. The thing is, on top of it being unnecessary and constantly guessing wrong, it's also completely inconsistent. The game has absolutely NO problem whatsoever with me clipping an engine, antenna, panel/radiator, or science instrument entirely inside fully SOLID parts, and will happily deploy and/or activate anything right through or inside solids without protest... but when it's a HOLLOW part in which actual physics laws would pose no obstacle, suddenly it's a special case that has to be singled out and force-avoided even at the cost of constant false-positives, because... well, reasons. So this mechanic teaches us the valuable lesson that the air and/or vacuum inside a closed bay/fairing is somehow so much more dense than solid metal or fuel that realism/physics/code requires it to be completely prohibitive of any parts suspended inside that hollow to work. But wait, there's more: to ensure we completely satisfy the Law of Conservation of Logic, when bay doors are opened even a micrometer, that same hyper-solid air/vacuum instantly phase-shifts out of existence and immediately allows activation, to instantaneously transform back into pure part-deactivating neutronium when the bay doors close again. Right. I've been quite ok 'protecting' myself from allegedly risky, undue, or improper deployments and activations all these years (other than outright staging errors, but why does stowed have to be a special case for that?); I'm pretty sure I can keep myself protected going forward. I have however zero recourse whenever the game stubbornly decides, sometimes mid-flight at complete random and in contrast with just a few seconds before or after, that a part is now suddenly to be considered 'stowed' or 'occluded' and thus inoperable, in 9 out of 10 cases when the aforementioned part was never placed inside a fairing or bay to begin with, is not currently inside one, and sometimes isn't even visibly touching one. Just please give me the stock option to disable this... thing. For all parts. Please.

Because the 'stray' end of struts are not actually connected the way other parts do. The part description basically just says 'it points in that direction' and the game code 'makes' it connected to whatever it first touches in that direction.

You only really need to place the strut right once. Then make copies of the section with the placed strut and at placing them, the struts will connect the same way every time. My suggestion though: make your frame from emptied SRBs instead. You will total much less parts, you'll need much less struts, and the frame will be a lot more rigid.

@Gman_builder Using FAR when the question is about stock parts... somewhat of a workaround there. In Gman's defense: this forum keeps stubbornly presenting years-old threads as if something 'recent' just happened in them by marking them bold in the index. Not sure what the purpose is of marking dead threads in bold even after I've marked an entire forum as read.

Ok, screenshot shows the problem clearly, thank you. I was hoping to save kat the trouble of diving into logs if it had been something easy to spot, but we appear to be using the exact same settings and all the thumbs on your craft page show perfectly for me, so the cause is something beyond my ability to help with. It may be a bit before he can get to it. Only think I can think of is if you and I are connecting through different CDN nodes and the node serving your geography is having an issue. I am connecting from NL, Europe.

A screenshot might be needed, cause they appear to be showing correctly for me (FF 47). Make sure the screenshot shows the filters you have chosen.. it's happened before that an issue only shows for a specific filter combination.

No habia visto esta aplicación todavía, está interesante (la ventana no parece poderse adaptar a la medida que yo quiero). En cuanto a la misión: el satélite parece relativamente fácil de reproducir en KSP. En stock será bastante simpletón. Con mods se podriá hacer más parecido, pero con ciertas cosas que están pasando ahora mismo, se me han quitado las ganas de usar cualquier mods por completo. Quizás haré un intento stock, ahora que me sobra tiempo por no tener que ver el resto de la euro copa...