Streetwind
-
Posts
6,112 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Streetwind
-
-
An easy way to test involves using the "display aero info in part action windows" option in the "physics" section in the debug menu. Then you can rightclick the engine in flight and see exactly how much drag it generates.
-
3 hours ago, antipro said:
Not he can, he have to hang on a ladder, in this way the parts have their attaching nodes,
Wow. o_O That is weird as heck, and very likely a bug.
Squad is on winter holiday break right now, but I'll poke them about it in January.
-
Well... technically you don't need to have anything to stage off of your craft. You could start entirely from storage... but your existing craft will still need to play a role.
- Weld a junior docking port to the side of your rocket
- Add a second junior port to it in docked configuration
- Build the rover on that second port
- Undock the finished rover
- Remove the docking ports from the rover and the rocket and put them back into storage
So your plan will work as long as you add the two junior ports required to your cargo unit.
As far as accessing the storage unit goes - it's distance based. You need to be close enough with the Kerbal you control to take parts from it, and you also need to be close enough to where you want to weld the part. Your Kerbal can hang on a ladder while doing this, IIRC, so that may help. (And remember that only engineers can do EVA construction, in case you tried it with a pilot.)
EDIT - Oh, and work lamps are deployable parts (like the Breaking Ground science experiments). You need to put them in your Kerbal's inventory (this may require you to put away parachute and jetpack first), and then deploy them fom there. Not using construction mode.
-
I use the suits as a stopgap solutions for telling apart the professions. Pilots keep the standard suit, engineers get the vintage one (from Making History), and scientists get the futuristic one (from Breaking Ground).
You'll need the DLCs for that to be an option though.
-
1 hour ago, king of nowhere said:
but the game still shows the center of drag much behind the center of mass
Actually a common misconception because the game doesn't explain this properly to the player:
The blue marker shows center of lift, not center of drag. This is great for building planes in the SPH, but unfortunately entirely useless for rocket construction in the VAB. You have fins at the bottom, and fins can generate lift, so you get a center of lift near the fins; but that doesn't mean that your combined center of drag is in the same spot.
There is no method I am aware of to actually visualize where your center of drag sits.
-
Right, I tried this out. Your issue boils down to two things: having extremely anemic liftoff thrust, and having barely any control authority. Each problem individually doesn't make a rocket unflyable, but the combination certainly does.
In other words: your rocket simply falls over sideways because there is nothing keeping it upright. Remember, this is akin to balancing a pencil - at rest, it is inherently unstable, and "upright" is the position it wants to be in the least of all. You do have fins, but fins need air passing over them to exert any force. Meaning, they need speed. Your rocket starts falling over long before it has gathered anywhere near sufficient speed for the fins to start "biting".
It is possible to force your craft to pitch east, by steering full-tilt eastward directly at launch. However, this just causes the rocket to fall over eastward instead. It still fails to gather enough speed for stable flight.
Another indicator that you have a control authority issue: you say it works just fine with a mk1 pod. But go to that pod and set the control authority of its reaction wheels to a value of 6%-7%. That roughly matches what the OCTO probe core can deliver. You'll find that the rocket now behaves exactly like the one with the probe: it simply falls over because nothing keeps it upright.
There are additional other issues with the rocket as well: (I realize you are doing a challenge that limits your options, but bear with me.)
For starters, let me get back to thrust. Your sea-level TWR is 1.16, which is terrible. Even if you had the control authority to keep the rocket upright, it would still be terrible. Why? Because as a rule of the thumb, anything below ~1.2 is so slow to lumber off the pad that it loses more dV to gravity than it gains from loading the additional fuel that made it so heavy in the first place. Additionally, the lower the acceleration, the harder the rocket becomes to steer. Personally, I try to stay above 1.3 at all costs.
Then, the 0.625m stack separator between two 1.25m stages. Don't do that for anything inside an atmosphere or exposed to significant acceleration (including gravity). Not only does it cause noticably more drag than a smooth, uniform 1.25m size shape, but smaller node connections are also weaker, and extremely flat parts like the stack separator have weaker connections than tall parts in the first place (it's got to do with the way Unity computes physics, don't ask). So you're introducing a joint that can flex a lot. Not good if that's the thing that connects your two largest stages. Just use a TD-12 instead. It actually costs less, and the 30kg mass difference is negligible for an 18 ton vehicle. When I replaced it on your template, the thing was exactly 18.000 tons. Rebuilding the fairing easily pushed this to 17.999 without any visible change.
Finally, your second stage is overloaded into diminishing returns, choking the launch stage. Your Isp multiples are split 7.97 to 13.13. You can actually turn this rocket into a three-stage vehicle that still stays below 18 tons and 30 parts while squeezing out 145 m/s additional dV (7147 total instead of 7002) despite using full-size 1.25m decouplers and not having a better third stage engine available than a Terrier. Of course, this doesn't fix either the control authority issue or the terrible liftoff TWR, but it is an improvement.
Chiefly because this additional dV budget allows you to fix the actual problems.
Here's what you do:
- Toss everything below the fairing away. Delete the fairing as well (but not the base).
- Insert a Small Inline Reaction Wheel between the fairing base and the stack separator that detaches the probe.
- Rebuild your fairing.
- Build the third stage: one FL-T100, one FL-T200, one Terrier.
- Build the second stage: one TD-12 decoupler, one FL-T100, one FL-T200, one FL-T400, one Terrier.
- Build the first stage: one TD-12 decoupler, four FL-T400, one Reliant. Nope, there are no fins. Fins are crutches. You don't need them.
- Check Yo Stagin'! Put the fairing after the second stage, before the third stage decoupler. I also recommend locking the gimbals on the two Terriers for more precise steering.
Voila: one science probe launcher with sufficient control authority and 7026 m/s dV, at 24 parts and (in my case) 17.43 tons. It has an improved, if still not optimal, 1.20 sea level TWR. The second stage TWR isn't great either, so keep that in mind for your ascent. But it flies to orbit alright, at least in stock KSP. I tested it.
If you have Precision Propulsion, your third stage can be a 0.625m size affair inside the fairing, with Oscar-B tanks and an Ant engine. This will greatly improve the rocket. But if you don't yet have it, the design described above should serve your needs for now.
-
Transfer Window Planner has an option that says "flyby only", which you can select if you do not want to perform an insertion burn. This is useful not just for flybys, but also for atmospheric worlds where you can aerocapture.
If you selected this, then the dV cost is for the transfer burn only (plus midcourse correction, if you got one). If you did not select this, then the dV cost is for both transfer and propulsive capture.
You say you got a transfer node with about 1100 m/s; that sounds perfectly fine for a good in-window Duna transfer. That leads me to believe that the rest of the total sum accounted for a propulsive capture.
-
2 hours ago, JoeSchmuckatelli said:
I've yet to find a tutorial that really helps me to picture what is going on when I look at isp numbers.
The most important takeaway is: Isp is measured is seconds because one of the ways of looking at it is simply the duration the engine can run at a specific amount of thrust with a specific amount of propellant. Which amounts those are aren't important. It just means that between any two engines with the same thrust and the same amount of available propellant, the one with 10% higher Isp will run 10% longer before consuming all the propellant.
An example is a Terrier and a Reliant. In a vacuum, they have 345s and 310s Isp, respectively. Throttle the Reliant to 25%, and both engines will produce the same 60 kN of vacuum thrust. Now mount them on the same tank.
Because the Terrier has 11.3% more Isp, it will burn 11.3% longer even though it runs at the same thrust and has the same amount of propellant available. So in a world where the Reliant drains the tank and flames out after 100 seconds, the Terrier will keep going for another ~11 seconds longer because it is more efficient. You can do this experiment in game and verify that's how it works.
But if even that mental image isn't really doing it for you, don't worry. You don't need to get hung up on Isp too much. It's not what really determines your available dV; it's just a small contributing factor. The real centerpiece of it all is the mass fraction.
-
Rather than tell you the answer, I'm going to tell you how to discover it yourself without even needing to go to Duna.
In the editor, build the craft you hope to launch from Duna, or a sufficiently similar stand-in. Now, click on the stage that has the engine in it to expand its view. You should be able to see its TWR there. Finally, go to the dV app in the toolbar on the bottom right. Make sure it is set to sea level. In the dropdown menu at the top, select Duna.
Your stage info will now show you Duna-relative TWR at Duna's sea level. If this number is greater than 1, you can launch with your current engine. If you then set the dV app to vacuum and refer to the Community dV Map for a typical cost to launch into low Duna orbit, you can check if you have enough dV as well.
-
The thing about unknown objects is that they don't actually exist as a physical object until you (that is, the player's current control point) gets within a certain distance of them. Only then do they actually spawn in.
Before then they are just blips on your tracking station view, and cannot hit or hurt anyone or anything.
-
It strikes me that this challenge would be a lot more fun if you waited for 1.11, and its advanced construction options
I mean, your Kerbals won't be able to lift much on the surface, but at least you can strut your docking connections after the fact to stiffen them up for launch. Also, all those 5kg parts like science instruments, antennas, basic solar panels... perfectly valid for EVA attachment in any gravity. Leaves more part budget for the bigger stuff.
-
Two notes:
- Make sure you press the green "keep report" button when confirming the science report in flight. If you accidentally hit the grey button with the revolving arrows at the top, it'll cancel the report.
- If you revert a flight to the launchpad or to the editor, everything that was done during that flight, including science collected, never happened. -
Yeah, those tutorials are all woefully outdated.
My advice would be to divest yourself from the aspiration of doing everything right the first time, and just try stuff out. Because KSP as a whole is a game about trying, failing, and learning from your failures. Kerbals are funny little creatures that are entirely expendable... that's the point. If your rocket blows up, so what. Just build a better one next time, solving one small problem at a time.
But if you want to learn from tutorials, the first stop should be the ingame training missions. If you have those done, then start a game in Science mode (not Career). And then, look for a tutorial on how to perform experiments and earn science points.
This one here might be of interest to you. It's a video series of someone starting a Science mode game as a tutorial for the absolute beginner. He's using version 1.8.x, which is reasonably recent - the two updates since then have only added bugfixes, visual improvements, and lategame content. So there should be few, if any, hangups over differences between his and your game version.
EDIT:
4 hours ago, mrsidknee said:He says he has version 1.3. My screen says I have version 1.10.1.2939, which confuses me because I just bought it so I'm not sure how I can be using a younger version.
You are not using a younger version
Or rather - you are, if "younger" is to mean "more recently released". What you probably meant was "a smaller version number", which would indicate an older, less recent game version.
Regardless: his version was "one point three". Your version is "one point ten". That is seven updates newer than what was used to record that old video. The thing about version numbers is, they're not decimals that can tick over. The point is just a separation character, not a decimal point.
The first number is called the release. Which is 1, because the game is finished and fully released as "version 1". Before KSP was fully released, it used to start with a 0 as its release version. You generally only increment the release version if you update the game to such a degree that you practically want to re-release it - for example, if it gets a major content expansion or a complete rework. But since KSP publishes its content expansions as optional downloadable addons (DLC), there was no reason to ever increment the release.
The second number is the major version, which is to say, the level of major updates. Every time an update is published, the major version increments. And yes, it can go to 10 or higher. It can go as high as you want. It is entirely independent from the release version.
The third number is the minor version. This is for little fixes that need to be made after an update is released and potentially brings new bugs with it. Again, this number is completely independent from all other numbers and can go higher than 10, or even 100.
So, your version number of 1.10.1 would read as "one point ten point one", or in human-understandable terms, "the first bugfix of the tenth update of the first release of KSP".
-
The thing about ideal ascents is not where your apoapsis ends up, but rather where your periapsis ends up. You want it to be as close to positive as possible before you have to turn off your engine and coast to apoapsis. The reason being, if your periapsis is already positive, or close to it, then you have achieved close to all the horizontal speed you need, and the orbit insertion burn will be fairly negligible. It means that not only did you spend the majority of your dV further down in the gravity well, where it is more efficient to do so (-> Oberth effect), but also that you burned sideways a lot instead of upwards, which minimizes gravity losses, and that you always burned reasonably near your apoapsis, which is the most efficient way of raising your periapsis.
And you'll find that if you follow that guideline, the two solutions you propose... kind of start to look the same. All you do is let the engine run just a little bit longer before turning it off and coasting to apoapsis. Which, if done while you are close to apoapsis and having a high periapsis, will involve flipping that apoapsis around to the other side of the planet. Which is functionally similar to inserting into orbit and then performing a Hohmann transfer.
So as long as you get the fundamentals right, you don't really have to worry about this question.
-
Honestly sounds like an out-of-memory error, but that would be weird if you have 16 GB RAM and no other programs open. Try screenshotting the error window. Also go to %username%\AppData\LocalLow\Squad (you can just paste that path as-is into the file explorer) and find output.log and player.log. Ideally grab them directly after a crash.
Regardless though, this is in the wrong forum section. I'll ping a friendly mod for a move to tech support.
-
Is your browser open when you start KSP?
If yes, try closing it. Check if KSP still crashes then.
-
That was never a thing, no. Not in the PAW. Not unless it was added by a mod.
However, if you hover over a part in the part list on the left, you can see the wet mass of that part. And if you pin open the details window, you can see the masses of contained resources.
-
Boyster is correct. This was also already answered by Squad officials earlier in the thread. There is no linking together separate ships without docking or klawing them. But the ability to attach docking ports and klaws anywhere (at least where the gravity isn't too high) will make that much easier.
I mean - did you ever try to have a rover dock with a surface base, and found that the ports were ever so slightly misaligned, because the landing gear compressed more than you thought it would? Now an engineer can fix this in ten seconds. Enter construction mode, select the Move tool, select the docking port on the rover, edge it down a little, weld, exit construction mode, done. Your rover docks flawlessly now.
Maybe pulling a fuel line from the rover to the base would be more straightforward, but you don't really need it to make things work. And if gravity says no - well, even that is moddable, if you'd like your SuperKerbals to lift one-ton parts on Kerbin's surface! Really, just give it a chance. Just because a mod has trained you to think with fuel lines doesn't mean there aren't any other ways.
-
The proper Kerbal solution would be to attach boosters to the rover and have it launch out of the cargo bay like a bat out of hell
-
6 hours ago, JIMMY_the_DOG said:
Some people have sounded like it already came out... just checked and it's still at 2939...
There is a small group of (invite-only) volunteer prerelease testers and streamers who get access to updates early once they are feature-locked and in a reasonably playable state, in order to help with QA. So yes, some people here on the forums have been able to play with Construction Mode already. Don't expect them to tell you anything not officially revealed, because there's an NDA... and honestly, the devs worked hard on this, the privilege of dropping the info is theirs
But do look forward to this one, it's really good.
-
The dV cost to orbit can be broken up into four things: orbital speed, gravity losses, aerodynamic losses, and steering losses. For launching from stock Kerbin with typical TWRs (1.3 to 1.5) and a reasonably pointy rocket, orbital speed is about 65%, gravity losses are 25%-30%, aerodynamic losses are 5%-10%, and steering losses are one or two percent at most.
You cannot reduce orbital speed, but you can reduce the losses. Out of the three, gravity losses are the largest by far.
Gravity losses are constantly incurred whenever a rocket engine is fired not perfectly perpendicular to the gravity well. The more it is firing towards the gravity well, the worse the losses are. Directly at launch, when the vehicle is perfectly vertical, gravity eats up 9.8 m/s worth of dV for every second the engine fires. 9.8 m/s, every single second, just gone. That's why gravity losses are the biggest loss factor.
So how do you reduce it? Well, if you could turn over harder and sooner, you'd be firing your engine further away from the direction of the gravity well sooner, and for longer. Also, if you could just fire your engine for a shorter time, fewer losses would accumulate. And both of these things have one thing in common: they require you to have higher acceleration. In other words: a higher TWR. This is what TWR does for you, beyond having enough of it to lift off; it makes your ascent more efficient by minimizing gravity losses. Which is what @Entropian already correctly pointed out, just with an actual explanation attached
There are two takeaways from this: one, if you lose more dV to additional engine mass than you save in gravity losses with the thrust from those engines, all you did was waste money; and two, TWR largely ceases to matter once you are in orbit.
(I say "largely", because stretching a burn over too large of a section of the circular orbital path starts incurring you significant cosine losses as you thrust off-prograde for minutes on end both ahead of and after passing the maneuver node. And if your thrust gets so low that you have to fly constant-thrust spiral trajectories, like ion engines require you to do IRL, then the cost of transfers can rise drastically - up to 2.4 times that of an ideal Hohmann transfer, given an infinite SoI and infinitessimally low acceleration.)
-
There are no sensors that auto-ignite retrorockets when you approach the ground.
So the only way to do them is to mount separatrons, remove almost all their fuel so they only have a very short burn, and then manually stage them a split second before landing.
-
You can, however, dock two craft and then weld a fuel line between them to bypass fuel crossfeed restrictions... then remove the fuel line again before you undock.
-
My memory is foggy, but wasn't there a bug in 1.10.0 that ruined modded fairings? It was supposed to be fixed in 1.10.1.
Dylan, are you on the latest version, and are you playing with mods?
If not, have you tried uninstalling and reinstalling the game? Sometimes things can break during updates.
It also often helps if you can show us screenshots or video of what you are trying to do. Especially if there is a language barrier
No jetpacks on Stranded Kerbals
in KSP1 Gameplay Questions and Tutorials
Posted · Edited by Streetwind
Welcome to the forums
Could you make a screenshot of the Kerbal in question with its rightclick menu open and post it here, please? (You can use imgur.com and link to it)