eightiesboi

Sorry, I missed your questions. Yes, as I posted, I use KCT (and highly recommend it), and yes the problem persists throughout resets. However, I gave up and launched the station anyway, and now I have a much larger (game-breaking) problem that is posted elsewhere. But thanks for offering to help with this!

Hello all, I have a space station just outside Kerbin SOI in orbit around Kerbol. If I go into Map View and try to set a maneuver node, KSP crashes. The logs show some kind of infinite loop. Help! Logs here: http://1drv.ms/1dO12tW RasterPropMonitor-Core v0.20.0 UniversalStorage 1.1.0.4 xScience 4.4 surfacelights 1.0 ModuleRCSFX v4.1 PilotAssistant 1.10.0 USI-EXP 0.4.1 KSP-AVC 1.1.5.0 ScienceAlert 1.8.7 FirespitterCore v7.1.3 KerbalAlarmClock v3.3.2.1 CommunityResourcePack 0.4.2 ProceduralFairings v3.14 Chatterer 0.9.5 TacFuelBalancer v2.5.1 TACLS v0.11.1.20 DockingPortAlignmentIndicator 6.2 TriggerAu-Flags 2.7.1.0 Toolbar 1.7.9 AlternateResourcePanel 2.7.1.0 TACLS-Config-Stock v0.11.1.20 RealChute 1.3.2.3 ShipManifest 4.3.0.2 KerbalEngineerRedux 1.0.16.6 FinalFrontier 0.8.2-1285 PlanetShine 0.2.3.1 AviationLights 3.7 KerbalConstructionTime 1.1.7 StationScience 1.5 PlanetShine-Config-Default 0.2.3.1 DistantObject-default v1.5.5 DistantObject v1.5.5 USITools 0.4.1 PreciseNode 1.1.3 DavonSupplyMod 014 SAVE 1.0.1-672 TransferWindowPlanner v1.3.0.1 KerbalNRAP 1.5.0.4 WaypointManager 2.3.2 EditorExtensions 2.8 KAS 0.5.2 StageRecovery 1.5.6 ModuleManager 2.6.5 AGExt 1.32d RemoteTech 1.6.5 Fusebox 1.31 RasterPropMonitor v0.20.0 KIS 1.1.5 GCMonitor 1.2.4.0-21 ActiveTextureManagement-x86-Basic 5-0 ConnectedLivingSpace 1.1.3.0 Protractor v2.5.1 DangIt 0.6.1 SCANsat v12.1 Trajectories v1.3.0a ModularFlightIntegrator 1.0.repackaged0 RCSBuildAid 0.7.1 SmartStage v2.6.1 DeadlyReentry v7.1.0

There are a bunch of people here that would happily help you, but we need more info. Screenshots, logs, and what mods you use are a good start. - - - Updated - - - And speaking of help, no one has any ideas?

You probably mean the KIS/EVA Portable Science Container and Transmitter v1.3 from Zorbaq... and it *can* transmit science. http://forum.kerbalspaceprogram.com/threads/106562-1-0-2-KIS-EVA-Portable-Science-Container-and-Transmitter-v1-3?highlight=backpack+science

Well, if you use Remote Tech, the Stayputnik is quite useful early on. RT 2 has a flight control computer that can orient and kill rotation, no SAS needed (although you will need some type of control, like a reaction wheel, added to your probe). My early comms sats all use Stayputnik cores, and many of my later ones do too for various reasons (weight being one of them). If you don't use RT, then I agree, they aren't very useful because of the lack of SAS. I suppose if you had a really well balanced rocket, you could use them for science gathering by giving them ballistic trajectories, using the Mun to capture them, or whatnot. But since RT 2 is one of my must-have mods, I don't see the reason. So, in keeping with the Tips compendium, if you want to get use out of your first available probe core, take a look at RT 2, as it's flight control computer makes up for the lack of onboard SAS without being too cheat-y, as it also requires you to have communications with your core. PS - KoS would probably work just fine with a Stayputnik as well.

Hi all, New problem for me, although I swear I read about it previously here. My search-fu is weak this morning though, so please bear with me. I have just built a station that will be bound for solar orbit. Plan is for one scientist to be aboard, and then have him return via a Mk 1 Command Capsule. The station, although unmanned, has a OKTO probe core hiding in it. The return capsule has a Stayputnik (so that I can use the flight control computer to setup my return course). I use KCT and I was running a simulated launch to test out my build. Everything went fine... made it into orbit, etc, then ran into some problems unrelated to RT 2. Went back into the editor, fixed the problems, and then restarted the sim already in orbit at 100km (I just wanted to check my return capsule. My intrepid scientist boarded the capsule and then undocked and prepared to go home: and here is where the RT 2 weirdness began. I brought the flight computer up and attempted to orient my vessel. No go. Checked and realized I had locked off the power on the core and my capsule (I keep the return capsule cold and dark to make sure I always start the return flight with full power and supplies, regardless of whether my solar panels are providing power). Restored power and tried again. No go. Checked the map and saw I had a connection to KSC (which shouldn't matter; I should still be able to use the flight computer in local control mode as long as I have a core with SPU on board, or so I understand). Nothing I did made a difference--clicking orientation buttons on the flight control computer put a notation in the queue, but didn't have an actual effect, and setting a maneuver node and hitting EXEC did nothing at all. And yes, I was manually able to control both thrust and rotation, so it was not a matter of an engine or reaction wheel issue. It seems to me that having more than one core has confused RT, but this is not the first multi-core vessel I've launched, and it *is* the first time I've experienced this issue. Thoughts? Logs and craft file here: http://1drv.ms/1KnqcMV Craft should be stock plus surface lights, KIS, Real Chute, and Universal Storage. RasterPropMonitor-Core v0.20.0 UniversalStorage 1.1.0.4 xScience 4.4 surfacelights 1.0 ModuleRCSFX v4.1 PilotAssistant 1.10.0 USI-EXP 0.4.1 KSP-AVC 1.1.5.0 ScienceAlert 1.8.7 FirespitterCore v7.1.3 KerbalAlarmClock v3.3.2.1 CommunityResourcePack 0.4.2 ProceduralFairings v3.14 Chatterer 0.9.5 TacFuelBalancer v2.5.1 TACLS v0.11.1.20 DockingPortAlignmentIndicator 6.2 TriggerAu-Flags 2.7.1.0 Toolbar 1.7.9 AlternateResourcePanel 2.7.1.0 TACLS-Config-Stock v0.11.1.20 RealChute 1.3.2.3 ShipManifest 4.3.0.2 KerbalEngineerRedux 1.0.16.6 FinalFrontier 0.8.2-1285 PlanetShine 0.2.3.1 AviationLights 3.7 KerbalConstructionTime 1.1.7 StationScience 1.5 PlanetShine-Config-Default 0.2.3.1 DistantObject-default v1.5.5 DistantObject v1.5.5 USITools 0.4.1 PreciseNode 1.1.3 DavonSupplyMod 014 SAVE 1.0.1-672 TransferWindowPlanner v1.3.0.1 KerbalNRAP 1.5.0.4 WaypointManager 2.3.2 EditorExtensions 2.8 KAS 0.5.2 StageRecovery 1.5.6 ModuleManager 2.6.5 AGExt 1.32d RemoteTech 1.6.5 Fusebox 1.31 RasterPropMonitor v0.20.0 KIS 1.1.5 GCMonitor 1.2.4.0-21 ActiveTextureManagement-x86-Basic 5-0 ConnectedLivingSpace 1.1.3.0 Protractor v2.5.1 DangIt 0.6.1 SCANsat v12.1 Trajectories v1.3.0a ModularFlightIntegrator 1.0.repackaged0 RCSBuildAid 0.7.1 SmartStage v2.6.1 DeadlyReentry v7.1.0

Love the mod... one question: should my log be spammed with FF entries? Log here: http://1drv.ms/1MlOKEk

PM'd you

I'm curious, are you stack-attacking (node to node) or surface attaching radially? I ran a test on a completely different craft. Radially attached the DERPs (propulsion module) to the surface (a structural fuselage). Ran three tests: 1. Propulsion attached normally, 2. propulsion attached upside down, and 3. propulsion attached normally, another propulsion attached to it. Results as follows: 1. "Evacuate" inflated module, transferred Kerbal, and activated Decouple setting but propulsion module did not decouple. Fail. 2. "Evacuate" inflated module, transferred Kerbal, and decoupled upside down propulsion module from pod, but propulsion module stayed attached to surface. This indicates that the Decoupler stage on the propulsion module *is* staging, but for some reason doesn't actual get detached from the surface it is attached to. 3. "Evacuate" inflated module, transferred Kerbal, and second propulsion module detached from the first, which stayed attached to the fuselage. I gave For a reason I am unable to discern, my propulsion modules are unable to detach once radially attached to the surface of a vessel. I was really hoping that Roverdude might have an idea, but I think he's a bit busy right now, so no worries... I've officially given up and moved on to other ideas. Thanks for your suggestions, MarcAFK... repped.

I routinely disable one battery on my probes to keep as a reserve. Even if you don't have a connection, you can enable the battery again at a later time and take whatever action (like rotating your craft) that is necessary. Think of it as a reserve battery.

Have you tried using the custom setting? You can set the pitch, roll, and heading manually, and IIRC, this is always set to the SOI celestial body. So a 0 pitch will always point your sat at the horizon line, a 90 heading will point you due west, and set your roll so your solar panels are always facing away from the planet. Granted at sunrise and sunset orientations, the body of your sat will block the sun, but you will get direct sunlight for most of your orbit. Also, I'm sure you are deactivating your DP-10... it only takes a little juice, but every bit counts. Finally, you can deactivate the battery on your probe, and if you find power running out rapidly, reactivate it and walk into the light, Carol Anne.... er, turn your sat towards the light. Good luck! I can't imagine KSP without this mod. I didn't launch a single sat when 1.0 came out as I refuse to play unmanned without Remote Tech.

Thanks for the quick reply RoverDude... I'm not so worried about the reentry (I was including it in case there's something that jogged your or someone else's troubleshooting senses), but I'd really like your input as to why the DERPs don't detach. I didn't include logs because there's nothing relevant in them that seems amiss, but I will certainly upload them if it helps. I'll also try building a different ship and again radially attaching the DERPs to see if I can replicate the problem. Again, I appreciate all you've done for KSP, both the stock game and the modding community. I know my problem is, well, *my* problem, but I am stymied and I would really appreciate some suggestions from you or others.

Attempting to add escape pods to a lander. Craft file is here: http://1drv.ms/1JwpQEl It's stock plus universal storage plus TAC LS. I have two action groups set: the Brakes group is set to Evacuate the pods and start the RTG slug, and the Abort group is supposed to decouple the engines. However, no matter what I try, the radially attached engines won't decouple from the ship. Can anyone figure what I've done wrong? I also get a CLS error in the debug log. Doesn't seem to affect anything. So far, I've not been able to land successfully. I put this down to pilot error, but I will probably end up adding chutes, as I do agree that an escape pod should be fire and forget. Roverdude, if you are considering at all fixing the chute, put me down in the "yes, please" column! Lastly, on a test reentry from 100 km orbit, my Ablative Shielding (DRE installed) wasn't even touched. Is that due to the shallow entry profile or something else? Thanks in advance!

Hi there. Let me suggest that there are a lot of interested gamers on these boards that would happily help you, but you've given almost no information. No logs, no screenshots of your directory structure or of the in-flight scene, not even a description of what is happening other than "refuses to work". This is a very stable, very popular mod, so if it isn't working for you, it is almost certainly user error, but without more information as to what is (and isn't) happening, logs, and screenshots, helping you will be nigh impossible. We've all been there. Take a deep breath, read a couple of different places where to find what you need to post, take some screenshots and post again.

One question--are you playing with Root Range Model? If so, and presuming you are set on the altitude of 2000km of your satellite network constellation, you could include DTS-M1 dishes on your sats with their dishes pointed towards Eve and a DP-10 on your lander. The root range model gives your lander a 2800km range when paired with the DTS-M1, which should be sufficient if my quick geometry calcs are correct. Sigma88 also has a great point in that if you use KOS to set your landing profile you can have your Communotron 16 deploy after atmospheric entry when it is safe to do so. If you do that, and again, if you are using root range, your C-16 will easily be able to communicate with your existing C-32s. Good luck! PS - If you don't play with Root Range, check it out... http://remotetechnologiesgroup.github.io/RemoteTech/guide/settings/#alternative-rules

All, This is not my first attempting with playing with RT2 (I consider it a must-have mod), but this is the first time I am trying to deploy four communications sats during one mission. Sat one went without a hitch. Sat 2, however, lost my maneuver node burn that I had setup in my flight computer. I had a checklist to make sure I didn't miss any steps, as I knew that this sat would not have a KSC connection at the time of the burn. Here's what I did, step by step, starting from my deployment vehicle in stable orbit, with all my sats having antennas deployed and activated. Sat one, decoupled from platform, engines activated, maneuver node and burn set (thanks, Precise Node). Raw time alarm set for next deployment. Flight computer updated by setting orientation to maneuver node, and program EXECuted. Engines fired on profile. Second maneuver node set (KSC connection still active), flight computer updated (orientation and program) and double-checked while still in range of KSC. Warped to second node (no KSC connection here). Engines fired on profile. Sat two, approximately 20 minutes before node (and within range of KSC), decoupled from platform, engines activated. Maneuver node and burn set, second maneuver node and burn pre-set in Precise node. Raw time alarm for next deployment set. Flight computer updated by setting orientation to maneuver node, and program EXECuted. Double checked program while still in range of KSC, as connection would not be available for first node. Switched back to Deployment platform. Completed a contract. Switched to KSC. Duplicated a building launch vehicle in KCT queue, added new contact. Switched to Tracking station. Warped to KAC maneuver node alarm. Switched to Sat two. Cleared and deleted alarm, opened flight computer. No maneuver node present. Flight computer now reads "Kill Rotation", which was *not* pressed after decoupling. Watched KER count down last minute to node burn. Engines did not fire. Output log here: http://1drv.ms/1KhNBNi Suggestions? It is, of course, possible that it was human error, but I was being really really careful about double checking, and this was only the second sat deployment. I am certain to the point of temporary insanity that the node was set in the flight computer before I switched away. One other oddity. While I was testing my sat deployment, I noticed that if I left the flight computer open while I switched from one sat to another, the computer would continue counting down the maneuver node for the sat I had switched from, and not the sat that I was currently looking at, until (and unless) I closed and reopened it. Thanks in advance!

Gotcha. So, for the record, you are saying I am not crazy and they can take the restraints off, right? Please--my kerbals need me! Lol! Thank you for the quick response and repped.

Am I crazy (well, I am, but maybe not in this specific case) or did the right click on parts in VAB used to have a notation stating when something was KAS grabbable / attachable? Updated KAS and KIS. Pics here: http://1drv.ms/1c5KVH2 Thanks!

What they said and look under the Aerodynamic tab.

If you mean the actual settings, they are accessed via the icon on the Space Center page. If you mean settings for your chutes, it depends on whether you are in career mode and whether you have unlocked action groups, as they are accessed either by right clicking the chutes, or by going into the action group settings for the chutes. This has been discussed many many many times. If you have to press spacebar twice, check your settings to see if you have them set to automatically arm. I prefer to have them auto-arm, that way I arm them via staging and then let them deploy as set. The message you refer to is a bug. stupid_chris has already noted it. I realize this is a long thread, but all of your questions have been answered by much more knowledgeable persons than myself, and multiple times to boot. At least reading the first page and the last few would probably save you the time of posting and asking questions that are already answered.

ATM helps with adding mods. If you are playing Stock, then you don't really need it (you aren't near the ceiling for OOM crashes). If you have a lot of mods (I do) that add a lot of textures, ATM is very helpful. That's the hell that's going on.

The tag 1.0 (or .90, etc) refers to the version of KSP that the mod works with or is being developed for, not whether the mod is error-free, alpha, beta, WIP etc. If every mod carried a .90 tag until it was done, there'd be much confusion (and CKAN would be confused, for those of us who use it.

magico13 - Thank you for the quick response! It's nothing I can't live with, and I wouldn't play KSP without KCT!

Hi! Love the mod, having one strange issue. I did a quick search to see if anyone had heard of it, but no such. Basically, when I recover a vessel from landing and try to edit it in the VAB or SPH, the vessel is above the ceiling. Sometimes, I can get lucky and click on it, then move it back down to where I can work on it; sometimes I can't. I can provide screenshots or logs, and I am wide open to suggestions. Thanks, and thanks for this terrific mod!

Yes, in the difficulty settings for the game, uncheck the option to respawn missing kerbals. Then, if your kerbals die from anything (including lack of LS), they are really dead. It is not necessary to make any adjustments to the config files. - - - Updated - - - Editing the save file is unnecessary, as I just mentioned. Oh, and on most boards, going back and effectively deleting your post once it is part of an exchange is considered rude. Just saying. You might also consider simply the courtesy of apologizing to RoverDude instead of asking him to unquote you.