sumghai

Indeed, the very short range makes the whole point of stock EVA suit antennas moot. I'd be inclined to have the transmit button omitted for Kerbal EVA science reports. Interesting! So he did development/maintenance work on EVA suit communications systems?

Sorry @kspe, but that image link is broken. I recommend uploading your screenshot onto Imgur first, and then linking to the Imgur version from your forum post.

I personally don't agree with adding antennas to Kerbal spacesuits. In the stock game, the main purpose of antennas and the CommNet system is to restrict the distance at which probe remote control can be transmitted back to base stations on Kerbin. Since Kerbals are living, sentient beings inside spacesuits, probe control restrictions aren't applicable to them, so they don't need antennas. As for transmitting EVA science reports, I'll point out that while real-life spacesuits do have antenna and backpack radios, they are very short range and intended for communications between the astronaut on EVA and a nearby spacecraft, not a direct EVA-to-ground comm link. Besides, even if an antenna was added to Kerbals on EVA, you would't actually see the classic cartoony whiplash antenna coming out of their backpacks, since they'd be completely enclosed inside the spacesuit anyway. Source: https://er.jsc.nasa.gov/seh/suitnasa.html

Progress Report, 17 October 2018 Sorry for the radio silence, guys - I was waiting to hear back regarding the MechJeb fixes. After playing around with the new KSP 1.5 update, I came to realize that there was no way the new stock stage burn indicator would ever cater for combined decoupler/fuel tank/engine parts. This, and the delays in the proposed MechJeb fixes, ultimately forced me to (very reluctantly) concede to splitting up the Service Module into the Crew Module Adapter (decoupler only) and the Service Module (fuel tank and engine). Thankfully, this was a relatively easy task, since the .MU model files for the CMA and the SM were already separate. All I needed to do was to patch up the missing faces from the top of the Service Module, which I (also conveniently) did by reusing part of the bulkhead ring mesh from the CMA: Therefore, the new craft-building workflow would now be: Attach SDHI Heatshield and ParaDock to Mk1-3 Pod Add the Crew Module Adapter underneath the Heatshield Add the Service Module -OR- build your own custom Service Module underneath the Crew Module Adapter As a result of this change, MechJeb now finally and consistently displays delta-V information for the Service Module, so I can now look into tuning its delta-V capabilities. On its own, the SM has a whopping ~4300 m/s of vacuum delta-V: However, just by adding the CMA, Heatshield, Pod and Paradock, the vacuum delta-V gets bought down to ~1600 m/s: Now, recall that the real-life NASA Orion SM has a rated vacuum delta-V of 1800~2000 m/s - therefore, far from having too much delta-V, the SDHI SM actually has less comparable delta-V. Given the smaller size of the Kerbol star system, I think we can leave the fuel capacity and resulting delta-V as-is. Finally, the "overheating" issue. As previously established, the overheat warning is displayed after running the SM engine continuously until fuel depletion. This warning actually comes from the fuel cell built into the SM, which usually displays an overheat warning whenever it reaches 50% of its max-rated temperature - in our case, this is happening because the integrated LF/LOX O-10 "Puff" means the SM is essentially a rocket engine, and the heat from the engine is affecting the fuel cell. The solution, in this case, was to simply increase the fuel cell PartModule's DefaultShutoffTemp to 95% of the max-rated temperature, and I have confirmed that I can now run the SM engine continuously without ever overheating the fuel cell. This also means I won't need to add the radiator PartModule to the SM. So, what happens now? Because of these changes, I'm going have to completely redo the (new) tutorial that I originally planned on uploading to the GitHub wiki this evening. Consequently, the revamped SDHI SMS month probably won't be out for another month, while I also work on updating optional mod support MM patches, better documentation, nicer brochures etc. But hey, c'est la vie.

[MOD - Moved to Kerbal Network subforum, as this is a question about posting on the forums rather than the game itself]

[MOD - Moved to Science & Spaceflight subforums, as this is a general question regarding astrodynamics] I assume by "geo orbit", you mean Geostationary orbit?

I'm somewhat ambivalent on adding tethers to the stock game, unless they could be implemented properly. The KAS-based tether implementation is a good first draft, but has the drawback that it is essentially drawn as a straight line between the Kerbal and the winch - the tether would then pass right through other objects without being obstructed or wrapped around them as expected, and wouldn't even cater for self-collisions. Ideally, I'd like to see realistic tethers with rope physics, but that would require the game to approximate the tether game object with a (very) large number of rigid bodies and joints, which (like high part count vessels) would lead to significant performance issues in the game engine. That being said, the Obi Rope asset for Unity looks promising, since their creators claim that their system does not rely on rigid bodies/joints.

I concur with @Gargamel. Even with concessions like stripping down the scope of the mobile app to just craft building and maneuver planning, that's still a fair amount of developer time and resources that would be better spent improving and maintaining releases on the core PC and major console platforms, where there's a larger audience (and a better return on investment).

[MOD - Moved to General Mod Development Help and Support subforums]

[MOD - Moved to Add-on Discussions, as farming, greenhouses and recycling are not present in the stock / vanilla game] The two mods that immediately come to mind for life support and recycling are USI and TAC Life Support: In particular, USI explicitly has greenhouse parts that produce provisions for Kerbals, so that may fit your needs best.

Hi @Kerbal #1265375, welcome to the forums. I've moved your post to the Gameplay Questions and Tutorials subforums. What sort of help or mentoring do you specifically need regarding astrophysics in KSP?

@Eaten by Black Hole, I've snipped the quote from your post to keep the thread readable - if you are quoting someone, just quote the relevant part you wish to reply to. Otherwise, if you are just replying to a thread in general, you don't need to quote at all.

That "something else", in this case, is the lower half of the Interim Cryo Propulsion Stage, which separates from the first stage core booster for orbital insertion and essentially still leaves behind an empty cone. Now, an argument could be made that the current ADTP be modified to be hollow (just be redoing the colliders), so that players can build rocket engines that extend into said hollow space. But I suspect that the reason the developers haven't done so is because there currently isn't a stock ICPS engine long enough to actually stick into that unused space. Another possible reason would be that the developers envision most players building rockets by stacking parts on top of each other, and felt that it would be more intuitive to not have parts from the next stage extending into parts from the previous stage (with the exception of payload and service bays, but that's another story). tl;dr - It's an empty structural part because it's the easiest for the developers to make compatible with existing parts

As neither of us will concede our respective positions, I think we're just going to have to agree to disagree, then.

[MOD - Moved to Modelling and Texturing Discussion subforum, as this issue relates to model object hierarchies and animations]

[MOD - Moved to General Mod Development Help and Support subforums]

Could you post a screenshot of the part dimensions and scaling from both Blender and Unity?

As I recently mentioned here, the ADTP-2-3 was based on the on the real-life Launch Vehicle Stage Adapter from the Space Launch System, which doesn't contain fuel. I have no strong feeling either way about a fueled variant.

Most likely because the top diameter was sized to match the old, slightly larger Rockmax decouplers, instead of the new OMB ones that observe strict fuselage diameters. My understanding is that it was based on the real-life Launch Vehicle Stage Adapter from the Space Launch System, which doesn't contain fuel. I personally have no strong opinions one way or the other regarding the addition of a conical fuel tank variant.

I'm very well aware KSP is a game - it simply needs to be consistent with its original theme of space exploration with rockets (and spaceplanes, to a lesser extent), not necessarily limited to Realism Overhaul. Propellers are nice-to-have, but not strictly necessary for atmospheric flight in non-Kerbin atmospheres. As for the (proposed and unbuilt) JPL Mars Helicopter Scout, I'd wait until it has actually successfully accomplished its mission in 2020 before considering the inclusion of electric rotors in the stock game.

Yes, NERVs too. Thanks for the reminder, although it's all water under the bridge now. That's what usually comes to mind when someone mentions propellers. Yes. While many bodies in the Kerbol system have atmospheres without oxygen, I do wonder if the developers simply intended players to make do with LF/LOX rocket engines, seeing as most space exploration happens in the vacuum of space anyway. As mods, yes. I think a distinction needs to be made between propellers (electric or turboprop) as a means of propulsion, and rotating turntables/bearing/actuators that actually move rocket parts relative to each other. The latter should be discussed in another thread. (ASIDE - KSP does have a little-known ModuleRotatingJoint PartModule, although no parts use it and it most likely hasn't been updated to work with 1.4.x. I recall the developers experimented with this a little, but gave up after running into problems where rocket parts moving relative to each other got out of sync, resulting in floating parts)

Personally, if I had my way, I'd have excluded RAPIERs from the parts list at the outset. I'd keep jet engines solely to allow spaceplanes to get some speed before kicking in their ramjets/scramjets/rockets. But getting back to the subject of turboprops in KSP - my argument against stock propellers isn't so much "nobody will use it" (you guys would, and I probably would, too). It's more to do with the fact that stock propellers aren't directly relevant to the game's primary theme of space exploration, and with the finite resources and time the developers have between updates, it would be better for them to focus on other, more pressing features and enhancements, rather than try to turn KSP into a Minecraft/Garry's Mod/LEGO/Build-anything-you-want simulator. Turboprops as mods? I'm fine with that.

@BadlyDrawnBoy, although I was able to view your image, I recommend that in the future you should host your screenshots on Imgur instead - unlike Online-Speicher/web.de, Imgur does not have a file expiry date, and Imgur images can be directly embedded into forum posts.

Older releases of SDHI SMS include a contingency MM patch that uses stock parachute modules, but I don't plan on including that in with the V4 revamp, since I consider RealChutes to be a hard dependency. You're more than welcome to ask someone else to write you an MM patch that replaces my default RealChutes implementation with the stock parachute PartModule, but please note I won't be able to provide support for modified/altered versions of SDHI SMS (i.e. Warranty Void if Tampered) I saw the overheating message myself even when the fuel cell was off, so it didn't matter whether I had solar panels or not. Yes, solar panels are the primary power source for the Service Module. However, I recall that back in the early days of this mod, I was asked by some users to include a fuel cell in the SM, as a backup power source if there was not enough sunlight or if all the solar panels were inoperable for any reason. I figured it was better to have something and not need it, than to need something and not have it.

Indeed - I've also found that reaction wheel torque from the command pod itself is almost sufficient for turning the craft during abort. For the LAS from my own SDHI SMS mod, I actually implemented solid fuel powered RCS thrusters for steering. This is based on the attitude control motors for the real-life Orion LAS, which is essentially a constantly-burning slug of solid fuel feeding eight nozzles independently controlled by proportional valves. What would be nice is for SQUAD to implement some control logic via a new PartModule similar to the PEBKAC mod, that automatically orients the pod retrograde after the abort motors burn out, possibly even automatically releasing the pod afterwards.