SpacedInvader

I've been using the boxes from SEP so far, but one thing about such boxes is that they can cause issues with craft balancing. I do like the idea of switching from a per-seat inventory to a per-pod inventory as it seems to make more sense. First of all, you don't have the issue where the inventory only exists if there is a kerbal sitting there at launch, then you also allow for that inventory to be more generalized instead of forcing a specific kerbal to sit in each seat. In addition its a little bit of a realism bonus as well since its unlikely a kerbal would carry his whole inventory from launch until use rather than pulling it from an on-board storage prior to use.

I guess an outgrowth of that might be to just include a "basic toolkit" with every command module in its own separate inventory so you don't have to manually add the two tools you will literally *always* need with KIS.

I'm thinking that's probably the best approach as it guarantees that the information is presented and I can't think of a way to present the information in a foolproof way within the short constraints of the right-click menu. Saying "(NEEDS LAUNCH CREW)" *might* cut it, but nothing will be accomplished if its just hinted at as crew vs seat doesn't amount to any real difference.

Could be as simple as putting "(Must be crewed at launch to acquire items)" next to each seat inventory button?

Solved my own problem, please ignore

That's probable where things went wrong then since the items were placed into the lander's inventory, but all my crew launched in the main pod. This might be something someone needs to either add to the wiki or the manual as this is quite counter intuitive.

Ok, I'll get that going sometime tonight

That is a far more Kerbal solution than I'm probably ever going to use, but I like it :P. What I ended up doing is some save file editing to place the contents of the original seat directly into Bill's inventory. Save file editing is not my favorite activity, but it worked well enough.

Is there any way to "cheat" a wrench into an inventory? I've just landed my first Mun mission with a full cargo of surface experiments from the SEP mod, only to find out that the wrench I had placed in one of the seat inventories has mysteriously disappeared. I've gone back to the saved craft in the VAB to double check that it was indeed saved into the inventory and it is there, but it is nowhere to be found on the landing craft or in the inventories of any of my crew. Since I'm using Kerbal Construction Time, the next possible time I could launch a ship up here again is more than 250 days, so I really don't want to waste half the science from this mission thanks solely to an evaporating wrench...

I know this is very much a necro, but upon returning to the game again after some time away, I'm experiencing this once again. I have tried making a quicksave and then fast forwarding to the time the encounter was originally scheduled to happen and have found that it has indeed disappeared, with my probe missing Eve by several hundred thousand Km when the original encounter should have resulted in a near-space fly-by within 200km and not nearly enough dV remaining to get the thing back on course. I just want to see if anyone else is experiencing this issue still and/or if there is a solution that has been found in the intervening time. Thanks.

When you say stock KSP scenario, are you saying completely stock or just no OPM? Also does this apply to the later .MAT file you requested?

The assumption comes from the fact that most, if not all, times in the past, errors in the log have been generally related to the lines immediately preceding them. I will spend time this weekend verifying as you've suggested.

This is an interesting idea, but aside from cookie cutter comsats or satellite contract fodder, I'm not sure how it would work in practice. In most cases I find myself building probes to suit their current mission which is usually stuffing them to the brim with as much science as is available currently, supplying them with enough power for their mission, and then giving them enough dV to get it done. In practice this means that a bus design that can hold everything I need today will probably be too small for tomorrow's application. That said, I guess it could have some potential if the design were easily extensible, though I'm immediately drawing a complete blank on how to go about doing that without ending up with an ever lengthening tube... I'm currently using a mod that reduces the maximum authority of reaction wheels quite a bit, so the 0.625m version only produces 0.5 torque in each axis. Not sure that this would be enough to counteract offset thrust. That said, is 5 torque enough to handle the kinds of offset thrust I'm likely to experience with a non-symmetrical, non-tubular design? I guess I could always load in a bunch of radial wheels instead... I've known for a long time that IRL probes weren't designed to look cool, but are instead 100% functional (after all, who cares what they look like after launch when they probably won't be seen by another living creature for a billion years, if ever), but it didn't occur to me to try imposing the same rules on myself when building in KSP. I feel like I'll still be running into significant balancing issues though, thanks to the inherently course way in which trimming of the vehicle happens in KSP.

This makes me very happy...

So I'm back into KSP again after some time away and of course TOT is one of the first things I've added into my install (still love this after all these months), but I'm running into a problem that I, as well as others, have run up against but in searching seems never to have been resolved, namely that the UT KSP TOT settles on for its maneuvers appears to be incorrect when imported into KSP. I'm in the process of plotting out my first flyby of Eve and have gone through the initial steps of plotting a course before uploading to KSP just to see if I've done it correctly (currently its just an impact mission before I fine tune everything), but upon uploading to KSP, the maneuver as placed is nearly 120° too early in the orbit even though the dV numbers are all correct (advancing the maneuver node ahead in UT eventually results in exactly the orbit that KSP TOT depicts without changing any of the dV values). I've gone back through the instructions several times and I'm definitely not missing any steps that aren't related to fine tuning the arrival a Eve, and I've reloaded / recreated the bodies.ini file a couple of times (I'm using the OPM mod) and have gotten the same results, so I'm at a loss as to what could be causing the program to be calculating the wrong departure time. Any help would be appreciated, either in pointing me towards a solution to this problem that I haven't been able to find in searching the thread, or in identifying the issue so I can correct it and move forward. Thanks. EDIT: Running into a new problem with the mission optimizer: I can run the basic "minimize distance to body" optimization easily, but then when I let it go to zero distance and then try to re-run the optimization with constraints to get my arrival to be where I'd like it to be, it stops after only one iteration and the log gives me the message "fmincon stopped because the size of the current step is less than the selected value of the step size tolerance but constraints are not satisfied to within the selected value of the constraint tolerance." This is how I always began my optimizations in the past and haven't run into this problem, did something change that prevents the program from working if the orbit results in a 0 or close to 0 distance from the body?

I'm running into a serious issue with Kerbal EVAs which I *think* might be resulting from either an error or a conflict with TACLS. Basically, when I send a Kerbal on EVA, I lose all ability to control that Kerbal as well as losing the ability to input game commands through the keyboard (can't let go, re-board, quicksave / load, change to map view, use esc menu, etc), ultimately forcing me to Alt-F4 to force close the game. The reason I think it might be TACLS causing this issue is because I get the following errors when sending a Kerbal on EVA: -INFO- Tac.LifeSupportModule[FFE45630][213.32]: OnAwake (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) -INFO- Tac.LifeSupportController[FFE6724E][213.32]: Vessel situation change (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) Input is null for field 'initialName' in config node 'MODULE' at System.Environment.get_StackTrace() at ConfigNode.AddValue(System.String name, System.String value) at BaseFieldList.Save(.ConfigNode node) at PartModule.Save(.ConfigNode node) at ProtoPartModuleSnapshot..ctor(.PartModule module) at ProtoPartSnapshot..ctor(.Part PartRef, .ProtoVessel protoVessel) at ProtoVessel..ctor(.Vessel VesselRef) at ContractConfigurator.Extensions+<GetHashes>d__5.MoveNext() at ContractConfigurator.Parameters.VesselParameter.OnVesselCreate(.Vessel vessel) at EventData`1[[Vessel, Assembly-CSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].Fire(.Vessel data) at Vessel.Initialize(Boolean fromShipAssembly) at FlightEVA.onGoForEVA() at FlightEVA.spawnEVA(.ProtoCrewMember pCrew, .Part fromPart, UnityEngine.Transform fromAirlock, Boolean tryAllHatches) at FlightEVA.SpawnEVA(.Kerbal crew) at KSP.UI.Screens.Flight.KerbalPortrait.ClickEVA() at UnityEngine.Events.InvokableCall.Invoke(System.Object[] args) at UnityEngine.Events.InvokableCallList.Invoke(System.Object[] parameters) at UnityEngine.Events.UnityEventBase.Invoke(System.Object[] parameters) at UnityEngine.Events.UnityEvent.Invoke() at UnityEngine.UI.Button.Press() at UnityEngine.UI.Button.OnPointerClick(UnityEngine.EventSystems.PointerEventData eventData) at UnityEngine.EventSystems.ExecuteEvents.Execute(IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) at UnityEngine.EventSystems.ExecuteEvents.Execute(UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction`1 functor) at UnityEngine.EventSystems.StandaloneInputModule.ProcessMousePress(UnityEngine.EventSystems.MouseButtonEventData data) at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent(Int32 id) at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent() at UnityEngine.EventSystems.StandaloneInputModule.Process() at UnityEngine.EventSystems.EventSystem.Update() (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) 2/2/2017 4:28:00 PM,AmpYear,OnVesselCreate (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) RemoteTech: SatelliteManager: OnVesselCreate(00000000-0000-0000-0000-000000000000, ) (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) -INFO- Tac.LifeSupportController[FFE6724E][213.32]: Vessel Modified: (00000000-0000-0000-0000-000000000000) (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) Input is null for field 'initialName' in config node 'MODULE' at System.Environment.get_StackTrace() at ConfigNode.AddValue(System.String name, System.String value) at BaseFieldList.Save(.ConfigNode node) at PartModule.Save(.ConfigNode node) at ProtoPartModuleSnapshot..ctor(.PartModule module) at ProtoPartSnapshot..ctor(.Part PartRef, .ProtoVessel protoVessel) at ProtoVessel..ctor(.Vessel VesselRef) at Vessel.Initialize(Boolean fromShipAssembly) at FlightEVA.onGoForEVA() at FlightEVA.spawnEVA(.ProtoCrewMember pCrew, .Part fromPart, UnityEngine.Transform fromAirlock, Boolean tryAllHatches) at FlightEVA.SpawnEVA(.Kerbal crew) at KSP.UI.Screens.Flight.KerbalPortrait.ClickEVA() at UnityEngine.Events.InvokableCall.Invoke(System.Object[] args) at UnityEngine.Events.InvokableCallList.Invoke(System.Object[] parameters) at UnityEngine.Events.UnityEventBase.Invoke(System.Object[] parameters) at UnityEngine.Events.UnityEvent.Invoke() at UnityEngine.UI.Button.Press() at UnityEngine.UI.Button.OnPointerClick(UnityEngine.EventSystems.PointerEventData eventData) at UnityEngine.EventSystems.ExecuteEvents.Execute(IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) at UnityEngine.EventSystems.ExecuteEvents.Execute(UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction`1 functor) at UnityEngine.EventSystems.StandaloneInputModule.ProcessMousePress(UnityEngine.EventSystems.MouseButtonEventData data) at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent(Int32 id) at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent() at UnityEngine.EventSystems.StandaloneInputModule.Process() at UnityEngine.EventSystems.EventSystem.Update() (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) FF: kerbal status change: Valentina Kerman from Assigned to Available at time 55293494.4518729 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) Here is the output_log.txt. Thanks.

I'm running into a very frustrating issue with my current game, namely that whenever I send a Kerbal on EVA, the game refuses to accept any more inputs to control that Kerbal (can't let go of the ship, reboard it, or switch focus to the ship and back) and I can't quicksave, quickload, or use the Esc menu. Most other game controls seem to work just fine like camera positioning and the various buttons in the menu sidebar, but I have absolutely no way to end the EVA or return to a previous save so the only way to get out of the situation is to Alt-F4 to close the game. Searching hasn't resulted in any obvious fixes, or even other people experiencing similar problems, so I'm hoping someone who has seen this before can give me some direction on how to fix the problem. Thanks.

I usually do, but the point of this thread is to try and find the techniques that people use to emulate some of those appearances in KSP. I don't think I've had less than 100 mods since 24.5, with DOS being one of my must-haves, that said, I'll have a look at Fuel Tanks Plus. As for trying to fit KSP probes to match real-world counterparts, the biggest problem I run into is balancing for thrust. Because of the way KSP physics work and the fact that there are no trim weight mods, I often find that just to make the thing fly straight I need to have symmetrical or near symmetrical designs which then results in the same "tube with science bolted to it" appearance.

I've had that installed basically since it was released, however the result is still much the same... You still end up with a tube with science bolted to it, now its just on the inside.

So I've been playing this game on and off for years (usually take a break after each major update for my favorite mods to get updated) for years, but one of the things that has always bothered me is the fact that pretty much every last one of my satellites / probes ends up looking like a tube with science experiments bolted to it. Unfortunately, I believe part of this is the limitations of the way the game's craft system is built, but are there any techniques that help make probes look a little more realistic? Thanks. EDIT: I'm aware of the mods that recreate the US and Soviet probes with love, but I'd prefer to be able to design my own.

First of all, the connectivity model you're describing is almost literally what the ROOT range model does in the remote tech settings. It allows you to have a massive dish on one end and a tiny dish on the other and as long as their additive range (approximately, there is some math) is enough to cover the distance, you've got a connection. As for working with the stock system as opposed to instead of it, it looks like that is in the cards for the future, just no idea when.

I'm experiencing an issue I've had in the past that I was never able to resolve where parts attached to procedural parts drift when a craft is loaded. In this specific case, I have a Real Chutes stack chute attached to a procedural Real Fuels tank and I've had to scrap the mission because the chute moved inside the tank after several loads and will no longer deploy because it sees itself as being inside a fairing. Considering this degree of movement has happened with only two loads of the craft (editor>pad and then one while in orbit around the Mun) on a very short term mission, I have significant concerns about using any PP on long-term missions where I'll be loading the game and probably the craft multiple times. Has anyone experienced this other than me, and if so, is there any way to prevent it? EDIT: I'm fairly certain that its the attach nodes that are moving thanks to some error in part loading.

Ok, thank you.

Right, but is the net effect X*1.5 or 2X*0.5?

After doing some testing, I'm really feeling that reducing ISP in this fashion is not a viable way to get the desired outcome, at least with Kerbin-Scale parts. For example, trying to do an Apollo-style crewed Mun mission results in a need for ~75 tons of fuel in the service module, leading to a tank that is 14m long if you want to keep the same diameter as the Mk1-2 pod. What has me confused though is how much more fuel mass seems to be required for this reduced ISP system than for real values... unless I'm reading the stats wrong, Apollo 11 launched with a mass of ~45 tons, which means a similar mission with scaled ISP in the Kerbin system should have similar values, but instead the mass of the command module + lander is approximately double. EDIT: Does ISP scale in a linear fashion?