<ProjectThoth>
Bornholio: Nono, like strapping an outboard motor to it and sailing it back.
<ProjectThoth>
(but fantastic video!)
<Bornholio>
we will get more of those if SLS flies
<ProjectThoth>
I also have yet to find anything about mid-air recovery of complete stages.
<Bornholio>
mid air recovery of final stages though
<ProjectThoth>
I mean, the largest gliders (in the US) were about 18,000 lbs, which is Delta-II class right there.
<ProjectThoth>
Bornholio: I'm imagining, like, taking a C-130 and grappling a stage that's gliding towards the ocean in order to extend its glide back to land.
<ProjectThoth>
Not actually an idea of merit, just a stupid thought I wanted to explore.
<Bornholio>
ESA is planning a turboprop fly back stage
<ProjectThoth>
ADELINE, yes?
<ProjectThoth>
I mean, you could add engines to the thing, but I'd imagine that that only becomes efficient for larger rockets.
<ProjectThoth>
And, well, it's certainly not perfect.
<ProjectThoth>
Given a choice, I'd rather do a boostback/shallow-up to achieve RTLS with a gliding stage.
<Bornholio>
I think that just recovering engines is also a good idea, works very good in a few of my careers for saving the bulk of the money
<Bornholio>
put all the money items in a boat tail and add 'chutes
<ProjectThoth>
Of course, turboprops and regular avgas would be way more efficient for the same task.
<ProjectThoth>
Bornholio: Oh, no, I agree that engine recovery is a great way to save cash.
<ProjectThoth>
I do like full stage reuse, though.
<ProjectThoth>
Huh, the Breguet equation's a thing, and it looks a lot like the ideal rocket equation.
<ProjectThoth>
That's... interesting.
<Bornholio>
cause it is :P
<Bornholio>
just adding drag
<ProjectThoth>
Bornholio: That's the coolest shit ever.
<Bornholio>
like the rocket equation its over simple, but still gives a useful engineering approximation
<ProjectThoth>
(I don't get out much, to be fair)
<ProjectThoth>
This is fantastic, I have a new toy to play with.
<ProjectThoth>
Bornholio: Before I got distracted by midterms, this was a question I was trying to answer.
<ProjectThoth>
Basically comparing boostback to flyback, in terms of payload to orbit.
<ProjectThoth>
The farthest I got was rationalizing gravity drag, assuming a constant pitch-over, as something like 1/2*9.81*burn time (because the magnitude changes at a constant rate, so it's a triangle, yay).
<ProjectThoth>
It's a crude approximation, but I'm all 'bout crude approximations as a first-round study technique.
<Bornholio>
best way to start
<Bornholio>
make each element a black box, then put in the content of the box as you increase complexity
<ProjectThoth>
That's how I made the LV calculator.
<ProjectThoth>
The annoying thing is that there's no standard launch trajectory. I might "borrow" one from Falcon 9, because I can source those pretty reliably.
<ProjectThoth>
Anywhoo, errands to run. \o
ProjectThoth has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
Hohman has quit [Quit: ChatZilla 0.9.93 [Firefox 56.0.1/20171002220106]]
lamont_ has joined #RO
WitchingRaptor is now known as UmbralRaptor
blowfish has joined #RO
Hohman has joined #RO
<taniwha>
who was it that "made" me buy a space mouse?
<taniwha>
got one, and got it working with my input lib :)
<Bornholio>
cool
<taniwha>
(wasn't that hard, had to add relative axis support)
<Bornholio>
Start off with low sensitivity and increase it as you get used to it, better yet dead zone
<taniwha>
needs some deadzones for poor control, but the thing is neat
<taniwha>
hah
<taniwha>
:)
<lamont_>
i hate left handed coordinate systems
<Bornholio>
lol
<taniwha>
lamont_: you and me both
<lamont_>
taniwha: you were incorrect about GetOrbitalStateVectorsAtUT, the velocity needs to be de-frame-rotated
<taniwha>
eh?
<taniwha>
hmm
<Bornholio>
taniwhat the input machine you made is 'nix only?
<lamont_>
yeah same vectors you feed into UpdateFromStateVectors come out of GetOrbitalStateVectorsAtUT for the same time
<taniwha>
yeah
<lamont_>
anyway i got my inverse rotation problems sorted out
<taniwha>
I think one of us (very likely me) got confused as to which one you needed :)
<taniwha>
cool :)
<lamont_>
gonna throw it up on a blog as well, and i’ve been posting it on the forums, since otherwise info about it is close to nil:
<lamont_>
i may be able to fix a very old PR of mine to try to add an arbitrary-orbit-constructor to kOS as well
<taniwha>
arbitrary orbit constructor? ie, specify ephemerides, get an orbit object?
<taniwha>
use SetOrbit
<taniwha>
or the appropriate constructor
<taniwha>
several ways to do it, really
<lamont_>
yeah just an API so that kOS can call Orbit.new with keplerian elements or r+v
<taniwha>
(and I did put effort into making it easy)
<lamont_>
it was actually a really easy patch, but the way i tried to test it was by trying to construct a KEOsynch orbit over KSC while the vessel was on the pad, so i got inverse rotation trolled
<taniwha>
ah, yeah
<lamont_>
that blocked it because my tests failed
<taniwha>
inverse rotation is a necessary evil
<taniwha>
removes the need to rotate the PQS every frame
<lamont_>
hmmm, i figured it had to do with keeping physics local to the frame of the vessel
<taniwha>
a bit of both, I think
<taniwha>
my memory is a bit fuzzy (I asked about it myself)
<lamont_>
i might have just been putting in the same bucket as krakenstuff
<blowfish>
taniwha: for what it's worth, I think I might make MM compile all its patches first, even if it initially doesn't provide any performance benefit
<lamont_>
(i figured that there was a good game engine reason for it, otherwise it would just be the most pointless and annoying thing ever…)
<blowfish>
because it allows me to break up ModuleManager's biggest (500 lines!) method and reasonably unit test the functionality
<taniwha>
blowfish: and then feed configs through the "program"?
<blowfish>
yeah
<taniwha>
yeah, that's what I was trying to suggest the other day
<lamont_>
how are you unit testing C#?
<blowfish>
how are you not unit testing C#?
<blowfish>
:D
<lamont_>
painfully
<lamont_>
i tried looking at xunit but couldn’t find the correct incantations to make it work on my mac or any examples
<taniwha>
lamont_: you can provide fake Unity modules if necessary
<taniwha>
and just write unit tests by hand (what I do)
<blowfish>
you can't unit test Unity objects
<taniwha>
and run as a standalone exe
<blowfish>
but you can test against other things in Assembly-CSharp
<lamont_>
yeah i don’t want to test unity objects tho, i just want to test mechjeb objects
<lamont_>
although i guess i don’t know what those inherit from ultimately…
<blowfish>
anything that inherits from UnityEngine.Object is off limits
<taniwha>
lamont_: blowfish: you can provide fake Unity objects to allow you to test the non-unity specific bits of your code
<lamont_>
if i have to i can extract objects that do the work from the modules that integrate with KSP+MJ
<blowfish>
lamont_: I have some examples in B9PartSwitch and ModuleManager (dev branch) now if you want to take a look
<taniwha>
blowfish: I've done it :)
<lamont_>
yeah totes
<lamont_>
ah i see
<taniwha>
eg, create a UnityEngine namespace with the objects you need stubbed out with the minimum to get your unit test working
<blowfish>
taniwha: doesn't that require compiling against different things for your tests?
<taniwha>
I went as far as Object, GameObject and MonoBehaviour
<taniwha>
blowfish: yes, and?
<blowfish>
ehh, seems risky
<taniwha>
they're unit tests, not system tests
<blowfish>
I've managed to unit test a lot without interacting with Unity
<taniwha>
my actual tests didn't involve the unity objects, but I needed them to compile
<blowfish>
if you're not actually instantiating any Unity objects, you can do it with the real UnityEngine.dll
<taniwha>
(because some of the stuff I was testing touched unity stuff indirectly)
<blowfish>
ModuleManager is nice because the things it deals with, ConfigNode, UrlConfig, etc are all not Unity objects
<lamont_>
what we’ve done at work is create entire mock servers that replicate the behavior of servers (which are tested with the same test suite which is applied to the real servers) and then we test our client code with that. the mock server has no state, has poor O(n) behavior, would be way too slow for production, and has no authentication and authorization, and no parallelization, but its easy to fire up in-memory to hammer on with tests
<taniwha>
blowfish: yeah
<taniwha>
lamont_: yeah, I've done similar
<lamont_>
so the idea of writing a testing library of mocked unity objects seems pretty reasonable to me, actually...
<blowfish>
you have to basically re-implement any functionality you depend on though
<taniwha>
yeah. it's not free, but it can be worth it
<blowfish>
ah, if only Unity properly abstracted things behind interfaces
<taniwha>
does C++ do interfaces?
<blowfish>
not sure
<taniwha>
I know it did not in the past
<taniwha>
(it took me a long time to wrap my head around the concept of protocols in objective-c)
<taniwha>
but since I did, C# interfaces were easy :)
<lamont_>
C++ has multiple inheritence and virtual functions + base classes
<blowfish>
lamont_: I'm partial to the xunit + nsubstitute combitation, but there are definitely others that work. If you have any questions about the unit tests I've written feel free to ask
<lamont_>
i think i’ll have to just check that repo out at some point and try to figure out how to get xunit running on it
<lamont_>
(i’m on mac and use vim + make as my IDE ‘cuz i like hard mode)
<blowfish>
it's mostly as simple as adding it as a NuGet dependency
<blowfish>
lamont_: I can run the tests on my (OSX) laptop too
<lamont_>
i tried that one point…
<blowfish>
and my Linux CI environment
<lamont_>
okay
<lamont_>
i didn’t see anything in the makefile there
<blowfish>
note, you do need to install the xunit.runner.console package
<blowfish>
also, worth noting
<blowfish>
there may be some issues with DLL signing if you
<blowfish>
you're reference includes the entire managed/ directory from KSP
<blowfish>
reference path, sorry
<blowfish>
the solution I found is to reference a directory that only includes the DLLs you actually need (Assembly-CSharp, UnityEngine, maybe Assemmbly-Csharp-FirstPass and UnityEngine.UI)
<lamont_>
heh and i found your .travis.yml that calls bin/test…
<blowfish>
yup
<lamont_>
yeah that’s probably got all the missing bits i was looking for in there somewhere if i go looking
lamont_ has quit [Quit: lamont_]
lamont_ has joined #RO
lamont_ has quit [Client Quit]
lamont_ has joined #RO
lamont_ has quit [Client Quit]
lamont_ has joined #RO
lamont_ has quit [Client Quit]
Jack-o-Melon has joined #RO
blowfish has quit [Quit: Leaving]
Shoe17 has joined #RO
Senshi has joined #RO
lamont_ has joined #RO
Theysen has joined #RO
<Theysen>
o/
<Theysen>
I think I go crazy, I seem to have forgotten how to calculate the fuel ratios out of engine data .. I get the m_dot from ISP and thrust, i have 2.5 F/O ratio and all I remember the ratios are per unit per second where a unit was a liter?
<Theysen>
I looked at existing ones for e.g. the SSME and can't reverse it either
lamont_ has quit [Quit: lamont_]
ProjectThoth has joined #RO
Rokker has quit [Quit: Connection closed for inactivity]
TM1978m has quit [Remote host closed the connection]
ProjectThoth has quit [Quit: +++out of cheese error+++]
Jack-o-Melon has quit [Ping timeout: 183 seconds]
ferram4 has quit [Ping timeout: 383 seconds]
<Theysen>
alright nvnm, Phineas Freak's fuel calculator offered me a look into the math behind it, back on course now :)
Shoe17 has quit [Quit: Connection closed for inactivity]
Theysen has quit [Quit: Leaving]
Hypergolic_Skunk has joined #RO
ferram4 has joined #RO
schnobs has joined #RO
R1s1ngPhoeniX has joined #RO
Mo-Zeroth has quit [Ping timeout: 186 seconds]
Shoe17 has joined #RO
<Probus>
Has anyone had the problem of your launch clamps disappearing at the moment of launch using kOS?
<Probus>
I love the sheer amount of engines on that thing.
<schnobs>
It's supposed to be, quote, "51 propulsion motors including 12 swivel-mounted rocket units for steering". Can't do that on stock scale, though.
<Probus>
Isn't that the one that von Braun presented?
<schnobs>
yep.
<schnobs>
However, as I'll need proctanks anyway for the transfer vessels, I thought I might go full scale and do it in RSS. Stock engine performance would be about right.
<Probus>
Now that's a challenge! Get that thing working in RO.
<schnobs>
Not RO, that would be over the top.
<schnobs>
It's a funny coincidence that stock parts line up pretty well with von braun's 1950 assumption. ISP and mass ratios are in the KSP ballpark.
QuantumSwag has joined #RO
<schnobs>
FAR should make it more controllable, because it accounts for the conic fuselage.
<schnobs>
However, I'd have to give Mars a pre-Mariner atmosphere. No idea how involved that would be.
<Probus>
You should put a link to the .craft file and we can all try to get it working in RO.
<schnobs>
And if you want it to work on RSS scales, you very much need Proc tanks. Takeoff mass was supposed to be ~6500t, bottom diameter 20m (with ~215m² of nozzle area)
<schnobs>
And, asking only half in jest: can one call it "reenactment" if the original only ever existed as drawings?
<schnobs>
It's mind-bogglingly big even by Saturn standards. And everything is recoverable, of course.
<schnobs>
The Mars mission called for 950 launches over the course of nine months or so. A fleet of 50 of these shuttles, with a turn-around time of ten days.
<schnobs>
Every launch carrying 40t to orbit.
<schnobs>
Pull out the compar-a-tron and weep.
<Probus>
Being in the maintenance/test side of engineering, a 10 day turn is inconceivable.
<Probus>
I wonder what the turn around time on the Falcon 9 is right now.
<Hohman>
I'm always tickled by the idea that we were just going to have umpteen billion gallons of nitric acid and hydrazine just... sitting there. Ready to go.
R1s1ngPhoeniX has quit [Quit: R1s1ngPhoeniX]
<schnobs>
Yeah, that painting gives you a nice feel of just how huge the tanks are. And then you notice the pointers saying "Nitric Acid" and "Hydrazine" as if it was soda.
BadInternetCo has joined #RO
BadRocketsCo has quit [Ping timeout: 200 seconds]
<schnobs>
hmmm. Is there any reason why 1.3 proctanks should cease to work in 1.3.1?
egg is now known as egg|tea|egg
BadInternetCo has quit [Ping timeout: 383 seconds]
<xShadowx>
didnt Sigma88 make a mod for multiple stars o.o
<xShadowx>
concept doesnt seem new
<Probus>
The only thing new about this is the number of stars and their proximity.
<schnobs>
Sorry for asking a FAQ, but what's the state of RSS/RO/RP-x development wrt the current KSP version? Can one expect it to drop Real Soon Now (TM) or will it be a while?
<schnobs>
(Right now I'm interested mostly in plain RSS, not even RO)
<Bornholio>
probably a while, have a chat with awang though he has dlls working for a lot of 1.3 RO maybe he's gone over to 1.3.1
<Bornholio>
also ask PhineasFreak on git if he would compile a 1.3.1 dll for you in an issue, cause sharing is caring
<schnobs>
Bornholio: Thanks.
Senshi has quit [Quit: Leaving.]
<schnobs>
Bornholio: in case you missed it earlier, the reason is that I want to do a 1950s Mars mission. Stock engine stats and masses are fine for the purpose :)
Jack-o-Melon has quit [Read error: Connection reset by peer]
Jack-o-Melon has joined #RO
TM1978m has joined #RO
ProjectThoth has joined #RO
VanDisaster has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
VanDisaster has joined #RO
<ProjectThoth>
Hmm, the flyback problem is annoying.
<ProjectThoth>
Problem is that adding any mass of fuel for flyback is going to influence the burnout velocity+position of the stage.
<ProjectThoth>
There's probably a place where they converge, but I'm not sure where...
<Bornholio>
they need to be treated the same way as 'chutes, legs, gridfins etc. for insertion, then aero kicks in, then at a drag reduced speed you start the return flight mode. If possible they should be run at optimal cruise speed on a psuedo glide path.
<soundnfury>
shirley you just have to produce an equation (downrange distance of landing point as a function of time-of-MECO) and solve for zero
<soundnfury>
heck the functions are probably well-behaved enough for a Newton's Method solution
<ProjectThoth>
Yeah, that equation's the tricky part.
<ProjectThoth>
I was attempting to come up with a more general-case solution (ripping off F9's trajectory, calculating gravity losses across that to get the "true" magnitude of the thing's velocity, using the pitch angle to solve for the landing position).
<ProjectThoth>
The issue with that is trying to rationalize start TWR and burn time into that mess, because a higher TWR means the graph of gravity losses shrinks. And a cut-off burn time would alter the graph in its own way.
<ProjectThoth>
I have a suspicion that it's a triangle with a shape determined by TWR.
<ProjectThoth>
And the area is, somehow, a function of burn time.
<ProjectThoth>
(I'm also assuming a constant pitch angle change here, that might not be valid)
qwertyy has joined #RO
qwertyy_ has quit [Ping timeout: 204 seconds]
<soundnfury>
ProjectThoth: I expect the actual trajectory comes from a calculus-of-variations optimisation
soundnfury is now known as soundnfury|COOK
<ProjectThoth>
soundnfury|COOK: Ye, which is why I was just going to rip one off as a starting point.
<ProjectThoth>
Another issue is that the trajectory is determined by altitude moreso than velocity, which makes shaping the gravity loss graph... interesting.
<ProjectThoth>
So somehow this has to account for altitude, after which there's a "runout" period where the pitch angle is constant or near-90 degrees enough to be ignored.
<ProjectThoth>
I'm sure there's probably a way to do it, I'm just not bright enough.
<Tyaedalis>
howdy, all. I'm testing out the current state of RP-0's dev branch (RP-1?). I've run into a big problem that probably just hasn't been implemented yet: engine upgrades are unavailable even after purchasing the upgrades through the R&D Center. Just wondering if there's something wrong with my setup or if it just hasn't been completed yet. Thanks!
blowfish has joined #RO
Hypergolic_Skunk has quit [Quit: Connection closed for inactivity]