Gilph

Hi, Been experimenting with the RR Parts and not using the patched stock ISRU. I have a miner/converter vessel on Minmus that is drilling Hydrates (14%) and has four Box B large and two small Box A converters. It's a Hydrolox fueled lander. I land with almost no fuel left, drill Hydrates, convert to water, and make Hydrolox to fill the tanks to bring up to refueling station in orbit. When the vessel has focus, I set up the converters that the four large ones are Hydrates splitters, and the two small ones are Hydrolox makers. With this setup, my Water is always empty because i cant keep up with the Hydrolox consumption, so my Hydrolox runs a bit slower. My Hydrates show a small net increase in storage from the drilling. When I warp three days and return to the vessel, I expected to see my Hydrates tanks a bit fuller, my water tanks still empty, and a certain increase in Hydrolox. What I actually see is the Hydrates filling up as expected, my Water tanks half full, and my Hydrolox tanks less than expected. It appears my Water->Hydrolox conversion is not working as expected after a warp. Is there any tips or tricks to consider? I know that MKS has a catchup process that needed certain tank capacities to hold like 12 hours of materials to properly convert during a warp. Is it the same here also? Thanks

Well...that did not work very well. After some reverse engineering, reading of release notes, and mod version control, I put my CryoTanks back, deleted the boiloff dll, removed the CryoTank patch for the ISRU, and got back to normal. There were too many MM functions I'm not familiar with yet. Thanks for your help, @PocketBrotector

I seem to recall that the @DMagic modlet EVA Transfer worked, at least in an older version. The mod is updated only to 1.8. It's the only other thing I can think of that has not been mentioned already. Would need a bit of testing.

Hi, my issue didn't really go away, so I made an executive decision to not use CryoTanks. The boiloff mechanic and different ISRU are complications that I don't really need or want, even though the tanks are awesome. I replaced the tankswitchforsquad.cfg and now have just the option for RR fuels for the stock tanks. I'd like the same functionality for the NFLV and SpaceY tanks, which does not have the RR fuel options in the menu. How would I create/change a cfg file to apply those options to those other tanks? Thanks

Hi, thanks for the response. I'm using 1.8.1 and most versions are still at 1.8.1 levels. In the VAB, it looks like all versions of tanks that are not stock (CryoTanks, RR, SpaceY) will have a select tank option. If I pick one that has boiloff like Hydrogen, I'll see an insulation EC cost and an option to to enable/disable cooling. The stock tanks only have an option to "Select RR Fuel" and no choice to enable/disable cooling and no EC cost. It looks like that menu is from a RR patch, and the patch may be overwriting the other menu for only stock tanks. Will play around with it a little more. Update: It was the RR_TankswitchForSquad.cfg file in Extras. Once I removed it, all the tanks now look the same in the menus, including stock. Now, I have to update all of my vessels that have stock tanks but contain things that can boil off in flight to enable cooling. Thank goodness it's only a few.

Hi, just updated from a older version of RR. Have a few questions. Stock tanks dont use EC because they dont have boil off enabled. I believe I saw this earlier. Is that true? My ISRU has both Hydrolox and LH2+OX choices, and Methalox and LCH4+Ox choices. You had verified earlier that they are the same, so why do I have 2 choices for the same output. Did I overinstall a patch with too many options?? thanks

This. MKS was built on the premise that certain things dont have to be attached to allow for transfers and sharing. But, if you need, I use EVA transfer from @DMagic. It's much simpler if you don't want the overhead of KAS/KIS

Hi, just found this tool. You've done a really excellent job. Thanks for making it.

Hi, I'm using a 1.8.1 version under Windows with JNSQ and have installed the patch with no issues. I also have 16GB memory and did have memory issues a few months ago when I installed the Scansat update. With JNSQ, you can run out of memory, even with 16GB. There was a very small increase in mem usage after my update and that was enough to make it not run anymore. I increased my swap to 12GB total and lowered my background memory usage and all seems well now. I found the memory issue by running the Windows Task Mgr/Resource Mgr in my second window. It seems like even a small increase memory can get you over a threshold, so you may wish to look into that with the corresponding MAC tools.

It's easier for me just to use Maneuver Planner to work around it. The only really tricky part is if the approach is so exact and I don't slow down in time, So when I do the match velocities at closest approach, i open the maneuver node editor and subtract 10 secs. It seems like, recently, it will pick the "wrong" choice more often. I could even disable AP, do the workarounds to get like 1km away, enable AP, and it would make the node to match velocities and maintain the distance i specified, but that doesn't seem to work anymore. I look at some of the recent revisions in dev and noticed there were a few updates.to Rendezvous AP that streamlined things a bit, which may be causing it. It's not terribly impactful, just need to validate the AP choices before going to the bathroom and finding out my vessel is out of fuel when I get back.

Hi, I've had come conversations with @DMagic on the subject of slope. Slope is not a native data element, but it can be calculated. In the context of Scansat, it's done in a certain way to support their scanning functionality. They take lat and lon and get ASL data, then get the ASL data for adjacent locations and calculate the differences for ASL to calculate slope. It sounded like if you have access to that ASL data, anyone can calculate slope, but it appears not to be a trivial task.

Hi, I've been noticing an issue with the Rendezvous AP. I am trying to rendezvous with another object around 10-15 km away. Our planes and orbit ecc are matched, and a simple Hohmann transfer will intercept very nicely using only about 10 m/s. But, the AP will decide to say "close to target, plotting intercept" and use hundreds of deltav in a loop, trying to get closer. Usually when that happens, i can disable AP and do the hohmann transfer, warp until about 2 km away, and reenable ap to match velocities. That doesn't seem to work anymore and I have to manually match the velocities. Is there a way to determine if a hohmann transfer will create a separation close to zero and prefer that method over the close to target intercept? Or, detect that I'm already on that trajectory and will just match velocities at the end? Thanks

Not in the current and prior versions. The new WOLF version is supposed to address that, but it's not ready yet. Also, it's best to visit all of the things that produce, like drills, first to fill up the PL storage, then visit the things that consume it.

I believe, yes. Habitation is shared with all vessels within 150m, iirc. I've done what you have described in a 1.3 save, and I don't think anything has changed.

Hi, sorry for the late response...been playing No Man's Sky for the past few weeks. Without some more data, I can try and give some general answers. I'm a long time user of TOT, although I'm not a huge expert in orbital mechanics. Most things in TOT give approximations of a solution, and those should be input into Mission Architect (MA). There are several MA examples to help you with how to set it up including multi-flybys. MA is the thing that will take the approximate values and fine tune them based on your criteria to give a more solid answer. But, there is always some general tweaking to make it work once you import, and, once you start, there will always be tweaking based on how well you executed the prior step. Some of the manouver utilities, which I use heavily, are amazingly accurate without the need for MA, but if you are needing to plan a multi manouver plan, MA is usually the final word. I haven't been able to learn the multi flyby to find specific routes yet, but I sometimes will find one in game by playing around a bit. When I do, I start TOT and put the steps in MA to see if MA will calculate the same answer. Then I'll experiment with the different ways to run the optimizer in MA and see the result. That was a really good tutorial for me. Hope this helps.

Hi @Arrowstar, Having an issue with the new 1.6.5 and MA. In my JNSQ instance I have a ship on orbit and was looking to optimize a transfer burn calculated by mechjeb. Open MA. KSP is in flight mode. Import values in Initial State successfully almost instantly. Right click window to select import maneuver node from KSP for active vessel. MA just sits there with the yellow Working... banner on the bottom. Task Manager reports around a 25% CPU load for KSPTOT. It took 10 minutes to complete just the import. As I'm typing this, I added a Coast to the target body (Nara, who is very far away, 1,712,000,000km SMA) and it took another xx hasn't finished after 15 minutes. I haven't even started the optimization yet, it's just adding steps so far. Are there options I can play around with to try and fix? Thanks PS: Maybe change this? MA/LVD: Added option to auto-propagate (or not) the mission script when changes are made to it. Useful when your script takes forever to propagate and you have lots of changes to make.

I'm afraid not. The two time systems are somewhat hard-coded in there, so additional work would be required to add a new time system. Hi, I've been playing around a little with this using earth time, which is exactly twice as long. Did a optimal 2 burn change on a probe around the new Moho and it went perfect, except I needed to do 2 orbits each to get to the two burn nodes. I was a little surprised because I used UT in seconds, which shouldn't care how long the day is (maybe?). I'll play around a bit more to see if I need to cut some intervals in half. It's nice to use the utilities though, i tend to rely on them a lot. Thanks

Good to know...flirted with the idea of a no ore save (meaning not using ore even though it's there), but too hard for my first RR playthrough. Yeah, been doing that since I started KSP. I did land probes on stock Eve and Laythe, but that's about it. Cost me my JNSQ badge because I scanned all the worlds, but landed only on the airless and nearly airless ones. Really? Does that mean I need the atmo sensor on scanners to airless worlds? Like the way Karborundum existed in bands around a body? Thanks

Thanks for the response. I haven't scanned too many bodies yet in my save, but I was thinking about when I had a body with no ore or CO2 and wanted to use LFO. If I have access to Oxygen (I think 4 things can make Oxygen), then I can mine something like Rock, convert it to Carbon using some sort of low conversion ratio, make CO2 out of Carbon and Oxygen, then make LFO. When I saw the CO2 splitter and did not see a CO2 generator, it seemed odd. It's a shame about the scoop. I dont use SSTOs and rarely do much on bodies with atmo. If the air is thin anough, maybe I can just use a small craft in the upper atmo, or download a good SSTO from Kerbalx.

Hi, I wanted to ask about CO2 related items. It looks like CO2 can be collected by drilling in crust and scooped from atmo. I'm surprised there is no ISRU recipe to make CO2. It brings up a few questions: It looks like I can split CO2 into Carbon and Oxygen, but I cant make it from Carbon and Oxygen. Seems like it's done on purpose, but not sure why. If I was to make CO2, I can make Oxygen in a few ways, but I cant seem to make Carbon. Shouldn't there be a few choices to make Carbon, even from things like Rock? Does the Scoop need to be moving to collect CO2 (atmo), or can it be attached to something stationary on the ground. Thanks

This is definitely more interesting than I would have expected. Less engine choice is making this hard. Right now I'm using my first transfer windows to scan things with scansat and send relays, but I might have to actually learn to play this game to get my ISRU stuff to work. Thanks for that..

Hi, finally started my 1.8.1 save from scratch with the latest JNSQ. I have a miner drilling on the surface to get some experience with the whole RR ISRU process. When I make that miner lander ship active, it jumps a small amount, not enough to break anything. I did see some posts about bases jumping from a 1.7.3 save, but this is not the case here. Are there surface issues on Minmus (or anywhere else) that would affect bases or landers? Thanks

Hi @Arrowstar, The new version of the JNSQ mod implemented a 12 hour Kerbin day. I remember only having a stock kerbin day and an 24 hour earth day available. Is there any way to set a 12 hour day in TOT?

Hi I had downloaded the new 1.65 prerelease, copied the new KSPTOT connect dll into my 1.7.3 JNSQ save, and tried to create a new bodies file. I got an error. The error log was: Index exceeds matrix dimensions. Error in getBodiesINIFileFromKSP (line 135) Error in mainGUI>createNewBodiesFileFromKSP_Callback Error in gui_mainfcn (line 95) Error in mainGUI (line 42) Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)mainGUI('createNewBodiesFileFromKSP_Callback',hObject,eventdata,guidata(hObject)) Error using waitforallfiguresclosed (line 9) Error while evaluating Menu Callback. Will revert back to 1.6.4 to see if it helps Thanks Edit1: Sorry...dd not write that well...meant to say that I recopied the dll from the 1.6.4. download, then added the new prerelease. Am deleting everything and will test a fresh install. Edit2: it works...just redownloaded everything and reinstalled. sorry for the mixup

I have always used these, they are stockalike and fit well with my MKS bases