ceaars

No, no no no. You need not worry. I got what you meant. Whatever they're attached to stays what they're attached to no matter how much tomfoolery I add. ...er, well maybe I do. Okay. I assume this means what I attached them to, they'll stay attached to, no matter what. If I later put whole stages below where I put them, that's my own dang fault (forgive my language). If I actually screw around with the stage they're on, they'll stay attached to that stage. If I mess with something above them, they'll stay where they are. Sure my dream would be if their initial spot were to be automatically attached to whatever (at the time of placing) was the first engine to fire. But I've already learned to check for that (as you've so aptly demonstrated, you really can't convince people a way different from what they're used to is a better way, no matter how many probes get crashed into the Martian surface, because "it'll always confuse people," since, to play devil's advocate there's *always* some jackass who thinks they've got a better way, and trust me on this ... you're not wrong). What you addressed was the real culprit - why after I've double checked what they're attached to, they somehow drift off of where I put them (it's maddening enough for them to not start where I want them ... worse yet is once I've repositioned them they just don't appear to "stick" to where I put them. It was the latter that caused the problem).

Huh. I didn't know that. So alt-clicking the clamps to a stage where something else is ... ah ... staged with "fix" them to that stage no matter what (well, beyond me just moving them somewhere else)? I'm going to have to give that a try... if it works, that'd be very helpful (and would also help with their tendency to seemingly randomly move around as you tweak the rocket - something that almost nothing else in the staging seems to have a problem with). Thank you! Huh ... I wonder if that explains their seemingly magical ability to move around in the staging where nothing else does. Although it seems some people might see me as crazy, I swear I *always* move them to the correct location in the staging (and in this case that set me off, I *know* I did), and then I might tweak something totally unrelated (or at least I think I did) and the clamps just mysteriously move from where I put them (in the staging) to something that will destroy the rocket, cost me 360,000 funds, kill five kerbonauts, and cut my reputation in half. Gargamel suggested something that might actually "lock" them in place for all time and get rid of that "random movement" behavior (at least I hope it will) ... but what you posted gives me some insight into why exactly they seem to have such weirdly random behavior. Now, granted, I still agree with you: it would be better if their default was just to put themselves in the "lowest" stage that had some engine getting activated. I don't agree that that would confuse people (the only confusion I see is all of those people used to having to fiddle with them staring in confused amazement at their staging, trying to figure out why exactly the clamps actually showed up in the right place; I think they're survive the shock), but that's just me.

Hardcore career mode. I'd decided it was time to really reap the scientific rewards and open up a lot of nodes in the tech tree. So I planned seven Mun land and return missions - each targeted for a different biome. Specifically picked some of my most experienced kerbonauts (that didn't yet have Mun landing XP) - they were to be my vanguard for a slew of missions to Duna later when the launch window on day 209 opened up. The Mun missions were launch - very well tested rocket and lander design that I knew worked extremely well. Mission 4 was destined for the polar crater, and placed in a polar orbit (along with Mission 7, which was to be the polar lowlands landing). I usually "park" my Mun missions about 7,000 m above the surface before triggering final descent. Well, you can guess what's coming. Normally, for equatorial orbits (which most of my Mun missions have been), that's plenty high. But the Mun has some mountain peaks near the poles that are *higher* than 7,000 m. I start landing my brave Kerbals in order. One, two, and three go off without a hitch. Then I get to 4, and she's nowhere to be found. Just gone. I check the Center, and sure enough she's now listed as KIA (along with poor Jeb, who died when a rocket tipped over on the launch pad on like day 2 or something). That just ruined my whole day. I was so proud of how I was executing seven Mun missions all at once and it was going off without a hitch. That just poured a giant steaming turd on my high. Had to quit and come back a day later when I cooled down (where I put together Mission 8 in memory of my poor, failed Mission 4). The other, repeating, close second, is every goddam time I even sneeze or look away from my screen, the VAB decides to prank me be repositioning my @#!$% launch clips from where I had them to some stage that makes no sense at all. I dread those things. They're literally never been "right" on their own even once. And even when I do move them, if I don't watch them like a hawk, they just end up shifting to some stage that'll ensure the rocket gets torn apart when it tries to launch. If I didn't need them to keep my rockets from tipping over (poor, poor Jeb), I wouldn't touch them with a 120-meter cattle prod. It's gotten to the point where my rage at them getting scewed up actually manages to justify in my head the right to go into my save file and edit it to erase the failure, and then go back into the game and move the damn launch clamps to where I originally put them. Again. Which sort of defeats the spirit of hardcore, but dear God I'm not going to lose 320,000 funds and five kerbonauts because the computer is being a moron (only when I'M being a moron - like letting my poor kerbonauts crash into Mun mountains; or accidentally triggering the stage that separates my re-entry pod from the rest of the ship waaay too early in the mission; or getting impatient with my descent rate and turning off my engines, but not turning them back on again fast enough to slow me down before I lithobrake; or getting in perfect position for docking, and forgetting I'm still in staging mode, and turning my main engines to full blast; or realizing I actually forgot to put a decoupler between two of my stages right as I'm about to trigger it in flight; or getting out past Jool and realizing I accidentally put the wrong antennas on my probe and it's lost communication; well, the list goes on and on. But not the damn launch clamps. Those aren't my fault. Ever.)

Yep. Correct. Never said it was a bug. Not in the post. Not in the topic heading. Here's an experiment, because that's how science actually works. Make a simple rocket. I'll let you decide what simple is... just do it. Seriously. Make it. Make it simple. Simple. Siiiiiiiimple. It's hard. I know. Less parts. Try not to eat the smurfs. You can do it. I have faith. Sim. Pol. Now launch it. Cool. Add a stage. Just for fun. I know you can. It probably still works. Sure you can put some pedantic "check yo' staging" squirrel in your sig. But you don't have to. With the simple stuff (which is not what 'check yo' staging' squirrel is about) it's pretty amazing how often the game actually gets it right. Add another stage. I'll wait. Probably still worked. It's actually kind of cool. You can add stages. And ... wait for it, I know this is an amazing thing that'll just blow your mind. It's quite something... I'll wait... Let you marvel... (unless you don't get 'simple', which might very well be the case). The game typically gets it right. No input from you. No check yo' staging squirrel needed. I'm actually impressed at how often it works. Very impressed. I actually typically 'check yo staging' on a regular basis, and I'm pretty surprised how often it actually matches what I intended. Even when it gets complex. Way way, waaaaaaay more complex than you'd think would work. No way I'm launching without a careful check. Yet it got it right. Now add launch clamps. loveed it up, didn't it? Every. God. Damn. Time. Seriously. Does it ever NOT love it up? (And let's be serious here ... you're actually good enough to make the adjustments ... and that's the goddamn point - you HAD to make adjustments! Didn't you... DIDN'T YOU?!) Did they ever get added in the way you intended (without launch squirrels having to tell you about your moronity so they could shame you into thinking what the game just did *isn't* an idiotic choice?)? Did they? Go ahead. Try it again. Add your pod and put a tank an engine on it. Huh. The game kind of gets the order you intended. Now add another stage. Yep, you should have checked it (loveing squirrel). But, weirdly, the odds are it worked (and checking it verified it did). Now add another one. Huh. Amazing. That also worked. I didn't have to change a thing. Sure I checked. But I didn't have to. Now add the launch clamps. Don't change anything. Just add them. Didn't work the way you thought, did they? Now you have to add a launch squirrel meme to shame you into thinking the mistake was all yours (and, let's face it, *technically* it was, but that's not the point). You *know* there's something insanely simple the game could have done that would have solved the problem, but didn't. Yet it did ... every ... other ... time. Eh. You don't really need to use them, right? It's not like rockets ever tip over on the launch pad and kill all your astronauts and destroy the pad. Nah. Never going to happen. Nope. So no need to pretty much automatically add something that the game's going to inexplicably get wrong when it got everything else right.

Make the goddamn launch clips automatically attach to the first ******* engine, so they are in the same stage. The fact this isn't a done thing by this point leads me to believe that I've stumbled into some sort of ongoing argument where the camp that thinks your rockets should fail for just spectacularly stupid reasons has been drowned out by the camp that thinks that the auto-stager doesn't even need to be a tiny bit, just a hair slightly smarter than a trisomy 35 toad (which isn't even a *thing*). I just wanted to say something. Just get my disgust out there. Because god DAMN. I know it won't get fixed. I'm sure it's not even considered a bug. I know I'm still going to have to hack my save file to occasionally make my Kerbals not so incomprehensibly dumb they actually break immersion. But damn guys. Just... daaaaaamn.

Is the Mun still "eating" ships? In a nutshell: Had 0.8.0 installed. Mun ate three ships all within (or very near?) its SOI. Added the ships back in (copied all three back into the save file from a backup). They didn't reappear. Installed 0.8.2 (removed the entire KSS folder and installed all of the 0.8.2 files fresh). Added the lost ships back. They reappeared when I loaded the save game. Went to do something else. Reloaded KSP with KSS. Loaded the 'persistent' save. Designed and tested a rocket. Noticed my three ships in the Mun's sphere of influence were gone again. Soooo ... is the Mun still eating ships? EDIT @StarCrusher96 Will do! I'll let you know what happens. EDIT #2 @StarCrusher96 The problem is still there, but I've done enough experimenting to pin down exactly how and when it happens. (And yes, I did lower Karkua's gASL to 1000). ANY vessel in the Mun's SOI when the game loads from start (i.e. "Resume Saved," which uses the "persistent" save) is destroyed (and it does count as destroyed - in one test I did whenever a Kerbal is in the ship as it is destroyed, you take the reputation hit). *However* if you "Load Game" while already in the game (i.e. from the Pause Menu), vessels in the Mun's SOI are NOT destroyed. That does make for a relatively easy (if somewhat tedious) workaround - if you are about to quit the game and there are vessels anywhere in the Mun's SOI, if you select "Save Game" and save it (for example, just call it 'quicksave' or 'Mun save' every time and overwrite it every time you want to quit), then when you start up the next game, you've got an easy way to recover your ships: while all of the ship's in the Mun's SOI will be destroyed when you "Resume Saved" from the persistent save, if you immediately "Load Game" and choose whatever saved game you manually made immediately prior to quitting the last time it will restore all of your ships that were lost in the Mun's SOI. It's tedious (and you actually have to remember to do a 'manual' save every time you want to quit - although, as I said, you don't need to build up a ton of save files - you can just keep saving over a single one), it *does* work. Like I said, it's not an actual fix, but it does get around the problem until you figure out a better fix.

EDIT: Awesome. Got it to work. The instructions in the readme file supersede (and, evidently, conflict with) the ones in the instillation wiki and the video. The version of Kopernicus you need is NOT 1.3.1-3 as indicated in the install wiki (and is NOT something you read from the install wiki as implied in the video). It's actually the version that corresponds to the version of KSP you have installed (as spelled out in the readme). So I had KSP 1.4.3, and had to use Kopernicus 1.4.3-2 (no idea if 1.4.3-1 would work, nor do I intend to try). The other trick is realizing where to actually find the correct version of Kopernicus ... the link on the link to its page (yes, I said that right; it's not a copy/paste error) in the install wiki takes you only part of the way (It's like buying a ticket to Paris, but the plane just drops you in London, expects you to know London isn't Paris - which, admittedly, is something all the "This is London" signs should clue you in to - then abandons you in London, and expects you know to just swim to Paris). EDIT #2 (To avoid unnecessary forum spam): @StarCrusher96 Not a problem! Figured it'd be useful for you to know to cut down on more newbies like me spamming you with "I tried to install KSS but couldn't get it to work." Incidentally, I got it completely installed (specifically, I have successfully installed and run all of the 0.8 modules along with EVE and Shader). Not only does it look fantastic, I'm surprised at how little of a hit to performance it caused (sure, fps went down, but I was expecting that, and it is still extremely playable). Looking forward to exploring your (not so) little alternate universe here! (Yep, KSP is ignoring time of day as you pointed out in the known issues - it's actually kind of otherworldly looking...)

Okay, I'm going to guess that the lack of answer means nobody's really explored this functionality and doesn't really know. So it looks like I might be taking point on answering my own questions. So if you're interested, here's a first update: I still have no clue how "funds" can actually be spent. You do seem to get funds by recovering vehicle components, but actually building and launching a rocket doesn't appear to affect it. At the moment it seems to be a de-facto "score" of sorts (you can deduct funds for failure or add them for success), but isn't actually *used* (or at least I haven't found a setting that seems to "use" funds). The "try again" problem I might have made somewhat more progress on. I'm beginning to suspect that to "reuse" a "spawn vessel" node, the previous mission spawned using that node has to be "recovered." In other words - once you "go to the launch pad" (as it were) that particular instance of "spawn vessel" is flagged as "on" (for lack of a better word). And if the builder script loops back to a spawn vessel node that is "on," it just ignores it (well, I think it's technically just assuming the "spawned vessel" exists, so you can't build a new version of it; so it's more like the "spawn vessel" node is set to TRUE, or CURRENTLY SPAWNED, if that makes sense). And the only way to clear that state is to recover the vessel. If I'm right about this, the complete destruction of the vessel is NOT sufficient criteria to set the node to FALSE or NOT CURRENTLY SPAWNED. If I'm right, that means that to "re-use" a spawn vessel node for a destroyed vessel, you've got to somehow make a totally destroyed vessel "recoverable." It might be as simple as spawning a "part" on the launch pad (or maybe a "water boy" kerbal or something) that will be flagged as part of the mission and recoverable. I'll have to test it out to see... EDIT: Well, I thought I'd found something - under 'Options' is a checkmark for "only do this node once." I figured that's what was keeping stuff from working (i.e. since the builder had already done "spawn vessel" it simply couldn't do it again from that node while that checkmark was checked). So I figured unchecking it might solve the "can't loop back around to 'spawn vessel' to try again" problem. THAT was a big no. Not only do you STILL stay locked out of the VAB - so far the ONLY way I've been able to give you access again is to put in a completely new spawn vessel node - but unchecking 'one only' actually seems to set the node as PERMANENTLY true... so I only managed to create an infinite loop that flooded the "Mission App" with more than 700 "you didn't get to the correct altitude" message since the builder literally read it as: VESSEL IS SPAWNED (it's actually completely recovered at this point) SPAWNED VESSEL IS FLAGGED AS RECOVERED (but "made it to 7000 m node" wasn't activated) DISPLAY "You didn't get to 7000 m" SPAWN VESSEL (but VESSEL IS SPAWNED) VESSEL IS FLAGGED AS RECOVERED .... etc. etc, looping through over and over and over again. So far it is seeming very much like NO MATTER WHAT THE SPAWN VESSEL NODE CAN ONLY BE USED ONCE TO ACTUALLY BUILD SOMETHING. After that it is flagged as TRUE *forever.* So it seems like the only way I've found to "try again" is to give the player "lives" in the form of multiple spawn vessel nodes for a given mission objective. Example: You want the player to build a vessel that gets to 10,000 m. Spawn Vessel connected to (1) vessel gets to 10,000 m, (2) vessel is destroyed, (3) vessel is recovered, such that 2 and 3 are alternate branches from Spawn Vessel to test to see if the vessel was destroyed or recovered *before* you got to 10,000 m. There's also another (4) vessel is destroyed or (5) vessel is recovered AFTER (1) to test when the "flight ended" if you did make it to 10,000 m. All of that works as expected. But, if you try to connect (2) and (3) back to (1) (i.e. "try again") you either get: A. A state where it is impossible to ever advance the mission, since you can't build a new vessel, but your old one was recovered or destroyed before reaching 10,000 m (and can never be triggered again). This is what you get when "do node 1" IS checkmarked. B. (2) and (3) "firing" eternally because EITHER "recovered" or "destroyed" is flagged to TRUE and the node can fire multiple times, so it just keeps firing OVER and OVER. And the fact it feeds into (1) is useless, because it thinks the vessel already exists (but didn't get to 10,000 m), so (1) just goes "yep" you've got a vessel, so check to see if it made it to 10,000 m (you didn't), but it WAS either (2) or (3), so cycle back to (1), but it never made it to 10,000, but is WAS either (2) or (3), so cycle back to (1), but it n... you get the idea. Here's the only work around that I can think of so far (my example gives you a total of 4 tries; it could be reduced to 3 or 2, or expanded to more). Call the first "Spawn Vessel" (0). 0) Spawn Vessel, connects to (1), (2), and (3). (2) and (3) connects to (5) Spawn Vessel Try #2. (5) connects to (1), (6) vessel destroyed, (7) vessel recovered (note these are separate copies of the original (2) and (3)). (6) and (7) connects to (8) Spawn Vessel Try #3. (8) connects to (1), (9) destroyed, and (10) recovered. (9) and (10) connect to (11) Spawn Vessel Try #4. (11) connects to (1), (12) destroyed, and (13) recovered. (12) and (13) connect to (14) Message: We've given you four tries and you failed four times. You suck. Game Over (i.e. End Mission). If either (0), (5), (8), (11), or (14) ever actually trigger (1), the mission actually advances to the next objective. ... so it's possible for "failure" to give you more "tries" - but it is REALLY a pain to program...

I can set both starting funds, and manipulate them (and have done so) in the mission builder. But building and launching a rocket has no effect on the funds level, and you can build and launch a rocket that is more expensive than whatever the current fund level is. Why is this? And is there a way to get the mission builder to actually USE the funds when letting the user build rockets? Or are "funds" in the mission builder just for show and don't actually do anything? Likewise, if I want to set things up so if you fail an objective you try again, how do I do it? More specifically - I have a Spawn Vessel node "flowing" into a "get to this altitude" node and a "vessel was destroyed" node. The "vessel was destroyed" node triggers a message saying you didn't reach the needed altitude and tells you to try again. It then loops you back to the Spawn Vessel node. But nothing happens. The player can't build another rocket and try again - they're locked out of the VAB permanently. Why? Thanks in advance - I'm trying to see what I can do with the builder (in fact, I'm actually seeing how viable it is to make some "labs" for my students to play with), but there are clearly some things that I don't understand (that aren't working the way it seems like they should)...

And just as a heads up to the folks that (like me) really like playing in Career mode, another type of contract to be especially way of accepting until the bug is fixed is the "Put a probe into a specific orbit" (either existing or newly launched)... Those without fail have multiple parameters that will almost always be fulfilled by virtually ANY ship you focus on every single time you focus on them (including the "stable for 10 seconds" one that spams every time you accelerate - 10 seconds later). I took three of those last night without really thinking about it and literally set about almost immediately completing them to clear them off of my contract list, and for each of the three satellites each time I switched focus to take care of a maneuver node on my way to the target orbit I would rack up an average of 60-100 notifications (since I was simultaneously fulfilling three contracts with about five parameters each *several* times per maneuver). By the time I got all three into position and cleared the contracts I had probably erased a total of 700-800 notifications!

Don't be! You just need to be strategic about it. If you pick contracts where every parameter gives a reward, you should be fine (an example is tourist contracts, or "rescue stranded Kerbal" contracts). Second, contracts that are extremely fast and easy to fulfill (transmit science from X) won't cause a problem. Finally, contracts that have "non rewarding" parameters that are fairly rare to fulfill WILL spam, but won't do it often because it's unlikely you'll randomly fulfill them (e.g. "be in orbit" or "be stable for 10 seconds" or "have 1000 units of electricity" is bad, but "alt between 55,000 m and 75,000 m," or "velocity between X and Y" still creates spam but is somewhat more tolerable since its much rarer for randomly selected missions you are switching through to monitor to automatically fulfill those). So if you're not getting a *lot* of spam, you can just "trash" the messages as they appear without getting overwhelmed. BTW, the "stable for 10 seconds" is really one to avoid right now. Literally every contract will spam that *every* time you fire and cut your engines and stay "coasting" for 10 seconds....

You're seeing a bug in 1.4.2, and it has nothing to do with any mods you (once) had installed. (I play on a completely unmodded version, and I'm seeing the same thing.) Here's what's going on. It used to be you'd only see "Contract Complete" (if the whole contract was finished) or "Contract Parameter Complete" (if you'd fulfilled one of the contract conditions) if there was a reward involved (funds, science, or reputation), which meant you'd only see the message once (since you can't get the reward for completing the contract - or a "rewarding" contract parameter - more than once). The bug (hopefully accidentally) set it so that literally all contract parameters being completed are being displayed, regardless of whether or not they give a reward. Which means you are being spammed with all of those "contract checkpoints" that have to be verified before anything that gives a reward can be given. So, for example, if you have three contracts that "require the craft to maintain stability for 10 seconds" than any time you switch to a craft and maintain stability for 10 seconds, you'll see "parameter fulfilled" spam for all three contracts. That's what you are seeing in your second picture. No doubt the "test the Rhino" contract requires the craft with the Rhino to "be in orbit." So when you switch to *any* craft that is in *any* orbit you are seeing it tell you you fulfilled the "be in orbit" requirement of your "test the Rhino" contract. Of course, that's totally useless, because most likely the craft you just switched to does not have a Rhino on board (which is another parameter of that contract). At the moment it seems the only option is just to delete all the spam the moment you switch to any ship, which is extremely tedious, but if you don't, you'll soon have hundreds (if not thousands) of those messages in your little "alert" area (all of which you'll eventually have to delete) - especially if you are doing a lot of switching between ships and have a lot of contracts with "minor checks" like "be in orbit" or "maintain stability" currently active. For what it's worth, it looks like completely fulfilling the contract stops at least the spam from that particular contract (since that contract isn't checking any of the little minor things any more). Also, this doesn't seem to be affecting the contract actually giving a reward; mine have been rewarding normally. Naturally, I hope they fix this soon - the spam is extremely annoying, to say the least.