Tyko

I've had the same problem you had since 1.3. Every time I've tried CKAN I've had the "doesn't show in the toolbar" problem. It seems to work better if you download from Github and manually install. Not sure how you were installing, just sharing what's worked for me.

It probably needs to be recompiled to work in 1.5.x. You can see there's been activity on Github, so it's actively being worked. I'm sure @RoverDude will release it when he's done updating.

Thanks! Yea it works fine. I updated SpaceDock just forgot to update the headline for this post. I'll fix that.

You'll need to set up your craft's orbit to intersect with the asteroid's path and make sure the two craft arrive at that point in space at the same time. Are you familiar with how to perform rendezvous maneuvers? If you've already learned how to rendezvous two craft in orbit this is very much the same thing.

You might want to try two very simple craft - just docking ports and bare minimum necessary to navigate and dock - see if those work okay. Then you'll at least know it's not your modded install that's causing the problems You can use F12 to rendezvous them so you don't even need to build a launcher

Yep UBM still works fine. The biggest issue is that Missing History parts aren't covered. There's a supplemental release by @theonegalen in which he adds MH support. You still need the original mod

Yea, I've been playing with it and didn't run into noticeable problems. I used CKAN and set CKAN to include 1.4.x compatible mods. Then I just told it to install the 1.4.x version of GPP and let CKAN pick my dependencies. This is risky with such a complicated mod, but it appeared to work for me. That said - remember this is an unsupported setup, so I'd avoid bugging our fantastic modders for help if you run into issues. If you run into probs I can try to help via PM to avoid clogging up this thread. I'm not an expert though, so can only share what I've tried.

Weh hoo!! thanks much

I'm using the unofficial release for 1.5 and it seems to be working fine. I haven't done a ton of stress testing, but during normal launches it seems to work well.

I just installed this last night and it worked. I'd suggest using CKAN for it because its dependency is for a specific version of Sigma Dimensions (0.9.8) and seems to have problems with the latest SD version. To install using CKAN you can go into the settings menu and select compatibility options - tell it to include 1.3 and 1.4 compatible apps. Install SSRSS and SD, then turn that compatibility back off so you don't accidentally download other old mods. here's the link for SD 0.9.8 if you want to install manually: https://github.com/Sigma88/Sigma-Dimensions/releases/tag/v0.9.8

Cool, hope that helps. I made the same mistake many times and had lots of broken stations til someone finally told me about those issues.

Are you using Autostruts? I've seen this exact thing happen when I used them. If you are, try turning them all off on both craft. A second possibility is the clipped RCS thrusters. If you clip parts around a docking port the invisible colliders from clipped parts can cause problems.

BlueDog Design Bureau has a nice selection of cameras: a low tech film camera that must be returned, a mid tech that sends some science back but has to be returned for full science and a digital high tech camera that can transmit 100%

That wasn't an accusation. It's helpful to sometimes clean up errors. When I scanned it I missed it

You claimed ISP was "extremely wonky" when it wasn't - I see you edited your post on that. I believe I'd heard that they handled atmospheric effects on rocket engines differently early on, but that was changed before I started playing when 1.0 released - so a few years ago.

Ouch, those issues are a pain to track down. Do you need to go through the mods you're using one at a time and look for which ones include TS patches? TS itself seems pretty benign in that it applies scaling to discrete parts. I know there are "tweakscale everything" patches out there, but don't know of any mods that have a global patch like that.

....but ISP DOES vary with altitude - technically it's the atmospheric pressure, but that's tied to altitude. Also, "imperfect" /= "low fidelity". It gets a lot right, more than most simulations that aren't designed for industrial or research applications. The atmosphere is challenging. The OP would have higher "fidelity" if they stuck to a rocket and skipped the plane portion. either way it's an effective demonstration of many of the concepts even if it's not accurate enough for NASA.

What about using PatchManager from @linuxgurugamer ? It gives an in-game interface which allows players to choose amongst optional patches.

I've played around with ReScale and Sigma Dimensions in 1.5.1 without any major issues*. I've only used 2.5x and 3.2x, but both seem to work right. There may be some minor graphical issues. I'd suggest installing ReScale 10x and SD but before actually starting your game cheat a small probe into low orbits around various planetary bodies and make sure everything looks right. Check a variety of body sizes from small moons to Jool. This will take a bit of extra time, but better than getting your first probe to Jool only to find out it's visually whacked *NOTE that this applies to the Stock solar system. You may get very different results with any planet packs.

Then again, NASA tends to be launching into an inclined orbit, don't they? If you're doing that, lining up the orbital plane as best you can matters more than a direct intercept... Inclination changes cost a lot of DeltaV. The shuttle could only perform a few degrees of inclination change with all of its on-board fuel. Essentially they had to get the inclination right at launch. All of the orbits were to give them time to precisely rendezvous. The shuttle entered a number of lower phasing orbits, each one getting it closer to the station's orbit. Gemini attempted direct rendezvous a number of times. Gemini 11 actually pulled it off. Here's some great info from this Rendezvous and Docking guide Going through a phase When you launch, the odds are slim that your target vehicle, such as the ISS, will be in exactly the correct spot in its orbit for you to go right up and dock with it. Most likely, it will be too far ahead or behind. Thus, you could launch into the correct orbital plane and directly to the correct altitude, and discover your target is on the other side of the earth. Mission planners could postpone the mission until a day when the target is in the perfect spot at the exact launch time, but a much better solution is to allow the chaser spacecraft to phase, or catch up to, the target spacecraft after launch. A basic tenent of orbital mechanics dictates that the higher the orbit, the slower the orbital speed, whether it’s a satellite around the earth or a planet around the sun. It’s why a martian year is longer than an earth year. Thus, the target vehicle will be moving slower than a spacecraft at a lower altitude. The greater the difference in altitude, the greater the difference in speed. The lower, faster spacecraft thus catches up to the higher, slower one at a rate that depends on the heights, or energy, of their respective orbits. It’s often not practical to raise the target vehicle to a higher altitude, nor can a chaser spacecraft safely orbit lower than about 100 nautical miles (185 km) altitude because of our atmosphere. Therefore, the chaser altitude range of 100 nm up to the target’s altitude defines the range of “catch-up rates” for chasing and rendezvousing with the target. (Note: You could launch the chaser into a higher, slower orbit and let the target vehicle catch up to it and then rendezvous from above, but this is a waste of energy and therefore, of propellant, payload, and money.) So when you get into orbit, the target will be some fraction of an orbit ahead of you, possibly close to 360°. This distance is called the phase angle. The lower the initial, or phasing, orbit, the faster the catch-up rate and the less time it takes to complete the phasing. Now we add in the human element. In the “good old days” of Gemini, the spacecraft was so simple that the crew could transition from launch to rendezvous almost immediately upon reaching orbit, and the rendezvous could be completed very quickly. (Gemini 11 achieved rendezvous on the first orbit!)

It's pretty easy once you get the hang of it and doesn't require any autopilot. The only mod I'd suggest would be one of the maneuver node mods that give you better control - Precise Maneuver or Precise Node. Here's how I do it: Make sure your station is well above minimum orbital altitude. For this example let's use 175km as a good altitude for stations. from Map mode time warp until your station a bit past the KSC. You want to launch so that you end up about 1/8 orbit behind the station when you circularize. You may have to try a few times to get the timing right, but once you've figured it out you can do it over and over. If you come up behind the station you might have to wait an orbit or two. If you come up AHEAD of the station that's when you might have to wait days. Launch into a lower orbit. For our example, launch into a 125km orbit. Circularize at 125km Set the station as Target Drop a manuever node in front of your ship. Raise the AP to the altitude of your station Drag the maneuver node forward around your orbit until you get an intercept. Depending on how far behind the station you may have to drag it around a full orbit or more. That's okay, the game knows you're an orbit ahead even if you drag past your ship's current position Fine tune your maneuver to get as close as possible. Execute the burn when you hit your maneuver node. Hope this helps. I do it all the time. If you have any questions let me know. EDIT: Keep in mind that NASA/Roscosmos with all their computers and flight engineers don't attempt to launch to rendezvous. Even the fastest flight plan involves the craft orbiting the earth several times while lining up a rendezvous.

Arguably we are all involuntary beta testers already. Many of the issues with 1.4.x were noted by the community within the first week or so. If they'd done a 2 week beta they would have had this info in advance and the broader player community would have gotten a more finished 1.4.0. With 1.5.0 squad launched with the aero issue. That was caught within 24 hours by the community. If there'd been a 2 week beta period players would never have even had to deal with it in the first place. go back and read the launch announcement thread and look at all the complaints that could have been avoided. The whole point of this is just like any other beta - to give the game a bit of soak time with a broader audience. It's just an added benefit that modders could start looking "under the hood" ahead of time. It would give them a head start in knowing if just recompile was likely necessary or if they were looking at more work.

There's still the problem of having to sit at your computer the whole time. Even Warp to Here doesn't pause the game when you get to the designated point. If you have a 4 hour wait before your next maneuver - which is pretty common for orbital activities - you could very well have to wait up to 4 hours, and with up to a half dozen other people playing you really have no reliable way of knowing if it's going to be a 4 hour wait or a couple minutes at higher warp. Since the game doesn't pause once you get to your point you have to be at the controls ready to act.

Thanks! Are you still considering adding 1.875 and some other interstitial sizes (.3125, .9375, 1.875, 3.125)? I've written and tested all the code already. Obviously you'd want to do more testing, but I've at least gotten you part way.

@theonegalen I've been maintaining my own version of UBM for over a while now with my own tweaks to it. While a lot of the core is still Yemo's work I'm at least partway to having something original and I'm familiar with the syntax. If you wanted to take a serious shot at rebuilding this I'd volunteer to help. We might be able to section it off and tackle it in segments. PM me if you want to talk a bit