Jump to content

Crater

Members
  • Posts

    267
  • Joined

  • Last visited

Everything posted by Crater

  1. I can't speak for the others, but that's my hang-up, yeah.
  2. Kerbal ISP Difficulty Scaler - http://forum.kerbalspaceprogram.com/threads/52882-0-21-Kerbal-Isp-Difficulty-Scaler-v1-0 - Another one from Ferram4
  3. This is a tough one to call. For usability, ease, convenience, I'd definitely love to have some sort of overlay that you could see layered onto the body you're orbiting. Scansat can very effectively help you determine which landing site you wish to select, but finding that point on the ball beneath you, especially if it is on the dark side, or with VisualEnhancement cloud layers, or even just "which of that chain of craters / peninsulae / islands was it again?" On the flip side, rendering just the portions that you've scanned with scansat, overlaying the resource data you're interested in, building a HUGE texture in memory (there is a reason there are not many hexes on a Kethane overlay), and updating that every tick as new scan data comes in, while wrapping that onto the planet, well, that's going to eat both RAM and CPU cycles, and I have things I wanted to do with both of those. What would people think about waypoints instead? If you could select a location in the scansat map view, and a waymarker was laid onto the planet at that point, so you could easily see it on the ground. I know it's possible already if you transpose the coodinates into MechJeb, for example, but a clean interface to drop BIG FRIENDLY LABELS onto the planet view might solve the navigation problems without being a massive coding effort, and be much nicer on resources (of the computer variety).
  4. That's because 1.7.6 is designed for use with 0.24.2 - You may indeed need to update your KSP Edit: which of course is exactly what you were trying to say.... I'll shut up now
  5. My point was more related to the fact that the error the poster was reporting with the tech research being nuked was a core game function, not anything added by MM, and therfore not really anything fixable by MM.
  6. I'd be cautious of taking the numbers in that thread.... 1) KSP stock "units" are more like 5 liters than 1 liter, according to most people who do the maths, so that would pretty-close to explain the factor of 4.5 everything is out by 2) At various places in the thread, people use 1m and 2m as tank sizes, instead of 1.25m, 2.5m, which is going to induce errors 3) Also at various places in the thread, people mix and match with whether they're using a radius or a diameter, which is again going to introduce errors.
  7. I think that you might possibly have two copies of the Karbonite TweakScale .cfg floating around. There should be one in GameData/UmbraSpaceIndustries/Karbonite/TweakScale.cfg, and no other. Check that you haven't dropped a manual config file for Karbonite into the GameData/Tweakscale folder.
  8. Another voice saying "thank you for asking us about it", and go for it. I already have the full AVC installed, after looking into how it does what it does and being happy with it. As I understand it, if you install the mini version, it'll be superceeded by a full install anyway, if one exists? So I'd say go for whatever works best for you, and I for one will be happy with having it.
  9. It is the database reload that causes this, which is a stock KSP function (it is on the debug menu), and nothing to to with MM, which just puts up a button that people might see. And just to be clear, even if you do not have MM installed, and you go into debug and hit the button, it trashes your research tree stuff.
  10. For getting to Mun, you're looking at travel times in the order of a day or two (earth day) each way, or less. For longer trips, take a look at http://alexmoon.github.io/ksp/ where you will find an excellent calculator for launch windows and transit times for anywhere to anywhere
  11. Previous versions of TAV-LS used to use "1 unit of resource = 1 kerbin-day of consumption", giving the readouts you were seeing. This causes...... issues if you have another mod that uses water, say, where 1 unit = 1 liter, similarly for oxygen, there are many mods that deal in oxygen, but 1 unit = two-and-a-bit thousand liters isn't very useful to anything other than LS. It gets even worse when you try to swap quantities around, using something like Modular Fuels, and the only real way to make everything play nice together is to standardise on the volumes of a unit of a resource, usually at 1u=1l or 1u=5l, and stick with that for all your resources. Hence in the pre-releases for tac-ls, the units are now liters, not days, so you can no longer simply see them that way in the resource panel. The life support status panel should still show you how long things will last though, I think.
  12. I was just wondering that myself.... turns out it is a bitmap, with one bit per sensor type, you can see all the definitions in the source code, over at https://github.com/S-C-A-N/SCANsat/blob/release/SCANsat/SCANdata.cs around line 38-65. Add up the ones you want on your sensor, and presto! that's your required sensorType value.
  13. Which becomes even more entertaining (in the Kerbal sense of the word) when you consider what would happen to someone trying to breath liquid oxygen without warming it up a little first
  14. You need to have Blizzy's toolbar installed (I think there is a link in the first post)
  15. Definitely uninstall 2.2.0 - you only need one version, and you shouldn't have any compatability issues. Mods that need MM use it by having MM config files, rather than linking to the MM dll itself, and the config language is backwards compatable, so you should be fine with just the latest version. Reload Database means re-read all the config files for all the parts, like the game does at load-time. It allows modders to edit a MM file (or a part) and reload it without having to quit the game. Dump Database, I -think- means write out the modded config files, after MM has patched them. Generally you won't need either of those functions unless you're developing your own mods.
  16. Well, the last entry in your log is related to Procedural Farings, and you're running the 64 bit client, so... it is probably nothing to do with MechJeb, and it is probably just that 64bit does that from time to time.
  17. You are very welcome. Thank you sir, for these amazing mods, for both your coding and cat-herding skills!
  18. *mutter mutter learn Git mutter install GitHub mutter fork mutter pull mutter mutter* Certainly, just sent you two - one each for MKS/OKS and Karbonite, since both need it. At least, I -think- I've juse sent two pull requests.... if you recieve three overripe melons and a golf ball, it means that I got my GitFu wrong, so just point, laugh, and let me know
  19. Without logs, difficult to say for sure.... Most likely two options are 1) you're running out of memory. 2) you're running 64 bit. The first can happen any time that you install another addon, that just happens to push you over the limit. The second can happen any time. Period. I know that some people are reporting that x64 is usable for them, but there are many others (myself included) who see random crashes in random places at random times, with different apparent causes in the logs each time, that essentially boil down to "x64 isn't quite stable on Windows yet". If you can post your output_log, we'll have a better chance to determine the cause.
  20. Sorry, but you're missing a British joke, there. In the UK, the rail system is famously bad at keeping to time, with many many trains delayed or cancelled, and one of the most famous excuses ever given on the station PA systems is that the train was late beacuse of "the wrong kind of leaves on the line". We've also had "the wrong kind of snow", "cows on the line". I was once on a train, stationary, half way between stations, when the conductor came on the PA and asked "Is there a driver on board?".
  21. For people having issues with the unreadable textures, you need to have a file similar to the following, anywhere in GameData, as a .cfg file I call mine ATM_USI.cfg and leave it in UmbraSpaceIndustries\ ACTIVE_TEXTURE_MANAGER_CONFIG { folder = UmbraSpaceIndustries enabled = true OVERRIDES { UmbraSpaceIndustries/Karbonite/ORS/.* { make_not_readable = false mipmaps = false compress = true scale = 1 max_size = 0 } UmbraSpaceIndustries/MKS/ORS/.* { make_not_readable = false mipmaps = false compress = true scale = 1 max_size = 0 } } } It sets a appropriate set of options for handling the maps (readable from main memory, no mipmaps, full resolution). Works for me, your delta-v may vary @RoverDude, it might be worth adding this to the Karbonite and MKS/OKS zips? ------ Well, given that Karbonite only works with 0.24.2, and that B9 doesn't work (properly) with 0.24.2, then the answer is that there is nothing in Karbonite that will conflict with B9 in any way, you you will have to apply some fixes to B9 to get it to operate in a game version that supports Karbonite.
  22. Easy - MKS/OKS ships with KolonyTools.dll, so just adding a :NEEDS[KolonyTools] to the MM blocks for those edits will mean they only apply for people who have MKS/OKS installed. Loving the work you're doing here.... really appreciate that you've saved me from having to script it all up myself!
  23. Are you using TextureReplacer? Edit: Actually, I was thinking of ATM. By default, ATM loads all textures into graphics memory, and not into normal memory, to save space.... I would very strongly suspect that is the cause of the error message that you are seeing, whether or not it is the cause of your map failing. Edit 2: If that is the cause, you could try adding the following two files ... pretty much anywhere should work ATM_MKS.cfg ACTIVE_TEXTURE_MANAGER_CONFIG { folder = UmbraSpaceIndustries/MKS/ORS enabled = true make_not_readable = false mipmaps = false scale = 1 max_size = 0 } ATM_Karbonite.cfg ACTIVE_TEXTURE_MANAGER_CONFIG { folder = UmbraSpaceIndustries/Karbonite/ORS enabled = true make_not_readable = false mipmaps = false scale = 1 max_size = 0 } I'm at work, so I can't test, but let me know Edit 3: After a little more looking, I think the correct syntax for the file would be ATM_USI.cfg ACTIVE_TEXTURE_MANAGER_CONFIG { folder = UmbraSpaceIndustries enabled = true OVERRIDES { UmbraSpaceIndustries/Karbonite/ORS/.* { make_not_readable = false mipmaps = false compress = true scale = 1 max_size = 0 } UmbraSpaceIndustries/MKS/ORS/.* { make_not_readable = false mipmaps = false compress = true scale = 1 max_size = 0 } } }
×
×
  • Create New...