Zorg

There are no official configs for Textures Unlimited. But there are some rough unofficial configs covering a few parts which you may be able to find if you search this thread.

Yeah I kept those instructions a bit generous to account for lower TWR rockets as well. I usually start at 50 m/s and follow a profile for a single burn to orbit (if a low twr upper stage is used which is most of the time for me). Anyway hope it works out for you, I've not had any trouble with the current Tantares build though I've mostly flown the smaller diameter upper stage.

This turning above 10km idea is from the old KSP aero model. This is NOT optimal anymore. For the vast majority of reasonably designed rockets, you 1) start a gravity turn by nudging 10 degrees in the direction you are launching it at 100-150m/s then holding prograde. (you can also start gentler earlier but this is pretty safe) 2) disable prograde hold at 45 degrees if you find yourself at 45 degrees before reaching 20-25km. 3) Then go as horizontal as possible from there keeping Ap at least 30s away (at stock scale, in 2.5x you prob want to keep it 60-90s away) 4) establish Ap and then circularise at Ap (or learn to do a single burn to orbit,) See the gif pkmniako posted which illustrates a proper gravity turn. That 10km thing these days would only be necessary for something with horrible aero like trying to launch an unshielded space station or something.

Er that sounds like the installation went horribly wrong. I would suggest uninstalling RealPlume, realplume-stock and smokescreen via ckan. Going into the folder yourself and making sure those folders are all gone and then finally installing manually. Since you are on 1.7.3 make sure to grab Smokescreen v2.8.6, and the latest RealPlume and RealPlume-stock. (you dont need to uninstall CKAN, its quite fine to install some mods using CKAN and other manually. Just make sure to uninstall the mods in question using CKAN and double check they were properly removed). If after all that you still have disappearing plumes then Im going to need all 3 of your logs again (configcache, mm log and outputlog.txt/player.log)

Hmm I took a look at the log and I am unable to identify the issue thats causing your slowdown much less whether realplume/smokescreen is directly responsible. I did see some "float curve errors" and i suppose a bunch of those spamming could cause a slow down though Im not sure (I have identified and fixed such errors in RP before but they dont have a performance impact at least for me). The log doesnt say where its from. RealPlume does use a lot of float curves so its possible there is an issue with a plume somewhere but I am not getting those same errors with those same engines and that doesnt explain why it only happens at Duna at 8km. Unfortunately since I cant reproduce the issue and since I cant identify a culprit in the log theres not much I can do sorry

Constellation is the sexiest Mars architecture, prove me wrong.

Oh lol I didnt get that far. I get it now lol. Will merge the PR, thanks

I am not sure I follow... what exactly is your staging? And how is the small tank draining from the lower tanks? (how could a full tank attached to an engine not even running drain from and active stage below or did I misunderstand what you meant?)

Build it like so: 1. place Probe core 2. Attach parachute to probe core (black panel facing down of course) 3. Attach heat shield to the probe core 4. Attach retro pack to the bottom edge of the heat shield The decoupler on the heat-shield will eject the engine, the decoupler on the probe core will eject the heat shield

Glad you’re enjoying it! Yeah for efficient coverage you kind of have to actively manage them. Use a bit of fine tuning on the orbital periods and trigger the start of a scan when passing over unmapped areas. Alternatively just spam LKO with a dozen or so sats all the the spirit of the Keyhole program. About Nimbus I personally haven’t had a chance to look at them yet.

Coming soon in the next update of RealPlume and RealPlume-Stock, an all new Alcolox plume which will be applied to CNAR

I've made quite a few adjustments today KH1, KH4 and KH4B all will now use the low res altimetry scan module KH7, KH8 and MOL will use the high res module but the altitude requirements are now the same as low res since IRL these optical systems would be deployed in low orbit. The FOV is still narrower though. Some changes have been made to the maxTemp of the heat shield. I did a couple of tests in JNSQ deorbiting from 127km, steep entry with full burn on the retro motor and it survived. Do let me know any feedback though.

Oof. Glad you caught it in the end. It was actually visible in the configcache now that I go back to it. I didnt spot the duplicated values. These things can kind of make your eyes glaze over

Hmm unfortunately I wasnt able to identify the problem from this. Could you try launching a craft with one of those problem engines, try to use it, then quit and send me your outputlog.txt (player.log if on 1.8). Just in case there is something useful there. However the easiest way to solve your problem would probably be for you to eliminate mods one by one (starting with the mods more likely to mess around with engines and stuff) until it starts working. Then we can see what and how the engines are being affected and if there is a solution.

You seem to have a mod that is controlling ignition limits, I assume its something to do with scrapyard since its under a reliability tab? A screenshot of your gamedata folder (so we can see installed mods) and your module manager config cache (GameData/ModuleManager.ConfigCache) would be helpful in diagnosing the problem.

Dont worry I'm quite happy to help as far as I am able to. Not sure whats up with your log though, no matter what else is going on in your game the log is supposed to update each time you run. Are you looking in here? I mean the file has the correct name so I assume you were looking in the right place but I guess its possible there was an old copy of a log lying around somewhere idk. C:\Users\<username>\AppData\LocalLow\Squad\Kerbal Space Program\output_log.txt (the file is called player.log for KSP 1.8)

Sorry got even busier after that post and then was abroad for a few weeks. Just got back and catching up on things. That second log file you posted seemed 100% identical to the first one. It might the same file mistakenly reuploaded? As mentioned that file seems truncated in the middle of the the part loading process and doesnt have any data on you actually playing the game. I will need a useful log that shows whats happening while you are playing to see if there is anything I can spot.

well Scansat already has two altimetry scanning options. The low res radar altimetry which is in B&W and the high res Synthetic Aperture Radar altimetry which also is in colour and provides useful slope data. Thing is the low res module is not suited to the earlier coronas as they are actually high resolution cameras in absolute terms. Even the early coronas got like 7.5m resolution and we also have actual radar altimeters in BDB like for the Ranger/Mariner. The KH5 was a wide field mapping camera (140m resolution) but I dont think Cobalt is planning on making that. The idea right now at least is to use the film resource to limit the utility of the early models so that the bigger ones feel like an upgrade. However depending on how testing goes and feeback I am open to switching the KH1 and Kh4 to the low res scanner instead. edit: The other reason I am hesitant to do that is that the big KH cameras will not seem that appealing with a low res Radar scanning module since the basic radar part in SCANsat unlocks very early. A KH1 and KH4 with high res altimetry, relatively early tech level but some limitations due to the resource contraint however offers something quite different.

For any peeps playing with the dev branch and SCANsat, I've just added SCANsat compatibility for the Keyhole cameras (as well as the MOL camera). All of these spy cameras are capable of high res altimetry (similar to the SAR in SCANsat), however in addition to EC, they will use a newly created Film stock resource for balancing purposes. The earlier models like KH1, KH4 will carry considerably less film so they will only be able to scan part of the planet. In order to get a full scan, you will likely have to launch several satellites to achieve full coverage. The higher end models carry more, in my test, a single KH8 covered about 90% of Kerbin at stock scale at the ideal altitude. This is all quite experimental and subject to change but any feedback would be appreciated. The need for the film resource to perform scans hopefully helps differentiate the different cameras as they are unlocked and also helps balance the fact that these cameras might unlock earlier in the tech tree than the easier to use SAR scanner in SCANsat proper.

Thanks! I’ve been away from home for a bit and haven’t been able to look into how the feeder/reflector system in NFEX works. Will use your files as the basis for the compatibility update when I get back.

The point being that MM compatibility patches are activated on the basis of the presence of the mod folder. Specifically my suspicion is that the RealPlume patches for Vens reliant and poodle etc are being activated. I presume you are using restock for the stock parts revamp and Vens only for new parts added by Vens? If this is the case go to Vens folder in RealPlume-stock and delete all the cfgs except for those applying to those parts. If I’m right that should fix it.

It is in fact possible to use it together with reshade. I use KS3P for the overall look and sometimes activate reshade on top for special scenes like when I need CRT scanlines and such. Not come across any conflicts.

I took a quick look at the screenshot of the game data. It’s possible (perhaps even probable) that having Vens in there with ReStock is the culprit. Not 100% sure as I don’t have my laptop with me and it’s a little tricky to open up and study the logs. But please see if removing Vens fixes it. If not I will have to dig into it when I get back home.

Hi. Sorry I’m out of town til mid January but will take a look when I get back. If you could post your module manager log and modulemanager.configcache in the meantime that would help me diagnose the issue when I return.

Well I think the output log you uploaded was truncated somehow because it only shows lines referring to the initial loading process of the game. It doesnt even show the loading of your save. The steps you took are correct but I dont see them in the log linked in your post. To be perfectly honest I am very puzzled how RealPlume/Smokescreen could possibly cause the issues you were describing but of course something unexpected could always happen.