surge's kos orbital library Activity
Various orbital physics tools written in kOS for Kerbal Space Program
Status: Beta
Brought to you by:
surge
Activity for surge's kos orbital library
-
Stäphen Goedzal committed [r105] on Code
-Changes for new version of kOS (1.4.0)
-
surge's kos orbital library released /obtlib-0.7.zip
-
obtlib-0.7
-
obtlib 0.7 release
-
-pre release cleanup & checking
-
-Fixed missing radius from Chlamydia system
-
-
-Quck fix for eccentricity vector wrong way around in tcm
-
-Fixed tcm loop screwup in mission_flymetothemun
-
dock.ks tries to kill us
-
Testing completed. r97 should be better or at least not deadly.
-
Some of the errors may have been caused by slightly inaccurate R2 vectors fed into the lambert solver. r97 has this fixed and tested. It is still slightly off but as mentioned above it's most probably caused by having to "guess" V2 (hyperbolic velocity).
-
Some of the errors may have been cause by slightly inaccurate R2 vectors fed into the lambert solver. r97 has this fixed and tested. It is still slightly off but as mentioned above it's most probably caused by having to "guess" V2 (hyperbolic velocity).
-
-Fixed missing "\"" in return.ks, some cleanup.
-
There is still no simple way to tell the width, let alone the CFD/"shape" of a body
-
Launch system with Vgo
-
Implemented in lagsav.ks, r95. It measures vertical speed and corrects with static and dynamic pressure, which is really the problem here.
-
-Tried to fix a problem with pre-selected wrong size docking ports in dock.ks
-
-Synced peeklog()/LEG in some mission_* programmes.
-
r94:
-
surftarg.ks seems to have problems with fast rotating bodies
-
r93 published
-
-fixed sign error in launchFindNextInc()
-
R93 has potentially fixed this. Iteration process was inspected. Yet to be uploaded.
-
surftarg.ks seems to have problems with fast rotating bodies
-
R93 has potentially fixed this. Yet to be uploaded.
-
xnode still uses a parameter for warping
-
SCOTTY has been assumed a global or ignored. ALIGNT has been conditionally queried.
-
-intercept.ks efficiency fixes and corrections.
-
dock.ks tries to kill us
-
Potentially fixed in r91. Requires more checking.
-
Launch system with Vgo
-
surftarg.ks seems to have problems with fast rotating bodies
-
-Updated Mb0R1 Chlamydia to use peeklog()/pushlog()
-
update lamberSolvers to return lexicons
-
It's also possibly caused by the orbit change after the phasing burn. Due to underflow (I guess) this puts the time to burn off by quite a bit. The easiest solution is still to split it up.
-
-derated Mb0R1 Chlamydia to 1.8.1 version. Try not to change it in future!
-
pitchover equation in lagsvs.ks is pretty bad
-
pitchover equation in lagsvs.ks is pretty bad
-
-
Structure is a mess
-
r89 is about as good as we can do, given the piss-poor language we were given. Closing
-
-updated Mb0 Chlamydia to be a unit test.
-
The real problem is that if we managed a trajectory that directly hits the target, there will be explosions and hilarity, but not what we want. We need to vmatch before we get to the target, and within 200m of it.
-
The real problem is that if we managed a trajectory that directly hits the target, there will be explosions and hilarity, but not what we want. We need to vmatch before we get to the target.
-
The real problem is that if we managed a trajectory that directly hits the target, there will be explosions and hilarity, but not what we want. We need to vmatch before we get to the target.
-
r88 moved important files where they should be
-
-
-fixed syntax bug in hs.ks
-
xnode still uses a parameter for warping
-
-
getAltoffset() is confuddled by landing legs and wheels.
-
The fudge factor can be/has been removed. It was partly caused by the hoverslam not accounting for cosine effect. Fixed and partially tested in r85.
-
-
dodgy AF
-
-added peek/poke logging ops to obtlib_mission.ks and a rudimentary
-
We're at the mercy of whatever KSP tells us. If a landing leg is stowed, does it report the unfurled position?? There is a fudge factor in hs.ks that tries to account for this. It causes low mass crafts to waste alot of fuel calmly landing at 1/3 throttle, while 50t monsters smash into the ground. Not good enough.
-
This is a long standing problem caused by the phasing burn not being executed perfecly accurately. Nor should it be. That's why they do "Trajectory Correction Maneuvres" IRL. And why tcm.ks in obtlib exists. Errors in the first burn cause exponential errors in the following nodes.. It turns out we can't chain nodes like intercept.ks does. it needs to be split into something like "phasefor.ks", and the resulting transfer. tcm.ks (if we get it fixed) could potentially handle the final transfer. I see...
-
-cleaned up landnatm.ks, fixed some TGO errors
-
-minor reverts for KSP forum post
-
-added preflight.ks
-
The whole outside 200m rendevous system needs a complete overhaul. Working on it. I really dont want to get into lambert solutions for it though, it is expected the user already get us close enough that we shouldnt need them. I just noticed when it nearly killed us again, (and sped past to over 700m before velocity matching) that it enabled the ILS system and somehow still seemed to aquire a docking port. It took ages to get there, but it was very safe. It didnt use much extra hydrazine (about 4L)...
-
Added iterative recalculation of getAltOffset in hs.ks and landnatm.ks for r83. This seems to help... maybe always? Needs thoughrough testing, especially hs.ks.
-
Added iterative recalculation of getAltOffset in hs.ks and landnatm.ks for r83. This seems to help... maybe always?
-
dock.ks tries to kill us
-
correctout4() seems to be pretty precice, though not very accurate. We can now even run tcm before the periapse! Still working on it...
-
More work on it in recent releases around r83... still needs work.
-
Potentially fixed in upcoming r83 by using fancy maths to calculate acceptable direct transfer angle. I say "fancy", its just (target soi radius/target altitude) *2 :p Untested for bodies outside Kerbin though. Should be close at least. Needs testing.
-
-craft & save update for KSP 1.11.2
-
-added preflight.ks
-
getAltoffset() is confuddled by landing legs and wheels.
-
direct transfer may not be working in intercept.ks
-
dowarp in xnode.ks
-
Fix scheduled for r81
-
r80:
-
tcm from outside target body orbit is not accurate
-
dowarp in xnode.ks
-
-Added mission_mland.ks
-
I just noticed unity only uses 32-bit maths, so it will always be horribly wrong. Recommend only using tcm when closer to the body - it becomes more accurate as you get closer. Most recent attempt achieved 38km from a requested 40km orbit around Minmus. That was run a little over 1/2 way there.
-
I just noticed unity only uses 32-bit maths, so it will always be horribly wrong. Recommend only using tcm when closer to the body - it becomes more accurate as you get closer.
-
tcm from outside target body orbit is not accurate
-
I just noticed unity only uses 32-bit mathematics, so it will always be horribly wrong. Recommend only using tcm when closer to the body - it becomes more accurate as you get closer.
-
guidance after high gate is wobbly
-
r78 includes apollo 11 guidance mathematics in landnatm.ks that fixes this for some situations. Apollo PDG was designed for their rocket only, not ours, so it does not fix all situations. The ultimate goal is a ground-to-ground hop-up mission. I need to add a different bug report for this, but am working on it now.
-
-fixed some throttling logic errors in lagsvs.ks
-
-
-
Caveman
-
r75:
-
11k25 Energia-Buran almost fails
-
It's related to what americans call "dutch roll". i.e. when a massive object gets a small yaw, it's nearly impossible to correct due to inertia... especially near space where aerodynamic forces don't do anything. I've set the top RD0120s to only cut to about 25% instead of off. which seems to fix it The only information I have about what the Energia really did is from https://www.amazon.com/Energiya-Buran-Soviet-Shuttle-Springer-Praxis/dp/0387698485 which just says "the outer RD0120 engines shut...
-
The problem seems to be we cant figure out V2 accurately enough. KSP/kOS might not be able to calculate it well enough - it should be close to 90°,, but not exactly and the furthur away you are, the bigger the error.
-
11k25 Energia-Buran almost fails
-
Structure is a mess
-
reopened. obtlib-design.txt has not been fully implemented.
-
Structure is a mess
-
reopened. no idea why this was closed. WIP
-
Figure out how to do lambertSolver() giving R1,V1,R2,V2 instead of R1,V1,R2,T (because we don't care about time; we never care about time, its space travel, for fucks sake),. That will give a proper normal to the B-plane instead of having to make it up and it should be several orders of magnitude more accurate.
-
Figure out how to do lambertSolver() giving R1,V1,R2,V2 instead of R1,V1,R2,T (because we don't care about time; we never care about time, its space travel, for fucks sake),. That will give a proper normal to the actual B-plane instead of having to make it up and it should be several orders of magnitude more accurate.
1 >
