AG5BPilot

Members
  • Content count

    72
  • Joined

  • Last visited

Community Reputation

32 Excellent

About AG5BPilot

  • Rank
    Bottle Rocketeer
  1. Plants, being green, reflect green light -- they don't absorb it. Other wavelengths are more useful to plants. If you saw pictures of the plant growth experiment that was just sent to the ISS, the plant lights it uses are pink.
  2. I am seeing the exact same problem with Kerbalism and a stock-scale GPP (no resizing). I ended up expanding the station with the greenhouse part to add additional solar panels.
  3. Thanks for the help and suggestion. Sorry for taking so long to reply. I didn't have time to adequately test your suggestion last night and I didn't want to give you a half baked response. I set up a fresh install with only DM Orbital Science, Kerbalism, Module Manager, and Hyperedit installed. Without the above patch, the behavior is as follows: The Little Brother recon telescope acted as described in my original post (no repeatability). The Big Brother scope also wasn't able to repeat the experiment, as expected. (Separate issue: There appears to be a MM config error because only the Little Brother is creating a sample. The Big Brother is producing transmittable science. My main install also exhibits this behavior.) With your patch installed as a config file in gamedata, the behavior of the Big Brother (4-use) part changed as expected, and allowed the science to be rerun (remaining as transmittable data). It was, however, not changing the animation to show that film canisters were being reused, and it was able to repeat the science indefinitely. So the patch is working, but the theoretical part about Orbital Science locking after the intended N uses is not. Since this patch specifically references the Big Brother part, I also tried the patch modifying DMReconSmall (i.e., "Little Brother"). It continued to produce a "sample", and became infinitely repeatable. Behavior on my main installation (which includes GPP and 100+ other mods) was identical to the test installation. The KSP log (from the test install) can be found here: https://www.dropbox.com/s/up8zxupy5njxa8d/KSP.log?dl=0
  4. Thanks, got it. It' sounds like neither mod author is likely to change the mods to preserve that feature. (That's not a complaint, merely a statement of fact.) There is a workaround, of sorts: edit the save file to restore the part so it's usable again.
  5. I read back over 10 pages, so I must have missed it.
  6. Does anyone else use DM Orbital Science and Kerbalism? It seems that all the multi-sample science parts (big and little brother, solar particle collector, and the two-sample versions of the materials bay and goo canisters) become inoperative after the first use. Anyone else seeing this problem?
  7. It shouldn't need to read minds since you can move the kerbals into the shielded sections when needed. I'm sure there a reason why it works the way it does.
  8. Forgive me if I'm asking questions already answered. I admit to being lazy and only reading the last page. At this point, I'm not asking for assistance. I'm only asking if these are known problems. If not, I'll dig deeper and do the due diligence before really asking for help. But if they're known problems, I don't need to dig. First of all, let me say that the work that went into this mod is really impressive. It's not just fancy coding and models. The design of the new game systems is really well done. Nice job! As for the actual questions: 1) I'm using DMagic's Orbital Science. Several of his science parts produce "samples" under Kerbalism. The problem is that some of his parts are supposed to produce 2 or 4 samples, but when running under Kerbalism they become inoperative after the first sample. Is this the intended behavior? 2) I think this has already been mentioned, but shielding on vessels isn't very user friendly. I thought I'd make one "safe haven" area that was heavily shielded, but since the entire ship is treated as having an averaged amount of shielding, that doesn't work. So it's either undock, or turn off the habitation systems in other modules. There's currently no other way around this, right? I suppose I could turn off CMEs or the entire radiation mechanics. 3) I had a kerballed vessel rotate such that it lost solar power, the battery discharged, the scrubber shut down, and CO2 climbed. There was a message that popped up on the screen, but by the time I could react and shut off the warp, it was already too late. Now, I know that the alerts will kill the warp, however, at the time I was using Mechjeb to execute a maneuver, with the "autowarp" turned on, so it was turning warp back on when Kerbalism turned it off. Other than F5/F9 or not using autowarp, do you have any suggestions?
  9. Sounds like Hyperedit to me. I've seen the same thing happen with Hyperedit, in stock as well as with GPP. From KSP 0.9 through today. Try instead using a sandbox and flying there under high warp, without Hyperedit and see if the problem goes away.
  10. I'm usually at 6 or 7 GB by the time I get to the menu. That prompted a few clicks on Amazon and a box to appear at my front door with a 16 GB upgrade. There are some memory leaks either in KSP, some mods, or likely both. I fell asleep one night night with KSP running in the VAB editor and when I woke up it was using 33 GB of virtual memory (on a system with 24 GB of real memory.) If you can, spring for another 8GB (or more). It's well worth the money. You'll see a tremendous speedup since a lot less virtual memory swapping will be needed, even with an SSD. I shudder to think what GPP would be like running on 8GB and a hard disk.
  11. You're asking specifically how to install the update in-place over an older version of GPP, right? This is what's worked for me: Delete all the folders inside the gamedata folder installed by your previous GPP, and then install the latest GPP. If your previous GPP is old enough so that it had manual patches to some other other mods, also delete those mods' folders inside gamedata and reinstall the those mods. Exactly which folders you need to delete will vary depending on which of the optional mods you chose to install originally. If your existing version of GPP is v1.1, be especially careful to remove all the old folders. 1.1 had a lot of manual modifications to other mods. Galileo has done a superb job of simplifying the install since then, which not only makes installing GPP easier, but also makes uninstalling GPP (when upgrading) easier as well. I find it helps to be looking at the old GPP's zip file when uninstalling to make sure I'm deleting all of the necessary folders. So far I've done the 1.1 to 1.2.0, 1.2.0 to 1.2.1, and 1.2.1 to 1.2.2 updates using this procedure without incident.
  12. I figured out what was happening, at least on my system. Do you have Kerbalism installed? In map mode, if you have the life support panel displayed (as opposed to, say, the resources panel, or the contract panel) using the buttons in the upper right corner, the life support panel grabs the focus when you hit the tab key. This, in turn, requires that you click on the background in order for tab to bring you to the next planet.
  13. For me it was happening everywhere.
  14. I've also been having trouble with using tab to switch between planets, but I discovered that what was actually happening was when I hit the tab key, the focus would shift to one of the mods windows (not always the same mod), so the next tab would be captured by that window instead of the main map window. Hitting tab, then clicking on the background map, then hitting tab, clicking on the background, etc., seems to work. It's an annoying work-around, but it works. Is this the problem you're seeing?
  15. What you appear to be overlooking from the dv map is the 820 dv for the plane change to Hox's orbit, but that doesn't get you up to 4K dv. Are you sure you're planning the burn at the optimal time for a Hohman transfer? I'm not sure how the dv map's numbers were done, but be aware that doing multiple burns (i.e., first getting to a circular solar orbit, then transferring to hox) should be less efficient than a direct burn from low Gael orbit to intercept Hox. Note that this isn't always true, as sometimes it's more efficient to do plane change burns separately, but usually doing multiple large burns is less efficient. The maps numbers may have been determined with a more efficient strategy. Furthermore, the game-year at which you do the transfer matters, because the destination's position changes. The distance from Cirus (periapsis vs. apoapsis) doesn't matter that much, but its distance above or below the ecliptic plane matters a LOT. That determines how much of plane change your ship will need for the rendezvous. Catch Hox while it's near its ascending/descending node with Gael and it will take a lot less dv to reach than when it's 90 degrees further along in its orbit. FWIW, TWP (Transfer WIndow Planner) around day 0 shows an intercept (for a flyby) from a 100 km Gael orbit to hox as needing 2820 dv for a 7 year trip. That includes the 935 to reach Gael's SOI, so about 1900 dv should be close near the beginning of the game. Note that TWP doesn't always pick good defaults for the transit time boundaries, so if it puts the "best" result right at the top or bottom of the porkchop plot, you should extend its search limits. Also note that the optimal transfer for going into orbit isn't always the best for a flyby. If you want to go into a 100 km Hox orbit, the optimal ejection burn from Gael increases by several hundred dv, but you save it on the other end when you do the Hox orbit insertion. And the trip is 19 years instead of 7. Using Mechjeb gives similar results. From a 100 km Gael orbit, it gives a 2822 burn around day 248 that intercepts Hox in year 14. It then needs about a 2500 dv insertion burn.