Bobe

It doesn't look like you've set the other vessel's port as your target, unless that indicator goes away in docking view. Never mind that. It was my initial thought that one port wasn't oriented properly, but my inspection was too lazy I suppose.

Maybe this will help you understand: In both cases, regardless of where the mouse goes, the P/A and I markers only move up or down (in an arc in the case of the I markers obviously) relative to the camera angle. If the angle were different, they would still only move along those axes, but the direction would be different relative to the camera. I'm sure you know what I mean. I don't see an issue with multiple maneuvers. Once you have one set, you would be able to create a maneuver on that projected orbit and do the same thing. Sorry, I did forget to mention that you would be able to drag the maneuver node along your current orbital path like normal, except that would be the only action on the node itself. To get an encounter, you would just grab the P/A, drag it to the target's orbital path and then drag the MN along the path. Alternatively, maybe you would be able to hold Alt and drag the P/A marker which would allow you to adjust the MN position at the same time as the periapsis/apoapsis position. Of course, this system might not be best for all cases, so it would make sense to be able to switch between the two systems. This system prevents exactly that. The current system, as you know, is vector-based, meaning your projected orbit is determined by individual changes in prograde/retrograde, radial in/out and normal/anti-normal. So for example if you increased your normal vector, your periapsis/apoapsis would be affected since the game is only concerned about adjusting your inclination and doesn't compensate for anything else. This system would be projection-based, meaning you set what you want your orbit to change to and the game does some simple MechJeb-esque magic to determine in what direction to burn and for how long.

What I may have failed to convey by saying certain vectors are restricted is that the markers would only move in one direction/dimension. For example, the P/A marker would only move towards or away from the the center of the orbit, it would remain in the same plane and on the same axis. Similarly, when dragging the I markers, they would only move along one axis on the same plane (ie. it would just tilt the orbital path). In other words, even if you move your mouse around wildly, the point will still remain in a sensible location with the other parameters of the orbit unchanged.

The current maneuver interface is fairly decent, it gets the job done. However, at times it becomes a bit fiddly and often frustrating. So instead of having to drag on the axes around the node, why not be able to click and drag on points on the orbital path? For example, if you want to increase your apoapsis, select the maneuver node point as usual and then click and drag the apoapsis marker and drag it to the desired location. The same information you get when you hover over a marker would be displayed as you drag it. What I envision is that when you create a maneuver node (MN), three markers are added to your craft's current orbit; a P/A (periapsis/apoapsis) marker on the opposite side of the MN and two I (inclination) markers on the two perpendicular sides of the orbit between the MN and P/A marker. Dragging the P/A marker lets you set the desired periapsis or apopasis, which would be determined automatically based on whether the point was further or closer than the current apoapsis or periapsis. This action would only affect prograde or retrograde vectors. To change radial vectors, you would perhaps hold shift and drag the P/A marker, which similarly would restrict prograde and retrograde changes. Finally, to alter inclination, simply drag either of the two I markers, which also would restrict prograde, retrograde and radial vectors. Finally finally (reminded by Kahusa), the MN itself would be able to be dragged along the orbital path like normal. Possibly you could hold Alt while dragging the P/A marker to adjust the MN position at the same time as the periapsis/apoapsis position. I think from a usability standpoint this would be a much better system and it allows the user to choose where they want to go and let the game determine the necessary burn parameters rather than the other way around. Some of you may see this as "easy mode", and perhaps you should be able to choose which system you want to use, but to me it just seems like the more logical approach. After all, when planning real life missions (although they are infinitely more complex than KSP), they know where and when they need to be and then work out how they need to get there, they don't just enter values and see where it gets them. I hope all of that made sense, and if it doesn't I'll see if I can't mock up something to illustrate it.

Was going to make this suggestion, so let me just bump this thread. Especially with mods like RasterPropMonitor that encourage missions controlled entirely from IVA view, a camera shake (or rather head shake) effect would be great. I think there should be two types of shake; acceleration and vibration. They should be self-explanatory, but acceleration shake would occur when the vehicle accelerates in a certain direction and the camera would "move" in the opposite direction. For example, if you accelerate forward, the camera would slowly (or quickly) move backward to simulate the effect of the acceleration on the Kerbal. Similarly for lateral acceleration. Vibration shake would occur during events like launch and re-entry and would obviously just violently shake the camera around. Maybe a bit less intense than real life though, because from watching videos and hearing the experiences of astronauts, that level of shake might be a bit too extreme. Obviously there would be an option to disable it.

I've started using Titanium Studio at work for a new project, but conveniently the guy who usually does app development is away on holiday. I've run into some early issues and I was wondering if anyone here had some experience and could answer some questions. Or perhaps you can just take a look at this Stack Overflow question: http://stackoverflow.com/questions/21035592/titanium-studio-official-tutorial-issues-and-tss-syntax

Wow, you're right. Had no idea. I don't think the same is true for solar panels because the wheels simply enter a damaged state whereas the panels just shatter and fly away. So it would still be useful in that case.

I don't like the idea of having to add parts for basic functionality. Things need to be simplified and consolidated as much as possible. The view would be optional anyway.

Very nice mod so far, but if I may, and I hate to be "that guy", could you please capitalize the action labels in the right click menus (eg. "inflate", "rotate", etc)? As a perfectionist, it just irritates me somewhat.

Would it be possible to develop some sort of repair system? While taking a look at the containers and the various parts that can be stored inside, I thought about all the times I carelessly broke a part like a rover tire by landing too hard to a solar panel because my Kerbal got too excited on his EVA. I would love to be able to do an EVA to retrieve the spare part from a container and place it on the broken attachment point. Of course this is assuming the broken part leaves some sort of damaged form or attachment point that can be interacted with, and obviously the replacement part has to be exactly the same as the broken part.

The wonderful Toolbar add-on seems to be growing in popularity and many developers are working to integrate Toolbar support for their own add-ons. However, I've noticed quite a few add-ons are bundling Toolbar in the download package. While for some, maybe most, this might be a convenience, it might cause issues or maybe just a minor annoyance for others. Obviously if the user didn't already have Toolbar, great, two for the price of one. However, what if they had previously downloaded an add-on that included a more recent version of Toolbar and they overwrote it? Most people are probably smart enough to see the Toolbar folder in the GameData folder and either ignore it or check their existing version, but doesn't it make more sense to not package it with the add-on and just leave Toolbar support optional by including a link to it on the add-on page?

I would love that too. The IVA views in the current stock pods like the Mk2 don't really have great angles for that. If we could translate the camera perspective as well as pan it would work much better.

Fair point. It probably makes more sense to keep it as a view that can be selected or cycled to, but not included in the auto group.

Most of you are probably scrambling to grab a link to Romfarer's Lazor Docking Cam, but hear me out first. I'm not looking for an inset window to provide alignment information, I use Docking Port Alignment Indicator for that. However, I suppose mostly for aesthetics, I would like to have a docking view in addition to auto, free, orbital and chase. This view would only become available when the ship has a docking port obviously and if the view is set to auto then when controlling from the port and another port is set as target, the camera would switch to docking view, showing the perspective from the port. Alternatively, it might only be available in the docking view as opposed to the staging view (I'm not sure if those two are considered different views or just different sets of controls within the same view). Again, this would likely be a low priority aesthetic enhancement.

Don't know how I missed that. Thank you for proving my ignorance.

Well that's what I thought initially, but I know that launching to rendezvous does not match the target's plane, so I thought perhaps he was referring to the inclination setting. If using launch to rendezvous, you still have to set the inclination manually, which isn't that big a hassle, but the guidance led the rocket into an a orbit with an inclination of about 20-30 degrees to the target's orbit. Obviously this still creates intersect points, but being at such an angle, rendezvousing is difficult and you waste a lot of fuel matching the planes once in orbit.

I know you can set the inclination manually, but that requires that you also manually warp until the target's plane intersects KSC, or just before. I would like MJ to handle that automatically.

I would definitely like to be able to set a decoupler's ejection force to 0. The force specified on the part would just be a maximum.

Could you add an option in the ascent guidance module to launch when the target's orbit intersects the equator? This would make rendezvousing with a ship on an inclined orbit much easier. It doesn't have to wait for the target to be in a position to rendezvous with, just as long as the two ships end up on the same plane.

I suppose I should learn to start using them. I'll see if my experiences with auto symmetry dissolve after a while.

This is a very simple suggestion; I would like the ability to toggle automatic part symmetry. Very often I might place a part with quad symmetry and then go to place a part with double symmetry, only to have it "intelligently" switch to quad when I hover over one of the previous parts, forcing me to go back and set double symmetry and then carefully guide the part between the previous parts to prevent it switching again. This get frustrating very quickly when making particularly complex builds.

I'm not sure why these options aren't already tweakables, but they're causing me some irritation. For instance, I often create payloads that have their own command unit and reaction wheel(s) which are then encased in procedural fairings from KW Rocketry. I always put a larger reaction wheel on the rocket instead of using the payload's reaction wheel to improve the rocket's steering and stability. If I leave the payload's reaction wheels on, they work against each other during launch and flexes the ship to pieces, so I have to manually go and disable torque on all of them and it's often annoying trying to guess where the parts are by clicking through the fairing walls. Similarly, because the payload may not always point in the same direction as the rocket, I use a remote guidance unit below the payload fairing which I have to manually set "control from here" each time I launch. This isn't really a big issue, but it becomes an issue in the VAB when you delete a set of parts that include your first part. Even if you have other control units, it completely invalidates your build until you add another one. We should have the option to set which part is node 0, or have it automatically fall back to another one if it exists. For now, I've had to handle the reaction wheels issue by setting the torque toggle of all the wheels as an action group, but it seems silly not to just have the option to disable them normally, and it's a waste of an action group.

I think there's a big gap between the Gigantor and the other 1x6 and 2x3 panels that should be filled with a medium size extendable array. It would be similar in design to the Gigantor, but roughly two thirds the size as shown below: You might recognize that it is very similar in scale to the SpaceX Dragon. That was not my intention, but it just worked out that way. However, I feel it would better suit medium size space vehicles. There could perhaps even be a smaller variant, one third the size of the Gigantor, though that would be fairly similar to the 2x3 panel, just oriented length-ways. It might even be practical to make it a packed unit like the SP-L and SP-W that would fit snugly on modules like the Storage Container as shown above.

I would like it as well. I don't actually know what kind of information Protractor adds, but I would like to see a 360 degree protractor around the body you are orbiting, or focusing on, with the ability to set 0° as the body's prograde, retrograde or your craft. There would then be a button to toggle orbit information, which would display various angles in the orbit view, such as inclination, argument of periapsis and the angles between your craft and the body's prograde and retrograde. When creating maneuvers, it would show lines indicating the body's prograde, retrograde and rotational axis, and display the angles to these axes relative to the maneuver node.

In that case it still seems to make sense, because I just launched to a distance of 20 km (28 km threshold) and is now performing the correction burns instead of the phasing burns. However, I have noticed occasions where it still did the phasing burns inside that threshold, but I'll just chalk that up to MJ's slight bugginess.