Bobe

Let's be realistic here. Well, as realistic as KSP warrants. A lander is typically designed to put one or more Kerbals in a stationary position on the surface. They can then perform EVAs in the immediate area, taking surface samples and setting up experiments. In fact, the latter is something I think we are missing. A rover, specifically an unmanned rover, is designed to explore a wide area of the surface, taking samples from many different locations. It could also perform experiments using on-board parts. You could say that a manned rover allows the same thing, but for now let's just keep them separate. Let's also assume that the role of a lander mission is to set up stationary experiments, take surface samples and then return the samples where they can be analyzed. We would also assume that the role of a rover is to act as a mobile experiment platform, taking surface samples at multiple locations, perform an analysis of the samples and transmit the data back to Kerbin. Think about it in real world scenarios, it's much cheaper and safer to design, build and send a small rover to a planet than it is to send an actual crew. Apply that to career mode, or what might become of it, and it makes sense that rovers be used as a means for more efficient and cost-effective science gathering missions. Then, once you have researched a bit more and gained more money, then you can plan a manned mission to generate even more science.

A couple suggestions, sorry if they've been mentioned before: In the maneuver planner, list all maneuver nodes with their T- time, estimated burn time and ÃŽâ€v, as well as total ÃŽâ€v for all nodes. In the landing guidance module, add the ability to specify distance from target. I realize I could plant a flag where I want the craft to land, but sometimes it's just a pain to send a manned mission.

After having spent years learning from harsh experiences with Skyrim mods, I have become very careful about mod use in general. I carefully inspect each mod I am interested in, determining things like version compatibility, general stability, conflicts with other mods and assess the benefits against the possible risk. So I only have a few essential plugins and part packs that don't overlap in terms of functionality. I also strip down some packs when I know I won't use certain parts, or if another pack has better equivalent parts. For example, I use KW Rocketry, an absolute must, but there are a few pieces in NovaPunch I like, specifically the control wheels and bulkheads, but that pack also comes with hundreds of other parts including fuel tanks and engines. Since Rocketry is perfect for the latter, I can happily delete almost all of NovaPunch and save literally hundreds of megabytes of files it has to load. Of course more memory can help, to a point, but being smart about using mods is possibly more important.

Sorry, I meant a decoupler below the LOX but which attaches to the bottom of the LH2 with a 3.75m interstage adapter, so that you can create a stage configuration like this:

The model looks great so far. Just a couple things though: How is a 2.5m engine with a flat "base" going to fit on the curved LOX tank? Will the attachment point essentially be at the base of the straight cylindrical part? Also, if you placed a 3.75m stack separator below a 2.5m engine, it would create a 2.5m interstage separator. I think NovaPunch has 3.75m interstage sections, but they're not very reliable. I don't know if it's something you can control or if the game handles it, but could you make 3.75m stack separators attach to the LH2 tank?

I would like this very much. It may seem like a small thing, but I find myself more often than not wanting to place a different part on just one side of a quad symmetry arrangement. Being the stubborn perfectionist that I am, I just can't deal with placing the other three parts separately.

Looks more like a B-52 with that massive wingspan, but certainly better than my attempt to make a jumbo.

In FSX, being a casual player, I use my mouse in lieu of a joystick, which I often feel more comfortable with, even if it is all wrong. I would very much like to be able to press a keyboard button to toggle mouse flight control rather than use the WASDQE keys which make flying rigid and unnatural. Using the mouse would allow smooth, fine-grained adjustment of the control surfaces rather than having to continuously tap the key and flap yourself to level flight. I suppose it might also be used for rockets and various other vehicles, but it would be intended for planes.

I would love to have a great big billowing plumes of exhaust shoot out the side of the launch platform on ignition, but from my experience particle effects have always been one thing that have plagued games over the decades. If you want full volumetric smoke/dust/fire, which looks much nicer, it puts a massive strain on the GPU, and if you use camera-oriented 2D sprites, they perform better but they just don't look that good. I suppose there could be an option in the settings to choose between the two, like in Microsoft Flight Simulator, but that may just require even more development resources.

Naturally I would place radial thruster blocks if the craft was bigger, for example if I was building an Apollo CSM replica: However, once the command module separates from the service module, it needs a way to orient itself for re-entry. Using flywheels for this purpose just doesn't seem right. That's why I said some of the command pods. In fact, when I said "particularly the Mk1 and Mk1-2 pods", I should have said "only", since it is just these manned pods that should, in my opinion, be using RCS instead of flywheels.

That's what I was talking about. All they'd need to do is change the model and texture to reflect something like this:

Right, I thought they did have monopropellant, but I wasn't in the game at the time and the wiki is still out of date, so I got confused.

This may be detracting from the spirit of KSP, but doesn't it just make sense to include RCS thrusters as part of some of the command pods, particularly the Mk1 and Mk1-2* pods? If you assume the Mk1 and Mk1-2 pods as analogs for the Mercury capsule and Apollo CM respectively, they would have several pairs of thrusters for orientation but not translation. Of course, KSP isn't exactly meant to be emulating technology from the '60s, but even the Orion MPCV uses RCS for orientation rather than flywheels, as far as I know. I don't actually know if any crew modules use flywheels. It shouldn't be too hard to add them in, they only need to be small holes. The Mk1-2 pod even has various holes in it already, for whatever purpose. This may be frowned upon though because it would mean the pod by itself would only be able to maneuver using a limited amount of built-in monopropellant, so more casual players might find it annoying. Translation or extended thrust time would be provided by external parts. In summary, I think the reaction wheels should be removed from some command pods and instead include RCS thrusters and monopropellant. *Why isn't it just called the Mk2 Command Pod?

I agree. Ghosting works better than differently shaped pips. For now Enhanced NavBall is great, but it'd be nice if it were added into the stock game. I'm sure they have much higher priorities right now.

This is exactly what I've been trying to advocate against. It is very bad practice to implement hard dependencies on third party plugins. What if, dare I say, Toolbar gets abandoned? Sure, someone else might pick it up, but hypothetically a future KSP update may break it and then all the mods that depend on it are broken. Toolbar support should always be optional. If the user installs Toolbar, they get the nice grouped buttons, but if they opt not to, they still get the old window.

You're confusing my inclination markers with the ascending/descending nodes. The markers are simply nodes that can be dragged to set your desired orbit. When changing your inclination, you would [ideally] set a maneuver node at either the ascending or descending node, then you would drag one of the two inclination markers that appear on either side of it as illustrated in the diagram. It is exactly the same as setting a maneuver node in the current system and dragging on the normal/anti-normal axes, except that this compensates for the change in eccentricity. The current periapsis, apoapsis, ascending node and descending node would remain in their original positions on your current orbit just as they do with the current system.

Ha, I had never even seen the launcher until now, Steam just launches the game directly. Even though I have seen Launcher.exe in the game folder many times, I just sort of ignored it. But anyway, the borderless window option is unchecked. Do I perhaps need to run in AMD compatibility mode since I'm using an AMD GPU? EDIT: Scratch that. It's just to do with Phenom CPUs.

I think it is for the sake of those people that I feel it should be kept separate. Like I said before, they may copy it over and unknowingly overwrite a newer version, which may cause some things to break. You can't assume every developer will always have the latest version included. I don't think any mod uses Toolbar as a strict dependency. In other words, if you used any mod that came with Toolbar in the download package and didn't install Toolbar, they would still work completely fine, just without a convenient button group. If that isn't the case, I strongly believe it should be. I don't want to seem like I'm getting aggressively overenthusiastic about such a minor thing, it's just in my nature to ensure things are as logical as possible.

I am running fullscreen (double checked) and I also get the same red texture issue. Not using KMM or anything. Interestingly though, even before I installed the ENB, I was getting some weird red grain glitch while using Romfarer's Lazor Docking Cam. Not sure if they might be related issues. Even though you say to disable AA and AF, which I know is typical for ENBs, doing so only reduced the game's visual fidelity to that of a slice of moldy bread. I was using the SweetFX version with HQ settings, and I did restart to see if that was needed to apply changes. I turned AA and AF back to full and everything looked nice again, except that it strangely wasn't being applied to certain parts of some ships.

Didn't see your post before I made mine. I'm having the same issue. As per Roxette's suggestion, I removed every single other mod, created a new save game and the issue persisted. What sort of hardware are you using? I have an Intel i5-2500k and a Radeon 6970 2GB (driver v13.251).

Is the red grain on the docking cam normal? I'm using the standalone version.

I figured the filename format from the existing ones, but I was a bit braindead and didn't restart the game. Nothke's icons do look very nice. Seems he's around but hasn't officially released them.

As do I, but it just seems pointless nonetheless.

What do I need to do to be able to use newly created icons, as well as specify active and inactive versions? I'm working on making a couple but I want to test them first.

Maybe there should be some indication in the VAB that a docking port is facing the wrong way, or simply prevent it from being placed that way (unless some people do it on purpose for some reason). Only really applies to the Sr. port though, but could be extended for add-on inline ports I suppose.