purpletarget
-
Posts
407 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by purpletarget
-
-
You can check this video here, which eventually gets to doing inclination changes, either by eye & math, or by modifications with the nodes.
Basically,
- take your perpendicular heading (eg: Prograde vector on 090, look at 000),
- run back towards the retrograde 1/2 the degrees you want to change. (30 degree change, go from 000 back 15 to hdg 345).
- Note your speed.
- Burn quick and hot, your speed will drop (you may want to point a bit above horizon to compensate) and eventually start to climb again.
- Burn until you've got back to your original velocity.
With the nodes, adjust your inclination until you're happy, and then pull the retro marker until your Ap goes back close to where it is. (You'll find the Manuever node in pretty much the same place as method 1)
- take your perpendicular heading (eg: Prograde vector on 090, look at 000),
-
If you want to get into the math without necessarily waiting for the old math texts to show up, and at the risk of making a shameless plug, I've run through several of them in the Krash Test Kerbals vids.
Also you can check in on Specialist290's drawing board, which will point you to several other sources that will briefly explain the equations and methods behind the Kerbal madness.
-
Merged like threads
-
That is correct. Prior to .22, some of the nosecone parts had drag values at .2 or higher, making them counterproductive in terms of improving performance, since all they did was add dry mass at best, and extra drag as well at worst.
With the change in .22+, they now improve the drag stability of the parts, as SofusRud mentioned. The jury may still be out as to the actual trade-off between the drag savings and stability advantages being worth the mass, and that's mostly an individual engineering preference. But they certainly don't hurt the way they used too.
-
This makes complete sense, but, considering that the craft is in SPAAACE, there should be no reason for it to lose energy to anything... So, sometimes it's better to have a stronger engine than more fuel?
Remember in SPAAACE, in KSP you don't generally lose energy to much, and but you also can't gain any. So all the rocket motors are Reaction Engines. That means they use the Newtonian principle of throw stuff out one direction, you'll get the same reaction in the opposite direction. All the fuel you have on board, isn't like a car where it turns gears and wheels to get that force on the ground. The rocket basically is throwing stuff out the nozzle behind your ship with a certain force, and that imparts the same force on the ship to go the opposite direction(forwards). The more mass it throws (Fuel Flow), and/or the faster it accelerates the mass it's throwing (ISP), the more force you get for your ship (Thrust).
So, if you have 1/2 your ship mass is fuel, and you throw it all out the back at once you get force X on the fuel going backwards, and force X on the ship forwards as well, and that will change your velocity (delta-V) by Y.
If however, you use the same mass of fuel, but double the mass of your ship, the fuel only accounts for 1/3 of the ship's overall mass. (Similar to your case above, increasing payload from 4 - 10) If you throw the fuel out as before, you still get force x, and it still imparts force x on the ship. But because the ship has twice the mass, it will only accelerate half as much, so the delta-V of the ship will be 1/2Y.
That's why you're dV went down...if you increase the payload, and do not increase the reaction mass to move said payload, you aren't going to be able to push that heavier mass to as high a velocity as the lighter payload.
-
Yes, the EVAMono is infinite...and topped up whenever a Kerbal leaves a pod. There's nothing buggy in your install as far as that goes.
Also, at Kerbalkon they said that you can transfer EVA prop between Kerbals that are on the same vessel, however it does not display EVA Prop at all while in a vessel...
The only (stock) case where the Kerbal is part of a vessel for this kind of resource transfer, is when they're "docked" in command chairs. Then they can transfer EVAMono between each other.
-
Luckily for you, in .23 tweakables you CAN do exactly this! Once in space, simply tweak your ailerons, and any other control surface you want to stay still, to inactive for all 3 axis....no more distracting flopping about during maneuvers.
Just make sure to turn them back on before re-entry.
-
Don't let the apparent size fool you. Mass wise, it's slightly lighter than the Mk1-2 command pod. So anyone who has managed to orbit an Apollo style CM, or even flown the Kerbal X, has already done it.
-
I haven't so far...but I don't run the music tracks on my vids much.
Plenty of evidence it's still going on though:
-
Oh, it seems I don't get the transmit to lab button option when I activate my different science modules. That stream was somewhat unclear about what recovery was, and what it means for the overall science. Do you loose science?
What's this "Power" counted in Megawatts doing for the science lab? Anyways, my lab doesn't seem to work at all, so...
That's because the Lab of which you speak has not been released yet. Wait till your game updates on the 17th, and then give it a try.
ETA: If you're looking at the Materials Lab Jr. in .22....it just gets the regular blue transmit button....no upgrading values in that version.
ETA again: Also moving to Gameplay.
-
Krash Test Kerbals, Episode 1-6: Hohmann Revisited - Kerbal Space Program Tutorial
Today we are taking a closer look at Hohmann transfers, to not only confirm the delta-V calculations, but also how to calculate the angular alignment (of Phase Angle) between our target and our intial injection burn point to affect a rendez-vous. We also play a bit with our Thrust to Mass Ratio (TMR) in space, and see what effect a long slow burn has versus a short and fast burn. And we setup for a free return trajectory, using a gravity assist from the Mun to drop a probe rightt back to Kerbin, with no additional maneuvers requires. (Look Ma, NO HANDS!).
Todays Topics:
Hohmann Transfers
Phase Angles (Angular Alignment)
TMR for Orbital Manoeuvres
Free Returns
Space Oddities - Rules to Live & Krash By!
-
Well Played!
-
If you want to see a real life example of an incident that give Gravity it's semi-plausible premise, check this out:
The ISS crew has been sent to their shelters on occasion for close debris encounters such as this.
-
The direction of your orbit around Eeloo doesn't really matter. You can just eject yourself backwards from Eeloo's SOI by driving your ejection clockwise instead of counterclockwise. The velocities will remain the same, you just need to adjust your ejection angles accordingly.
Similarly the inclination may or may not be relevant....depending on how inclined, and where the An/Dn axis is. If the An/Dn axis is pretty much inline with the direction of Eeloo's orbit when you want to escape, you're golden. Otherwise you may suffer some inefficiencies, and that will be dependent on how much the inclination is. If you're only a few degrees, it won't matter much at all. If you're in a polar orbit with the RAAN (An/Dn axis) aligned with Eeloo's radial directions...you're going to have a trickier time.
If you're inclination is above 60 degrees, and you have some time to spare (you may want to backup a bit from your launch window to give some time) then you can try a series of 3 burns to and see if they provide better results.
1. Push your Ap up close to Eeloo's SOI. (This is the part that you probably wanted to do a while before your transfer window). Do this burn near the Sunrise terminator so the Ap is near the retrograde side of Eeloo.
2. At the high Ap, do your inclination change.
3. Back at Pe, conduct your ejection burn for Duna.
If your RAAN is closer to Eeloo's radial, then you'd be looking at having to torque the orbit instead...and that might again put the dV required out of reach.....then you might also just check if it's less dV to just push just outside of the SOI, and then conduct your maneuvers from Solar orbit. (You may loose some oberth advantages, but it may still be less than all the orbit fixes.)
Another option may be to see what dV would be required to land on Eeloo (on or near the equator), and then take off again into an equatorial orbit. (Not likely, but might be easier to execute)
Without some better details about the actual inclination, and relation to Eeloo's trajectory, it's hard to give you anything too definitive. (Screenshots can assist as well)
-
IHMO It does not really read to me as a bug.
Part of the problem with implementing something as complex as sub-assemblies is that there's no way to know whether the user wants the stages to be combined, or separate in the final result. When you add a sub, are the stages supposed to be earlier or later? If you're adding a lifter, it seems reasonable to assume the stages of an added sub would get added to the bottom. But if a user builds the lifter first, and adds a satellite or lander to the payload, that assumption would be incorrect for them.
So this is a case where the tool is provided and the user is required to figure out how to make it work for their style of play.
So the current implementation just takes care of the simple case. When you save a sub, the stage numbers for the components are saved as part of the sub. The engine that stages on 3, will remain a 3, and if the sub is re-added to a new ship, it will get put back into 3.
So the easy workaround for using lifter and payload subs is to save payloads as normal, generally lower numbered stages to trigger last, and to insert a bunch of blank stages (as 5thHorseman alluded to) to the lifters before saving them as subs. Add 10, if you never expect your payload to have more than 10.
Then the only part you need to be careful of is that if your payload has 5 stages, the extra blanks will get dumped when you add the lifter sub. So the lifter sub with 10 blanks will put the stage 11 into stage 6 of your combined vehicle. This shifting might cause some extra work and grief if you have multiple subs that you like stacking/expanding for different payloads (Core, then 1st boosters, 2nd boosters, etc) rather than a complete lifter systems from launch to delivery. Proceed with caution.
Note: The advantage to Col_Jessep's version above, is filling the "empty" stages with throwaway decouplers will avoid that shifting until you're ready, allowing greater control for the player.
-
t = 24*60*60 = 86400 (for Kerbin)
Kerbin's day is only 6 hours long.
Units in KSP are metric...so yes, you'll want to use meters
-
The upshot is that the 909 is gimbaled, so you don't need to use the reaction wheels to hold a heading during a burn. Thus you can save a lot of power by turning off the reaction wheels for most of the flight, with possible exception of an occasional orbital reorientation, and maybe during landing.
As for why it doesn't generate power...different engines have different trade-offs. The 909 has never generated power ... but I don't know if it's purely for gameplay balance, or based on some real world motor designs like the LMDE...which looks to have not required the alternators and turbopump arrangements are seen on the terran LVT-30/45 analogs.
-
The purple is a marker for where the target is *now*. However, many targets in an orbit, like the Mun, are moving. So if you want to hit them, just like deflection shooting, you need to lead your target.
-
the early stages, power is at a premium, so you need to be careful with your power consumption. Transmitting data will use a lot of juice, so as has already been mentioned, you want to only transmit while you have a LVT-30 running to recharge the pod.
If you decide to work with only a 909 at some point, the engine itself will give you control via the gimbal when it's running, but there's no power generation. So it's critical to minimize you're use of reaction wheels. Don't leave SAS on during coast phases, only rotate the craft for burns, turn off reaction wheels during burns so the gimbal can do all the work, etc.
Without transmitting, and careful power management, it's entirely possible to do a direct mun landing and return with just the power provided on a single Mk1 Pod.
-
The actual tech node for parts is defined in the part.cfg file....so if you want to move parts around on the nodes, but not change the nodes themselves, it's a simple text edit.
-
The early stages is fertile ground to work out power management...because there is none, other that what the engines provide...and even then, perhaps that's only during an initial ascent.
That said, it is possible to do a full Mun direct and return mission with the power of a single pod, and no additional generation after dumping the initial ascent stage. But it does require careful power management, and maneuvering. (Turning off reaction wheels and SAS during transit, only turn when you need to for a maneuver,etc.)
This is one reason that having probes earlier wouldn't be useful, since the constant power draw, and no additional batteries means that a probe would run itself dead in only a few minutes...and without the power to transmit anything useful back to boot.
-
Yep, 5thHorseman is correct. Each of the objects that can store science, get to store basically one experiment at a time. So if you want to reuse goo containers or whatever during a mission, is to dump old data entirely, or transmit for lesser value. Otherwise, the whole science part needs to be recovered at Kerbin to get the full science potential out of it.
Pods are slightly different in that they can only hold one crew report at a time, but the crew reports also don't loose any science from being transmitted.
Kerbals can hold one sample, and one EVA report at a time, and multiples of those can be stored in a pod....however, only one EVA and One Sample from a given situation/location/biome can be stored at a time. So you can take a Dirt Sample from the grasslands and another from the highlands into the same pod...but it won't store a 2nd grassland sample.
-
There's plenty of good resources mentioned in The Drawing Board: A library of tutorials and other useful information, some of which contain some of the formula's, derivations, and some exceptions that exist only in the game itself. (*cough*Air Drag*cough)
Also, as not to miss a chance for shameless promotion, check the link in my sig as well.
And of course, plain old wiki can fill in a lot of blanks once you start hitting the right terminology to find what you're looking for.
-
I see. Could it be that the game measures inclination in the range [-90°, 90°] instead of [0°,180°]? Usually, 0° means an equatorial prograde orbit, 90° is a polar orbit, and 180° is an equatorial retrograde orbit.
The game measures the An from 0-180, same as IRL systems. However it just displays the Decending node using the negative angle, but it's always just the negative counterpart to the An.
Uhm. I know. That's why I posted what you quoted where I pointed out that the claim that it depends on where on the planet you cross the equator going northward cannot be true.Don't get too hung up on the Longtitude term with regards to the RAAN/LAN. Specialist290 is right on the money, as is NefariousParable. The Longtitude of the Ascending Node is not based on the longtitude of the planet, so the rotation of the planet doesn't matter. Indeed the planets position in the Orbit doesn't matter either. It's a longtitude as measured on the celestial sphere, and 0 degrees is the reference direction.
When discussion this measurement on Earth, or indeed anywhere in our solarsystem, that reference direction is based on the First Point of Aries, a nice bright easily identifiable star, which by virtue of being several dozen light years away, means that the parallax effects in measuring angles from one side of the solar system to the other are effectively negligible. So the RAN is measured as a counterclockwise angle from that line between the CoM of the body being orbited and the Reference direction, along the equatorial plane, to the point where the Subject orbit crosses the plane from South, to North. That's the Longtitude of the Acending Node, and that doesn't change based on the rotation of the planet.
For a little more granularity of some of these terms, the OP's diagram, and how they all work, you might want to check out the following:
Solar panels are usable too far out and RTGs never become economical
in KSP1 Suggestions & Development Discussion
Posted
The OP table also only addresses power generation of the device itself. It does not however, account for the storage requirements, that is the Battery Mass. The power generation per time can be met by one RTG, and one small solar panel, at a significant mass difference. However, the batteries required for Solar to be useful though eclipse periods are the more significant mass portion of the solar powered systems.
In which case, when looking at just the keep-alive power requirements of a basic probe, without instruments, transmissions, lights, or reaction wheel maneuvering, the mass trade-off happens at ~15 hours. While this isn't too much an issue for orbital ops, there are a decent number of celestial bodies that have night cycles lower than that for landed craft, night capable rovers, and even in orbit, there are more and more requirements for power (ie: Science) that can start drawing enough power to either preclude night ops, or require an RTG to maintain capability.