Ruahrc

Thanks for your suggestions! Based on your comments I did some further tweaking and found out that the reflection size and quality are MAJOR impactors to performance. Previously I had them on "every frame" and 2048x2048 (the maximum for both). Cutting just those 2 settings down to "medium" and 512x512 improve my performance significantly, almost to stock levels even with AVP + scatterer active. Now I can enjoy good levels of performance and also enjoy the enhanced visuals of AVP . Ruahrc Same tests- ran after tweaks On Launchpad: 70fps After launch at 5km altitude: 65fps 87km low kerbin orbit and looking directly down at Kerbin (using cheats, so all 215 parts still there): 65fps 1087km high kerbin orbit (again using cheats): 120fps

Getting back into KSP and this has been great! I do have a question though- is it expected to see absolutely titanic performance drops when using this addon? I have a pretty respectable rig and even on my setup I am seeing fps drop of 50% or more compared to stock KSP. My KSP install is currently really lean, only mechjeb, modulemanager, scatterer, EVE, and AVP. Basically the only mod I have right now that is not required for this pack is Mechjeb, so there should be minimum or no impact from other addons affecting performance. Here are some details and performance numbers I measured: My setup: 9900KS @ 5GHz all-core 32GB RAM 2080ti GPU Running with maxed graphic setting and 3840x1600 @ 144fps monitor Loading a 215-part stock Saturn V replica I have the following fps: On Launchpad: 90fps After launch at 5km altitude: 70fps 87km low kerbin orbit and looking directly down at Kerbin (using cheats, so all 215 parts still there): 110fps 1087km high kerbin orbit (again using cheats): 130fps AVP w/4k textures On Launchpad: 40fps After launch at 5km altitude: 30fps 87km low kerbin orbit and looking directly down at Kerbin (using cheats, so all 215 parts still there): 40fps 1087km high kerbin orbit (again using cheats): 90fps As you can see there are absolutely massive drops in fps just from running the AVP. I noticed some small but overall not huge impacts by changing around between 2k, 4k, and 8k texture sets. Are there some things I can do to improve the performance I am seeing, to make the launch and LKO experience a little smoother? Are these levels of performance drops expected? Are my expectations too high for KSP (40fps on a 215 part craft is it just maxing out the practical limitations of the engine on current hardware)? Thanks! Ruahrc

I would say I'm definitely guilty of this! Playing KSP has for me too led to me reading a lot about historic space exploration missions, and then ultimately leading me to attempt a recreation of the same mission in KSP. It also started when I came across DMagic's orbital science parts which included the boom magnetometer and RPWS antenna needed to make a passable Voyager replica (the first replica I made). I have made a number of probes however I have only launched a few because I am waiting for launch windows in my career save, and in some cases mission planning is non-trivial (multiple flyby with Voyager probe... very difficult with the mission planning tools available for KSP ) The other problem is that since there are more planets in real solar system than in KSP, some of the probes have nowhere to go It's not that I don't have the creativity to make my own probes (I already did that in a previous version of KSP) but I find myself enjoying the challenge of making a craft that looks and operates like the real thing. So far I have made: Ranger probe to impact Mun (launched/success) Munar Surveyor lander (launched/success) Munar Orbiter for surface mapping/photography (launched/success) Mariner 1/2 probe to Eve flyby (launched/enroute) Mariner 3/4 Duna flyby Mariner 8/9 Duna orbiters Mariner 10 Eve+Moho flyby Viking Duna lander ("simulated launch" in sandbox) Pioneer 6/7/8/9 interstellar space network (launched one) Pioneer 10/11 outer planet exploration Voyager 1 and 2 outer planets/Kerbol escape (particularly proud of this one) Magellan Eve mapping Galileo Jool exploration with Jool atmospheric probe ("simulated launch" in sandbox) Cassini Jool exploration with Laythe surface probe ("simulated launch" in sandbox) Ulysses kerbol polar exploration Kerpollo Munar and Minimus manned landings (did this in earlier version of KSP, want to re-do it) I will probably next attempt Juno probe to Jool.

Yes sounds like a problem with KSPAPIExtensions, which I have because of the latest Infernal Robotics parts. I put a post in the KSPAPIExtensions thread about it

With 0.24 out and 64-bit included, the memory cap issues of the past are on their way into the history books. Does this mean we may eventually see more official planets from Squad? I know there was talk of at least one more gas giant a long long time ago (Eeloo was supposed to be one of the moons) however my theory is that Squad never really went down that path yet because maybe the memory footprint was getting too big to comfortably fit in 32-bit address space (I say this because the extra planets mods take up a ton of extra memory, causing compatibility problems with other mods because there is not enough memory to fit both). With the memory issue removed due to 64-bit, will Squad eventually add in a set of outer kerbol system planets for us to visit and not crash everyone's install? Personally I would really love to see 2-4 new planets well beyond the orbit of Jool, maybe a couple of eccentrics like comets with highly inclined/elliptical orbits as well. Something about twice as far and 4x as far away, maybe even more. The outer planets of our solar system are a LONG ways out, each one way further than the one before it. Saturn (~10AU) is twice as far from the sun as Jupiter (~5AU), Uranus is twice again as far as Saturn (~20AU) and Neptune is almost twice again Uranus' distance (~30AU). I just wish there were some further targets to reach for. Using gravity assists, really even reaching targets well beyond Jool's orbit would not be that difficult since if you can get to Jool, you can basically get to kerbol escape velocity using Jool as a boost. Ruahrc

I came here to say I encountered the same thing as Bomoo. And I agree with his assessment. Having too-fine of control over some tweakables does make it more difficult since it is more hassle to get the right ratio (rather than just , and with the granularity of the modification seemingly dependent on your KSP screen resolution (per-pixel sliding of the bar), there may be situations where it is impossible to perfectly balance LF to Ox because the correct number you need is some decimal you cannot choose because one pixel too short or too far makes you straddle around the correct value. It's also annoying to have to fiddle with pixel-level precision on the bar (I get enough of that in trying to place parts, I don't need more). I also ran into some instances where these fine-grained adjustments do not propagate properly across symmetry. Example, I have a rocket with twin solid boosters, one per side. I tweak the solid fuel amount in one to say 2505.43/3000 (because I cannot get it to adjust to a round number), the other ends up with 2500.27/3000 for some reason. I go to adjust the second one to match and now the first one is off. The two never get in sync. The result is that the twin boosters produce slightly different TWR on launch (gets slowly worse with time due to offset being larger fraction of total mass) and slightly upsets the balance of the rocket. Worse, one booster burns out slightly before the other causing a LARGE upset in craft attitude on ascent, usually unrecoverable in most situations.

Hope this is in the right forum, move to bugs if needed? I ran into some interesting behavior in the VAB. Normally when you tweak the fuel load in a rocket you can only change in increments of 10% at a time. Even though you may be able to manipulate the green slider bar pixel-by-pixel, the numeric amounts in the tanks only changes in increments of 1/10 the capacity of the tank. Just the other day I noticed that my install no longer does this. I can move the tweakable slider in any increment of one pixel and the fuel amount in the tank is reported in sub 1/10 increments (basically as fine as each pixel I move the green bar). Now you may think this additional granularity is a good thing but really it is not. First off, it makes it nearly impossible to maintain the right ratio of LF to Ox so that the tank does not have any surplus left behind. Secondly, I noticed when "tweaking" tanks or boosters with symmetry, the symmetric counterparts do not always get the same amount of fuel, it is off by a tiny amount. This means booster stages become unbalanced and throw off the balance of the craft. I'm still on 23.5, and did not install any new mods when this behavior started. All I did was copy an existing part.cfg file and changed the name and some details to make a new variant on a part. Did I fat-finger some hidden key combo to toggle this behavior? How can I get the old 10% increment functionality back? Thanks, Ruahrc

Wondering if anyone here has gone from using FAR back to stock aero? I enjoy using FAR for the realistic atmo behavior however I find it simply too easy to launch things. I build a lot of lightweight payloads (probes) and as a result it is too easy to launch them to the farthest corners of the kerbol system. I rarely ever require anything greater than 1.25m parts and even then a couple of the longest KW 1.25m tanks stacked on top of each other is enough to fling a probe well beyond Eeloo orbit. The only time I go to 2.5m is because my payload is too bulky to fit in the 1.25m KW fairings, so I use 2.5m launch stage to match diameters. 2.5m launchers are way overpowered and I can lift giant payloads into orbit with ease. I have never ever built anything close (including space stations) to needing 3.75m parts. With stock aero it may not be as realistic but at least the extra dV required to get to orbits means I get to build bigger rockets. With FAR I find myself sometimes building things inefficiently on purpose just in order to have bigger rockets and use more than 2 stages to get to Jool. Things like deliberately building poorly balanced stages, launching with tanks half full, etc. I find I can just play within the spirit of FAR if I continue to make sure my payloads all fit within fairings, use realistic launch profiles (no straight up to 10km then 45 degree turn) and make my rockets look like rockets (no asparagus pancakes). I tried playing with the kerbal ISP difficulty thing and tried the setting that penalizes your atmo ISP to make up the difference, and still require 4.5km/sec dV to get to orbit. However I found it a little subpar because you get an enormous ISP penalty for the first 10-20s, then the same old FAR after that. It makes your stages very unbalanced because on the ground your engine is unbelievably inefficient but as soon as you cross 10km or so the inefficiency dies off very suddenly as the ISP ramps up to vacuum levels. Not really interested in playing RSS scale KSP as I believe it interferers with some mods I want to play with and I do not want to get bogged down in playing the incompatible mod game. Just curious if anyone else has run into the same thing I have? Is there another solution to keep playing with FAR but make it harder to launch to orbit? I am not bragging about my rocket building skills but I tend to approach it with some realism i.e. weight savings on payloads is critical and they should be as small and light as possible to get the job done. I guess I have gotten a little too good at that . Ruahrc

P.S. I saw back on page 500 of this thread you posted a sample code to enable the RTG decay module you wrote, I played around with trying to add the RTG module to the stock RTG part, but had some trouble and got confused. I'm not sure if it is because the module was not fully implemented or if I am doing something wrong. First, seems like FNModuleRTG Thermal Power of 0.000075 MW seems to be the correct value to get electric charge generation equivalent to the stock RTG's eC output... although that does not seem consistent with my math. If RTG converts heat to charge at 10% efficiency as you stated on page 500, then shouldn't it be 0.0075 MW = 07.5 kW * 10% efficiency = 0.75 kW = 0.75 eC/sec? Using 0.0075 as ThermalPower seems to make the RTG much too powerful. Maybe my unit conversions are off? I did not totally understand your formula of 2000 * ThermalPower for Pu238 amount. What exactly does this control? Changing this value only seems to affect RTG mass since it's the amount of Pu238, however, what is the purpose in adding/subtracting Pu238? Shouldn't the amount of Pu238 remain constant as it is not consumed persay, only thermal output decays? Does RTG life/power output go up or down if this is altered? I tested a little with 100,000x time warp and saw Pu238 amount slowly decrease, does this decay linearly to 0 (making the RTG more like a binary state battery and not an RTG with exponentially decaying output) and does vessel lose mass as Pu238 is consumed? The RTG does not actually seem to produce electricCharge unless there is a ThermalPower resource present. The problem is, the RTG slowly generates ThermalPower with no outlet. When ThermalPower reaches maxAmount, the RTG shuts down and no further eC is generated. I think in a system with an attached electric generator, (which constantly consumes the thermalPower) it would work OK but I am installing this on a probe with no generator part (I want to use the internal thermocouple of the RTG). Given that the rate of ThermalPower generation is so low per above, I could just add a large sink of ThermalPower like 100000 or 1000000000 but that seems like a kludge. I tried adding a "FNGenerator" module with 10% carnot efficiency to consume ThermalPower and simulate the 10% efficient thermocouples, but it said the generator was inoperable since KSPI does not "see" a FNReactor on the vessel (the FNModuleRTG module must not count as one). This may just be incomplete implementation since I don't know how to get around this. The way I see it, the RTG part should be a totally self contained "black box", running off an internal "fuel" supply of Pu238 that degrades with time and simply outputting eC at some decaying rate. WasteHeat could also be included, however given that the RTG part already has fins on it, I would also think it reasonable to assume its radiating needs are already taken care of internally and no external radiators are required (I suppose one could just add an FNRadiator module onto the part too, and adjust the parameters so that it is just enough to dissipate its own heat, but this seems like unnecessary complexity). Here is the ModuleManager cfg I made. Is there something I am missing? @PART[rtg] { !MODULE[ModuleGenerator] //Removing stock generator functionality { } MODULE { name = FNModuleRTG ReactorTemp = 450 ThermalPower = 0.000075 radius = 0.3125 } RESOURCE { name = Plutonium-238 amount = 0.15 maxAmount = 0.15 } RESOURCE { name = ThermalPower amount = 0 maxAmount = 100 } }

I have a suggestion for new feature, but I'm not sure it will go over that well since it will likely break most users' "infinite free power" setups. You see I think the strict application of inverse square law solar panels seems a little OP. Then again I don't really use KSPI other than to model waste heat from solar panels, and also to have a magnetometer to put on my space probes . There are a couple ways to address this: 1) In reality, solar panels will saturate at some point and further light intensity will not produce more power. I think if the inverse curve were modified such that there was an upper limit on the amount of power you get by distance (say 100x Kerbin's output or something) it would balance things out a bit. 2) The other idea I think would be cool to have is radiation damage affect solar panel output. This would also introduce a "closer to the sun but less longevity" system where the closer you are to the sun (or say in a high radiation orbit) the faster your panels would degrade. You could adjust the radiation damage curve so that panel output would not go to zero, to prevent craft from being totally dead in orbit, but that one would at least need to consider spacecraft longevity when planning missions, or how close to park that mega solar factory to the sun in order to decrease radiation damage. I looked through the source code, it seems like all the infrastructure to actually implement both 1 and 2 are already in place. The radiation damage system is already all there, even with radiation belts around each planet from the ORS data. All one would need to do is to extend dose tracking to solar panels, and then provide some kind of "output reduction" multiplier curve based on how much dosage the panel has received. If I interpret it correctly, it would even work to accumulate radiation damage for panels that are not on the active craft (so time warp would still realistically decay the panels). #1 could be a simple tweak to the formula used to generate the inverse power curve. I've actually thought about trying to write a small mod that included stuff like solar panel radiation damage, RTG power decay, and battery capacity degradation as a function of spacecraft life and exposure. This way probes and spacecraft would have a finite lifetime in the Kerbal universe, or at least suffer a performance penalty for extended duration in orbit. Long duration mission planning would need to account for things like RTG decay, battery capacity loss, etc. Missions to Eeloo would need to factor in low solar flux at that distance, but equally so, missions to Moho would need to account for accelerated decay of panel output due to high radiation levels. The point is that in reality space is quite a harsh environment for spacecraft and I wanted to try to incorporate some of those factors in KSP so that you would need to consider some of these factors. Unfortunately while implementing RTG decay seems very straightforward (calculation based on mission time) and battery decay similar (could approximate usage-based wear with another decay based on total mission time... more advanced implementation would also be to try and incorporate temperature extremes into this somehow), the solar panel part was quite a bit more complex. Then I realized KSPI had all the radiation exposure modeling already done . Not to mention that with only CS101 level background in programming, it would be very challenging for me to try to code such mod up. I still might try someday. Anyway thought I would throw it out there and see what people thought Ruahrc

So I had a question about the cargo bay. I notice on this model (and the current KSO too) that you model in some kind of square bump on the front and rear surfaces of the cargo bay. What is the reason for this? IMHO, those surfaces should be flat, since you are going to be putting on a docking port on the node(s) on each end anyway. Removing those little bumps gives you a few more inches of space in the cargo bay since the nodes will be slightly further apart, and would make the look a little cleaner too since the docking parts you add on do not always match the square bump in the model (round docking port, octagon, small docking port, etc). Was there some specific detail you were going after when putting those little bumps in? It would seem to be they are a little redundant given you included a variety of attachment parts in your recent packs. And like I said it would give you a little extra room on either end. I launched a 0.7x scaled version of the Cacteye telescope using the current KSO and it *just* fits in the cargo bay. Removing those baked in bumps would have given a little more breathing room on either end when maneuvering it out using the arm I made. Otherwise the shuttle(s) are looking great

Double post sorry guys, please see above

Great mod, been having a lot of fun playing with it! The stock launcher was way OP for FAR, so I created a new config file for a KSO booster "solid fuel edition" with reduced thrust and fuel. Toning it down makes the boosters not be OP and also use solid fuel which is a little more "realistic". I also put in the sounds from KW rocketry so I get the cool thundering solid booster sounds . Performing various launch stress tests I can get the KSO to 200-250km polar orbit carrying a 8-10 ton payload reliably (that was the uh... Kerbal armed forces' design requirements). If I am flying with less payload I reduce the booster thrust, solid fuel amount, and liquid fuel amount in the EFT as necessary to not carry surplus fuel to orbit. My most recent KSO mission was to launch the Cacteye telescope to 250km orbit at 60 degrees inclined; I landed with about 100 m/s dV left which seemed a pretty good safety margin although I could probably tweak it further to make it more challenging to get into orbit. I just used ballpark numbers to start with and they were pretty good so I kept with them. I tried the FAR configs published earlier but had no success. Using the stock cfgs I have no trouble whatsoever landing reliably on the runway, but with FAR the whole craft becomes unstable, even during launch. Maybe I needed to tweak the control surface paramters or the cfg I used was incompatible with newest KSOS pack. Using the stock configs it flies like a dream except for the fact that my dromoman shuttle arm causes some funky behavior on re-entry since the parts inside the cargo hold are not shielded from the airflow. Anyway I am not sure what problems people are having with FAR, unless they are using the FAR specific configs which I found to be unnecessary. I tried just making the cargo hold to be a "Part" and not a "Winglet", but even that one change made the ship very difficult to control (it became very sensitive to payload mass, MJ for some reason was not able to hold it on the right launch vector but I could do it manually for a while before I lost it too). I do not understand the FAR configs enough to try to make my own so I will have to put up with the unshielded cargo bay until someone comes up with a fix. I also found a pretty good solution to the "mechjeb problem" (where burns in orbit using MJ cause the node to drift around and the orbiter to spin around and around unable to finish the burn). The source of the issue is that the OMS engines are offset from the axial direction of the ship, so when MJ points the nose at the burn node the thrust vector is not pointed in the same direction, so burning without compensation (as MJ apparently does not during orbital maneuvers... although it can do so during launch using corrective steering?) will cause drift. To fix this you need to get the thrust vector in line with the maneuver node. I accomplished this by surface mounting a stock cubic octagonal strut behind the nose cone, but angled it down by 10 degrees. I then put a stock probe core (I just call it the "orbital computer" ) on top of the cubic octagonal so it too is pointed down 10 degrees. Setting the OMS engines to have a trim of 10 degrees puts everything more or less in line (there is a lateral shift between probe core axis vector and thrust vector but overall it is much better than default layout). I have not experimiented with mounting the probe core in other areas of the ship such that the thrust vector, CoM, and probe core axis are all incident, but that should make the craft fly even better. I am not sure why the default/recommended OMS setting is to be at 14. Based on my observations of CoT and CoM in the VAB/SPH I found that a 10 degree OMS setting produced a thrust vector that was pointing through the CoM. This varies some depending on what payload and fuel remaining you have, but on average it seemed much closer at 10 than at 14. Anyhow setting the engines to 10 degrees offset also makes the thrust vector in the same direction with the probe core axis, so when MJ burns there is vastly reduced drift. Using this solution MJ can auto-pilot orbital maneuvers to within the default 0.1 m/s tolerance about 75% of the time; the rest of the time it will start to lose it at 0.2m/s, necessitating a manual disengage of MJ to prevent it from spinning around and around. I believe if you changed the burn tolerance to 0.2 or 0.3m/s it would work no issues pretty much all the time. I always have RCS enabled during the burns too which helps the ship compensate. Manual burn accuracy should also be improved using this method too since you are again fixing the fundamental problem which is that the thrust vector and ship's nose vector are not aligned. Anyways to use the solution above, you have to "control from here" on the angled probe core before initiating any orbital burn (hinged nosecone is great for this!). This will essentially shift the orbiter 10 degrees nose up to the direction you want to go. One side effect I noticed is that going to IVA causes the "control reference part" to be the cockpit again so you cannot burn from IVA (the workaround is to burn by hand, but instead of pointing at the maneuver node just point about 10 degrees nose up from it). Also remember that RCS is aligned with the cockpit so your RCS maneuvers may be a little off until you "control from here" on the cockpit again. Basically what I do is always have control from teh cockpit, and change the control to the "orbital computer" for any OMS burn, then reset control to the cockpit once the burn is complete for RCS maneuvering. FYI I may be wrong but I believe this is the same issue experienced by the real shuttle, and they compensate in a similar manner by not pointing the shuttle nose in the direction they want to go but rather offset it some amount so that the thrust from the engines is pointed where they want to go instead. If you do not want to futz with all the 10 degree offset and control part switching stuff above, the easier but slightly less realistic solution is to add a 3rd OMS engine on the spare node on the shuttle's rear surface. Then make all the OMS engines have trim of 0, and reduce the two upper OMS engines thrust output to 45% (if you leave them at 100% output the thrust vector will again not be pointed through CoM). This arrangement is slightly heavier/less efficient since you are carrying an extra engine, but it lets you MJ around to 0.1m/s accuracy with no issues whatsoever and you do not need to juggle what part you're controlling from. The increased ISP of the OMS engines might also make this slightly more efficient than simply using the main engines at 0 trim to burn around in orbit (also slightly less realistic). Sorry this is a LOT of text, the whole concept is pretty straightforward if described with a couple diagrams/pictures. I may try to put those together and post them this evening. The unintended but neat side effect is that it forces you to consider CoM, CoL, and thrust vector of the ship when designing various payloads, something that was carefully accounted for on the real shuttle missions. How to make this solution more integrated? I don't know if there is an easy way to automatically switch which part is used as the reference, or how to get it to be offset in IVA mode, but maybe making a new KSO nosecone part that has built in probe core with 10 degree offset would remove the need to add the angled octagonal cubic and probe core.