DBowman

I finished up the Eeloo mission here ... One thing I learned is that the Pe kick and the capture are pretty easy to do with very low TRW. The hard part that also generates a lot of errors / deltaV buffer requirement is the departure burn. How much would it help just doing the easy bits? I compared three options: 16.809 t Just Nuke 13.051 t Nuke & easy Ion 06.474 t Pure Ion I think it would make much more difference for Duna where the post Pe Kick part is relatively much smaller.

@Gilph Think of the starter not as a day to day consumable but like an emergency backup for the ecosystem. If some strain of algae overran, or the pilots accidentally let things get too hot/cold and killed the ecosystem then the starter is used to reestablish things. It gets consumed at about 1/1000 th the rate of the day to day slurry from all the non gas waste. One thing to note is that although in principle the arrays are light driven it's not enforced - the simulation facilities provided by the underlying game engine don't do a good enough job for it to be reliable. You should calculate your 'dark time proportion' and scale up the arrays to compensate. e.g on a planetary surface you should double the nominal rating, in LKO something like 1.33 times depending on the orbit.

Finished up my 'Low mass Eeloo and return with TAC-LS' 17.994 ton on the runway post and some details ... doing it the very low thrust way; 18 Pe kicks and some departure burns

I finished my 'TAC-LS in one launch' mission - 17.994 ton on the runway! The album is here ... Originally I was thinking to do it with solar ion from Kerbin and the rest nuke per my mission dev thread Low TWR missions can be pretty painful to get the maneuver nodes setup. Pe kicks are not too bad, until you have to move them in time. For the departure burn if you make a few nodes then they look nothing like the final trajectory, if you make a lot then it is horrible to manage. So I made some kOS scripts; things like DeltaTimeNodes(), PeKickifyNode(), SplitNode() they let me: - make a reference trajectory to hit Eeloo on a 'marker' probe, then switch to the real vessel target the marker and see it's trajectory, - make the same transfer node - use my script to make many Pe Kick Nodes + one departure node - adjust the last kick to put the departure node at the right point in the orbit - use my script to split the departure node in to many segments - move all the nodes back in time until the whole trajectory best matched the reference trajectory [ http://imgur.com/OR3zwdv.png ] after only 1 burn it still looks tidy, errors creep in though... Since I'd made that all more or less work I thought 'why not just ion the whole thing' - so I re-planed and made a new craft: - add couple small LS cans to cover all the Pe kick time - add 'enough' radial Xe tanks to the capsule for Eeloo capture and return - throw away the nuke and liquid fuel tanks - make a smaller plane to launch it (drag from stage-able wings cost more in drag than lifting a ton of wings to orbit) [ http://imgur.com/7UJluGO.png ] last node of the departure burn [ http://imgur.com/oU16gmp.png ] Eeloo capture - Val has been burning for a long time at 70 mm/s^2 now draining the battery (nearly) with a full thrust 0.5 m/s^2 [ http://imgur.com/PeWtWxq.png ] Eeloo departure burn, wacky or no? I haven't decided if I'm doing something wrong with very very low thrust node plans I thought I had allowed plenty of excess Xe, but turns out I finished with 2% left, so there is still a lot of error/cost in doing the Low TWR burns. The Pe Kick script is pretty easy to work with, so if one just did Pe kicks and capture on ion and the rest high thrust then this mission would have been 2400 m/s LowTWR and 2300 HighTWR - one could pretty easily save a lot of mass that way without much pain. I check in the VAB - PeKick & capture only with ion save 25% mass vs a 17.3 ton pure nuke vacuum vessel.

I'll tidy it up, add some comments, and post it. I can just paste in in this thread I guess.

I had some success getting kOS to help me build very low TWR planetary transfers ( like 0.07 ms2, the craft will run at 15% throttle limited by 2 RTGs) for a low mass Eeloo challenge though sometimes the results look odd, and they are still painful to execute

I've been playing more with kOS to try to make low TWR easy by making some scripts / functions. The plan was: find an initial impulsive transfer burn the usual way; MJ or alexmoon etc write it down in kOS so you can create it over and over have a reference craft in your departure orbit. You can setup the transfer on that and then with your real craft you target it and can see the trajectory - try to make the real low thrust trajectory look like that impulsive one. Split the real burn in two; one part big enough to get an Ap past the Mun and the rest Split the sub escape part into Pe kicks: PeKNodes( 50, 900, 3, ALLNODES[0] ) - this does 4&5 in one step splits the first node into 50 m/s chunks up to 900 m/s starting 3 orbits ahead of now Adjust the last Pe kick node magnitude 'by hand' to get the departure burn to lie over the reference node: DeltaMagNode( 18, -1) - this adjusts prograde, normal, and radial to make the result magnitude 1 less than before (that's right already 19 nodes...) Now the split the departure burn into chunks so you can see the effect of the planet cranking your orbit around Move all the nodes back in time 'by hand' until the resulting trajectory 'looks like' the reference one: DeltaTNodes( -232 ). Adjust the last node here you can see it needs some extra dV: DeltaMagNode( 42, 100 ). All looks good and basically works but: I love MJ but I don't think it burns properly for these kind of craft; it seems to do something 1/3 burn time before and 2/3 after the node. I think it should be 50:50 for these small low TWR low propellant burns. I have to look at that. I love MJ but you cannot physics warp and execute all nodes cause it pops out of physics warp after each node. So right now if you want 'hands off' auto pilot you have to run it in real time. I want to fix that. There is something wrong with my node building logic, at least for very very low thrust. Here is a 6 hour burn plan at 0.08 m/s2 from Eeloo. IT says 0.5 ms2 but it will burn at 15% throttle, limited by 2 RTGs. I should fix this - once I figure out whats wrong, maybe it just looks odd

Nice 'staging' plane, and you landed the nuke (couldn't at first figure what the structural plates were for - leg attachment 'adapters'). I noticed some red line coming from your craft during landing - is that a visualization aid like the aero forces?

Life Support needs more love for sure. Apart from the extra mass the LS consumption complicates dV budgets and you also have to worry about the 6 hour suit EVA limit for any lawn chair landers.

It looks like I can make some good enough low thrust trajectory helper scripts, but enough kOS for a while. @Firemetal I am looking at a single launch. I put this together pretty quickly - basically a plane with a nuke&ion vacuum stage strapped on top. My dV guess for the closed cycle stage was close. Then I added a remote control in case I want to try to land it (which I've never done...) and adjusted the propellant so it should have 'just a little left over'. It flies ok, as long as you throttle limit the lower R.A.P.I.E.R. as the lower tanks empty. Looks like around 36 ton all up, maybe 6 ton recoverable if I could land it. The nuke vacuum vehicle 'stages' the fuel and LS tanks by decoupling chunks of it - to try to keep the fairing small. The docking ports don't seem to make horrible drag.

eeek 3.6 .... that's low...

oh so I can say in the terminal: run someCmd( 2, 200, 400) where I have a someCmd.ks file in the Scripts directory? thats 'as good as calling functions' from the terminal use experience, it just makes extra files...

@blub01 I use MechJeb quite a bit I don't think it can help with handling multiple nodes at once - I'll look again though because I am still finding 'new to me' things (e.g. in the maneuver planner recently). Were you thinking of Precise Node? I've not used that but it looks to include better time editing than MechJeb - but still not multiple node editing. I also want to probably add things like 'split a node'; e.g. split Pe kickable part off from the rest, then split the rest into chunks, tweak magnitude and have the code translate that to a tweak of the components, specify the UT of the burn. Probably other stuff will come up as I start using it. Undo, Save As - so you can try a few different ideas and go back to the best one.

I've just started playing with kOS - kudos on a huge undertaking. Naturally the first thing I want to do is one of the things you cannot do - I just wanted to check if there is a better work around than the one I imagine. I have made some maneuver node manipulation functions that I'd like be able to run from the terminal; e.g. deltaNodes( 200, 0, 0, 10 ) to eta+200 & p+10 all the nodes. It's to help do mission planning with low thrust vehicles; normally to get to the Mun you can drop a node and drag it around until it encounters the Mun - for a low thrust craft you might have 5 Pe Kicks that all need to be moved in synchrony. Being able to type commands from the terminal to interactively fiddle with the nodes would be great. It looks like I'd need to make some NodeFunction.ks files and then run it from NodeCommand.ks. Then I'd use NodeCommand.ks as 'the terminal' - editing the file and typing 'run NodeCommand.ks' in the terminal. Is there a better way to get the effect I want?

A crazy Mun 'encounter' dialed up with a 'make n identical low thrust burns jammed together' function. 12 times 110 m/s six minutes apart - 1320 m/s to the Mun - but maybe it makes sense to move something really massive with nukes.

KOS ... programmatically created nodes, 200 seconds apart. Scripts can easily shift the times for the whole list also.

Oh that revamp is large, it substitutes models. I did a quick check and it looks like the processing works ok ( i.e. the algae is there and eats waste producing the good stuff ) but all the cosmetics are missing since the models (and textures) are completely different. Ven's does things like: @PART[*]:FOR[zzzVSRPathPatch] {... @MODEL,* { @model ^= :^Squad/Parts/FuelTank/xenonTankRadial/model:VenStockRevamp/Squad/Parts/Propulsion/RadialXenon: }... so it will 'wreck' any re texturing mod. There must be a way to patch around it that doesn't involve copying squad's models.

Low TWR and what to do about it... We all know that usually propellant dominates mass so getting lower mass means using higher ISP engines, more deltaV per kg of propellant - but high ISP engines are low thrust, which means long burn times ... It's easy enough to leave MechJeb executing nodes for as long as you want, the problem is what nodes? For those who haven't come across the problem; an ion craft may need to burn for an hour to impart the deltaV required for a transfer burn. You cannot just burn for an hour 'in the right direction' because you will spend most of your time burning at the planet / retrograde / radially... Half the solution is a series of Pe kicks + a final departure burn. The Pe kicks raise your orbit's Ap as much as you can without escaping, the rest of the required deltaV will be the final departure burn. (Pe kicking & a reference trajectory) You have to arrange that you will be at Pe when you need to do the final departure burn. You could 'do the math' and back calculate all the Pe kicks, but you can get close enough using some seat of the pants astrogation and laying down a few nodes. The key thing is you can lay down a vanilla departure node from a reference craft (the whole 1400 m/s for example) and your real craft's final departure burn node ( for example the 600 m/s left after Pe kicking a few or many times). On your second last Pe tweak the deltaV to set your last Ap to place your departure node over the reference node - you will be in the right place at the right time to do the final burn. (adjusting the final departure node - only one kick in this example) Orbits with Ap past the Mun to near Minmus have a wide range of orbital periods so you have a pretty wide window when you can start Pe kicking - it depends on how much you can kick each time, for a craft that can do 100 m/s in six minutes leaving 20 days early gives you enough time. The second half of the solution is doing something with the final departure burn. You may still have a lot of burn time left, too much to burn 'at' the planet and miss. Even if you can avoid disaster you are introducing large errors that you have to correct later, and you cannot really tell what the correction will be until you have done the burns. Ideally we'd have a non instantaneous 'maneuver path' rather than a node, but I think I have a reasonable way to avoid burning 'on faith' just with the in game tools. Remember your final departure deltaV and modify the node to be your kick size. Then lay another identically sized node one burn time ahead, repeat until the subsequent trajectory is 'pretty straight', drop a final node with the residual deltaV. These two show about 1500 m/s of a 2400 m/s Eeloo burn - you can see now the trajectory is flat enough that you could then use one big 900 m/s two hour burn one hour out from the last node. Now you have a well defined trajectory and can make corrections by tuning the final node. The bigger you can kick the less nodes you will have to put down. This method should be much better than one burn - your predicted and achieved trajectory should be much closer than 'one big burn'. The imperfections in the method include; to be safe you will leave gaps between burns (not optimal), the gaps will get larger as the craft gets lighter (but calculating the burn times and adjusting each one would be tedious), and the burns start 'below prograde' and end 'above prograde'. Oh and importantly since the craft is going slower for longer it's orbit will be more wrapped around the planet than an instantaneous burn. One way you could compensate for that would be moving all the nodes back in time - so tedious but maybe some KOS script could help...

I love the inflatable solution for re-entry and launchpad.

Lately I've been doing some Eeloo missions for @Firemetal's low budget Eeloo mission challenge - playing around developing the mission plan is a lot of the fun so I thought I'd try making a mission development diary style report. I have some reasonable fast transfers I found earlier: Kerbin 2400 m/s departure burn Eeloo 1400 m/s capture burn Flags and Footprints using an ion lander I developed earlier Eeloo 2000 m/s departure burn Kerbin aerocapture 5 years 380 days This is a mass / deltaV / staging mock up that I think will work ok. (http://imgur.com/cHTofCx.png) Everything but the departure is straight forward. Nuke burns and staging away tanks and life support containers (1.6 ton of LS 'tankage' for the outbound trip ). I don't think I can (want) to Ion capture since there is 'no sun' it will be running on 2 RTGs which is like 10% thrust which means maybe 6 hours of burn. I don't mind leaving it to run while I do other things, but the navigation is a worry. The Kerbin departure is the tricky part. Ion powered, Pe kicks then continuous burn powered by the solar arrays. I have a good 'seat of the pants' technique for hitting the final departure burn at the right place and time, I figure it will add 20 - 30 days of kicking time before the departure burn. There will still be 1500 m/s - ( three hours! ) of burn to do while the craft is swinging around Kerbin. Just escaping Kerbin SOI at the right time and then doing one 'straight' burn doesn't sound optimal. I'm not sure how to do better without mod support (some kind of extended time continuous thrust node) but I have some thoughts to try out. The vacuum craft is about 50% heavier than anything I've space planed before, so that will be interesting also. My current cutest space plane launched vehicle , the vacuum craft is less than a ton. (http://imgur.com/2CoVgdn.png)

That makes sense up to a certain point, supplementary photons - but at some point the need to keep the water liquid will mean putting it in a small volume rather than something radiator shaped. Although photosynthesis should 'work' out to near Saturn the frost line is near the asteroid belt, maybe the Soylent gigantors should work like radiators also? orienting them edge on to the sun should be fine - light can pass through quite a long water column and still drive photo synthesis. Though probably cooling isn't your big thermal problem out at Jool.

@Gilph Sweet station - looks very ISS, and with room to grow. One thing I noticed though is the algal arrays are supposed to be colored (the algae) - I cannot believe I didn't notice the cosmetics when I was checking that the resources looked okay in 1.1.3. Turns out Squad changed the name the gigantor model uses to reference it's texture, so I have to change my .cfgs to match. I released a v0.4 on spacedock that you can install. Or you can just use notepad or something and change 'model000' to 'panel' in GameData/UberDyneAstronautics/Soylent/gigantorSoylentGreen/gigantorSoylentGreen.cfg and gigantorSoylentRed/gigantorSoylentRed.cfg // texture = model000,UberDyneAstronautics/Soylent/gigantorSoylentGreen/model000.g needs to be texture = panel,UberDyneAstronautics/Soylent/gigantorSoylentGreen/model000.g I checked a saved ship in orbit and the new texture re-map was applied. Sorry for the mixup, thanks for the image or I might not have noticed for a while!

post a pic if you like

I meant the 'you' in 'if you have not done planes this is a good reference' as 'whoever you are reading this' not as 'you firemetal' I went to check out your showcase but the plane albums are not showing up - maybe the recent imgur album borking? I thought it was just a problem with inserting new albums - I'll have to go check on some of my old ones - later after work ...

Does anyone know anything about how planets are drawn in the map view? I wondered what it would take to draw also their SOI, either as an alpha-ed sphere or a 'point cloud' on it's surface.