OrbitalManeuvers

Yes it does, but let me give you some good news for a change. I've been testing Armstrong in BH for reasons. But I'm looking at Rock right now (cheat to orbit) which uses the Moho template and it's (pardon the pun) rock solid. So given that I have planets that suck and planets that (omg again) rock, is there anything specific you'd like me to try?

I feel like I've been showing pictures of this pattern for a long time. The picture from last night you thought was the mun ... the one from the other day of KSC ... This is a consistently inconsistent feature of this defect on my machine. The mis-textured rectangles are always like a tint offset or a pattern overlay or both. The shapes within the pattern are unpredictable in layout but always the same in form, as if you're seeing a viewport onto a larger texture with random offsets. You can see this in the first image below - different rects have different patterns, but the nature of the shapes is always similar.

So I installed 34 (191) last night, cheated to orbit to several BH planets, and nothing had improved over previous versions, in fact it looked worse to me. But, I'd prefer to be more confident about what I'm testing/reporting. Have you decided about cheating to orbit, whether that's a valid test for checking the patchwork texture issue? I'm guessing that it's probably safer to avoid it, it's just much more time consuming to test, so I wanna be sure that I'm doing what matters. Also, last night was the first time I've seen the term "atlas" or any mention of alternate shaders, so if there's something I'm supposed to be doing other than just replacing the entire Kopernicus folder with your build updates and leaving everything else the same, I don't know about it. For Beyond Home (no resize, solar system replacement) do you want any settings tweaked? Tonight I'll grab 35 (or whatever is current a little later today) and try again. But ugh, I hate reporting that something isn't fixed, and I want to be 100% sure that I'm not mis-testing something and giving you false negatives. OK last question. In the attached image from last night, I've circled a feature of this bug that no one has said anything very specific about. Do you already understand what's causing this very non-random pattern to appear super-imposed on top of texture areas?

Confirmed working great. Thank you!

Not in my case, no. I flew there and landed for realsies. HOWEVER ... how very interesting to see you say this. When you first started looking into this, I was utterly convinced that KRASH was a huge contributing factor, precisely because it does scene switches, and scene switches felt very involved early on. Plus, pretty much all RSS/RO players use KRASH, it would seem. However, removing KRASH still showed all the symptoms on my JNSQ install, so I figured it maybe wasn't involved. I still think cheat to orbit or KRASH seem to make the problem show up more/worse ... totally unscientific observation.

Yes, this is correct. Sorry, left that out. I should also mention it's not being resized, and also not the latest BH ... I grabbed the last pre-parallax release. yes, Ultra. btw, I'll just add that my 1.9 JNSQ install seems really stable in the texture department. Your fixes toward this problem have absolutely made progress. Thanks for looking into it!

Hello ... I need help figuring out this heating issue with the Staara SRM. The picture shows my problem ... the SRM is heating up the decoupler beyond its limit, and it goes BOOM before we have the necessary velocity to make the moon. This makes us unhappy and is too much like real life. All the decouplers at this size have the same stats, and die the same. I've tried the Staara at thrust limits of 70 and 100, same results. I wouldn't be able to do this at 100 anyway ... that's well over 9g's at the end of the burn and leaves me like 0.000002 seconds margin of error for the shutdown, and I'm too old for that. Anyway ... So, is it normal for an SRM to transfer so much heat to an adjacent part? Is there something I should do differently?

Have to report that I'm still getting farmland circuit board patterns with 1.9.1 and the latest release on Github. Log file: https://drive.google.com/drive/folders/1h1I1rsmufICuiOOkw6lCQDKUtwJfdFqK?usp=sharing

Hmm OK, not sure how to help you other than maybe suggest you delete RealPlume, RealPlumeStock, and SmokeScreen, and try to unzip the distrubution zip again? The other day I was copying the contents of my GameData folder elsewhere by hand, and I can tell you that if you install RealPlume/RealPlumeStock and you do not have smokescreen installed , engines have no plumes at all.

if you don't have a SmokeScreen folder then I think you're missing a requirement? It's in the distribution zip. In general though, KSP traverses the entire tree under GameData, so you can put a cfg where ever it makes sense to you.

Going out on a limb here since you mentioned CKAN in earlier messages. Are you using the dev branch or the release? The new parts are in the dev branch and the wiki build guides in the issues tabs refer to the new parts. https://github.com/CobaltWolf/Bluedog-Design-Bureau/tree/v1.7.0-Development

There are lots of variations. What are you missing? Also, are you using: https://github.com/friznit/Unofficial-BDB-Wiki/issues/43

check last post on previous page (114)

if you're talking about Friznit's build guide, all the new content is under Issues on the github.

@linuxgurugamer Could this still happen? The zip file still does not contain any sample file, nor does it contain the "required and included" magicore.dll. thank you edited update: took a guess (and was wrong) but discovered that the mod will create a config file on its first run if it doesn't find one. So for anyone else, you can just run the mod, or to pre-populate it, you want a file called gamedata\sensiblescreenshot\pluginData\settings.cfg

- removed -

Back in April, Zorg showed a dock rotate spin table thinger on youtube for Explorer. Does that capability exist in the dev branch?

@R-T-B Hi, the work you did on the farmland-patchwork texture issues ... is that only in the BE builds? And if so, will the BE builds work on 1.8.x and/or 1.9.x, or only 1.10.x?

Zorg's Agena from earlier reminded me of a build I wanted to redesign. Here's an Atlas-Agena delivering a rover to the moon.

ahh the mystery text in the part is now explained. ok thanks. i'll shelve it until further notice.

Would any kind soul be willing to share a some VAB pictures of how you're using the Belle MPA? Since I finally figured out Fore By Throttle today, I figured I should tackle my other current mystery ... which this part.

Mr Zorg, I'm trying to step up my screenshot game and wondering if I can pick your brain about a few details? are you using KSP's F1 for screenshots? my nvidia software thingus can save screenshots too, after passing through their effects engine stuff .. a whole unexplored world there. could you comment on your in-game resolution and your setting for SCREENSHOT_SUPERSIZE in settings.cfg? what do you typically do with the screenshot file before posting to the forums? just wondering because if you're cropping/resizing/re-saving, then your save settings might be very interesting too Many thanks!

Huh, well if you just build it normal (i.e. no rotations) then what it lets you do is roll the craft on launch so that astronauts are on their backs, but still use the D key.

How long has the Control Point feature been in the Leo capsule? Is this an expression of Cobalt's hatred for yawing to orbit? Whatever brought it to be, I flippin love this feature.

am I being paranoid by completely deleting one before trying another? idk how sigma would otherwise know which to use ... is there a smoother way to switch between them between runs?