Zorg

In my defense it wasnt in the part list because it was later in the tech tree than it should have been, which I just fixed

Meanwhile putting our Juno IV troubles behind us for the moment by launching a much more sensible launch vehicle Atlas Agena B. With a Ranger Block 1 of course. EDIT: Looks like I forgot the antenna

Sonne is Helios. Btw there is a patch in BDB_Extras that switches everything to use their real world names. Just copy the folder BDB_Realnames into your game data.

So we would generally advise most users not to use the dev branch in a career save you really care about. Not that it stops a lot of people In general you usually don't get save destroying issues but things are being added all the time and things like tech tree positioning can change regularly. There will also likely be a significant rebalancing of science instruments in terms of how much science they can transmit and or return coming in the next few weeks. If you like to live dangerously the majority of new parts intended for this update are in game and most of the tech tree balancing is also done. And we do appreciate feedback from people playing with the dev branch. But yeah it is very much an at your own risk type situation So you posted the other day just as I started flying some Juno IV missions with the new stuff. Juno IV-A seems to be just fine but even with upgraded engines and reduced fuel loads even the new Juno IV-B has some trouble (it can get to space but with considerable difficulty and a lot of gravity losses). A careful fuel loading and mass rebalancing of Juno IV tanks is therefore in order. The Juno IV tanks actually were quite inefficient and wasteful of space. The 6k stage for instance is two spheres inside the conical tank so it would actually carry much less fuel than you would think compared to other stages of similar size. And thats before we talk about reduced propellant loading. So yeah we're still working on Juno IV-B. About your other point I'm not too familiar with the history of Juno IV apart from the basics such as outlined in the spacelaunch report page, maybe someone else can chime in. The reason the tanks were partially empty is indeed because the S3-D engine brought over from the Juno II was not powerful enough to lift the three stage Juno IV-B with all stages full. Juno IV wasn't a great idea IRL either and it was cancelled before it could be built. But we do want to be able to match the theoretical performance even so. The quote I posted earlier is with respect to the real world concept.

So the 3 stage vehicle you have there is a Juno IV-B. Ed Kyle's Spacelaunch report is one of our more trusted sources for information and it seems the Juno IV concept was in fact not capable of launching with a full propellant load on all 3 stages. If you run full on the upper stages, you reduce on the lower and vice versa. Friznit will update the wiki with a note on that. The new Juno IV in development with all 3 tanks full can get off the pad barely but with an LR79-NA13 instead of the S3D (in the new update the S3D, Lr79, RS27 and various configs will be a single part with upgradable and switcheable configs). Still adjusted propellant loads will be the optimal way to build it. or strap some castors to it. "A three-stage Juno IV would weigh up to 62.41 tonnes (137,600 lbs) at liftoff. Its Jupiter first stage would be loaded with up to 44.5 tonnes (98,100 lbs) of propellant. The second stage would carry up to 11.14 tonnes (24,550 lbs) of propellant. The third stage would be loaded with up to 3.4 tonnes (7,500 lbs) of propellant. Propellant loading would vary depending on the mission type, with maximum upper stage loading for LEO missions and reduced loading for lunar or escape missions. Reduced upper stage propellant loads would be offset by increased first stage propellant loads, and vice-versa." http://www.spacelaunchreport.com/jupiter7.html

@Morphisor I was actually literally just flying a Juno IV-A mission with a JPL 6K upper stage. Its the new one in development, I dont recall if there have been significant changes in tank sizes, I dont think so. In any case the overall trajectory for a launch should be similar. This was flown with mechjeb using the PVG ascent guidance mode. Doing a few launches with PVG can be a useful learning tool to see how it handles low TWR upper stages while doing a single burn to orbit. The chart below is Altitude vs distance downrange. As you can see it established an initial apoapsis of 120km in order to reach the target altitude of 100km. A lot of IRL rocket launches have this kind of profile for instance the Centaur on Atlas V. If you're not familiar with PVG I have a WIP guide on Friznits wiki (which i really need to update with charts and stuff :| ) https://github.com/friznit/Unofficial-BDB-Wiki/wiki/Launching-and-Trajectories Couple of bonus images while im here

Are you playing with the official release or with the BDB 1.7 development build? In either case as of the previous release upper stages were switched to 25% of irl thrust scaling same as lower stages. A lot of people use 50% for upper stage engines but for consistency's sake BDB now uses 25% (it also helps resolve issues with engine that have both sea level and vacuum versions). As such you may find some upper stages have very low twr and require a lofted trajectory just like their real world counter parts. meaning establish a higher initial apoapsis than you normally would. I feel the experience with this kind of scaling is quite nice once you adjust your launch trajectories in JNSQ or similar larger scale systems. However if you dont like it there is a patch in the BDB_Extras that changes engines back to 50% scaling. I not aware of insufficient Dv on any vehicles. However it should be noted that the current development branch of BDB is revamping all of the early rockets (Vanguard, Redstone, Thor/Delta, Jupiter/JunoII&4. They will be capable of performing the missions they were designed for with all of the early game probes also being revamped or added. Oh and most of the balance testing is being done in JNSQ

Not gonna lie, as much as I love JNSQ I wouldnt mind another upscaled playthrough of an updated shiny new GPP at some point in the future.

Trying out an Atlas SM65-A (prototype with no central sustainer) derived launch vehicle. I tweakscaled the Jupiter control block to 1.25m so it will act as a spin platform for a small upper stage solid after MECO.

Some early game stuff Juno II and Thor Able side by side ready to lauch Thor Agena A launching a KH1 KH1 Explorer 11 Mercury Redstone

OP updated with new Neutral profile that resolved AO issues with some planet packs when landed. (weird bright or dark edges like a rectangular vignette). Done through removing high precision in the ambient occlusion settings Fixed grain node has been added Small tweaks to brightness.

CryoEngines ships with its own custom smokescreen configs (which I made and is the basis for some of the stuff I subsequently added to realplume). If you're testing on the ground it may look identical as the plumes are built from stock CryoEngines effects. But they will expand with altitude. Edit: the edited message loaded after I replied.

I had bundled Smokescreen v2.8.7 with the spacedock version of RealPlume-stock. That seemed quite trouble free in KSP 1.8.1. I have no experience with smokescreen 2.8.8

Oof I have not kept up with this thread and didnt have notifications on! sorry for the months late responses Um I have a rather powerful PC, but for running the visual mods I dont think you necessarily need such specs. However the more things you want to have running together the better it is. Also the JNSQ planet pack in particular recommends at least 16GB of RAM. KSP performance is mostly limited by the single thread CPU performance and whether you have sufficient RAM for the number of mods you are running. Having said that my specs are: i7 6700K oc to 4.6Ghz Nvidia GTX1080ti 64GB of DDR4 3200mhz ram Samsung 970 evo SSD (helps with the loading time to an extent) You get blue icons from running DX11 in ksp versions older than KSP 1.8. You can fix this by installing Textures Unlimited. If you make changes in game, you have to export using the export settings function and copy those settings into the various profile cfgs in the KS3P folder. If you download a 3rd party profile you need to overwrite any existing profile with the same scenes. At the moment (even for Clusta's unofficial patch) KS3P only supports 1 profile per scene.

Hi @sarbian, can confirm the bug report by Kerburettor. Smokescreen is not responding to live changes of any parameter as far as I can see. From what I could tell, none of the effects are broken per se, the parameters are all picking up the correct values from the cfg. Its just not updating to any live changes via the GUI so I went back to an earlier version to do realplume development. Tested on 1.8.1 with Smokescreen 1.8.9. Log in case it helps. https://www.dropbox.com/s/cze4vtmt7l7ckfn/Player.log?dl=0 Thanks a lot in advance for looking at this.

Just a little heads up for anyone who may be curious, although not officially updated, PersistentRotation seems to be functioning fine in KSP 1.8.1

That file has been wreaking havoc in various installs for quite a while

No worries. The B9 switches come in handy with dealing with KSP upgrades. So even after you unlock the upgrades you still have access to the older configs which is handy when you want to recreate an older rocket. The next version of BDB will add a little alert to the part description for all parts that have switcheable configs that B9 configs are available and also that some configs might be behind upgrades Should help with people missing it.

If you're in science/career, its likely that you simply havent unlocked the upgrade yet. The upgrades for the Buzzard are in advanced rocketry and heavy rocketry. Some configs for certain parts are available in the same node (basically just giving you other options) and some configs are spread out as upgrades over other tech nodes.

That was more a joke than anything else The final balancing still needs to be done (will probably commit the visual scanner compatibility sometime after Kop 1.8 drops and the new ScanSat has come out of beta so that more users can try it and test it) Um there are a few objectives we want to achieve with this including making scanning a bit more involved than just set and forget. The upcoming sunlight requirement however probably does mean we will need to turn the balance dials to turn down the film constraint compared to what they are now. Also the film limitations especially in the earlier models is supposed to incentivise upgrading to the bigger and better keyholes as opposed to merely launching like 20 KH1s. (though multiple launches to some extent are to be expected) We will try to settle on what is hopefully a reasonable balance. But we cant please everyone of course. For someone trying to min max in career the keyholes may well end up not being super appealing even just due to the size of them putting all else aside. On the other hand for someone looking for a bit more of the roleplay element and the fun factor factor of recreating the keyhole program they would offer something quite intruiging. The keyhole tech balance will also be closely tied to the Agenas and we will need to see how it compares to where the visual scanners will be in ScanSat and how/if that will feed into our balance factors. So yeah the final balance is a fair ways off.

My only concern with this would be does the dang camera shut off when it is on the night side or does it waste film? I don't sit and fly single missions at a time. While mission 1 is performing a Photo Surveillance of Kerbin, Mission 2 is about to land on Duna and Mission 3 is picking up rock samples to return from the Mun. The camera does not shut off when on dark side. Of course this is not a huge issue for normal scansat parts since they only utilise EC. However for the keyholes with the custom film resource indeed you have to monitor them if you want to avoid wastage. Alternatively just keep spamming more spy sats and eventually everything should be covered. What’s that military industrial budget for eh?

@Marcelo Silveira @Pappystein Yeah I have been thinking about how best to add in a resupply method for the Dorian specifically. A film subtype just seems a bit wasteful to carry like 2-4 kg of film in an entire ferry segment though I havent ruled that out entirely. Speaking of Scansat changes are coming soon. All the spy cameras will switch to the new Visual Scanner module (high and low res options are available) once Scansat officially updates. The visual scan is a colour scan that basically pulls the scaled space texture from the planet. Essentially a nice colour photograph of the surface rather than altimetry. Furthermore it will only successfully scan on the daylight side of the planet. I think this will be quite fun as it makes scanning more involved and engaging. Dmagic has previewed this in their dev thread (its available to download and test) but I will only be committing the BDB compatibility update once Kopernicus updates to 1.8 as this new scansat looks to be 1.8 only. The current BDB scansat compatibility configs will prob be thrown into BDB_Extras for people who dont want to move to 1.8 even after Kopernicus updates.

Its just on the previous page. Its a bit sped up but as you can see its a continous turn that starts gently very soon after lift off. This is how real rockets are launched and this method is the most effective since KSP 1.0 I believe (or even earlier I forget when the aero model was changed)