DeadJohn

Try CKAN. It might have old links to Github, Spacedock, plus more obscure hosting sites. If you remember the mod name you can also try direct searches of Github and Spacedock. Be wary of old mods on unknown hosting sites. It's pretty easy to insert a virus into a DLL.

I don't think there's a need to increase contract rewards for KSRSS. I usually play at 2.5/2.7x scale with either KSRS or JNSQ planets, plus contract packs built on top of the Contract Configurator mod. I don't know whether CC adjusts rewards based on planet size, but I get playable reward settings. My most recent KSRSS playthrough was at fairly difficult contract reward settings: funds at 60% default, science at 80%. Comments on that: Funds were tight early career. Part test contracts are a good way to gather funds, and also create reasons for new rocket designs with specific parts. The Tourism Plus contract pack offers new ways to gather funds mid career. Science progression was challenging. I felt completely stalled once or twice, and could remedy it by driving a science rover around KSC. I also like building planes to gather science from Earth biomes. Note that I was using Bluedog Design Bureau parts, so I had extra science experiments available. A lot depends on which tech tree you are using. The stock tree is pretty shallow. If using a more complex tech tree, you will likely need to use science labs to get through the end of the tree where some unlocks might take thousands of science points.

You don't have enough facts to know whether the QA team is to blame. It's an unwise career move for insiders to provide too much detail. We don't know what led to EA going out in the current state. Maybe QA screwed up? Maybe the devs and QA asked to push EA back a month but someone above them insisted on sticking to the announced February date? Maybe someone in the decision chain didn't want to tell their boss bad news; that could be the fault of a lazy worker or a mercurial manager?

Are you looking for a mod? Stockalike Station Parts has expandable, animated rings.

IMO it's too soon to be reviewing. KSP2's current state is more like a prototype than a product. I expect things to be further along when they have science mode in the game. Have fundamental bugs been fixed? Are deltaV and TWR shown to players? Did they avoid adding too many new bugs with each patch? "Indifferent" is the best word to describe my feelings. It's just a game. I'm hopeful it will turn into a great game, yet disappointed that 3 years of delays didn't make more progress. Software development is hard.

[Deleted my question because I found a prior post with an answer]

The OP created 3 (or more) similar threads. 2 say "carpetable" 1 says "compatible". Merge? https://forum.kerbalspaceprogram.com/index.php?/topic/213289-why-are-all-the-near-future-mods-no-longer-compatible-in-ckan https://forum.kerbalspaceprogram.com/index.php?/topic/213287-why-are-all-the-near-future-mods-no-longer-carpetable-in-ckan https://forum.kerbalspaceprogram.com/index.php?/topic/213286-why-are-all-the-near-future-mods-no-longer-carpetable-in-ckan

1st post troll. #sarcasm: There's a fully polished version of KSP2 that was given to youtubers, yet a version with worse graphics and extra bugs was released to EA because the development team: Is part of a conspiracy against the OP? Likes drama? Is bored and likes to read complaint emails?

That was canon to KSP1. Many things from old science reports may have changed. Welcome to KSP2.

Respect != identical copy.

FYI the science config in that part is not working. CobaltWolf confirmed it a few pages back.

Regardless of having to tweak the fuel amounts, that interface uses dark gray numbers on a darker gray background. Poor readability and I hope they improve that portion of the UI.

Connecting multiple fandoms: Kerbal Barada Necktie! Kerbal Barada ... N [cough]!

Anyone who can help, I'm brand new to editing B9PS. Why isn't the spoilered code below working? I see the 2 subtypes show in the VAB PAW, but changing types doesn't change the crew capacity. It stays at zero for both. If I put a hardcoded "CrewCapacity = 7" just before that code, then crew stays at 7 regardless of what I pick. TweakScale has challenges scaling crew due to the way a prior KSP version changed things. Maybe that same thing is affecting B9PS (but it's more likely I'm making a novice mistake) Also, on a more advanced note, can I put an entire ModuleInventoryPart or otherwise vary packedVolumeLimit inside those SUBTYPEs? I want to have little inventory in the passenger model, and much in the cargo model. @blowfishThe wiki says "Please note that this feature [MODULE] is highly experimental, please talk to me before trying to use it".

@zer0Kerbal I'm not sure if you've had an opportunity to review my push request. No rush, just letting you know I'm going to experiment more this weekend to make the passenger vs. cargo versions more distinct, more like the ever-evolving Dreamchaser, and create better game balance. Passenger cabin carries 7 crew plus 3000l inventory. Cargo strongly reduces that to 4 crew and only 800l inventory, which seems like too much penalty for adding the top hatch. My current line of thought: Passenger: 7 crew, reduce cargo inventory to 650l inventory (same as stock 1.25m SEQ-9 container). Cargo: Zero crew, increase cargo inventory to 5000l (twice that of 2.5m SEQ-24 container). I'll try to find a better resource for estimating cargo volume and revise the inventory numbers above. The passenger version still has node placement quirks. If I can't resolve it with cfg changes I might change the passenger cfg to share the cargo hatch model. Some unfinished things noted with the earlier push. Localization, etc. Sample Craft with folding wings, similar to the real Dreamchaser announcements: I'll try stock robotic hinges but anticipate kraken. I might have to take liberties such as making more lift come from the cabin, less from the wings, to avoid torquing off the wings during reentry. Rear cargo module: The real Dreamchaser has plans to put an extra conical trunk and docking port aft of the cargo cabin. I can't create a model for it, but if I think of one from another mod with an open license I'll borrow it. Regardless, players who need more cargo space can kitbash service modules from stock or other mods. Holler if you think any of this should go in a different direction.

The way KSP aero and parts work, focus on speed rather than wing area. Use the Whiplash engine. It has good high altitude performance and becomes more efficient near its top speed. For a test flight, try these in order from the nose: shock cone intake -> mk1 inline cockpit -> 2x mk1 fuel tank -> whiplash. Then add wings, landing gear, control surfaces as needed. Raise wing angle by 3-5 degrees; the extra drag from wings will be offset by less drag from the plane's body. For good control, position wings so that total center of lift is behind center of mass. Consider using canards near the nose instead of or in addition to rear elevators.

Is it really that bad of me to not want to pay more money for the exact same game so I can enjoy the exact same mods, only they're being actively updated? I don't earn a lot so I can't be wasting money on stuff like this. Funny how KSP started dying precisely when KSP2 was announced. Please can you at least try to understand my frustrations here? I understand you are frustrated about KSP2. There are other threads and subforums for that. The BDB mod team made a choice to move on to KSP 2, and pestering them to volunteer their time to add features to KSP 1 forever is unreasonable. *If* KSP 2 sucks they can change their mind. Your current KSP 1 and BDB will keep working (until a major upgrade to your operating system breaks it). Nothing is being taken away. No one is screwing you over.

Why abandon KSP 1 modding? Because of posts like this The BDB team isn't obligated to keep adding new parts to a dying game. Their call as to whether to mod for KSP 1, KSP 2, both , or none. Regardless of their choice they aren't screwing you over.

Thanks. I opened a github issue.

Is RCS broken on the hollow aft tank? Its part window shows RCS capability, and Kerbal Engineer thinks the part produces RCS thrust. When I actually use RCS though the part creates zero thrust, uses no fuel (so it's not an occlusion issue), and no RCS animation and sound. As a test, could someone else test a craft with just 3 parts: any crew part that does *not* have RCS in middle, hollow aft tank attached to one node of crew part, solid aft tank attached to other node of crew part. Cheat into orbit. My RCS maneuvers are only using the solid tank. If I disable the solid tank's RCS I then get zero thrust. I already checked the hollow tank's part window to confirm its RCS is enabled and RCS thrust is at 100%. (It's easy enough to workaround by adding the Mk-33 external RCS parts to the hollow aft tank. I'm trying to rule out installation error on my end before reporting a bug.)

Maybe you should if you want parts at 3.125m.

Tweakscale? Not all parts are Tweakscale compatible, though. I recently resized some Near Future Construction trusses that had a good artistic look for my station spine but were the wrong width. SSPXr has many more station parts but I forget whether they are compatible with Tweakscale.

There are more "efficient" (less DV, fuel, and game calendar time) ways to do this, but here's a pretty easy way that doesn't take much of your personal time, needs no tricky calculations or mods. Get into Minmus orbit. When you are on the "forward" side of Minmus (relative to its orbital path around Kerbin), burn prograde until your apoapsis will leave Minmus SOI. I suggest watching in map view so you can see as soon as your apoapsis breaks Minmus. Set your target to Mun. Timewarp until you are in a very high orbit around Kerbin, then timewarp more until you are at the first ascending or descending node between your current orbit and Mun. Burn descending or ascending to get into the same inclination as Mun. (Changing inclination in low Kerbin orbit is expensive, but you are up near Minmus orbit and changing inclination is much easier) Drop a maneuver node slightly ahead of your ship. Drag the retrograde handle of the maneuver node to lower periapsis until periapsis touches Mun's orbit. Then drag the maneuver node further ahead of your ship until you get an intercept with Mun. You might need to finetune the maneuver's pro/retro direction as you change the manuever's time (because your high Kerbin orbit is probably elliptical). That's 3 burns in total. #1 is a rough burn to get away from Minmus, #2 is a rough burn to remove inclination, #3 is a plotted maneuver to get the right time to intercept. There are much more elegant ways to do this, but they are IMO more complex and will take more of your real-world time trying to get a perfect maneuver in as little as one burn. It's possible to get from Minmus to Mun intercept with 1 complex burn. Note that getting from Mun orbit to Minmus can use a similar set of steps.

Is there a mod or other way to edit CoMOffset and CoLOffset interactively? I'm trying to improve aerodynamics in an old mod. The unit of measurement for those properties isn't documented that I can find. Manually editing the cfg requires a restart each time, making it difficult to assess whether a prior test or the current value flies better. I want to make things "good" not merely "good enough".

@linuxgurugamer or anyone else who might know, are there any mods that interactively edit a part's center of mass and lift offsets, similar to what this mod does for nodes?