• Content Count

  • Joined

  • Last visited

Community Reputation

41 Excellent

About jamis

  • Rank
    Spacecraft Engineer
  1. Thank you! Clearing the input locks allowed me to regain control of the craft and the interface. I still haven't figured out what triggers this condition, but at least clearing the input locks gives me a workaround. - Jamis
  2. This happens to me as well. I haven't yet figured out how to reliably duplicate it, but it happens often enough to be frustrating. The only way out is to "cmd-Q" and restart the game. Some notes: I've only noticed it happening when I have the orbital info active. That could be a red herring, though, since I have that mode open far more often than the others. The F* keys works as usual (I can hide UI, show mission stats, etc). Other keys have no effect (including escape, z, x, shift, control, wasd, t, etc.). The other tabs for the flight modes (the ones that let you switch between staging view, orbital info, view, etc.) are darkened and disabled; clicking them has no effect. The game continues to play -- engines continue to burn, craft continue on their preexisting trajectories, etc. -- but no input is recognized. I've attached a screenshot from the latest incident. I was in the middle of maneuvering the rocket, pressing the usual keys (WASD, shift, control, arrow keys), but I don't recall if there was a particular combination of keys that caused it. You can see the tabs in the lower left are darkened. You can see that the probe has a network connection and ought to be controllable. The electricity resource is not pictured (because the UI at this point was unresponsive) but the probe had plenty of electricity. If/when it happens again I'll try to post more information to help diagnose. This is really getting frustrating. Thank you! - Jamis Edit: this is in KSP 1.7.1, on macos 10.14.5, on a 2015-era 15" MacBook Pro with retina display.
  3. In the interest of saving others some headache, I relate the following. I recently tested the warp drive out successfully on a smaller ship, and then--confident that I could make it work like I wanted--built a warp "tug" and docked a bunch of things to it, and sent it to Eeloo. The mission was a wild success, but when I tried to bring it home, the ship would explode upon entering Kerbin's SOI at warp. I tried auto-strutting all the things, I tried undocking bits I could (just barely!) live without, but all to no avail. I could not seem to enter Kerbin's SOI (at warp) without the ship exploding. Almost by chance, I tried entering the SOI obliquely, barely intersecting the sphere, almost at a tangent, and it worked just fine. So, if anyone out there ever encounters this situation, perhaps try entering the SOI at a tangent?
  4. I apologize if this has been addressed before. I looked through much of this thread but didn't see anything that seemed relevant. For any world with atmosphere, I'm seeing the following visual glitch when within some distance from the surface: Again, this happens with Kerbin, Eve, Laythe, Jool, and Duna. Anything with atmosphere. I'm on a Mac (last year's 15" MacBook Pro), using these CKAN-installed mods: I will try paring away mods to see what fixes it, if necessary, but I wanted to see if anyone else has seen this, and if there might be an obvious fix for it. Thank you! I love what I've seen so far with SVE, but that atmosphere glitch is a real kill-joy. :/
  5. I don't have any plans, myself, to update this anymore. It's trivial enough that I wonder if it could be done now as a simple ModuleManager patch -- it just adds the "MechJebCore" module to the "kerbalEVA" part.
  6. Thanks for the suggestion! I'll give that some more thought. I'd considered trying rotations but got stymied trying to figure out the order of operations, there. Time to do some more tinkering, I guess.
  7. I've seen this question asked in a few other contexts, but either they weren't ever answered, or the answers weren't helpful in my case. Regardless, here's hoping someone knows the answer, here! I'm trying my hand at modding, and I figured I'd pick something simple and science-fiction-ish -- a teleportation mod! OP, sure, but it's mostly just for learning the ropes anyway. The idea is this. You send up a ship with this part on it. You dock it to another ship with the same kind of part, and then "entangle" the two. (You know, like quantum entangling...? Yeah.) Then you fly one of the two ships to some other (presumably distant) location and forget about it. The good part: you fly another ship to the nearest of the two nodes and dock. Then you say "teleport", and voila! The ship magically appears in the vicinity of the corresponding entangled part. I've got it mostly working... You dock two nodes, entangle them, etc. Even the teleport works---you can send a ship to within 30 m of the twinned vessel. THE PROBLEM: I want the ship to appear "in front" of the target node, aligned with it (but not necessarily docked with it). However, everything I've tried keeps putting the vessel off in some other direction. The magic occurs on lines 49-68 of the following file: https://gist.github.com/jamis/35a48a80bce87f349ae6#file-moduleteleportationnode-cs-L49-L68 . The facing that gets computed on line 57 is local to the part (or something), but I can't seem to figure out how to convert it to worldspace. Help? Thanks!
  8. Apologies if this gets asked a lot, but I've not found any good answers to this. I'm trying to assemble the Apollo components, and I've managed to figure out the CSM, and the LEM, but I can't figure out how to put them together. There was one video, but it used an unreleased version of the mod, which wasn't very helpful. I've looked through this thread (well, much of it) and searched elsewhere, but to no avail. Can someone point me to a writeup of how these two components are supposed to be linked up? Even better, if there's a writeup of how to assemble the entire thing, that'd be great. I feel like I'm missing something obvious. :/
  9. I've got some sad news, all. If I'm going to be completely honest with myself, and with you, I have to admit that I really don't have the time right now to maintain this. I'm going to have to walk away from it for awhile, I'm afraid. This means it will rapidly lose its usefulness, unless there is someone that wants to step up and start maintaining it. I'll warn you--it's not easy to maintain. This is because it is flawed. I could write at length about the fundamental problems here, like how some mods are distributed as RAR files, and some as zip files. Or how everyone seems to have a different way of hosting their mods (dropbox? mediafire? self-hosting? spaceport? something else entirely, potentially impossible to automate?) Or like how some mods archive their own subdirectory structure, while others bundle their GameData contents, and yet others start their distribution at the KSP root directory. Or how there is no way, currently, for mod authors to specify their dependencies in an easily-automatable way. Or how SpacePort doesn't let you download older versions of mods, which means the entire modding universe needs to upgrade in lock-step with every other mod. Like I said. I won't go into it at length. Suffice to say that what the community really needs is to address these more fundamental issues first. Trying to build a mod installer without that infrastructure means that the installer must do like my bundler did and encode all that logic in the manifest files. This results in a lot (A LOT) of work for whoever maintains the manifest files, because things change constantly, and with no prior notice. Breakage is the normal way of things, because it is impossible for one maintainer to constantly be testing every permutation of mod combinations as things get updated. Anyway, if someone really wants to take over maintenance of the bundler, please feel free to fork the GitHub project and go for it, with my blessing (and condolences ). For now, though, I'm going to update the initial post in this thread to indicate the true status of the project, so that people don't expect it to work anymore. It's been a great run, and it was a good proof of concept. I'd love to see someone (or some group) take the next step and spearhead some standards! Cheers, Jamis
  10. My apologies. I fell off the face of the planet again, didn't I? Things are crazy, and this might be the new normal for a while, for me. I've updated the manifest, but as I haven't had a chance to test any of the updates...it might be just as broken now as it was before. Please post issues you discover and I'll try to address them as quickly as I can. (For example, I just saw NathanKell's last post here and realized that I probably need to update the manifest to include RealEngines now... I'll see about getting that added this afternoon, if at all possible.)
  11. All: my sincere apologies for letting the manifest file languish. I was out of town, and then changing jobs, and things have been patently crazy. I'm still trying to get my feet under me, but I'm making progress. I've updated the manifest files with the latest versions (as of this morning). Note that many mods are still in some state of flux because of 0.23.5 (in particular, MechJeb is known to not work very well, and you actually need to download one of the dev builds for now), so things will probably be changing rapidly for a while yet. I'll try and stay on top of things better!
  12. Phenom Anon X wrote a great post about getting Java set up on your machine. You might want to give it a read, and see if it helps you: http://forum.kerbalspaceprogram.com/threads/67668-Mod-bundler-for-Real-Solar-System-%282014-03-25%29?p=977803&viewfull=1#post977803
  13. @OtherBarry, yup, you're right. :/ As a workaround, you can download the manifest separately, and then, from the command-line, specify the path to the manifest as an argument to the script, e.g.: real-solar-system.bat c:\path\to\real-solar-system.manifest You'll want to redownload the manifest periodically, to get the latest version.
  14. That's...really odd. Can you try creating a folder named "tmp", at c:\tmp, and then see if it works any better?
  15. Hey all, sorry for the silence. I've just posted an update (version 20140325) which hopefully will fix the "OpenSSL::SSL::SSLError (handshake alert: unrecognized_name)" error that some of you reported. Also, this new version will hopefully give a better error message when Java is not installed, which ought to help with troubleshooting.