Camacan

I found MakeItSmaller to be a terrific tool for investigating and fixing this problem. When a UI element is scaled up and down there are obviously a few sizes where the font scaling works and many where it doesn't. When it doesn't all kinds of jaggies and haloing occur as the anti-aliasing doesn't put "grey" pixels at the edges of letters to smooth them off or fails to put any full-color pixel on a line and tries to build a letter stem out of grey pixels. And you can rescale different UI elements independently, repeatedly, and without exiting the game to the main menu for each change. To me it looks like some elements such staging and the resource tab were scaled below what their text element supports while other such as the nav ball were increased in size, but not enough to get to the next point size. 1.1 looks like this for me: (Sensations of eyeball vibration are probably Illusory.) Resized via MakeItSmaller (All) (actual text is much crisper: imgur seems to compress everything.) EDIT: MakeItSmaller's All option affect menu text size, which also has a problem. I've been scalling All up and then scaling some individual elements back down. EDIT EDIT: Hmm both stock and MakeItSmaller "All" UI scaling trigger a known significant bug: ships/planets move off their orbit lines, Ap, Pe markers too. Maybe the "All" part of the workaround is not so hot.

I suspect the contract system works best for new players. Having an array of goals laid out in challenge order seems highly useful for climbing the "difficulty wall". But I'm not a new player and I find contracts become grindy fast. Doing stuff for the means of doing what I want to do doesn't appeal. Some contracts are informative and I like that: the ones for specialised orbits were educational, but they are not something I'd repeat. The rescue contracts have a bit of drama to them: the poor pilot waiting in the chilly wreck, deep in the clutches of Jool's gravity. Then there is a garbled voice on the radio, a flare of light as the pitch black approaching rescue craft lights all eight nuclear engines in a crash stop ending eighty meters away. I think I'd benefit from turning the rewards from contracts way up so I don't have to worry about them that often. And I think the system would benefit from a greater diversity. Not that it is easy. KSP has great depth, but not that many basic mechanics.

Thanks for all the hard work on the migration. I expect there are lots of behind-the-scenes improvements, such as security, that we are now enjoying. From a user (avid lurker, mostly) point of view the new system does seem to be a big step back in terms of visuals. Rather than just whine I thought I'd present the things that worked so well in the old system: It would be great if these features could be reintroduced.

It does. I really did not expect that to be an option! I (blindly) assumed it would always show. Well -- checking options goes on the list of things to check before reporting a bug. I wonder if other folks might also get bit by this one -- perhaps it should default to "show"? Thanks for your help.

Two nodes exist. PreciseNode-1.1.3.png: a row of four buttons appears between the title bar and the time. Left arrow, Node 1, Del and Right arrow. PreciseNode-1.2.0: no buttons appear between the title bar and the time. Edited to add: I now notice that two nodes are not needed -- the missing UI as described above is apparent with a single node.

When I create multiple maneuver nodes, PreciseNode 1.2.0 only shows the first node. I reverted to PreciseNode 1.1.3 and I get the UI elements for editing the other nodes. If there is info I can provide to help I would be happy get it. (MechJeb2-2.5.4.0-521 maneuver node editor picks up both nodes FWIW.)

The edge of Jool's atmosphere has moved out to ~200km from 138.2 km. I wonder if some folks are going to find ships currently harvesting resources at the old edge are going to find their ships in a "surprise reentry" situation? In passing, the new atmosphere limits and the new aero model means the online aerobraking calculator at http://alterbaron.github.io/ksp_aerocalc/ is currently out date. My tip is to those who are working with ships designed under 0.9 and now trying to do aerocapture around Jool. Expect the thermal issues to be significant; without heat shields only grazing encounters with the atmosphere are survivable. It seems that that first encounter can yield an orbit, but expect a long orbital period on the first pass. I found the number of passes needed to achieve a low orbit to be higher than I had patience for. I ended up using the cheat to ignore heat limits. I think that's a good option for those wanting to stay with 0.9-style aerobraking gameplay. (I'm very thankful for that addition: means I can finish up with my 0.9 ships before moving on to new 1.0 designs.) Elliptical orbits are still doable with unshielded ships, possibly even in one or two passes depending on the ship and target orbit.

Both radial and mirror symmetry are useful in both the VAB and SPH. Switching between them is just a matter of hitting the 'r' key. Perhaps symmetry inheritance is causing you grief: if a parent part got attached with radial symmetry by accident, new child parts will also start in radial, no matter what mode you set the editor to before attaching them. It's a matter of finding out what mode the parent part is in and swapping it to mirror.

Does this action only have an effect on some engines? I can see an LV-N kicking of off its left or right shroud in response to a jettison action, but none of the others seem to do anything. (Wow, kicking off one shroud of a pair, now that's specialized. )

In my experiments I was using the IR control panel arrow to spin the rotors and it was quite unwieldy. But then I remembered that IR actions mapped to action groups are applied differently: it toggles on or off. Much better. (There's an audio bug related to that functionality: the sound will sometimes continue after the servo is toggled off if an action group is used.) Being able to change servo speeds using keys would be useful in other nonrotor servo-y contexts. Perhaps two keys that could be mapped to double/halve the speed of any active servos, even if .cfg setting was the only way to do it. I'm an IR noob, but a rotor seems more like an engine part to me than a servo. A rotor needs fast continuous movement and is ideally under the control of the throttle.

Galane: I suspect the phenomena that you are seeing are a result of KSPs aerodynamics being quirky rather than realistic. Neither lift not drag works in intuitive ways. Perhaps things will improve with the coming overhaul. I wonder if docking washers are a good choice to power rotors, in terms of what they were originally designed for. (Gotta be better than this monstrosity though!)You might be interested in this helicopter design competition. And this crazy coaxial helicopter design.

That would be terrific. (Just to clarify -- that first bug report up in #5011 isn't Tweakscale related.)

I'm reading a lot about folks having trouble with Tweakscale. Naively, it seems like IR would be well served by having its own bare-bones rescaling support built in; just enough to change the size of its own components. Both to get away from the bugs and avoid an inter-mod dependency which never seems optimal from a mod management point of view. But it is easy to suggest someone else does more work. My install of KSP has been uncrashable for months but I'm getting crash bugs every 40 minutes or so since I installed IR/Tweakscale -- but only when I revert to assembly. I've been trying to work out if it is IR or Tweakscale, but so far it's just not reproducible. And it's a "silent" crash -- no dialogue saying a crash log has been generated. Is there a way to identify which mod crashed / get more info?

Hi. I've been having fun making fancy rovers with your excellent mod, thanks for all your work on it. I have a bug report. KSP Version: 0.90.0.705 (WindowsPlayer) Steam BETA Mods installed: Infernal Robotics Parts Pack - v0.19. TweakScale - v1.50. Problem: The attachment point of GantryLargeScaleable moves after a quicksave/restore from quicksave. Reproduction steps: Create a simple craft with a GantryLargeScaleable. Launch ship and move pad to one end of the track. Quicksave f5. Restore f9. The GantryLargeScaleable track has moved a large distance with respect to its parent Log: Before the quicksave. After: waaaay off to the left. Makes for amazing bunny hops if the rail is now in the ground. Log Files bug_report.txt before_quicksave.png after_quicksave_restore.png IR_quicksave_bugtest_1.craft quicksave.sfs.before_quicksave quicksave.sfs.after_quicksave_restore quicksave_diff.txt output_log.txt I figured the quicksave.sfs would help tell us what is going on. Certainly there are differences. The relevant section of the diff appears to be this one (?) PART { name = GantryLargeScaleable cid = 4294202464 uid = 4236401740 mid = 3706330563 launchID = 5 parent = 1 9398,9399c9398,9399 < position = -1.20888352394104,-1.89850175380707,5.18722970355157E-07 < rotation = 0.5000014,-0.499999,0.5000011,0.4999986 --- > position = -1.20889353752136,-1.90301132202148,4.00000333786011 > rotation = 0.5000005,-0.4999996,0.5000007,0.4999993 9415c9415 < And: 9486c9486 < translation = 0 --- > translation = -4 9654c9654 The different translation figures make sense, but my guess is something is up with that third figure of position. Oddly, if I restore the position to the "before" values I get this: Now the pad's back in the center -- not where it is meant to be on the left, and the track is still out of position, but not as much. If I set both the position and translation back to "before" values the problem is gone, which agrees with the fact that I don't see the problem if the pad is centered. It's as if the position of the track is taken using the pad as the base coordinates and so needs to be adjusted as the pad moves to keep it still -- but something has gone wrong during quicksave? Just a guess. Thanks again. (Workaround Recenter all gantry rails before quicksaving. It also seems to fix the problem after it occurs: recenter, quicksave, restore.) (Edit to add: tried removing Tweakscale so IR is the only mod installed. Bug remains.)

I thought it would be nice to have a fuel tanker rover that could land and re-orbit. I came up with the idea of putting the wheels on Infernal Robotics gantry rails. That way they can be symmetric in flight. Once we've landed, the wheels can be lowered into place. But therein lay a problem: what we've got is an STOL rover. Sideways takeoff and landing. I got inspiration from watching the rocket tilt when I moved the wheels. With an addition of a wheeled boom: The tilt can be controlled into a steady decent. Ready to roll! Arrival: docked with my Karbonite pilot plant to pick up fuel. The Karbonite mod is great fun. Version 2 on approach: boom on either side for more controlled and less terrifying tilting. The first version needed the main engine's help to get the tilt past the balance point. How KSP is that? Rockets solve everything! V2. also has much better landing gear: less breakable on a hard landing. The legs are set on pistons, so they can present a broad landing base, then retract to allow driving without plowing up the Mun. It's servo-licous!

I took a luxury-weight spaceplane to Laythe. The launcher was this monster: Those cabin lights sure look cozy compared to what's outside the front porch. Aerobraking at Laythe. Coming into land. Those struts at the back are the most important part: Jeb sez a floppy plane is a deadly plane. I coulda made better use of those nice new spaceplane parts: this is a bit old shool. Lakeside landing. After hundreds of hours and many unplanned high speed ground reunions, I have now touched down on every planet and moon. Into the sunset, and back to orbit. The mothership awaits to carry us home.

Hi, This excellent mod is not working for me in 24.2.559. The supplied ModuleManager.2.1.5.dll causes the game to hang. The most recent ModuleManager.2.3.3 solves the hang but the mod does not work in game. There is a note above stating MM is not needed, so I tried removing it: the mod still does not work for me (I also get this error in the log in that last case: [LOG 15:45:47.987] AddonLoader: Instantiating addon 'DockingPortAlignment' from assembly 'DockingPortAlignment' [EXC 15:45:48.087] NullReferenceException: Object reference not set to an instance of an object)

I intercepted an incoming asteroid with a very low periapsis. Hmm, four minutes to rendezvous and lock on before entering the atmosphere. We're on! Now I assume this asteroid will areobrake but get back to orbit. I mean it has Kerbin exit velocity. Or not. Maybe we should be leaving soon. There was supposed to be an earth-shattering kaboom! We're both still intact. Chance to sample an asteroid in the desert biome.

* Instability in a rocket-powered lander may be caused by fuel imbalance. A fuel imbalance can be caused by a missing fuel line. The editor occasionally drops/cuts fuel lines, typically when the line is close to being occluded. So I would suggest you check the fuel lines before final launch, especially on interplanetary missions. Even small changes from a tested design may trigger this problem. * With aircraft, consider the "wing count". Ideally this number should be even. I'm less certain about this one, but anyway: * An aircraft with landing gear set evenly around the centre of mass handles rough landings relatively well. But such an arrangement can't rotate on to allow takeoff in the first place. One hamfisted but effective solution is to fit a pair of tiny thrusters to the nose and use them very briefly while at takeoff speed.

A couple of techy things I learned recently: Keeping obsolete versions of plugins within the game folder can cause problems. I thought the game only looked in GameData. Not so: I had some older plugins in a folder called "plugins" at the top level; they got used before the ones in GameData. Much head-scratching ensued. Plugin load failures with System.TypeLoadException errors in KSP.log If a plugin throws a System.TypeLoadException error in KSP.log, it might mean it was built targeting the wrong .NET framework version. Apparently KSP's Unity works on 2.0. The default for MonoDevelop is 4.0. The version is set in Project->$SOLUTION_NAME Options->General->Build.

I have the solution. It was a mismatch between the .NET framework version I was building to and the one Unity works on. Apparently Unity is 2.0 while the default for my MonoDevelop is 4.0 Man that's a gotcha: a System.TypeLoadException error doesn't suggest anything like that! So I can confirm PreciseNode can be built from the supplied source using MonoDevelop. Thank you.

Hi, Thank you for this wonderful plugin. I wouldn't be able to burn nearly as conveniently or intelligently without it. I was hoping to have a play with the internals. When I naively dump the 0.9 source into a MonoDevelop solution and link against Assembly-CSharp.dll UnityEngine.dll I can build PreciseNode.dll, but when I try overwriting the real dll and run the game: KSP.log: System.TypeLoadException: Could not load type 'RegexKSP.CompatibilityChecker' from assembly 'PreciseNode, Version=0.0.5140.39137, Culture=neutral, PublicKeyToken=null'. All the other symbols fail to load, too. Yet they are sitting there happily (apparently in the right namespace) when I compare the assemblies in dotPeek. Could you offer some build instructions?