Nertea

We did a modification to this in version 0.9.0, which was around KSP 1.3 (May 2017). Nothing since then. I'm still probably a week away from finishing NF Spacecraft updates, so as a result here are the 1.5.x updates for the remaining mods. NF Propulsion 1.0.4 KSP 1.5.x Updated ModuleManager to 3.1.0 Updated B9PartSwitch to 2.4.5 Updated CRP to 1.0.0 Removed MiniAVC distribution Updated Gas Separator part to use new CRP atmospheric rules Updated ModuleRCSEmissive with options for other color curves than simply alpha and ability to specify the shader property to work on NF Electrical 0.10.3 KSP 1.5.x Updated B9PartSwitch to 2.4.5 Updated CRP to 1.0.0 Updated ModuleManager to 3.1.0 Updated DynamicBatteryStorage to 1.3.3 Removed MiniAVC NF Construction 1.0.4 KSP 1.5.x Updated MM to 3.1.0 Updated B9PartSwitch to 2.4.5 Fixed a issue with some parts that would cause B9PS to throw errors in versions >2.4.0 Modified the orientation of the 2.5m octo-docking port to be consistent Fixed tech tree nodes for both linear docking connectors NF Solar 0.8.13 KSP 1.5.x Updated MM to 3.1.0 Removed MiniAVC distribution NF Launch Vehicles 1.1.7 KSP 1.5.x Updated B9PartSwitch to 2.4.5 Updated MM to 3.1.0 Removed MiniAVC distribution Fixed an issue with the 5m docking port's collider NF Aeronautics 1.0.2 KSP 1.5.x Updated MM to 3.1.0 Updated CRP to 1.0.0 Updated B9PartSwitch to 2.4.5 Removed MiniAVC distribution Added Spanish translation (Sergi Ruiz Zarzuelo)

I was hoping to get NF Spacecraft done at the same time, as there are some texture updates I want to propagate. That will have to wait for a new version though as it's taking a while SSPXr 1.0.9 KSP 1.5.x Updated NFProps to 0.3.5 Updated MM to 3.1.0 Updated B9PS to 2.4.5 Removed MiniAVC distribution, version file remains Contract improvements: Observation modules, 1.25m/3.75m cupolas will now fulfill cupola contracts Large lab will now fulfill lab contracts Station/Base contracts that require a greenhouse will now generate Station/Base contracts that require an aquaponics module will now generate Station/Base contracts that require a hab module will now generate Station contracts that require a centrifuge will now generate Increased base science for visual observation experiment, all science should now be sent with one transmission Fixed compatibility of revised stock docking port with IndicatorLights Added missing vesselType to vessels that didn't have it Fixes experience gain Fixes issues where if there is no VesselType specifying crewed module on the vessel, science experiments will fail Fixed flag for lab replacement Changed rotation of replacement docking port and extensible docking port to be consistent with the original part Small fix to deployable module resource costs: will now round resources, so you are less likely to get issues where you have 1999.999993 resources when you think you have the 2000 needed to deploy Added optional SpinResource and SpinResourceRate to ModuleDeployableCentrifuge - allows specification of a resource and a rate needed to rotate the thing

Really weird bug. I'll see if I can find why.

So by your arguments there it's not quite a good choice, actually. ISRU factors: This would make it the same as lithium Boiloff: Same as Xe, Ar, Li Transport factors: Same as pretty much everything except uranium Cost: I'll give you that one Tank mass ratio: Xenon and Argon just need pressurized tanks, not cryo. Engine selection: Yes, you could make different engines That's down to 2 weak factors (cost and engine selection), which certainly does not justify making a whole slew of models and associated tanks. Not to mention as you point out a lot of engines can technically use iodine as a fuel source already. Maybe you should make a ModuleManager patch to accomplish what you want (patch existing engines with multiple modes, perhaps). Great! Will be in next official release. Nah that's not what I'm saying. Functionally, the Lithium engines could be made to use Xenon without affecting the balance of the mod at all, they could still have higher thrusts and lower Isps. If the effective only reason for a different fuel is the name on the tank it's not enough.

Worth looking at this post - you need to think differently than your average rocket to use it effectively. Lofted trajectories are more effective, and getting up to high speed in the atmosphere is not effective. I was just testing a SSTO rocket using 4 gas-core aerospikes a day or two ago and didn't have any trouble getting large payloads into orbit (and back) with a bit of adjustment to my vessel and trajectory design.

First step: justify them using these principles:

They're currently just straight-up drop-in replacements and are designed to match well with SSPXr and the current quality targets for my stuff, but I will consider a white outer texture for the 2.5m one for sure (in fact, it's arguably more realistic considering the IDA that it's based on is covered in thermal blankets).

I could make about 6 pod exteriors in that time

It's not hard, it's just time consuming. Consider the visual distance you are in an IVA from the panel, it's much, much closer than an external. That means that the internal needs to be about an order of magnitude more detailed than the external. Typically I draw parts at 250-350 px/m these days, which is a good compromise - an IVA needs to be drawn at ~1000 px/m to look decently sharp. That's about 4x the linear texture density of the outside, so at LEAST 4x the time to draw textures. In addition, additional mesh detail requires additional UVing and that is passed on to texture time. This all combines to make it take forever (1.25m IVA will take upwards of 12 straight hours of work, 3.75m IVA could take 36), with results that are really not used that much by the average player (from my observations, most people take a quick look and then stop). However, there are some small portions of the playerbase who will scream and throw a tantrum if things are not exactly to their liking in the IVA space. This further discourages me from making them, because if I do I want them to be appreciated. I tried an experiment with the PPD-1 and Mk4-1 IVAs where I spent less effort and really just laid out props for them. It didn't go well with the latter group.

Sorry not quite clear here - you have a mod with an engine that has been patched to use LH2, but it still has an LF engine on it after patching as well?

Yeah there was little to no point to those parts anymore. They were back from 0.25 KSP or so, where joint strength was proportional to the mass of the parts. So those were theoretically high strength ports, which had mono inside them to kinda justify the mass increase. I didn't scope these for the revamp because they didn't feel very useful or much fun to make. Instead I concentrated on making this and this, which I hope will be released in a "new" project fairly soon and should resolve the "stock docking ports look nasty" problem.

It's been reported, sorry I haven't shipped the fix yet. I was hoping to bundle the new NFSpacecraft release in with it but that has taken longer than anticipated (IVA hell) I found an inconsistency in the model and have pushed a fix to dev branch. Can you see whether this resolves it?

@MaverickSawyer, @KSPrynk, @Kablob, (or anyone else really) if you want to test or talk about the NFS dev version, PM me directly. There are a large number of bugs and problems with the current state and they are not really ready for precise testing yet. Nothing wrong with the config or model that I can see. I'll continue to investigate but *shrug* I can't repro it!.

I welcome testing of the development version, chances are this will need some tuning to get the profiles right for re-entry. Generally in the mod, gridded thrusters provide more specific impulse at a lower thrust, and hall thrusters provide more thrust at a lower specific impulse. The power-to-performance should be fairly similar between them if you consider the same tech level (ie, entry level HET vs entry level electrostatic). Argon is also much cheaper and easier to find so HETs have another advantage.

Do you have some suggested numbers for me? I don't maintain the other mod compatibility configs and really often don't play the game these days except when testing balance, so I don't have a handle on what these should be? Grab the latest version of B9PS, it may solve this.

Your attitude wasn't fun for me to come back to after a long day. I've used bold colored highlights to indicate where you went wrong in your post. Remove these and you have a much less combative post. What did you think would happen upon deploying that language? Protip - saying something bad, crossing it out and adding a slightly different word does not make it better. A quick perusal of the imgur album attached to the OP would have revealed something was wrong with your install. Let's also check this excerpt from the readme (this exact version is from dev, but note the Dependencies section) ==================================== STATION PARTS EXPANSION REDUX v1.0.9 ==================================== This pack provides a set of new space and ground station parts. New parts exist in all size classes from 1.25m to 3.75m. Rigid station parts are provided as well as expandable centrifuges and habitats. Ground bases are served with auto-leveling bases and extendable docking crew tubes. In addition this pack reskins the Hitchiker, Cupola and Mobile Lab to improve their quality and match the new parts. ============ DEPENDENCIES ============ Required: - ModuleManager (3.1.0) - B9PartSwitch (2.4.5) - NearFutureProps (0.3.5) Optional - RescuePodValidator - Community Tech Tree (v2.2+) And just to satisfy myself I took a ls of the contents of the zipfile from spacedock. Yep. The dependency is bundled. drwxr-xr-x@ 6 cadderley staff 192 30 Sep 15:38 NearFutureProps -rw-r--r--@ 1 cadderley staff 104960 30 Sep 15:38 ModuleManager.3.0.7.dll drwxr-xr-x@ 10 cadderley staff 320 30 Sep 15:38 B9PartSwitch drwxr-xr-x@ 9 cadderley staff 288 30 Sep 15:38 StationPartsExpansionRedux

I can't support you if you don't help me figure things out. Try pastebin, google drive, dropbox, there are many great options.

A log file would be most helpful!

I haven't touched that config in a dozen releases. It kinda sounds like you're upgrading from a really archaic version. Perhaps 0.6.0 or thereabouts judging from the changelog.

It's fine in 1.5.1.

It's very efficient resource wise. It's not necessarily best if you want really short burns. The high DV values achievable are great for speeding up interplanetary transfers though as was mentioned. That being said, just like the stock ion engine, all these engines are tuned to be about 1000x more thrusty than they realistically should be. This helps with burn times. Thanks! Weeeelll I still have to finish the IVAs for two of the pods so things are still a bit off. It is an access door to a cargo area that you can use for adding a docking port or other things you like. Beautiful is subjective, they look like garbage to me! They were removed some time ago when I redid all the engines and made them more cluster friendly.

Hah. Uh, I wrote a really nice thing on this a while ago but can't find it. Basically there are 2 kinds of heat in KSP, regular and core. Regular heat is the thermal system that governs re-entry, solar heating, that kind of thing (and engine heating as well). This heat is added via various methods and affects every part (this is what the part's maxTemp and such refers to). Regular heat is divided into Skin and Internal buckets - some processes add heat to the Internal bucket, like engines, and some processes add heat to the Skin bucket (re-entry heat, solar). Regular heat conducts between Skin and Internal on a part, and between parts that are connected. Radiators can remove this heat by pulling it to them and thus increasing their temperature, which then radiates out using normal radiative processes. Core heat is module-level, which means that only a part with a ModuleCoreHeat block is affected by it. This heat is added only via specific ModuleCoreHeat affecting Modules (in stock, only drills and resource converters). Core heat is mostly independent from the rest of the ship - if a part's Regular heat is really hot, the Core heat reservoir on a part will very slowly trickle higher. If a part with a Core's Core is really hot, some heat will slowly bleed out into the Regular section. Core heat is also removed by radiators, but this is totally orthogonal to regular heat removal. Core heat removal basically takes a set number of kJ out of a ModuleCoreHeat and makes it disappear into nothing.

There is a new 4-man pod in that render in the 2.5m scale. However there is also this:

Nope, you can now use the 3.75m shield properly though due to a lot of changes to how that pod works. In addition there is another large pod that is not shown there that should be better for up/down stuff.

Working through some minor bugfixes for these mods. Most should be done shortly except NFSpacecraft, which is under heavy dev to bring it to 1.0 state. 1.0 state includes 6 new pods and facelifts for the others....