Jump to content

psamathe

Members
  • Posts

    13
  • Joined

  • Last visited

Reputation

7 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi this is a great Mod. Wanted to flag up a minor bug in the biomes for Karen. You have two biomes named Sogelrun. Looking at the cfg it looks like one should be called Dyson, but the wrong localization reference is given.
  2. Hi, I have a question about a change in the latest Kopernicus. I can see a part module got renamed from KopernicusSolarPanel to KopernicusSolarPanels. This causes warnings on my saved craft (from 1.7.3) in the VAB, but loading and resaving seems to put in the new module. Also my existing craft in game seem to need their solar panels re-deployed. Other than the two things above is there anything else I should be worrying about?
  3. @dlrk As far as I am aware, most of the MKS parts providing a habitation bonus don't use machinery - only some of the inflatable ones use machinery in MKS I think. Are you adding machinery to everything or just the inflatable parts? If anything I would have said the kerbal months values for some parts in SSPRx may be a little high, but the multipliers look about right to me - the MKS 3.75 kerbitat has a multiplier of 5.42 (& no machinery cost), which is a fair bit bigger than most (all?) of the parts here. Generally electricity usage in the parts here is bigger than in MKS, and the MKS parts can be reconfigured, but I'm not sure how much of a balancer either of those are? Personally I feel that the best habitation values come from combining MKS and SSPRx parts - one for multipliers, one for months. 3 SSPX Hostels gives much more total time than 3 MKS 3.75 Kerbitats (configured optimally), but 2 hostels and one Kerbitat beats them both.
  4. Hi, I've been having some issues with heat on MKS drills with multiple separators. Basically if I start a second separator the drill begins to overheat, irrespective of how much cooling I have. I can start additional drills with no issue as long as I only ever start one of the separators on each drill. I'm on KSP 1.4.3, using MKS 0.55 from CKAN. I'm using a number of other mods as well (several of the USI ones, Near Future stuff, some planet packs, plus more) To reproduce (for me anyway): I start with a Duna Power unit, add some dirt storage (I'm using a ranger unit), a ranger thermal control system, as well as two MEU-500A pulse drills (left as default dirt). Then launch, start the cooling, start the reactor, and deploy both drills. On the first drill I start one separator, and I see temperature stabilise at 500K. If I then start a second separator on that same drill it starts to overheat. If I now start the first separator on the second drill it will stabilise on 500K. When I switch off the second separator on the first drill, it will gradually drop back down to 500K. Both drills will run quite happily provided I never start a second separator. I've tried adding (a lot) more cooling but it doesn't seem to help. Is this a bug or am I doing something dumb?
  5. I had this problem, but fixed it. The issue was in the combination of Kopernicus and GPP I was running. Kopernicus 1.3.1-3 introduced a deliberate change to how stars behave. If you have a planet pack which adds stars (like GPP) the owner of the planet pack needs to update it to handle the Kopernicus change. The latest version of GPP has this update. For the shadows to disappear and lighting to behave normally you need to run Kopernicus 1.3.1-3 with GPP 1.5.88. If you are still on GPP 1.5.3 you will need to either revert back to Kopernicus 1.3.1-2 or upgrade GPP to 1.5.88.
  6. Hi, was trying out this planet pack, with OPM, but the OPM patch does not appear to be working. All the moons load, but Froth is still around Eeloo. Tested it on a fresh install with no mods apart from OPM and its dependencies. Changing the 1st line of patch to "@Kopernicus:NEEDS[OPM,!GalacticNeighborhood]:AFTER[StockPlanetExpansion]" fixed it for me (it was @Kopernicus:NEEDS[OPM,!GalacticNeighborhood]:AFTER[OPM]).
  7. Ah ok thanks. And its only going to be an issue with a planet pack then if the planet pack includes stars. I double checked and GPP is the one causing it for me with that kopernicus change - I'll check there (I know there is a recent update to GPP I have not yet installed). Thanks again.
  8. Hi, I've noticed a possible issue with Kopernicus 1.3.1-3. Planets seem much darker now. Kerbin is noticeably dimmer, and the Mun is so dark when I land on it (in daytime) I can barely see anything. If I zoom a long way out on the Mun, at some point it suddenly lights up, zooming back in makes it dark again. Reverting back to Kopernicus 1.3.1-2 seems to set the lighting back to normal and I can see fine on the Mun and Kerbin. In case it matters I'm running quite a few planet packs (including OPM, GPP secondary, Trans Keptunian, Xens Planet pack, Asclepius and Arkas).
  9. Wanted to report a possible bug in 17.5 running on 1.2.2. On the zoom window, the resources button does not do anything - I can select resources, but they never show and the mouse-over does not report the resource value below the cursor. Works as expected on the big map.
  10. I dug up an old save and went back to see if the problem was there. It was - quicksaving and reloading did not make any difference. I'm hoping you can get the save from here: https://drive.google.com/file/d/0Bylkrr1nWeS5OWZoM2pIRjhRcm8/view?pref=2&pli=1 I think I have stripped out all spacecraft other than one kerbal standing on minimus by the monolith.Be aware I'm running a number of other mods as well.
  11. This is a great pack. I have spotted an additional issue beyond those already mentioned by others (possibly its fixed with the reworked missions released a couple of hours ago?): in my game the TMA contract on Minimus had the waypoint about 250 m underground and I had to alt-F12 it to complete it.
  12. MechJeb is precise, but it only optimizes for flyby intercepts (i.e. optimizing the departure burn). TWP is the only tool I know that can also take into account a capture burn - for some transfers it does not make that much difference, but for something like Kerbin to Moho there is a big difference, as the capture burn is where most of your dV is used - you can save 1000s of dV using TWP transfer windows in this case.
  13. [quote name='Warzouz']I must say I also used tools (alex tool, KAC window, MJ interplanetary transfert...) I rarely got what I wanted. Maybe I don't use those tools correctly. I'm better with my own method (even I still use MJ for executing nodes :D ).[/QUOTE] You can use a combination of the Alex tool and Mechjeb to get a good transfer. Main problem with Mechjeb is that it only takes into account the departure burn - for somewhere like Moho the insertion burn is more important. What I do is use the alex tool to get the time and journey duration of a good burn. Then I use the advanced transfer to another planet option and click on the point in the diagram with the same departure time and journey time. That should give you something very close to the optimum transfer taking into account departure and insertion burns.
×
×
  • Create New...