SpacedInvader

Simply fantastic!

Wonderful

I can confirm this behavior on the current version as well.

Ok, finally had a chance to test and I'm getting the same behavior 0.75m prior to tracking station and 0.628m after.

I am, I guess I could try replicating the issue when I get a chance tonight. What are the steps to replicate?

You may have trouble getting support on an old version. I know ferram has commented in the past that everyone should be updated if they want help because its not easy for him to keep track of all of the different versions. But I hope you get it sorted out.

Was able to figure out my question on my own. This can be deleted now.

Nevermind, my issue was definitely user error. Mods can delete this if they want.

I think the water purifiers in the sleeping modules would represent urine reclamation while the ones in the labs and gym would be representative of greywater reclamation. On the ISS, both the service module and tranquility contain water purification systems according to that map, with tranquility being mostly for exercise / storage according to wikipedia (equivalent to the GymHab) and the service module containing 4 of the 6 sleeping berths (equivalent to the SleepHabs).

That's a nice find! Much more detailed than the general "This is what the ISS has for ECLSS systems" I've been able to find. I especially like that systems map as I spent some time looking for equipment locations to be sure that they were actually distributed around the station and not concentrated in one or two places. As far as the masses go, if you've already added some to account for subsystems, that works just great. Right now, I've got a carbon extractor and a water purifier in all 5 SleepHabs, the GymHab, and both Labs. I figured the node and the airlock probably shouldn't have them as they're more secondary modules. I think I will probably leave the life support modules out of the PMM since it is really just for logistics and storage, so it should consist of a big KIS module and a similarly large service module / life support MFT tank. All of the converters are scaled to support 2 Kerbals so at a minimum, two modules will be needed to support the three crew of the NapHab and three modules will be needed to support a full 6 Kerbal crew.

Question: I'm thinking about adding additional mass to the modules to account for the life support machinery. I've only been able to find a mass for the Elektron, which is 150Kg, but thats not the process that I'm putting into to deal with O2 recycling. Instead I'm using the carbon extractor process, but I can't find a mass for something similar to it and the TACLS unit seems pretty heavy at 5 tons, even dividing that by 4 to account for the reduced size of the one I'm putting into the modules, the TACLS weights for the extractor and water purifier would come to 2 tons per module, which seems heavy to me. So, does 2 tons sound like a good number, or should I go with something smaller than that? Or am I overthinking this? EDIT: I did just find that the ISS ECLSS water reclamation / purification system weighs in at about 1.5 tons, but that's for the whole station and not for an individual module.

Maybe something to think about for the 1.1 update then as most people will probably be starting new saves and anyone attempting to convert their save would be adept at save file editing anyway.

I should have some configs to share by later tonight or tomorrow afternoon. In the meantime, @cxg2827you might want to consider changing your part naming convention somewhat. As they are now, they are named only with their actual part, but this leaves it open to name conflicts and also makes it a little harder to call them out in MM configs because you have to use the specific name for each part. What I was thinking about would be to change it to follow the convention CxAero_TYPE_MODEL_VERSION or something similar. Functionally, this would end up looking like CxAero_SleepHabV4-1 or CxAero_LabMini. First of all, this would add the CxAero_ to all of your parts so if someone created a part also named 2MMiniLab sometime down the road, there wouldn't be any conflicts, and second, it would allow you to call out all CxAero parts, or all CxAero_SleepHab parts without having to call each out individually. Just a thought.

This is the craft: The largest part is the 3.75m procedural heat shield on the bottom.

TACLS has various converters designed to emulate real life ECLSS processes like the Elektron or CO2 scrubbers. TaranisElsu put a ton of work into trying to balance them based on real human needs, but you can use his template to scale the reaction appropriately. I was thinking about giving each functional module (Hab, Lab, Gym) converters to support 2 Kerbals, emulating the ISS style of distributed life support systems, and also promoting variety by needing more than a single sleep hab to support its full compliment of Kerbals. As for the science lab, I think 3 would probably be just fine as it fits with the size difference between it and the mini. For some reason I thought both the mini and the 2M had capacities of 2 Kerbals, which is why I was going to make the 2M 4.

I did a little testing and feel that something is not correct with the aerobraking calculations. Both KSPTOT and the online KSP aerobraking calculator state that 0.2 is a decent, though very rough, estimation of the coefficient of drag. Now, I've gone and run through the aerobraking calculator a couple of times and its given me different numbers based on two different periapse altitudes, but both seem WAY wrong. The first time through, I set my periapse at 50km with an apoapse of 1000km and the calculator gave me a Cd of 20.07. The second time through, I set the periapse at 60km with the same 1000km apoapse, and the resulting Cd was 24.30. Seems to me that these numbers should not be different? Here's the funny thing, though, after getting these numbers, I replicated the maneuvers in the Mission Architect and was surprised to see that the resulting change in orbit did not match what was occurring in KSP. The first aerobrake, with a periapse of 50km predicted an apoapse of ~870km after the maneuver, while in KSP, it was actually ~691km. The second pass predicted an apoapse of 973km after the manuever, but was actually ~935. Now, I can understand that KSPTOT is really only a simulation and there are variables it can't account for easily (like periapse dropping during the braking maneuver), but it would seem to me that if I do the test braking for calculation, then immediately input the resulting Cd into an aerobraking maneuver within KSPTOT (basically the conditions which resulted in that Cd calculation in the first place), then the orbits should be the same in KSPTOT and KSP? EDIT: The reason I'm trying to figure this out so intently is that I've already got missions on their way to Duna and Eve that are going to rely on accurate aerobraking to hopefully get encounters with their respective moons in addition to assisting in capture.

He's asking which color people like best. Personally, I like the darker grey as it looks a little more realisitc. That said, I don't necessarily think that all of the modules of a space station should be the same color as it tends to make it feel like a single part rather than a collection of modules. @cxg2827have you thought about maybe including fstexture switch to make the textures changeable in the VAB? It would take some extra memory, but the whole module can be written out in favor of one color or the other using an MM config for those who would rather save memory. Just a thought.

I understand what you're saying about hot-bunking, but for me at least, the current config gives that impression because you can't actually fill all of the bed space in a module. As best as I can tell, ISS crew don't sleep in shifts and only sleep in different parts of the station because that's where the sleeping berths could be fit in. Also, the original plan was to have all of the crew sleep sleep in one module, but the end result was instead split sleeping areas. All of this is why I think the sleep habs should have a crew cap equal to their number of beds... This would allow everyone to have their personal space when not "on duty" rather than being forced to float around in the gym or science lab. On a side note, I was thinking about keeping the life support rates for the modules at around 2 Kerbals per module and maybe even none in the nodes to encourage variety in station design. For the science labs, the 2M is definitely ~3x the size of the Mini: That said, for some reason I didn't see the 3 Kerbal capacity, and I was only going to make it a 4 Kerbal capacity anyway to represent the extra science racks that would be added in there for its size. The addition of the station science research module is not because the current science modules aren't working, but rather to increase functionality and reduce necessary parts for anyone who is using the station science mod (like me ). EDIT: On a further side note, I'm also thinking about adding OKS functionality into these modules as well, though those will end up being much more complicated and I've got no idea what would make a suitable aeroponics / agricultural module. I should also point out that the configs I'm planning for the extra mods will be contingent upon those mods being installed, so they won't add a bunch of useless modules to the configs for people who don't have the mods.

Have you thought about giving the current parts a functionality pass at all? I'm about to start building a career mode station with these and it occurred to me that a 6-berth sleeper should have the capacity for 6 Kerbals or that the larger science lab should be able to fit extra crew since its triple the size (not triple the crew capacity however). With all of this in mind, I'm putting together some MM configs that will make these changes, plus add a little extra functionality like TACLS air and water filters and probably also add the station science lab module into the large science lab. I'm also thinking about re-purposing a copy of the V4-2 sleep hab as an interim PMM to give some KIS inventory, increased life support resources, and maybe larger life support converters a place to live. The only reason I bring this up is that some of this might have already been on your plate, so if I can offer my files to you, or share them here, and that would be helpful in any way, I'd be happy to do it. On the other hand, if you'd like me to keep them to myself because you don't want anyone stepping on your toes, I'm ok with that as well.

Thanks, I've had a chance to read it and I can see where I was going wrong I think. I was placing the aerobrake maneuver at the periapse because I assumed it would be modeled as impulsive like dV maneuvers. Setting up a coast to prior to the atmosphere solved that issue at least. Now, a question: In the drag coefficient tooltip, it says that for FAR this is Cd * A, of which, Cd seems readily available, being listed right next to Cl on the data and stability derivatives page. A, on the other hand has me a little lost... is this referring to the "Ref Area" variable, or is there another "A" somewhere? That all said, is the FAR data an acceptable way of finding the drag coefficient, or should I really go out and run the calculator?

I'll give these a try. As for AoA sweep, shouldn't I really only be worried with at most 5°-10°? The only time I've ever gone much above 5° is at altitudes in the 30+ km range to flatten out my trajectory, and never above about 10° below 50km. I have started reducing max throttle to reduce the rate of acceleration, though sometimes I find it hard to judge what is enough throttle to give me a reasonable rate of acceleration. For basically the last 3 years, I've designed my launch vehicles to begin their gravity turn at ~100m/s, which is still what I go for these days, I'm just finding it more involved than it used to be thanks to the new aero system. This, very much... However, the behavior that started this whole discussion was that my smooth-sided rockets weren't able to statically hold themselves on the velocity vector in the way they used to in the old aero system. @Wanderfound: Testing the theory about convincing bricks to fly?

Has anyone tried this in 1.0.5?

Is there a guide somewhere describing how to read the analysis tools in relation to rockets? I know how to use them for aircraft / spaceplanes, but have little to know understanding of how those principles apply to long skinny tubes meant to get out of the atmosphere as quickly as possible...

So it's not letting you resize the part at all, or only withing certain limits? I doesn't look like you've installed anything that would affect the tech requirements, but it might be worth trying to test a clean install with only PP to see if you're getting the same behavior.

Well, after writing a whole paragraph about my setup, I found that I had installed fixURL which is supposed to block redirects (can't remember why at this point), and that was where the problem was coming from.