Jump to content

AccidentalDisassembly

Members
  • Posts

    1,167
  • Joined

  • Last visited

Reputation

281 Excellent

3 Followers

Profile Information

  • About me
    Assistant to the Regional Rocket Scientist

Recent Profile Visitors

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

  1. Huh... well, in that case, then just allowing for setting up the auto-trim for level-ness and the total ballast to neutral, then keeping things that way (not disabling on keypress) should probably be enough, then, I imagine...? Easier! Hooray.
  2. Very cool! A couple suggestions, if you're open to them: Both Maintain Current Depth and Auto-Trim are switched off if the player presses any keys (i.e. WASD) - however, sometimes you want to help the system out (get your ship to level itself faster?), or make an adjustment, or deviate for a time from your depth for some other reason (avoid hypothetical obstalces - do those even exist underwater?) without having to re-set the system after. It would be great to allow user inputs (and allow for accidental key presses too) without disabling the systems, which would then try to return to depth X / attitude Y after the user is done doing whatever it is they wanted to do. Would be handy to be able to set the depth (numerically) to maintain as well Adding a button to maintain neutral buoyancy (adapting to depth as the player zooms around underwater) would be a really cool feature, allowing the user to effectively point themselves in a direction and apply thrust to go where they want - especially for zippy little crafts. I imagine this would combine features of auto-trim and dive control - the sum of all ballast required to keep the ship neutrally buoyant at Depth X is distributed in ballast tanks such that the craft would, if stationary, have a level posture without roll (à la auto-trim), or something like that... Then you can flip your craft around, roll, dive, climb, etc. at will, and while the total ballast changes to keep you neutrally buoyant, the ratios in the tanks stay the same so that you don't have pitch/roll forces on the craft other than the ones you apply (I think). I dunno, could be really neat.
  3. Unfortunately there appears to be an issue with spawning Kerbals for contracts - when you accept a contract to retrieve Kerbal X, that kerbal appears in the roster and what appears to be a copy of that kerbal (same name) also appears on the map/in the flight scene. It is possible to load your target kerbal in your craft before taking off as a result. Perhaps there's a way to make only one of them?
  4. With the prerelease installed, I am noticing an issue with science: after installing the prerelease, when a kerbal goes on EVA from a rover while around the KSC, the EVA-ing Kerbal will be able to run a whole heap of experiments (plant life, something related to big and small icebergs, object analysis...). The experiment text on some experiments mention 'cells in the "tree" are similar to ones on Kerbin' and the body Blalo, so I assume this behavior is caused by something in how GU is setting up experiments, and I haven't noticed this behavior before. Anyone else notice this in a career game w/ the prerelease GU? Also, just a suggestion - it would be nice to decouple GU scatterer/EVE visuals, specifically for the stock system only, from the rest of the package and make it optional - if (for instance) you are using OPM alongside GU, packages like AVP have configs ready-made for OPM planets while GU does not. It's certainly possible to go pull out only the OPM planets stuff from AVP, but it would make more sense just to allow the user to install something like AVP (or whatever other stock visual pack) and GU, with GU stock visuals being an option if the user wants to go that route. EDIT AGAIN: I do notice, however, that it appears you can just delete the _stock folders in the GU EVE/Scatterer folders; maybe that's the easiest option?
  5. Some MM errors on the newest version (hopefully) of OPT Reconfig - relevant portion is here, I think:
  6. It's conceivable (but I don't know for sure) that any issues with Pood's OPM VO could cause general problems with scatterer/eve - might affect GU's stuff as well. Just one possibility among many. I am not the best diagnostician, to start with, and it's also pretty hard to say much without a log file (which I only know how to read in the crudest possible way). Others will be more knowledgable, hopefully.
  7. Couple things: The __LOCAL folder is almost certainly in there by mistake - possibly (from what I have been able to glean) an artifact of people making mods on Mac or Linux, zipping up a folder, and not looking for hidden folders getting ZIPped with others, or something like that. You don't have the latest version of Module Manager - almost certainly no significant effect from that, but worth updating nevertheless. Some other folders look suspect, or not, hard to know - For instance, what' s "Patch"? Poods OPM Visual Overhaul may or may not be up to date with latest versions of scatterer/EVE, can't remember on that one.
  8. A general set of guidelines that might help, no promises: 1. Many mods require other mods to function, or are themselves split into multiple parts. For instance, GU requires Kopernicus, which is composed of two parts: Kopernicus itself, and ModularFlightIntegrator; Kopernicus and everything else that uses Kopernicus also requires ModuleManager. Always check for mods' dependencies. Sometimes these are noted clearly on a mod's main forum post, sometimes they're not - you may have to do some looking and definitely need to do some careful reading, possibly even most of the time. In the case of GU, you'll need to read the "How to install" section on the first post of this thread. HOWEVER, the link to Kopernicus included in that description is incorrect - instead, go here and download the version of Kopernicus for 1.11 (it's the ZIP with 1.11 in the name): https://github.com/kopernicus/kopernicus/releases 2. Most mods, but not all, are packaged in such a way that they try to show you how to organize folders by the way they are organized in the .zip file you download. For instance: when you download GU, you get a ZIP file with a series of folders inside it. Always open the folders and look around for a moment - you're looking for a GameData subfolder (if it exists). If it does exist, then the mod intends for you to put the folders *inside that GameData folder* into KSP's GameData folder. If no GameData folder exists inside the .zip file, then the mod probably intends for you to put whatever folder(s) you see in the .zip (without digging) into KSP's GameData folder. Because mods are all made by different folks with different ways of thinking, the folder structures inside ZIPs aren't always the same. Sometimes, you have to make educated guesses as to what's intended. 3. The inside of your KSP GameData folder should look like this if you've installed GU correctly, *with its dependencies* - of course, you might have other folders in there too, but at least these should be there along with whatever else you've got going on. (Note: ModuleManager is also required for just about every other mod out there, and it will generate some files that will appear in GameData after you run the game with it installed.) Pic here: 4. Some parts of some mods are optional, such as the 'visuals' and Parts bits of GU. You can choose whether you want those or not. If you do, they may have additional dependencies. 5. The general logic of mods is thus: They're going to give you a .zip, and inside that zip will be one or more folder(s) intended to go into <KSP Directory Here>/GameData. Make sure the mod has any other mods it needs in order to function, and look around inside the .zip file to see if there's any obvious hints as to which folders are supposed to be the ones that go in GameData.
  9. Just now had a chance to look at the issue I was having again - it may or may not be related to Recall, but it seems to involve Extraplanetary Launchpands too. Removing Recall and trying it again will allow adding fuel lines on new craft, but not on the old one that used to have Refunding. This was happening when the fuel line was added: Seems like perhaps an interaction between Recall and EPL, because on previous iterations of this save, I was using EPL just fine - behavior changed with installing Recall --.7.7, *I think* (low confidence). Or the aftereffects of some other interaction, or... I really don't know at this point, I can still sometimes reproduce it after removing Refunding stuff, so... Ugh.
  10. Having an issue I think is related to Recall/Refunding (see log here: https://www.dropbox.com/s/3e4odf1dtmaunko/KSPLog_Refunding.log?dl=0) In editor, I can't put external fuel ducts between parts - connect the fuel duct on one end, and it won't then connect on the other. just picks up the part again. I don't know if it's related to Refunding, but when looking in the logs, I saw a number of errors that is (I think) equal to the number of parts in this save... Passing along the log in case it's useful, whether or not that's actually related to my editor issue.
  11. Based on issues with TweakScale (caveat: I don't really understand what's going on), it is *possible* that this recovery issue is a bug with KSP itself. Just a thought, but only based on vague dot-connecting (there's an issue with recovering parts with TweakScaled parts as well, it seems; might be somehow related...).
  12. Took the new version for a spin! Noticed some slightly odd behavior with some exceptions in the log as well. KSP 1.11.2, not too many mods (dev-ish install). I think (hope) it's installed correctly w/ Kopernicus and whatnot. In Kerbin's deserts, this happens - the vehicle looks visually like it's going over terrain that is more undulating and uneven than appears in the image; when it's going "up" some invisible terrain, it rises up as shown: Log with exceptions: https://www.dropbox.com/s/ganwdxhi67loxp9/KSPLog_parallax_exc.log?dl=0 The exceptions didn't seem to correspond to any particular behavior, but.. well, there they are.
  13. Sadly figured out I was simply misundestanding you AFTER hitting reply. Ugh.
  14. I mean to say: after changing settings, you need to restart to generate the patch file, which seems to be generated after parts load. (Maybe?) Then restart *again* to have the patches applied by MM - two restarts in total. That's what the dialog boxes suggested needed to happen, at any rate... EDIT: I am dense. You are saying what I am saying.
×
×
  • Create New...