purpletarget
-
Posts
407 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by purpletarget
-
-
I've generally attributed such things to Coriolis effect, which basically goes back to Sal's original explanation, the planet is turning underneath, plus the angular velocity delta as you gain altitude from the surface. The atmo is probably the main thing that helps keep the ship where it is as long as it does.
Check another experiment sometime, landing on an equatorial plane on Mun, Minimus or some other airless body. Check your hover experiment there, and see what drift you end up with. It'll be easier to see on larger/faster sidereal velocity planets though (Tylo perhaps?).
-
Your video did not include your resources panel. One of the things with early SRB + Pod rockets is that the Pod torque can somewhat handle some of the forces to keep things straight, but once you throttle down the VT, there's no power generation and your torque wheels will loose effectiveness when it runs out of charge.
As was already suggested though, tweaking down the thrust level of the initial boosters will probably do wonders to get you higher and further without as much bending.
-
Yes, this kind of thing would not be supported in KSP natively afaik. An external programmable driver for your joystick, or some other peripheral repeater would be required. You might be able to get away with the functions you seek by mapping the axis on repeats of certain keys and being able to use a shift button to allow a different profile...not very elegant, but may technically be doable with a great amount of patience. However, to actually map to the Axis configurations in the KSP settings, you would need the driver to do the differentiation so that Axis 0, Axis 1, and Axis 0+Button are able to present themselves to KSP as Axis 0, Axis 1, and Axis 2 respectively. (for example)
Not knowing your particular setup or joystick, etc...I can't actually say if such a beast exists. I looked into something similar to try and be able to swtich my X52 to present different axis depending on a mode setting, and eventually came to the conclusion that it wasn't worth my time to bother with it... I didn't feel like reprogramming drivers. But that's just me.
-
Yes, a pic of the craft and readouts, and also it wouldn't hurt to see where it's located. The full output for solar runs on a roughly linear trend depending on the distance from Kerbol.
-
EDIT: @purpletarget. I think he means axis roll, not rolling down the runway.
So it would seem...pay no attention to the brakes then!
-
It's fairly typical behavior as far as I know....generally seems to accompany physics kicking in as the craft gets dropped on the runway.
All I can really recommend, is hitting the parking brakes once you get control, and then take your time with the rest of your pre-flight checks.
-
The previous stable versions are available at the Store, or through opting in through the Beta feature on Steam. As discussed here.
Of course you will still want to backup your saves beforehand, and be careful not to launch into the game without checking to see if it has updated. You won't want to corrupt your saves by accidentally launching into .25. Reverting to Previous on the Beta should keep you in business with .24.2 for a while, until 0.26 anyways.
-
The inclination from the equator of a planet is directly related to the Max/Min latitudes that the ground trace will cover. So, your base at 1 degree 27' N, you will need a minimum inclination of 1 degree 27 minutes (1.45 degrees) for the top / northerly pass of your orbit to touch the latitude of your base....and then you just need to wait for the planet to rotate the base underneath the trace to make your landing.
If you do a higher inclination, then you will end up with 2 chances for the base to pass under the ground trace.....one on the way up, and one on the way down.
If you're on a tight orbit, and just want to change inclination and then land, you want to set your inclination change slightly more than 90 degrees from the base' longitude, so that the burn pushes the top of your orbit to the desired Lat just ahead of where the base is about to rotate under. By the time you get to the top and start to land, the base should be there to meet you.
-
Kerbals have been able to open the panels for a while now. Try it out. Walk a kerbal over to a ship, and right click on the solar panel for the extend option
-
You'd probably have to did out the phase angle calculations for the planets in question.
You'll need to determine the phase angle based and transfer time between Jool and Titan. (Where Titan needs to be when you do Grav assist at Jool)
Then you'll want to calculate the Transfer time & Phase angle between your origin and Jool... (To line up initial transfer to Jool)
You'll need to backing off the time for origin to Jool, and add it to the Jool/Titan phase angle caculation. That'll tell you where Titan/Jool need to be in relation to each other when you leave the origin
The combined times, Origin to Jool, and Jool to Titan will give you the time required, and you should have the relative phase angles that both Jool and Titan need to be in before you leave. Fortunately they're probably so far out that the origin angle (presumably Kerbin) can be cycled 2-3 years before the outer planets get out of the window.
Check here for the equations, mostly in section 1 of Kosmo-ot's guide: http://forum.kerbalspaceprogram.com/threads/16511-Tutorial-Interplanetary-How-To-Guide
-
No, the throttle is linear, and directly affects thrust.
(Caveat - Unless he was using a Mod that changes the way throttle or motors fuel flow works)
-
I just want to remind you guys that even that is broken, in real life the thrust scales with air pressure, not the isp :/
Actually it's both. The ISP increases inverse to the air pressure, and that results in greater thrust, because IRL engines generally maintain a constant fuel mass flow throughout their operation (with a few notable exceptions)
-
I'm also really concerned that the inclusion of the nuke is really driving the entire equation being fit on that chart. If you know anything about regression or statistics, that whole chart and equation (which most of this point seems based on), throws up a lot of red flags.
It probably should. The trendline is based only on the cherry picked engines which are previously assessed as "balanced".
If you run a polynomial trendlines with all the conventional engines (No LV-N), you get a much different picture.
Full trendlines for conventional engines.
Breaking them up by size class also ends up with a bunch of funny lines with no real pattern.
Multi-trendlines, broken down by sizes
Finally, IRL engines...don't really follow any trendlines. It's all just a mish-mashy-mess.
Smattering of IRL engines compared to KSP incl ARM
If we want to take a look at another factor for example, how about how the thrust of an engine relates to the mass...the trendlines aren't nearly as offensive, it's almost like they mostly fit. If anything the 25x4 starts to look too heavy.
Thrust to Mass
Here's another factor where the size-3 ARM engines really don't bother me, ....the 25x4 needs more fuel just to move itself than the smaller ones....yes, even the mainsail. And while the KR-2L needs less fuel than the mainsail in Vac due to a superior ISP, the ASL leaves the Mainsail as requiring slightly less fuel, which ties in with the KR's high atmo area.
ASL Fuel Mass
Vac ISP
These charts are not intended to necessarily prove anything particular about the engines, but merely to demonstrate that there's many ways to make "math" say whatever you want it too....so don't think that just because it's math, that it's beyond dispute.
-
The harm is the obvious unethical use of "being a mod" (If that ended up being the reason the parts were nerfed) having a higher priority in game design decisions as opposed to the community or the internal testing team.
Before anyone carries on running away with the fact that stupid_chris is a mod, it should also be pointed out he's also part of the community. There is nothing unethical about him expressing his opinions in this forum, on the bug tracker, or any place within the KSP team framework to be involved in whatever discussion there is about the game. If his argument and evidence is persuasive enough for the devs to pay attention to it... then chances are that he had a good point.
Unfortunately for him, and possibly bonus for you, the mods run a gambit of opinions not unlike the community at large. So it's not like there aren't other mods who think the engines are mostly fine as is.
I think the LFB might need a slight tweak, but nothing as drastic as most of the nerfing suggestions bring bandied about. It's gimbal range is half, it has no alternator, or a bottom node, and it's got a jumbo stuck to the top that you can't remove! It's not all sunshine and roses. And frankly, once contracts and cost come into play, if it is superior in all other aspects, then I will expect the cost in R&D or production to be suitably adjusted. Balance isn't all about one factor, or all the engines against each other. Between tech and economics, there's plenty of other aspects to consider.
So perhaps the question might be, rather than just automatically calling for the nerf nuke....what other options might exist? What could be changed in the LFB that would present a notable role for it, while preserving a role or niche for the mainsail?
-
Definitely. It can be done but I've found it to be way more trouble than it's really worth. But that's because I probably am doing it wrong
I find for the big ones, I find it's critical. Sending a small probe out for a solar SOI does a few things. (The new ION's are perfect for this, deep space has few shadows)
1. You can get the mass of the asteroid once docked.
2. You can use the probe to plane the capture burns with maneuver nodes in the Kerbin SOI. That will tell you exactly how much dV is required to get it where you want it.
3. Between the two, you can find out how much fuel you need on a capture ship to achieve that dV.
4. Then you can tack on the extra fuel you need to get the ship itself to the RV....and you are less likely to be surprised later by not having enough fuel.
(Trying to do all this during the Kerbin Encounter, is less likely to have time to build, launch and RV with a new ship)
....but maybe that's just me.
-
I'd suggest not trying to rush out and meet one as it's whizzing by. Go out interplanetary and grab one where you have weeks to guide it to an aerobraking pass. Remember, the farther away you start, the easier it is to change the asteroid's trajectory.
Yes.... and solar RV is a whole 'nother conversation.
-
A couple things you can work with:
1. Find an asteroid with a descent Pe around Kerbin. (ie: Not just a grazing pass, you'll have an easier time with something that has at least 1/3 an orbit, if not more)
2. Launch into a co-planar orbit with the Asteroid pass through the Kerbin SOI. (Adjust once in orbit to make your An/Dn close to 0 degrees.
3. Set a maneuver node to push the Ap of your s/c out to somewhere a little before the Pe of the roid. Take a note of the time it will take to get out to Ap.
4. Switch back to Tracking station, and allow asteroid to close with Kerbin. Stop timewarp when the Roid is a little longer to Pe than your Ap transfer time from Step 3.
5. Once within a day to hours, switch back to S/C, and setup a new maneuver (the node from Step 3 will be way out of date), this time target the asteroid and setup an RV. You want to intercept earlier than Pe, because you'll probably need some time to refine the RV and get setup for the capture and burn.
6. On reaching the Ap/intercept with the roid, you'll need to zero the relative target speed. Have lots of dV for this...it's generally at least as much as a circulation burn at the Pe altitude, plus escape velocity, plus the excess velocity the roid had when it came into the SOI.
7. RV is similar to any spacestation or s/c docking, except that you usually only get one shot to intercept before the roid leaves the SOI.
-
Not so much...the action groups are set in the VAB/SPH, and so far are not configurable afterwards (unless you like to try your hand with save file editing).
What can be done, is if you carefully plan out your final ship ahead of time, then each of the components you build can have the action groups set as you built them. So if you want your engines to go on a certain button, set them all when your building each engine cluster before launch. Once assembled, the action groups of each individual component craft remain intact.
-
There's no simple solution to the problem, but it is possible to calculate within a reasonable approximation through iterative calculations if you are handy with a spreadsheet or similar tool for such calculations. If you look here, at ep's 1-2A, 1-2B, and 1-3, you'll see the various equations and steps needed to pre-calculate the numbers. For mine, I just do a 1 second time lapse...not overly accurate but does get a reasonable approximation. The exact number does vary from craft to craft depending on the TWR and various other factors that can affect gravity and atmospheric losses.
-
Because for the first few messages they go to a queue to wait for mod approval.
-
The ASAS model was from an earlier version where the part wasn't a reaction wheel, but simply a set of flight computers to allow SAS functionality (And yes, based on something similar to the pictute, which is all guidance and telemetry gear. Now that functionality is included automatically in all the command pods.
The part has been re-purposed as a reaction wheel...however the skin of the model has not been changed yet to reflect that. I'm sure they'll get around to it...along with all the other parts that need attention, and a 3D modeler/artist to work on it....I seem to recall a job posting being advertised a short while ago.
Remember in KSP, if you try to do real science to stuff in game...you're going to have a bad time.
-
Already in QA!
Everyone should keep in mind that the development process for KSP since about September uses branch testing, which means that the branch of any feature being developed goes into QA right after it's mostly ready. Once it's done the Branch QA, it'll hang out until the integrated QA phase, followed by experimentals (which would be formally announced)
Ted spelled out the process in fine detail here.
All that to say, if they mention QA, it's something that happens mostly continuously through the process, so we needn't get too excited.
If they say something is ready for the experimentals phase...that doesn't mean experimentals is started. An Announcement saying experimentals is started means experimentals is started. (Example from 0.23)
On the other hand....
Another new part is the robotic grappling device, which players will use to snare the rock and redirect it into orbit around the Mun, Kerbin or other planets. This new device can also grab things other than asteroids, making it one of the most versatile parts added to the game.That's a reason to get excited...
-
Yes....you'll loose most of it to drag.
~15 sec at 9.8ms-2 will see about 150m/s lost to gravity alone. With a high TWR of your ship (don't have numbers on me) but you could be easily losing 2-4x as much on air drag as well after you hit terminal velocity.
-
What I found in the approximations was the vertical dV required to get to orbital altitude is ludicrous below 10km, because the air drag for such high velocities is prohibitive. So it never gets within a significant fraction of the horizontal dV to reach orbital velocity. So it makes most sense to put all the effort of the flight into the vertical.
After 10km, two things generally happen.
1) The terminal velocity starts increasing at a rate that any rocket is quickly unable to accelerate to match.
2) The additional dV "Upwards" requirement starts being small enough (and quickly as the rocket ascends) to be within the orders of magnitude to compare properly with the Orbital Velocity requirement on the horizontal. When the shortest path between two points is a straight line, the tangent of these two requirements starts generating an angle that can be used to guide a gravity turn.
There may be some links at The Drawing Board: A library of tutorials and other useful information which may have some further information close to what you're looking for...and/or you can also check the link in my sig for some vids, some of which touch on the series of calculations and how one could approach the problem.
Calculating DV is "hard"??
in KSP1 Discussion
Posted
I've still probably spent more time running the math, or building spreadsheets for KSP than I have actually playing the game. I'm not afraid of a calculator, or my paper and pencil, and I have a notebook filled with scribbled diagrams and equations, and derivations.
I don't use in-game mods.
I see a lot of people suggest using mods to make their life easier, or use other mods to watch "and learn" from the way a computer does it, and then try to emulate it. What I have seen as a result is plenty of people who use rules of thumb about how to do things based on some mod mission profile said so, or something they read on the forum, or saw on a video once. But they don't necessarily understand "Why" something is more efficient, and having coached a few twitch players through some of these follies caused by blindly following these rules of thumb, I believe that understanding the "why", and the underlying equations is very powerful.
It allows for much greater flexibility and success, especially when mods aren't available after updates, or haven't been programmed to solve the actual situation you've discovered yourself in.
So what does actually doing the math assist with? I actually understand the numbers that I see. I know where they came from. And the more I play with the equations, the more I can figure out when to apply them, and when to start breaking the rules....because there are times when radial burns are more efficient than pro-grades, and what autopilots do for inclination changes aren't necessarily optimal either. If you understand the math, then you'll know when inclination changes can benefit from a drastic Ap change...and when it's not.
I calculate and plan out my ships ahead of time with spreadsheets I build. Or in a time crunch I use also use pre-generated dV maps, and an Isp/Mass ratio to dV graph and some head cheese math to build up quick ships from the ground up. Neither of these even require a calculator...the two graphs required are available in the community, and the ratio's are simple enough that if you can divide and multiply in 2's and 10's in your head, you're golden.
Don't fear the math, or a little work... because the pay-offs can be awesome. Do the hard things, until they become easy, and the impossible will become merely difficult...(This is a bit of a life philosophy too, btw)