septemberWaves

Does the mod have all of its dependencies installed?

A Saturn V rocket stands ready to launch Voyager Mars. My favourite images from the mission:

It's not one part, it's a flat disc part with several science parts attached to it. Look through the science tab and you'll find them.

Does this work with Principia? I know it's based on RSS but I don't know enough about gravitation to know whether n-body effects behave the same when you scale masses and distances by the same factor.

Where are the configs for it? Also, to be clear, this is the correct thread, right?

The colour is a Kopernicus issue. There's a patch called "colourfix" that you can download separately from Kopernicus releases on Github, and put in your GameData folder. Also, what version of Parallax were you using when you tested the JNSQ patch? I'm trying to figure out why it's not loading for me, and I don't know how to diagnose issues from log files so I'm basically just dependent on guesswork at this point until someone can provide me with a concrete answer.

What other things were broken? I've had no trouble with JNSQ itself on 1.12. If planets look wrong or you're getting a weird lingering motion blur effect (both issues I've had recently), you're using the wrong version of Scatterer and need to revert back to 0.772. Did the game load for you at all with these Parallax configs for JNSQ? The reason I ask that is because it doesn't load at all for me, it gets stuck forever on a loading screen after mods and patches are loaded but before reaching the title screen.

Skyhawk is pretty good, though recent things like Voyager Mars aren't configured properly. As for contracts, I'm not really sure I've seen any set of contracts that provides a particularly good career experience without completely overhauling contracts (which RP-1 does), but I don't think there's anything wrong with BDB ones. I'd recommend Strategia though, since although it's not a contract pack it gives you incentives to explore and to otherwise play in interesting ways.

This doesn't seem to work. The game gets stuck loading the title screen forever. Here's the log: https://www.dropbox.com/s/h9bnb5r3ycxwggj/KSP.log?dl=0 Does this work for you? If so, what did you do to make it function?

While taking a bit of a break in between phases of modpack development, I decided to launch a totally normal Skylab mission. This is definitely your standard typical Skylab configuration with no changes made. Definitely. Apologies for the strange motion blur effects that appear in some of these screenshots, I was having issues with Scatterer versions. If you hadn't figured it out already, this is probably the point where you start to realize that maybe this isn't the historical Skylab configuration. This is a wet workshop configuration. But why launch it on a Saturn V instead of a Saturn IB..? The answer is that it has a very different destination. Behold, Moonlab 1! This is a very fun thing to do with Skylab parts. In a proper career game I'd probably set it up with a Spacelab configuration, and then add a docking adapter capable of docking with lunar modules.

In the specific context of viewing an active spacecraft, moving the camera in any way results in lingering visual traces (example screenshotted below), as every frame appears to remain overlaid onto the next frame. I've never seen anything like this before in KSP. It appears to be a sort of motion blurring effect, but magnified far more than it should be and lingering for way too long (sometimes indefinitely). I have the following list of visual mods installed, none of which have ever caused this problem for me before in several years of using them: Distant Object Enhancement Environmental Visual Enhancements Redux PlanetShine Scatterer EDIT: I've managed to identify Scatterer as the cause of the problem, but I still need a fix for it that does not involve simply playing without using any version of Scatterer.

Here's the log ("KSP.log", if this is the wrong log please let me know what the correct one would be): https://www.dropbox.com/s/yuoogawreyypl0l/KSP.log?dl=0 Game version is 1.12.3. I'm using JNSQ, Principia (version Ἱππίας), Bluedog Design Bureau, EVE, and Scatterer, as well as all prerequisites for the aforementioned mods. The few other mods I have installed should be irrelevant because I experience the exact same problem without them. I can't even begin to guess at the cause of this, so any help with figuring out what's causing the problem and how to fix it would be appreciated (best solutions would ideally not involve removing any mods completely and only changing mod versions, because I don't have anything installed that I would want to play the game without). One thing that is worth noting as well is that the issue does not appear to ever occur if I only spend time in the editor or other KSC windows, it only occurs in flight.

The biggest concern is the reflectors, and whether they'll work properly to amplify other antennas.

Tech tree has been rebuilt from the ground up for version 0.2.1, and now uses Yongetech Tech Trees Plugin Revived as a hard requirement. The modpack should have a vaguely-functional playtestable alpha release once I've configured Kerbalism and added costs to tech tree nodes, which I will hopefully be able to do soon.

I have another question about something I've just noticed: what is the "aft bulkhead" version of the Centaur engine mount for? I see that it has an extra attachment node but I can't figure out what that node could possibly be intended for, aside from, presumably, a player-made subsatellite.

@610yesnolovely Very nice patches, though is there a reason there's no decoupler to separate the WAC payload nosecone from the rocket?

Thanks for the clarification, that makes sense.

Which engine (if any) represents the RS56-OBA used on Atlas II? I find it a little strange that the half-stage engines get an upgrade which seems to be for that purpose, but the sustainer doesn't. Does BDB just not have that, or am I missing something?

Interesting take on a Venus flyby. Is it based on anything particular, or just an interesting use of the parts?

What kind of skill set is needed to make a Parallax config for a planet pack (specifically for JNSQ)?

JNSQ works just fine with the latest versions of Kopernicus on 1.12.3 as far as I can tell. I haven't tested 1.12.4 yet.

Is the "HLR-TRYP" probe core supposed to represent anything in particular? It seems like a bit of an anomaly compared to all the other probe cores which very clearly do represent specific spacecraft.

I was trying to find an answer to this myself. The Near Future forum thread says that it's incompatible, but I'm not sure whether or not that's been edited since NFEx was released. I did, however, find this issue on the RemoteTech Github, and it appears that the code to add NFEx compatibility has been added. I've not checked whether it's in the current release, but it's definitely in the dev branch on Github, so if you're still wondering this, there's your answer. I have not tested this, so I don't know how well it works, but it looks like it should work somehow.

I have tried to make a tech tree without this mod. The reason I thought to try this mod was because it, in combination with Tech Tree Editor Revived, allows for a much more accelerated workflow, because instead of having to manually place every individual part in a config file to patch its tech tree placement, I can instead just do it with the Tech Tree Editor Revived UI. The tech tree isn't the only thing I'm rebalancing, so being able to assign parts to tech nodes more efficiently gives me more time to work on other changes. Here's the current iteration of my tech tree: https://www.dropbox.com/s/31inir0y1ko25r0/000TechTree.cfg?dl=0 And here's the patch to move unassigned parts into a default node: https://www.dropbox.com/s/n1oy5behyikunlc/001DefaultNode.cfg?dl=0 Other than this mod, it also requires BDB if you want to actually see any parts in the tree because I've not allocated stock parts yet, but if you're just troubleshooting the tech tree itself then you probably don't need that. The only other thing which may be relevant is that this install also contains a currently-unchanged version of Kerbalism with the default KerbalismConfig, since it adds experiments to some tech nodes but the experiments aren't actually parts, they just modify parts. Also worth noting is the fact that the tech tree file was generated by Tech Tree Editor Revived using the option to allow it to work with this mod (the only manual edits I've made were to add a couple of parts that didn't show up in the editor UI for some reason). If Tech Tree Editor Revived is doing something to the file that it shouldn't, or if it's not doing something to the file that it should be doing, that might be the reason the stock tech tree doesn't get overridden properly. Renaming the stock tech tree file to something other than a .cfg file as someone else suggested earlier does solve the problem of the stock tree showing up and allows the custom tree to override the start node, but it does mean that when I distribute the final version I'll have to tell people to modify the stock files manually. If that's something I have to do, then it's an acceptable workaround, though is far from ideal. Thanks for taking the time to look at this, if there is a fix that'd be great, but at least there is a manual workaround.

@linuxgurugamer Thanks for the quick recompile. Unfortunately, it doesn't solve the problem. My custom tech tree remains overlaid on top of the vanilla tech tree. Additionally, the new tech tree's "start" node does not override the stock "start" node, meaning that all custom nodes with the "start" node as a prerequisite require the stock version of the node rather than the custom one. I did find that it's possible to trick the stock tree into hiding itself by manually editing the stock file so that all nodes are hidden when empty, and making a separate patch that moves all unassigned parts into a dedicated overflow node. However, since I'm wanting to publish this tech tree once it's done I'd rather not have to tell players to manually edit the stock files, and this workaround still doesn't solve the start node issue.