ElWanderer
-
Posts
397 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by ElWanderer
-
-
This makes me very happy. I guess the work lights will be good for setting up screenshots
-
4500m/s for Kerbin orbit is indeed out of date.
However, ejection from Kerbin to another body involves adding together two or three numbers: the amount to leave Kerbin's sphere of influence plus the amount to intercept the desired body, plus (potentially) the worst case inclination change value
Personally I would use Alexmoon's transfer planner website to find out how much delta-v is required for the specific transfer you'll be doing. It can vary quite a bit depending on the relative positions of the bodies and whether you need a big inclination change or not.
-
My current career is the first time I've visited Eeloo, Dres and landed on Moho (rather than flying past it at ludicrous speed). I've not done a return to orbit from Eve's surface, but I'm not sure I have a strong yearning to do that.
On the other hand, I've often wanted to install Realism Overhaul/RSS/RP-something, but never had the time (and not sure how well it would run on my PC).
-
I finally managed to get a good transfer burn to Moho, such that I could circularise with plenty of delta-v leftover. My previous efforts have either missed the planet entirely or flown-by at such velocity that I didn't have enough delta-v to enter orbit.
Having made orbit for the first time, I flew over the Mohole for the first time, then landed a probe for the first time. I'm now wondering if I have enough delta-v to do a sub-orbital hop that'd take me into the Mohole itself. That'd be one way to dispose of the lander!
-
1 hour ago, DerekL1963 said:
Testing an Apollo style Munar mission... While approaching to dock, accidentally separated my CM, which shot across the gap and docked as pretty as you please.
I've done that too many times
I wish there was a special stage lock that prevents a heat shield from being uncovered unless you're on a re-entry trajectory.
-
Just to add that you'd use a ! to negate the check i.e. anything that tries to add in a kOS processor module should be checking that there isn't already one.
Something like kos-for-all goes through all parts with the Command module, adding kOSProcessor if there isn't already one. I imagine it would be harder to find examples where the check isn't done properly (if at all).
-
You left ten days early? That's an age when trying to intercept Moho.
If you have tons of delta-v you can get into a phasing orbit (match part of your orbit with Mojo's, then put a manoeuvre node at that point and adjust your orbital period until you meet Moho at that point in some future orbit). I've done this but not very well - my last visit to Moho involved shooting past at 4.3km/s when I only had 3km/s left in the tank.
I've heard getting an Eve assist is a good way of saving delta-v.
-
Warping through a sphere of influence change at too high a time multiplication used to cause all sorts of issues.
I know this was partially solved by slowing the warp down to x50 for the transition, but I don't know if the underlying issue was ever tackled.
-
KSP's delta-v calculation (which defaults to sea-level) says about 700m/s instead of the 4.5km/s that KER is displaying, which also ties in with the Isp and thrust being awful in an atmosphere.
The other thing to check is whether the engine needs a lot of time to spool up to full thrust. I usually stage the engine first, then the docking clamps. Admittedly, very few stock engines spool, but it is good practice to avoid dropping launchers onto the pad! -
On 7/7/2020 at 8:12 PM, Soda Popinski said:
I asked if there were any issues with 1.10 on /r/kos, and got a reply that it's broken. Not a lot of details, unfortunately.
Ah, that's not too helpful.
I've just run a simple orbit and back script in v1.10 and didn't encounter any problems.
-
In Steam, you can "downgrade" to an earlier version that RSS/etc. supports. I think it's the opt-in beta section and you'll probably want v1.8.
Once you've downgraded, take a copy of the whole KSP folder in the Steamapps directory. You can then opt back out of the older version in Steam, keep the main install as a clean, up to date, stock version and go to town on the v1.8 (or whatever) copy with as many mods as you dare.
-
By enlarging the rocket, have you gone over the mass limit for the avionics you are using?
"In RP-0, avionics units have a maximum amount of mass they can control."
https://github.com/KSP-RO/RP-0/wiki/Procedural-Avionics
I would expect RP-1 to be similar.
-
55 minutes ago, Soda Popinski said:
I heard kOS doesn't fully work with 1.10. Anybody know what specifically isn't working? Or is it completely broken?
No one has reported anything as far as I'm aware and there aren't new issues on GitHub: https://github.com/KSP-KOS/KOS/issues
However, I don't think anyone can say it works perfectly and there were some statements in the change log for v1.10 that had the potential to cause small breakages.
It'd be interesting to know what you've heard.
-
Yes, ideally.
With SAS disengaged, your rocket should just follow surface prograde, which will lower towards the horizon as you go (the Wikipedia page for gravity turn tries to explain this, though I'm not sure it does a great job).
It's diverting from surface prograde that will produce aerodynamic effects that could flip the rocket, unless you can counter them.
With the right initial turn, you don't need to steer away from prograde at all, or at least until you're high enough that it doesn't matter.
Personally, I can't be faffed with getting the right initial turn for each design, so I use gimballed engines to retain control authority (and add small fins to prevent flipping). I am aware this leads to launches that are not as efficient as they could be.
-
The reliant engine has no gimbal, which means you only have the (admittedly overpowered) reaction wheels in the pod with which to steer.
Using the LVT-45 Swivel instead means you have an engine with gimbal, that will make your craft easier to steer. However, the Swivel has lower thrust which you'll have to make up to get off the pad, possibly with strap-on boosters.
You say your liftoff TWR is about 1.25, which is quite low and it'll only rise slowly as you have a lot of fuel to get through in that first stage. That means your flight profile needs to loft the rocket quite high - turning too much/too soon will result in you being horizontal way too low. The reaction wheels won't be enough to help lift the nose to maintain the trajectory you need. As such, it's probably very sensitive to how you manoeuvre at low altitude.
-
4 hours ago, Jacke said:
Obligatory XKCD
Is it sad that I am giggling at that even though I've not clicked on it?
Just add a config option to re-enable space-bar heating...
-
11 hours ago, ManEatingApe said:
I'm trying to use the the POSITIONAT function to calculate the relative position of planets for transfer planning purposes.
When using it with planets the values returned are correct, however the values returned for moons seem a little wonky.
// Pass: Prints constant 13599840256 as expected
relativeDistance(kerbin).
// Fail: Prints changing value e.g. 9337055 that is not 12000000
relativeDistance(mun).
// Pass: Print constant 21783187949 that seems plausible
relativeDistance(duna).
// Fail: Prints changing value e.g. 5489455 instead of 3200000
relativeDistance(ike).
// Pass: Print constant 65353911824 that seems plausible
relativeDistance(jool).
// Fail: Prints changing value e.g. 29352791 instead of 27184000
relativeDistance(laythe).
// Fail: Prints changing value e.g. 70651219 instead of 68500000
relativeDistance(tylo).local function relativeDistance {
parameter planet.print planet:name + " " + round((positionat(planet, 0) - positionat(planet:orbit:body, 0)):mag).
}Moons are indeed weird (though I thought this was only the case when you are orbiting their parent). When you ask for their position vector, it is (I think) relative to the parent body (and so you just need to subtract the parent body's current position vector). This is my position vector function:
FUNCTION posAt { PARAMETER c, u_time. LOCAL b IS ORBITAT(c,u_time):BODY. LOCAL p IS POSITIONAT(c, u_time). IF BODY <> SUN AND c = SHIP AND b:HASBODY AND b:BODY = BODY { SET p TO p - POSITIONAT(b,u_time). } ELSE { SET p TO p - b:POSITION. } RETURN p. }
Now to see if I documented exactly why I have those checks.
Looks like I didn't. Bother. I do remember being wildly confused for quite a while before I got something that worked, mostly through trial and error.
-
4 hours ago, infinite_monkey said:
I have an annoying issue, not sure if it can be solved: some keyboard entries are not catched by the kOS terminal and toggle other screens. Most notably, since I just installed probe control coom, "c" switches camera to the control room. Or (on German Keyboard it's Alt Gr + 0) "}" toggles EVE settings. Is there a way to get around this?
It's a known issue: https://github.com/KSP-KOS/KOS/issues/2659
The best way around it is probably to write your code outside of kOS (which is generally preferred anyway) and avoid typing in the terminal (which makes it hard to test code).
-
If you're still trying to work out timing, I'm pretty happy with my solution. Here's a link to my documentation where I go through my launch azimuth/ETA calculations:
-
8 hours ago, Zeiss Ikon said:
there's a decoupler between with crossfeed disabled
The display is showing two different TWRs against two stages, the first of which has no delta-v. I think it is assuming you are going to decouple the extra mass before burning, giving you a TWR over 2 and 4.2km/s delta-v, but actually your TWR is more like 1.7 and your delta-v will be correspondingly lower.
It doesn't know when you intend to fire that decoupler, though you may be able to help it by moving it about in the staging menu.
-
On 9/25/2019 at 9:42 PM, RizzoTheRat said:
Hi foilks. Is there some oddity with the way stage:liquidfuel is calculated
Yes.
kOS was changed a fair while ago and this behaviour became really noticeable (reporting 0 fuel, or fuel within SRBs that aren't firing, for a stage), but my understanding is that it matches the way KSP itself calculates it.
Trying turning on the resources view in KSP and tick the "stage only" (from memory) box. See if that reports any fuel at the time kOS says it is zero.
It's something to do with confusion as to what is in a stage. I tend to notice it when I have sepratrons that will fire on stage separation, that are attached to the stage that will be discarded.
-
10 hours ago, Martin911 said:
Hi guys i need help with KOS please getting errors, undefined variable print "Launch Time: T" + round(missionT - launchcht) if anyone could help please.
Well, the simple response is: where is missionT defined?
However, the code you've printed is full of variables and function calls that aren't defined anywhere that we can see. missionT is just the first of many such problems and fixing them one-by-one would be quite painful. Is your code meant to be loading libraries that define those variables and functions? If so, those libraries need to be run at the top of your script, to load in all the bits you are dependent on.
-
Safety is also an important consideration. You can't just put yourself on a (near-)collision course with a view to matching velocities once close - what if your vehicle loses control in the meantime and can't change velocity? Approaches to the ISS are failsafe in that if the engines fail, there won't be a crash, but this means making multiple small correction burns to get close.
-
Orbits are stored internally in that format (e.g. that's what you see inside the save file), which is why I guess the cheat menu gets you to enter those values rather than Ap/Pe and calculate the SMA/ECC for you.
https://en.m.wikipedia.org/wiki/Orbital_elements
(see the section on Keplerian orbital elements)
[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System
in KSP1 Mod Releases
Posted
This is how I do it:
FUNCTION launchSteerUpdate { LOCAL cur_v IS SHIP:VELOCITY:SURFACE. LOCAL new_v IS HEADING(launchBearing(),launchPitch()):VECTOR. LOCAL max_ang IS launchMaxSteer(). // returns different values depending on height/velocity IF VANG(cur_v,new_v) > max_ang { // limits the maximum angle between our surface velocity vector // and where we are aiming to steer SET new_v TO ANGLEAXIS(max_ang,VCRS(cur_v,new_v)) * cur_v. } SET LCH_VEC TO new_v. // LCH_VEC is a global where I store the vector I want to steer to }