Jump to content

Gilph

Members
  • Posts

    696
  • Joined

  • Last visited

Everything posted by Gilph

  1. Hi, Yeah...you need 3-4 Tundra bays if you are making RE and MK full time. But my point was regarding the tank storage that is locally attached to the Refineries. One RE bay and one MK bay consumes like 500 chemicals per day at 100%. When your bonuses get higher (or if you have more than one MK or RE bay), you need 1500-2000 per day or more. Budgeting for 12 hours of tank space gets you 4000, which is a 2.5m tank. If you don't have a tank roughly that size, then you may run out of Chemicals during a 6 hour run of catch-up processing.
  2. When you run into these types of issues, the first thing to check is tank size. This has been discussed a few months ago in the forum, but I'll give the highlights. Chemicals are one of the largest things you need to manufacture if you wish to manufacture everything to be self sustainable. The way that catch-up mechanics work with MKS manufacturing, this requires a chemical tank size that can hold 6-12 hours of chemical consumption. Since Chemicals require Minerals and converts it with 20% efficiency, you need to have a max 1-5 ratio of Chemicals to Minerals storage (can be adjusted). If your tanks are smaller than this, then you won't make the maximum amount per day. When I resolved this in my base, everything worked as expected. The only issue I had left was if I used more than one tank to get the capacity. It did not seem to recognize the total capacity correctly. So for the large items like this, I stopped using inflatable storage and used single very large tanks. Hope this helps.
  3. I had noted it in the GPP forum a few weeks ago. Maybe a Kopernicus issue?
  4. Happened to me in a GPP non USI career. My scientist changed to an engineer in a lab on a space station on Niven. May be a stock issue since we run different configs.
  5. These are not issues just with the latest build. I have had them in every build. They're somewhat easy to work around, except for #1 in planets with atmosphere. I fly manually to a spot where I think will work, and say "land anywhere".
  6. Not really, but I have a few ideas. I know that Kopernicus sometimes gets confused on what the dominant star is, like pointing solar panels to Grannus when you are very close to Ciro. Also, even though I change Ciro to Sun in the bodies file, I don't edit Grannus. Maybe some sun-like parameters are being set for Grannus in TOT even though it should be just a body and throwing off the calculations. What gave me the idea was that I was working on a trajectory to Thalia (similar to Kerbin->Eve), and it was totally off. It was burning prograde (like it wanted to go to an outer planet like Grannus). I moved the burn 180 deg and had a trajectory with a Pe that looked close, but was not lined up to intercept Thalia at all (Thalia was in the wrong place). When I put that maneuver in, it calculated a final spacecraft state as orbiting Grannus (which is like setting up a Kerbin->Eve burn and seeing it intercepted Eeloo). If TOT thought Sun (Ciro) was Grannus, then that was correct. So I thought to just delete Grannus in the bodies file to make sure only one sun (called Sun) was included. When I reimported the file, it's been perfect ever since. fingers crossed.
  7. SIgh...sort of. V1.5.7 was not working perfect. it seems like some vessels always work in doing the two step MA of set state/coast to Pe, and it looks like it's the same vessels in 1.5.7 and 1.5.8. Also, the SOI after maneuver did not work after the first test on either version. I wiped the MCR runtime and installed it on a different drive, and did the same with the TOT app directory. Did not help. I think I won't take any more of your time on this. I'll do some work with stock saves I have archived to see if it's a Kopernicus issue. If there is any command line debug or log modes I can capture, please let me know. Thanks very much for your help Edit1: Found the problem. In the GPP bodies file, I deleted Grannus, the outermost body that is also a sun (it's not marked as a sun in the bodies file, but it may have some parameters that was confusing TOT). Every vessel now has the correct intercepts and all of the ones with maneuvers are correct also. Now I can get some sleep. Thanks again. Edit2: this was with 1.5.8
  8. Challenge Ac......denied Actually, I'm sending a science craft to try and return to Gael. I ignored trying to use Hox and got this result. Puts me at a Pe between Tellumo and Gratian in 93y with only a 1.6 degree inc. relative to Gael. It took 3100ms deltav and a 61ms plane change right outside of Gael SOI.
  9. Whaddya think? This is my Hox scanner that is on a free return trajectory with Grannus. There is the original and an updated burn on a year to fine tune. Very tempted to not stop at Hox.
  10. @Arrowstar, It looks like it's working again: Reinstalled 1.3.0 and every flippin mod in a new directory. TOT did not work. Deleted and Reinstalled TOT back to the main 1.5.7 release in the same TOT directory (e:\ksptot). Still did not work. Created a new TOT directory (e:\ksptot2) and reinstalled the 1.5.7 release. It worked. Not sure why creating a new directory worked. A quick look at the security settings shows no difference. Same drive and a simple directory off the root. Thanks very much for your help. I will stay at this version for a while.
  11. FYI, to give perspective, Gael is a kerbin replacement at roughly the same SMA as Kerbin. The inner planets are not that far and the purple body is about a Duna distance away, so nothing in the screenshot is that far. I have two other vessels in flight with a valid SOI and no maneuvers going to Gauss and Nero, which are far and very far. Doing the process you asked, I made two MAT files: GaussRelayGood.mat: correctly shows the SOI at 2y141d away NeroRelayBad.mat: does not show the SOI at 15y273d away. Thanks
  12. OK, the file is problem2.mat in the same shared link as above. The MA screenshot above is that exact scenario you requested. The screenshot here is the station intercepting Gael in 45 days. Gael is the pale blue dot (to coin a phrase). You can see the Commnet green line linking the vessel to Gael. I also copied a recent persist file for your reference. Thanks
  13. *sigh* OK. Hoping it was something easy. I can look to try to make a youtube video. I made one once to show a USI MKS bug, I just need to remember how to do it again. I am very sure. In fact, I don't need that maneuver node to get an SOI. I was just moving the Pe a little closer. Here is a screenshot to give you an idea. It's the station icon in the center and the SOI is upper left. I am on an intercept with the body connected by the green line: Edit1: Executed the burn and encounter and Pe are good. Created a MA where I just set initial state and a coast to Gael Pe. This is the MA screen still showing a total miss:
  14. Sure, here is the link found some other things. I deleted my appoptions.ini file to allow the program to recreate from scratch. I restarted and changed the time from Earth to Kerbin, but changing to Kerbin does not save in the file. I use the GPP pack, so I deleted the default bodies.ini file and load a GPP file with another name. If I delete the options file, it will start with the stock system parameters, even though I dont have a stock bodies file. Is there a set of stock data embedded in the app?
  15. Was able to work a bit on it today. here are the steps: I open a flight scene for a vessel on orbit around the sun heading to Gael. I have a small maneuver in 36 days to fine tune (14m/s), encounter at about 116 days (Thalia->Gael in GPP) Open TOT and start MA Import the maneuver, which creates a set state, coast to UT, and dv_maneuver node. Import the orbit info into Set State Add a fourth step to coast to Pe of Gael. Final spacecraft state should show orbiting around Gael. Instead, I'm orbiting around the Sun and an error that I cannot go to True Anomoly because there is no SOI for Gael. I had done that exact sequence a few times in the past days and it always worked. I have not tried to optimize yet because I can't get the actual state correct. The imported data looks correct. The log was pretty empty: Let me know if you need anything else? Thanks
  16. HI, I got this contract today. I saved the log if you need it
  17. HI...This build may have some issues. I was not able to get an intercept from a MAT file that worked in the previous version. So, I tried to recreate all the steps and it still did not work. When I reverted to the prior versions, it all worked again. I'll try and work through it more carefully over the weekend and post some logs. Thanks
  18. Not really a show stopper, but if you change the departure time in the Departure Burn calc window (Enter Transfer and Initial Orbit Info window), and right click the Arrival Time field to "Find Optimal Arrival Time for Input Departure Time", it throws an error: Thanks
  19. Hi, had two of the listed issues and this release fixed them nicely. Thanks. I am finally getting the hang of MA, after only two years. Have a mission to Otho (GPP) all set up and it looks really good on paper. I wanted to ask what the best practice for using Set State after the initial state. Based on one's piloting skills, the state after burns may not be as close to the planned state as you would like. Is it a good idea to add a Set State after a burn step, import the current orbit of the vessel (which is the result of the burn), set the current step to this step in MA and rerun optimizations? Thanks
  20. Hi, I have used both, and have also experienced a lot of the same concerns you have addressed. My solution is this: If I wish to run a career using life support and wish to use MKS for bases and resource manufacturing, I use USI-LS If I wish to run a career using life support and some small bases but don't want to use complicated manufacturing, or habitation, I use TAC USI has some support for TAC, but it is user driven and feels somewhat incomplete. You can tell it's a bit of a kludge. The complexity in USI is not in the life support part, it's in the resource and manufacturing part. The usage and consumption of Supplies is easy, the recycling is somewhat easy, and the manufacturing of them is hard. I really do not recommend TAC in USI. I don't think you will be happy, although some say they are content with it. The design of Supplies, which bundle air, food, and water into a single unit has a lot of drawbacks, but it works in USI. TAC and KPBS are a really wonderful combination, along with the other manufacturing/recycling mods to support TAC. Using them is comfortable, intuitive and easy, just like USI-LS and MKS work nicely together. The overall TAC design is really nice and make a lot of sense with the separation of resources and how you need to manage them, as long as you don't try and crowbar it into USI. Hope this helps.
  21. look for the Kestrel MK1 super heavy on Kerbalx. It's very configurable by being able to add tanks and stages. You may need to clean things up a bit in the VAB, but it's a great stock launcher.
  22. Hi, running with GPP also. I have a scanner around Gratian with three NF solar panels. It chose Grannus to track, even though there was 0 EC generated. When I manually switched to Ciro, I got about 2 EC. It did not autoselect the choice that gave the best EC. Will post some logs after my really long ion burn. Thanks Edit1: logs are here Scenario: Vessel was in orbit around Gratian. It auto selected Grannus for the three small NF solar panels. The Sun Exposure was higher for Grannus, but it produced 0EC. Manually switching to Ciro had a lower Sun Exposure, but generated 2 EC Also, the Status field seemed to be reporting the status as if I were tracking Grannus, even after I switched to Ciro. Please let me know if there is anything else needed Edit2: Restarted the game and checked the Thalia vessels. They also seem to be tracking Grannus by default, even though they are very close to Ciro
  23. Look here, it's listed https://forum.kerbalspaceprogram.com/index.php?/topic/139980-130-community-database-of-module-manager-patches-for-stock-ksp/
  24. I found an ore mining spot at the bottom of a steep chasm. The decent, like yours, was stunning. I did also find the one flat impact crater on Iota, probably put there out of pity for me, and I am eternally grateful
  25. OK...you need more than two small radiators to land on Thalia if you want to stay there for more than 45 secs. Sorry I didnt capture the explosion, but was smart enough not to have a kerbal on board at the time. *sigh* This one should work a bit better:
×
×
  • Create New...