purpletarget
-
Posts
407 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by purpletarget
-
-
Be sure to read the pod descriptions. Only Manned pods are "SAS equipped" by default. So if you have a probe controlled craft, the SAS functionality will do nothing, just like 0.20 ships without ASAS installed. If you want SAS to do anything with a probe body, then you have to add one of the other SAS equipped parts, which include the Old ASAS 1m & 2.5m parts, or the Avionics nosecone thingy.
-
I also agree. From what I have experienced, the new ASAS system seems "weaker" and less responsive. Before, the ASAS will immediately lock into place when I turn it on, but now, when I let go of the controls, it doesn't lock immediately into place like before.
This is one key difference with the new SAS behavior. The old system would shake a ship apart trying to fight it's way back to a particular heading.
The new system allows us to use the controls to fly and change heading while the SAS is engaged. But it's not a mind reader, so it can't know if you let go of the controls what your intention is... So one of the key differences is that when you've introduced a turn or swing on the controls and let go, SAS won't try to get back to the point that you let go of the controls. What it will do, is try to kill the turn or swing and steady up...and that steady up point is the heading it will attempt to hold.
What this requires from the pilot, is a little bit of work to anticipate your desired course, and let go in advance of reaching your desired heading. If it's going to take SAS 10 degrees before it steady's up, then you want to stop turning when you're 10 degrees from your desired heading. Small ships this anticipation should be fairly trivial. Larger ships, you might want to plan ahead.
-
Excessive wobble on space stations wasn't so much competing ASAS modules, but rather the torque of a bunch of disparate command pods on the ends of various ships connected around the many docking ports.
However, now the torque of pods is produced by the reaction wheels which should be able to be turned off. So if you do start getting oscillations in your stations, try turning off the reaction wheels on the docked ships, and it should settle down.
-
You can also figure it out with half a minute of trig and a calculator, or 10 seconds with a relvel board, compass and rolling ruler, or ruler and triangle.
-
I'd be careful about associating delta-v effects as the same thing as gaining speed.
From the link provided, it looks that the Aero part is an additional component to a gravity assisted turn, where atmo allows a sharper turn than would be provided by gravity alone. This sharper change in direction, without atmo would otherwise require additional dV on the s/c.
From the brief description given, I don't see anything that would indicate an increase in the actual velocity, other than that which might be provided from the gravity assist. Otherwise, the aero component can only add drag.
-
For now, Kerbalizer is a separate program, with no integration with KSP.
There was some talk at one point about it becoming a possibility, but as with all planned features (and unplanned) in KSP, they are only speculative until they show up in a release with no promises or warranties expressed or implied.
-
Inclination changes require that you rotate you ship during the burn. As your inclination changes, so does the normal/antinormal axis, so you need to rotate your ship accordingly, or do it in several burns.
The easiest way is to use MechJeb and use the Smart ASS to keep your ship pointed Normal/Antinormal during the burn.
And yes, inclination changes are expensive in terms of fuel. It is best to minimize them. They are cheaper when done at a high altitude (because you are going slower), so it is usually best to do them when you are entering the SOI of a planet, or even to raise your altitude, change your inclination, and come down again.
You don't need to follow the rotating normals, it's more efficient to go straight at the half-angle. And the calculation involves dividing by two, and adding 90. It's literally quicker than the time it would take to even search for Mechjeb on the Spaceport, much less install it.
And as for the altitude thing, pushing the Ap up for a higher altitude only starts producing dV savings for inclination changes of about 60 degrees or more.
-
Your hohmann numbers are probably correct, but...that assumes that your already doing orbital velocity at 0m altitude, which for the Mun is about 570m/s. The surface of the Mun however trundles along at a leisurely 9ish m/s...and good thing too, otherwise jumping over a trashcan would put a poor Kerbal into orbit instantly!
So, launching from the Mun requires a bit of Delta-V to get to altitude, but mostly on vacuum worlds, you need to gain (or kill) the orbital velocity needed for your desired orbit.
-
Hmmm, inclination changes, my favourite flavour!
You'll want an An/Dn angle at least equal to the latitude of the green hexs, and then wait till the planet comes around. You can either do the inclination burn directly, and easily using the tricks I show in the video, or you can use the maneuver nodes, but in addition to the normal/anti-normal pink markers to get the inclination where you want it, you also need to use some retrograde to keep the Ap from going waaaay out there. (The vid explains why this happens)
-
You can see the not so fancy math on how to calculate the time required for transfer here, late in the video, I think it's the last 10 minutes or so.
You also don't need mods. The maneuver nodes will allow you all the precision you need, and the time calculations. Once your first Sat is up, you can use it as the target for the next satellite. When you push the Ap of the new Sat up to the KSO altitude the intercept markers will show up. Shift your node around on the orbit to move the intercept, but unlike an RV, instead of matching the markers as close as possible, make them so they're 90 or 120 degrees or whatever you want, away from your original KSOSAT. Once you get there, circularize as close as you can.
Wash rinse repeat with the other sats as required.
-
Part of the problem with large skycranes and other puller designs is that the Gimbals on the rocket motors currently don't adjust for being above the Centre Of Mass. So, if your motors are high up, and you depend on them for steering, you'll find that the Pitch and Yaw controls end up reversed, and ASAS will be completely counterproductive. This is a known bug in the controls.
-
I've never heard the word "clutch" used like that before.
Check the definitions 1-5 here.
Unfortunately I have no suitable stories, since I tend to plan ahead.
-
Yeah, if you're talking about the Stock Scenario, here's the problem.
IIRC, the Lander Module doesn't have any RCS fuel or thrust blocks. It's just the target which is why RCS on the LM doesn't work. It's not there.
Secondly, the , Command Module has RCS, but no ASAS. I'm pretty sure the scenario was around in v0.18, where the RCS translation was broken in 18.1, so the translation controls on the CM are a little off the COM, which induces the undesired pitch & yaw. And because there is no ASAS, there's nothing to try and maintain the heading during translation operations. So switching to docking mode does nothing to help maintain attitude, it only remaps the controls, because there's no ASAS.
So, the upshot is, the Mun Orbital Docking scenario is docking in hard mode, so I'd recommend staying in staging mode, and using the combination of both keysets (IJKL) for translation, and (ASWD) for fixing you Yaw/Pitch whenever you try to translate. Accomplish this despite the broken RCS, and you'll be golden for any other docking operation ever.
-
It's completely possible to get accurate orbits manually, it just requires a bit of patience and forethought. The Ap/Pe's don't need to be exact, just close enough, and mostly it's just that you need the Semi-Major axis to be the same. Of course at 10km separation, that's only about 5 second apart from one station passing overhead to the next, and any orbit will eventually drift a little.
If you really want to avoid the lag, then I'd put them in different orbits, that are at least 4-5km apart in their Ap/Pe, as then you'll never be in range of both at the same time. You can adjust the orbital period to something in resonance, like 40 minutes and 60 minutes, which would give you 2 & 3 orbit windows, but really, how often do you need the windows to happen? 35 & 42 minutes should get a sync every 7 or so.
But as long as your transit bus has a few hundred delta-V for the transfer, even a station on the other side of Kerbin is only one outside orbit to an RV away, allowing a transfer at anytime within an hour or for a daily commute time, in which case all you need is the altitude separation to avoid the lag, and the timing and resonance becomes moot.
-
If you are talking about the fuel gauge on the staging list to the left side, they don't show the fuel per tank. They show the fuel available to the engine. So asparagus staging allows all fuel available to the engine, which would include your two almost empty tanks. Once those first 2 tanks are jettisoned, now the fuel available is only from the remaining 3 tanks, which up to that point, would be full.
Similarly with the resources tab at the top right, which will show all the fuel in the s/c, but once staged, it may go from 800/1000 units to 800/800 if you dump two empty tanks with 100 units in each. It's the total ratio of resources remaining to space available for it, so as you stage, the space available is taken away.
-
I only know to burn prograde or retrograde, how to burn radially?
Radial can be predicted using the Maneuver node's blue markers. From the screenshot you provided, you can burn inwards, bending your path to the left, until you get a Pe ahead of the Mun, which should not only solve your escape issue, but may also give you a free-return trajectory too. (Slingshot back to Kerbin). Chances are however, you may need to use some normal/Anti-normal (pink triangles) as well to line up on the equator for that to work properly. We can't tell from the screenshot if the current problem is off the Mun's orbital plane, but I suspect it is. (ie: Your escape is slinging you up or down away from the plane that the Mun orbits)
The other radial to the right should give you a Pe behind the Mun as it passes, and that'll probably aggravate your escape slingshot. However if you burn retro at that Pe to get captured by the Mun, it doesn't matter so much.
-
Probably to maintain consistency with the usual mapping for the pitch axis. (Forward = Nose Down).
If you don't like it that way however, you can always remap the keys in the controls settings.
-
The Weighted Thrust averaging formula is incorrect. You need to figure out the full Thrust, and the full mDot of all your engines and run it through the ISP formula, or use an mDot weighted average.;
Check here.
-
1. delta V corresponds to how far your vehicle can travel which roughly translates into how much fuel you've got.
2. TWR corresponds to how much you can lift at once and corresponds to how many engines you have.
So to fixup a rocket:
More Distance = More Delta V = More Fuel/Efficiency
More Lifting Power = Thrust:Weight Ratio = More/Stronger Engines
It's not entirely unlike a car, but one level up...
Delta-V is like the Range of a car, how far it can go on a tank of gas. But instead of a car measuring KM's, you're measuring a change in speed or velocity, hence the V.
ISP is like the MPG, or L/100km in a car. It's a measure of fuel efficiency of the motor. The higher the ISP, the more Delta-V that motor can squeeze out of a L of fuel.
And where you might look at how fast a car can go in km/h to get from A to B in x time, the Thrust of a rocket motor plays into how fast it can accelerate to the Velocity you need to get somewhere.
You can also check here for math, and explanations, including how to solve ISP for a mix of engines. (I recommend against the Thrust Weighted formula from the Wiki tutorial.)
-
If you make an ejection burn while very far out from Kerbin, you will not be able to utilize the gravity well(Oberth Effect) to make your ejection burn as efficient as possible. I don't know for sure if that's correct(haven't done maths), but that's what I'd guesstimate.
The flip side to this is that refueling that far out in the SOI, you shouldn't need much Delta-V to complete an escape burn anyways, and you start it with a full tank of gas. So you're craft should leave the SOI with about an extra 1km/s delta-V.
However, that also has to be measured off against the risk that your orbital period that far out is about 31 kerbin days...so what is the risk that your interplanetary transfer window can open and close in that amount of time if your tanker is in the wrong position for the transfer burn?
-
The upshot of having a refueling base on the Mun, is that you don't need to worry about getting more fuel shipped in from elsewhere. So it would make more sense to leave the station as is, and let the landers do the inclination adjustments. Bulk them up a bit if you need to pack on the extra 1km/s or so they'll need for a round trip with payload. Who cares if they use a little extra gas...they can top up when they get back to the base, and then fill cargoes. How much are the arrivals (presumably larger ships) at the station going to need to get back on the transfer plane once they're done collecting their cargos?
-
Determining the orbital period is part of the process, but depending on the size of the orbit, it can be much less than half the time. LPO orbits are close enough that it's around half, but out at a semi or Geo Stationary, it can be a lot less.
So, it helps to split the planet, and orbit down the middle and do some quick trig...
The Semi-Major axis from the centre of the planet, to the orbit of your satellite, as AncientAstronaut described is your hypotenuse side and the shadow zone forms a right angle that can be only as wide as the planet's radius...so 600km. Take the sin of that angle, and you'll have 1/2 of the orbit angle that will be spent in darkness. Double the angle for the other side of the planet, and you'll have a full angle out of 360, which will give you the proper fraction of your orbit in darkness.
So, LKO orbit at 80km + R 600km, = aSin (600/680) = ~62 degrees, double for the other side of the planet for 124/360 degrees times 31min orbital period and we're closer to 11 minutes.
At KSO, with SA around 2868km = 3468km. aSin (600/3468) = 10 degrees, so 20/360 of 6 hours will give us 20 minutes in darkness.
-
One thing to note about doing the calculations is that you have to apply some common sense to it. For example, RCS tanks have a wet and dry mass, but they would not apply into the DeltaV calculation for your main engines...they MAY constitute a slight reserve of DeltaV is you got in a pinch, but mostly they're for maneuvering.
I personally like doing the calculations myself for that reason....knowing where the numbers are coming from provides confidence to my estimates. And then I build large spreadsheets to assist the process, although there are some available around here for download that other people have built.
-
You do realize at this point we're really just arguing the minutia...
Squad, where are you guys?
in KSP1 Discussion
Posted
Let's all keep it cool, civil, take a few chill pills and relax.
And if you have a legitimate bug, that you can reliably reproduce, then by all means, file a proper bug report.
In fact, Harvester even mentioned that in the response that was already noted at the beginning of this thread, including a step by step test people can go through to test the new SAS behavior, how it is, and isn't supposed to work, and steps to ensure your install is working properly.