Jump to content

BGog42

Members
  • Posts

    53
  • Joined

  • Last visited

Reputation

15 Good

Profile Information

  • About me
    Rocketry Enthusiast

Recent Profile Visitors

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

  1. Well I used a warp drive and it still took over 9000 delta v to match speed with it once I arrived. It is non-trivial.
  2. Thanks for this. It was really fun. I won't be able to play for the next week. Since I only had a couple of hours I put together a "interstellar mod" ship with a warp drive. Flew out there and then burned like 9000 dV to match velocities and bring it into an intercept. I put a claw and a docking port on it. Alas, not the correct one. So now I'm going to see if I can attach the claw to the center and bring it home to kerbin.
  3. Thanks Creat, I'll take a look at your patch. The reason there is code for handling "every lcd-screen" is because I test by plugging in a G19, G510 and a G18 at the same time and making sure they all work. Most users will have just one screen.
  4. No idea why you are seeing jitter, I don't get any. Yes the call was in Update but it was limited to doing lcd draws only 5 times per second or so. I've been planning to move it to either fixed update or a coroutine with a yield waitforseconds. Thats great that you coded it up. I'll take a look at your pull request and get it in. But note that it was not doing LCD ops every frame but only checking the delta time and returning.
  5. I've updated the mod for 0.24. Unfortunately the dll used to access the keyboard screens is 32-bit only. So for now the mod will only work for 32bit KSP. This is sad and I will work on an alternative solution which will also work for 64bit. This update also fixes the framerate issue reported by Creat. There was a bug introduced in 1.2.1 that caused the mod to drop the framerate of ksp in all screens except flight. This has been fixed and GHud should have little to no impact on KSP performance now. Note, I've also submitted GHud to Curse and it is awaiting moderator approval.
  6. Thanks to the efforts of MattZZ, I've release version 1.2.1 of GHud! I can't upload to "Curse" as it just says "Page not found" when I click the upload link. So you can get it via the link on the first post of this thread. Not sure I care for this 'Curse' business but we'll see how it goes.
  7. Are you replacing the joint? If so this feels like the original joint is still in place. As you move the original resits and torque is created. If you replace the joint, how are you destroying it. When you call "Destroy" on a GameObject, unit just flags it for removal. If won't go away immediatly. In addition if there is still a reference to that old joint, it will stick around until the reference is gone. I'd make sure you fully detach the old joint before destroying it.
  8. I followed the instructions. Launched monodevelop with monodevelop.bat and ksp with the debug script. The debugger attaches and catches uncaught exceptions etc. However it is all disassembly and doesn't relate at all to the .cs files. I can set breakpoints but they become a hollow icon and do not work. Any clues as to what I may be missing?
  9. Hey sirkut, I dug into to code a bit as well and thought I'd share my results as my approach may have differed from yours. I went down the road of modifying the existing joint rather than creating a replacement. (did you find a way to replace it? seems to be read-only). I was able to get a basic hinge working properly and rotating from correct origin. But only if it was attached in-line. Joint.anchor and Joint.connectedAnchor both required modification as follows: attachJoint..SetBreakingForces(breakingForce, breakingTorque); ..... mod all the assignments to use attachJoint.Joint. .... attachJoint.Joint.anchor = attachJoint.Joint.anchor + (-attachJoint.Joint.connectedAnchor); attachJoint.Joint.connectedAnchor = Vector3.zero; However when attached radially, this falls apart and the direction of rotation is completely off. I suspect I ran into the same roadblock as you did on this front. My working theory (correct me if I am wrong) is that all of the IR code is expecting a joint that is normalized to the orientation of the parent part as occured in the past when a new joint was created. So when the new joint was created, it's local transform was remained zero relative to the new parent. However when I modify the existing joint into an IR joint, the transform remains as is. The issue here is you can't just zero out the transform of the existing joint because the attached parts will transform as well. What I'm planning to try tonight is to clear the joint transform and then apply the negative of that transform to the attached parts (hopefully returning them to where they belong. Thoughts? BTW if you care to share your findings, I'd be happy to help but I understand if your too busy working on it to do a brain dump. Good luck.
  10. Delta-v calc in editor, readouts mostly. However when I'm doing big assembly projects that take a couple dozen launches, I'll use the auto pilot after the first couple because it get so tedious to launch and rendezvous so many times in a row.
  11. I did some testing of the "GHud" mod and verified it working throughout launch and around 4 planets. You can put it in the likely working column.
  12. greenfun2 and thebeardo I've updated the logitech software and am not having any problems. When you say it is crashing, do you mean the logitech software or KSP? If its KSP can you send me the KSP.txt file from your ksp dir after a crash? Unfortunately I don't have a G13. I have a G19 and a G510 but the G510 and the G13 have the same screen so it should work fine as others have reported. I use the "Arial" font. If that font is unavailable, then it falls back to some aweful default which may be what you are seeing. Did anything remove or replace the default Arial font from your system?
×
×
  • Create New...